lotek/opensim
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
Page: Observations Running a Grid
Pages
Adult and PIOF checking Compiling Economy Home Hypergrid Teleport Inter‐object email with llEmail() New .ini options Observations Running a Grid Scripting Unimplemented Why NOT enable hypergrid
Clone
1
Observations Running a Grid
Lotek edited this page 2026-02-28 10:56:49 +01:00
Table of Contents

There is little actual documentation on running a grid. Here I share some of my own findings that may be useful to you.

Know what adventure you are embarking onto, and know your job! Grids don't provide events, shops with goods, and nice destinations; It's your residents who do. If you don't have a profound interest (either professionally or as a hobby) in computer science, networks and intellectual property laws; then running a grid is not for you, and you may be better of renting virtual land on an already well-established grid.

Almost all issues below 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.

OpenSim only has acceptable security in a non-HG configuration. Not even a 'trusted' hypergrid is sufficient, because a trojan/rogue 'trusted' grid (that will join it's just a matter of time) could exploit content from all the other grids in the trusted hypergrid collective.

The downside of disabling HG is that you start with nothing, and have to attract initial creators (for products) and landscapers (for places) to get something going. For that you first need a good social network of talented (and willing) people.

On death and continuance

I've been busy with OpenSim since 2010 and I've seen a number of grids fold just because the only person who knows how to operate it died. Maybe the best way to run a grid is a joint effort in the form of a organisation:

  • You will either have to found a non-profit or a company that runs the grid
  • You will need board members to operate the non-profit or staff for a corporation
  • For a domain transfer you need a transfer code that only the administrative holder can request. Hence it is a good idea to register it in name of the organization
  • For servers, they also need to be rented on your organizations name; and within your organization at least two admins will need access (root access, and control panel of your host corp)
  • At least one other admin (companion) will have to know how to fully operate the grid and all operations without your help, in case something happens to you. Each admin will have to document (for the shadow admin) what they do, why they do it, and how they do it.
  • One benefit on using a organization is you don't pay VAT on things like server rent. You MUST charge residents VAT if renting out regions or parcels to consumers (not b2b). Received VAT is paid forward to your government IRS at the end of the year on your yearly tax form for the organization (no, you can't keep the received VAT).
  • Depending on which country the organization is founded and the juridical form, there may be legal requirements such as setting up your official goals with a notary. This is pricey, but a one-time cost.
  • You will have to register your organization to your national chamber of commerce. Yes, even non-profits need to do this!
  • In the case of non-profit, it may only use any returns it makes for the official goals the non-profit was founded for (it's already in the name non-profit)
  • Each year you will have to make a financial year report for the IRS.
  • Boardmembers' maximum terms are limited, seats need to be replaced or rotated periodically.
  • Your organization will need its own bank account (at least to pay the servers and domain name renewal)
  • Your organization will have to conform to any laws in the country where the organization is officially seated (not necessarily the country where your server(s) are located).

Caching

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 but can be at most 20 seconds out sync.

Hypergrid Friends

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.

Hypergrid IM's

Hypergrid messaging works if your HG friend is online. If offline, two things can happen: 1) Message could not be sent and the system tells you so; or 2) Message sent, but the system still tells you it can't send the message. To be absolutely sure your offline message arrives, always send the message on the destination grid of your friend, by first teleporting to their welcome area for example. The fact that avi to hgavi offlines fail, is probably also the root cause of hypergrid groupchat not working or at least has to do with it.

Groups V2 module

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.

What works intergrid is group notices; what doesn't work is intergrid chat.

Attachments to a notice can't be opened by hypergrid members because it links to an asset on the foreign assetserver, the grid of the hypergrid member doesn't have the asset. Hypergrid members also won't see a group icon (texture) because their grid doesn't have that asset.

Locally (non-hg) all groupstuff works as expected.

It is impossible to eject hypergrid members from a group. Those can only be removed with database queries.

To unjoin a foreign group as a user, it's best to first teleport to their grid (for instance their welcome region), and only then leave the group. When teleporting back home, you may then also unjoin from your homegrid if the foreign group is still visible.

Caveat: Attachments to group notices you post are NOT copies of the item you attach; it is coded a bit poorly in that it refers directly to the item in the posters' inventory. If the poster deletes the item from their inventory, people can't open the attachment from the notice anymore.

Group bans are not implemented, there are also no related database fields for this.

Avatar names and the hypergrid

The only data about an avatar that is static and never changes is the UUID. There is a problem in the UserManagementModule and possibly HGUserManagentModule which caches the relation between username and userid. After an avatar changes their name, the old name sometimes finds its way back in cache, because the cache is populated from names on prims and from visiting avatars. Profile names, nametags will then show the old name. Maybe I can fix this now that I found where the issue is.

For now, if your grid will be hypergrid-enabled, it's best to have the policy to NOT allow name changes for your users.

For further (technical) info see the upstream wiki about Name Binding

Update 2026-01-26: I think I got this fixed now in opensim-lickx, as far as I could with regards to the HG.

Gatekeeper

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 (as HG explorer) or HG visitors get the dreaded 'cannot verify identity' when hypergridding.

Login

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) or else because LoginService runs in a different instance than PresenceService (or perhaps a combination of those things). Any help with this would be welcome so I can re-apply that commit.

The error that 81cfd6e caused is:

 (.NET TP Worker) - OpenSim.Server.Handlers.Presence.PresenceServerPostHandler [PRESENCE HANDLER]: ilegal login try from 192.168.0.2:43988 for userID <myuserid>

So I reverted it.

Hypergrid version and inventory

  • 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.

Landmarks

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.

Region sizes

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.

On var regions floating point rounding errors are more prevalent, and this increases the bigger you make a var. It is already well known that mesh bodies (the slices) deform at high altitudes on standard sims because of this same reason. It's a bad idea to make a var region bigger than 1024x1024.

Best stick to standard 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. After the introduction of PBR, people set it even less to compensate for poor performance.

Additional advantages of single regions:

  • Generate pretty Warp3D map tiles. Doing this on a var region would at best take very long, and at worst crash the simulator
  • Better load balancing. Should be obvious, but when a large region is split over multiple processes (simulators) it will improve performance
  • Individual parts (regions) of an ex-varregion can be taken off line or restarted without it affecting the rest of the land
  • Troubleshooting will be easier, for example finding out where a script goes rogue or where you have physics problems
  • Loading and saving a region terrain can be simply done in the viewer itself in the Region/Estate floater (raw files)
  • Landing points and teleport links will always work. On var regions they don't work for hypergrid visitors beyond <256,256,z> (routing the avi to <128,128,z> instead)
  • Huge flexibility for ground textures: for every 256x256 square, four different ground textures and elevations can be set. Interesting (seasonal or otherwise) gradients can be made this way that would not be possible on the space of a var region, which is limited to just 4 corners and 4 textures for the whole space.

Hardware resources

In the 90s during the dial up days, there was a key rule to follow for web developers: if your website isn't loaded after 15 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 one standard sized region (256x256 meter) per sim.

A simulator can use up to 100% of one core. If you have more simulators running than cores, other simulators will have degraded performance. So stick to 1 sim per core; and 1 region per sim.

A lot of grids fail to deliver and sell you an underpowered sim for a few bucks per month. For a 500 region 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, and each sim crunching on multiple regions.

Super fast sim startup with pretty Warp3d maptiles

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

If you are already logged in, you may not see the newly generated maptile reflected on the worldmap until you relog your viewer.

In OpenSim/lickx you can also define a custom folder for where the "MAP-uuid.png" files are to be saved to and loaded from; in [Map] in OpenSim.ini, add:

[Map]
GenTilesDirectory = "C:\Maptiles"

Speaking of maptiles and the HG

There is an issue in viewers where if you make a hypergrid jump, the maptile of the 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.

This has been fixed in Firestorm since 7.1.13 in this commit. Hopefully other viewers will follow.

OpenSim archives (OAR)

There are 3 distinct and important ways to make OARs:

Making an archive to be loaded in your current grid

Does NOT store assets, to be loaded for example in a new deployed sim server on the current grid. "Load oar" on the new server will fetch all referenced assets from the current grid's assetserver upon loading. This kind of backup can be scheduled very regularly (ie. daily) since the filesize is small (typically a few megabyte):

save oar --noassets MyRegion.oar

Making an anti-disaster archive to be loaded in your current grid:

Stores all referenced assets, this is good in case your asset server somehow blew up (worst case scenario). This kind of backup can be scheduled low frequent, for example monthly. Can take quite some disk space per oar, up to over 1GB.

On grids with frequent asset issues (such as OsGrid), this version should be used instead of the --noassets version above.

This version should also be used instead of the --home version below, if the current grid is going to be shut down permanently.

save oar MyRegion.oar

Making an archive to be loaded in a different grid:

Stores all referenced assets, AND full hypergrid address for this grid's avatars, so when imported on the new grid, anyone can lookup the creator's profile from objects made on this grid (if this grid doesn't shutdown).

Warning: You DON'T want to reload these kind of OARs in your existing current grid, because when loading such oar then creator/owner information will become "firstname.lastname @hg.example.com:8002" instead of "Firstname Lastname"! So these kind of OARs are only to be loaded into another/new grid!

(Technically, hgnames are stored in the db as "avikey;homeuri:port;Firstname Lastname" instead of only the avikey for local grid users)

save oar --home=http://hg.oldgrid.com:8002 --publish MyRegion-oldgrid-export.oar

According to the wiki, --publish strips owner+lastowner info but NOT the creator on objects (confirmed)

More on creatornames

If you inspect your inventoryitems table, you'll see lots of mangled creatornames. For local grid creators it should be just be 'avikey'. For HG creators it should be 'avikey;homeuri:port;Firstname Lastname'.

Examples of mangled entries:

  • ;http://hg.oldgrid.com:8002/avikey;Firstname Lastname (avikey in wrong place)
  • ;http://hg.oldgrid.com:8002;Firstname Lastname (missing avikey)
  • avikey;http://hg.oldgrid1.com:8002;Firstname.Lastname @hg.oldgrid2.com:8002 (two grids)

This is just too much to fix, don't bother. Maybe someday someone can write a script to fix this at best effort. Btw notice many grids don't exist anymore. These are things you will just have to put up with and accept when using hypergrid, or even with a non-hypergrid grid that imports foreign stuff (iar/oar).

The mangled and missing creator data provided to the build/object floater in the viewer, is so bad and useless that it is perhaps better for viewers to remove the field entirely from the object floater, at least when logging in to OpenSim grids.

Land impact accounting

Prims

Prims are always 1LI per prim. In SL, we have can have 0.5LI per prim if we link two box prims together and set the linkset to convex hull. In OpenSim this is not possible.

Meshes

Meshes are always 1LI per mesh, no matter if it's just one triangle or a megacomplex hugely sized object. If multiple meshes are in one linkset, each linked mesh is 1LI.

Scripts

Scripts within convex hulls (meshes) don't add any LI weight, unlike SL.

Since LI accounting for mesh is so useless, it is probably the reason why the PrimLimitsModule is NOT loaded by default. Should you still want hard enforced LI limits (as set in your region .ini file), then in OpenSim.ini change the permissionmodules line to include PrimLimitsModule:

[Permissions]
permissionmodules = "DefaultPermissionsModule,PrimLimitsModule"

Grid Statistics

OpenSim (0.9.3.1 or higher) now has a standard way of getting grid statistics. Don't use external scripts for this anymore such as OS_Simple_Stats (which reported incorrectly anyway). Use:

curl -X GET http://example.com:8002/get_grid_stats

Which will output statistics in xml:

<gridstats>
<residents>6</residents>
<active_users>6</active_users>
<region_count>7</region_count>
</gridstats>

Residents is total grid users. Active users is the number of visitors in the last 30 days, including hypergridders. Region count is landmass converted to units of standard region size (256x256 meter).

Vivox and NAT

If your grid is behind a NAT, then besides the robust port 8002/TCP and the region ports/TCP+UDP you also need to forward port 3478 and 3479, both UDP to get voice working. It becomes problematic when you have multiple simservers behind NAT (can only forward the ports to one server).

Estate rights

It is normal to give estate manager rights to tenants who rent a full region. Keep in mind that estate managers can change settings (like Environment or ground textures) on ALL regions within that estate. For security it's a good idea to attach each region that is going to be rented out, to their own separate estate.

Shared estate database

This can be done by defining (GridCommon.ini):

EstateConnectionString = "Data Source=192.168.0.15;Database=opensim_estates;User ID=opensim_estates;Password=thepassword;Old Guids=true;SslMode=None;"

When granting the sql user access to this database, be sure to omit @localhost in the username otherwise your other sim servers can't remotely access this database! For example:

GRANT ALL ON opensim_estates.* TO USER opensim_estates IDENTIFIED BY 'thepassword';

Estate-wide or region?

One more gotcha regarding shared estate database: When changing settings for an estate such as the owner or adding an estate manager, the changes don't propagate to other regions within the estate until the other regions are restarted.

If you wonder what is stored per-estate and what per-region, have a look in the source code in OpenSim/Data/MySQL/Resources/EstateStore.migrations. For example the manager-list and ban-list is estate-wide, while the covenant and environment (EEP) is per region (they are in RegionStore.migrations).