-
Notifications
You must be signed in to change notification settings - Fork 0
Observations Running a Grid
There is little actual documentation on running a grid. Here I share some of my own findings that may be useful to you.
Almost all issues pertain to the hypergrid functionality. I always joke to my friends "that's another thing the hypergrid ruins" and it's true, you just can't have a feature complete, secure, and creator friendly grid when turning on Hypergrid in OpenSim. The downside of disabling HG is that you'd need a huge promotional campaign, making exclusive arrangements with creators and landscapers, to attract a decent amount of users and creators which InWorldz and Avination did really well. Not something for shy people like me :)
GridUserService and PresenceService where not happy about being multi-instance (presence0.ini presence1.ini etc) due to caches being out of sync. I made the cache an option, so you can disable it if you run multiple instances behind a proxy. That will do away with errors like 'avatar already present' when TP back to the homegrid. If you run just one GridUserService and PresenceService cache can be enabled.
Groups V2 also has a cache, I have yet to look into that. So far groups works fine in our fork, much better than upstream.
Maybe due to config error on my side, but whenever I run FriendsService and HGFriendsService in its own robust instance, I don't get the 2nd confirmation bluebox (to add the hypergrid friend) when I return home, after I befriended someone on a foreign grid. This means the friendship will essentially not be established. I found out that running these services within the same instance as the Gatekeeper resolves this issue.
When unfriending a HG friend, they will still have you in their list. Teleport first to their grid, and while there unfriend them.
When changing username, your HG friends will still see/know you by your old name. This is because you are stored as friend on the other grid's GridUser database by Firstname.Lastname @example.com:8002 instead of user uuid (and grid). You will both need to unfriend, and then re-friend to make your name reflect your current name in their friendlist.
Another reason why a foreign user may see you as your old name, is when the sim they are on, has your old name cached. OpenSim does a stupid amount of caching in various places, to offload grid services. My guess is a foreign sim's UserAccountCache knows you (your name) by whatever prim/object it found last in the sim, if it is made by your user UUID. As long as no stuff made by your old HG name is rezzed on their sim, they could try typing reset user cache in their sim console. This will temporary (so don't worry) make some HG creator names on objects in their sim turn into just their creators UUIDs (no name) until the cache is filled again (could take a few hours to a few days).
For further info see the upstream wiki about Name Binding
Groups are for land management, however many people like to use them for other things as well. Think of event notices and new product announcements, or chatting with like-minded people on specific interests.
It seems notices from groups on foreign grids that use Groups V2 works, however intergrid chat doesn't. If you where offline, you'll receive notices too. It doesn't work with groups you joined on foreign grids that use the old Groups V1 (like OsGrid).
It is impossible to eject hypergrid members from a group. Eventually you'll have many members from dead/closed grids, that can only be removed with database queries.
To unjoin a foreign group, first teleport to their grid (for instance their welcome region), and only then leave the group. Otherwise you are still in the group on their groupserver and keep receiving notices.
The gatekeeper needs to have an A-record in DNS. Dyndns providers already take care of that, but if you have your own domain example.com, and your gatekeeper is hg.example.com, then hg.example.com needs an A-record too. Thus, if both example.com and hg.example.com run on the same server, you'll need two A-records (one for each, both pointing to your server IP). If you do not set this up, you get the dreaded 'cannot verify identity' when hypergridding.
I've had problems logging into my grid after commit 81cfd6e so I had to revert that commit. This is possibly because my loginservice is behind nginx (to have secure SSL logins). Any help with this would be welcome so I can re-apply that commit.
- HG2.0 is the most secure, and the most limited. Many grids use this. When on a foreign grid, you can only rez or attach anything from the suitcase folder. #RLV is inaccessible.
- HG1.5 is less but still secure. I found a bug (or possibly deliberate?) that when your grid is HG1.5, you can only buy and not take copy when on foreign grids. When taking a copy, and rezzing the item at your homegrid, you get the dreaded 'asset not found'. The #RLV folder works however.
- HG1.0 is the least secure, but the most flexible. If you're going to use this, I recommend moving valuable assets out of your inventory, and boxing them up on a private region. #RLV, take copy and buy works. To my surprise, even Kitely Market deliveries work.
A hypergrid landmark will stop working if the foreign destination region moved to a different location on that grids' worldmap. I usually put the HG address (example.com:8002:Regionname) in the parcel name, so when people make a landmark they'll still have the address in the landmark name.
Var regions are multiples of 256 meter wide. The only reason for making a large region like that, is where you need much space with not much objects.
OpenSim isn't very smart about sending objects to the viewer. It sends all objects in the sim, whatever the database returns first without any consideration of where the avatar is located. That means a tree on the other side of the sim will load first, and the very chair right in front of you might load last. The bigger the region is, the more random and slow this experience feels to the visitor.
There is no object occlusion in OpenSim. If you land in a big hollow box, then most objects outside the box will be loaded first, until maybe at some point stuff inside the box will load too.
Changing your draw distance doesn't help, and staged loading (an option in the viewer) neither. Second Life is just much smarter about this.
Therefore my advice, stick to 256x256 regions. Make sure that your primary area of interest is within 128 meter of the landing point, as most people have a draw distance of 128 meter or less. Especially now with PBR, people set their DD lower because PBR viewers tax their computers' performance much harder.
In the early days of web development, I'm talking 1998 here, there was a key rule to follow: if your site isn't loaded after 20 seconds, the visitor will have lost interest. Apply this same rule to your regions, taking into account the amount of assets used and the region size. A fast upstream bandwidth (1 gigabit) is essential to this, as well as keeping the number of simulators within ratio: 1 cpu core with 2GB ram PER SIM, with just 1 (one) region per sim.
This is exactly why most grids fail to deliver and sell you an underpowered sim for a few bucks per month. For a 500 sim grid, they would need 125 quadcore servers or 63 octacore servers (and being paid for, hardware, bandwidth, electricity!). The sad reality is that it's probably one single old laptop/desktop or cheap VPS running over a hundred sims at once.
You can bypass the slow warp3d maptile generation entirely, by re-using an earlier generated maptile. Here's how:
(note that it's OK to start without having a maptile PNG file, in that case it shows water until you generate one)
In OpenSim.ini:
[Map]
MapImageModule = "Warp3DImageModule"
GenerateMaptiles = false
RenderMeshes = true
;Don't render skyboxes:
RenderMaxHeight = 512
;Don't render NPCs as dots:
ShowNPCs = false
In Regions/myregion.ini:
[My Region]
RegionUUID = 2d4e3a69-e612-41e2-89f9-6435070c5a60
Location = 10000,10000
InternalAddress = 0.0.0.0
InternalPort = 9000
AllowAlternatePorts = False
ExternalHostName = SYSTEMIP
MaxPrims = 20000
MaxAgents = 40
RegionType = "Standard Region"
MaptileStaticFile = "MAP-2d4e3a69-e612-41e2-89f9-6435070c5a60.png"
Take notice how MaptileStaticFile uses the RegionUUID in its name! You only have to generate a maptile manually once, or whenever you want it updated after changing stuff on the region. This can be done on the region console with the command:
generate map tile
If you are already logged in, you may not see the newly generated maptile reflected on the worldmap until you relog your viewer.
There is an issue in OpenSim where if you return from a hypergrid trip, the maptile (both worldmap and minimap) shows the maptile of the region on the previous grid at this region's map location, or if no region exists on these map coordinates in the previous grid, a water void. I don't understand yet why this is happening or how to work around this. In my memory, Singularity Viewer didn't have this issue, yet when i recently fired it up again it exhibited the same problem as Firestorm and other viewers.
- Owners of breedables can modify them to not need food or need less food
- Owners of breedables can modify them to only produce rare coat offspring
- Owners of weapons can modify them to inflict more damage
- Owners of shields can modify them to receive less or no damage
- Grid and sim owners can give their own grid/sim an unfair advantage in the game by modifying the scripts
- Owners of a vendor can modify them so they receive a 100% cut with 0% going to the creator.
- Owners of a vendor can unpack and use the content from the vendor without paying for it
- Owners can modify the perms to enable copy+transfer, and then distribute them to whoever. Essentially rendering the item worthless.
- Scripts can't use modern features, because they have to be compatible with old/outdated OpenSim versions
- XEngine, a dated and low performing script engine is still widely seen and differs in critical ways from modern YEngine (such as the order of evaluating mathematic calculations)
- Stuff like llGiveInventory doesn't work to hypergrid receivers unless they have visited the local grid at least once. And then still a hack is needed to make it work (osAvatarName2Key)
- BulletSim is still used a lot, almost always on sims that have counterfeit stuff rezzed (because copybots can't copy physics hulls which are needed on modern physics engines such as ubODE)
- All game logic must happen on a remote webserver in the case of intergrid/intersim games, client scripts (such as attachments) must be just dumb clients since they can be godmoded
- If the competition is limited to happen within one sim, the game logic could be put in a server object written in lsl. But client scripts should still be dumb clients
- Having all logic server side introduces network lag (llHttpRequest) or sim lag (communications via listeners). Any action or scoring needs to be verified by the server before it is final, introducing considerable overhead.
- Though attachments are fixed for hypergridders landing on OpenSim/lickx sims, upstream and other forks are still broken when visiting their sims. Attachments and HUDs will cease function when landing there, and most likely will total reset at some point losing all variable state.
- All linkset data, introduced in 0.9.3, are totally lost in attachments when teleporting wearing them to sims running older OpenSim versions
- These are never accessible by hypergrid visitors
- Due to obsessive hypergrid caching, a changed user name doesn't propagate to hypergrid sims and friends that already know you by your old name. See above on this page
- Scripts can't use or refer to assets that don't exist on the local grid