4
Why NOT enable hypergrid
lotek edited this page 2026-03-01 05:53:11 +01:00

A.k.a. "why can't we have nice things with the hypergrid?"

The best description of the hypergrid I've seen, is it being referred to as being 'anarcho-communist'. Wether you create something and gift a personal copy to a friend, make it available to a large audience by sharing or selling it, or keep it rezzed for yourself on your own parcel; it will most likely end up being owned by everyone at some point, due to godmoding and/or copybotting. This is why SL creators don't open stores on the hypergrid; hypergrid residents haved showed to be incapable of handling intellectual property and item permissions respectfully.

Did you know that if you teleport to a foreign sim, all your worn assets including LSL sourcecode are being copied to that grid's assetserver unless you've been there before (cached)? This is needed, because otherwise your avatar would appear as a cloud to the people in that grid. You can disable this (and be a cloud when visiting the HG), but then you also wouldn't be able to share or sell items on your grid to hypergrid visitors anymore. See "DisallowExport" in the [HGAssetService] section in Robust.hg.ini.example

It is safe to assume all grids are at least on OpenSim 0.9.0, because 0.8.x is not spotted in the wild anymore.

Some stuff is not implemented to work hypergrid-wise, not even in git master; don't expect this to ever be implemented either as work on hypergrid seems to have ended.

Some considerations when deciding whether to enable hypergrid. Hypergrid:

  • opens the door wide open to creator impersonation, godmoding permissions and piracy
  • due to foreign grids running old versions, modern or recently introduced scripting functionality can't be used: your script won't run
  • many common user features we take for granted don't work such as group chat
  • advanced projects/games are not possible either technically, or due to lack of security
  • hinders RLV-scripted roleplay where the shared folder (#RLV) is used (due to Suitcase aka HG2.0)
  • prevents attached scripted objects/huds to run at all, losing state (initial hop to a grid)
  • is a mixture of different script and physics engines as well as meshmerizers
  • the hypergrid implementation is 'early alpha' quality and doesn't seem to be developed any further
  • allows your residents to connect with a much bigger audience, for example visitors or making friends
  • enables an intergrid market with a large quantity of both goods and consumers
  • many grid owners are control freaks who like to exercise power over their visitors
  • discrimination against minorities such as child, furry or lgbt avatars is unfortunately common
  • there is no standardized way to file take down requests or DMCA, and many grids don't even care in taking action

For more info, see also Observations-Running-a-grid

Breedables

  • Owners of breedables can modify them to not need food or need less food
  • Owners of breedables can modify them to only produce rare offspring (coats or other traits)
  • On the hypergrid every breedable (in fact literally everything) is worthless, because of lack of an economy. And no breedable is rare, because the nocopy restriction can be hacked, and then the breedable can be endlessly duplicated.
  • There are technical limitations too. If a baby is born, and it has certain genetic traits; how will that baby get its traits to be visible? Those unique textures and/or sculptmaps will have to come from somewhere. Including all possible variants within the object is a no-go, as a godmoder can just take the most rare ones out and apply them. You can't refer to them by UUID either, as your grid might have not have those assets if the creator of the breedables is on another grid. And finally, having the unique baby delivered by a remote inworld server object (llGiveInventory()) is not possible hypergrid-wise.

Combat games

  • Owners of weapons can modify them to inflict more damage
  • Owners of shields can modify them to receive less or no damage
  • In general, if attachments are involved, assume the scripts are compromised (modified) to attempt to give the wearer an unfair advantage in the game. Because of this scripts should just be 'dumb' clients that communicate with a rezzed server object or a website with a REST API that does all the heavy loading.

Intergrid and intersim games and competitions

  • Grid and sim owners can give their own grid/sim an unfair advantage in the competition by modifying the scripts. One example that happened, was with Satyrfarm. A new farmer modded the scripts of the object talking with the backend website (the truck), bumping him from nothing to an impossible high score of many millions.

Affiliate vendors

  • 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
  • Network vendors that deliver from a Dropbox object (similar to CasperVend in SL, or the old SL Marketplace Magic Boxes) can only be done on grids that have working object2object email (llEmail) and primservers (llRequestURL). llGiveInventory delivers to hypergrid visitors if they are currently visiting somewhere on our grid, even if the giver object is on another region than the hypergrid visitor. However, delivery to a hypergrid visitor that is NOT currently visiting our grid will fail and requires modification of OpenSim to work (opensim-lotix has this). See also @ Scripts below.

Rare items (single-use, gacha etc)

  • Owners can modify the perms to enable copy+transfer, and then distribute them to whoever; rendering the item worthless.

Scripts

  • Intergrid scripts (like attachments) can't use modern features (like try { } catch()), 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 expressions). Refer to this forum thread to see just how bad XEngine was/is.
  • llGiveInventory doesn't deliver to the hypergrid unless the receiver has visited the local grid at least once. And then still a hack is needed to make it work (osAvatarName2Key), as well as a tiny patch for llGiveInventory() (which OpenSim/lotix has). The object would end up in 'My Suitcase/Objects/' (HG2.0) or 'Objects/' (HG1.5, HG1.0) without notification.
  • llInstantMessage does not deliver at all to hypergrid receivers residing on their homegrid (the message will never arrive)
  • Sensitive/private data in scripts cannot be guaranteed to be kept safe in no-mod scripts due to godmoding on some (a lot of) grids: private API keys for REST APIs, (prim-)e-mail addresses, passwords, etc

Different physic engines

  • BulletSim is still used a lot, almost always on sims that have counterfeit stuff rezzed. On a properly made mesh, you make and upload your own physics hull, besides the 4 seperate LOD levels. Copybots neither can't copy all LOD levels (only the one visible), nor the physics hull, however under BulletSim, the physics hull is the highest LOD level when not supplied seperately by the uploader. This is why BulletSim is favourite by content pirates.
  • ubODE vehicle params are tuned to be on par with SL. With minimal effort, vehicle scripts from SL can be ported to ubODE. BulletSim vehicle params often need to be a factor 100 or even 1000 larger!

Game logic

  • 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 prim 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 an external webserver or an inworld server object before it is final, introducing considerable overhead.

Attachments

  • Though attached scripts 'just work' for hypergridders landing on OpenSim/lotix sims, upstream and other forks are still broken when visiting their sims. Scripts in attachments and HUDs will cease function when landing there, and will total reset at some point losing all variable state.
  • All stored linkset data in an object, introduced in 0.9.3 (but not fixed until 0.9.3.1), will be totally lost in attachments when teleporting wearing such objects to sims running old OpenSim versions (older than 0.9.3.1)

Age verified and PIOF estates/parcels

  • In upstream OpenSim, these are always accessible, even to local grid users who do not have 18+ and/or PIOF flag set, because upstream incorrectly checks for those flags.
  • In OpenSim/lotix, these are never accessible to hypergrid visitors because user flags (18+ and PIOF) of foreign visitors are not visible to the local grid.

User name changes don't propagate

  • Due to simulator caching, a changed user name doesn't propagate to hypergrid sims and friends that already know you by your old name. The old name remains forever in friend lists, and for example in the creator field on objects you made that are rezzed on other grids.

Assets

  • Scripts can't use or refer to assets that don't exist on the local grid. For example a script can apply a texture by its UUID, but that doesn't work (resulting in a blank texture) if that texture asset does not exist on the grid where the script is being run. OpenSim does attempt to fetch all used assets by scanning notecards and scripts for uuids that may or may not be assets (UUIDGatherer).

Groups

  • Foreign members can't participate in groupchat. They neither can receive nor send chat.
  • In the memberlist, foreign members' last login date/time is always 'Unknown'
  • Foreign members can't be ejected. This has to be done through SQL commands.
  • Foreign members can't open notice attachments, because those assets don't exist on their grids' assetserver
  • Foreign members can't see the group logo, because that texture asset doesn't exist on their grids' assetserver (it may or may not be cached in the foreign members' viewer cache)
  • Foreign members won't see group notices on login, notices only appear while the HG member is already online when they are being posted
  • Foreign members can't browse notices of the last 14 days unless they first hypergrid teleport to the grid of the group

Online/offline notifications

  • For hypergrid friends using upstream OpenSim, these don't work at all, or sometimes only works for the first friend on a given grid (if you have multiple friends on a foreign grid). This is fixed in OpenSim-lotix.

Inventory

  • When llGiveInventoryList (such as in a scripted vendor) passes a folder of items to a hypergrid visitor who uses 'My Suitcase' (aka HG2.0), the folder won't show up in their inventory until they relog. Possible workaround in recent versions of Firestorm (not tested) is right-click the parent folder and choose Reload in the context menu.
  • When a hypergrid visitor from a grid that uses HG2.0 changes their outfit, they will become naked and ruthed because the user often doesn't store the to-be-worn clothing and other items in their Suitcase.
  • Items embedded in a notecard (such as objects, textures etc) can't be copied to your inventory if the notecard was made by someone on the hypergrid. Those assets don't exist on your grid.