Journey Bunny
The VSCode plugin to work with scripts in SL from an IDE over a local connection to the viewer is nearly ready, so I'd like to add this request when it comes along:
Any chance we'll be able to commit scripts into objects...within objects?
Use case: Item gives a temp-attach HUD, which has scripts. Game rezzes pieces, which have scripts. Tons of use cases.
Challenge: Finding out what's inside an object. The simulator doesn't know until it fetches the sub-object.
I see a path forward here:
  • When we use the local address to connect to an object, and that object has contents, the simulator fetches those sub-objects and
    their
    content. Sub-Objects are represenred as sub-folders in VSCode, with contents inside.
  • When contents are synced back up to SL, it's all existing functionalities. The simulator unpacks sub-object(s) to get to the intended resource and replaces the script, then re-takes the objects. So a kind of automated "unpack to find out the content" and then existing capabilitiesthat power script pin and derez to re-pack.
Most of this exists. Rezzing to get the object info from the asset server, replacing scripts in objects (via script pin in LSL, so the simulator knows how to do this), and recently, the derez ability to take things back into an object.
The current gap:
Rezzing is a bit of a problem. This automated "unpack the sub-objects" setup could cause unintended side-effects from rezzing things in ways they weren't intended to rez.
Proposed fix:
The simulator "rezzes" the content objects, but in a way that is out of the user's control. Li-less, permission-agnostic, invisible, non-physical, owned by simulator process, with scripts non-running. To the user, nothing happens. The simulator fetches the info it needs, sends this to the localhost, and discards the objects. On check-in, a similar process will invisibly get to the right sub-object and replace the script without allowing it to run (but without toggling its run state), and taking the object back. This all runs as an elevated simulator process that simply ignores no-copy, etc. The permissions to do all this editing are checked up-front; the simulator doesn't mess with anything.
This has some performance implications, so let's imagine that recursion shouldn't go more than 2 levels or X sub-objects, whichever is met first, where X is whatever LL finds reasonable.
Bonus!!
If this can work in VSCode (via this shadow-simulator-agent rezzing thing), then I could see a future Viewer UI piece as well. Trivially, drag a script onto an object inside the contents area, get a menu asking whether you want to copy to Contents, or within object XYZ. If you choose object XYZ? Same routine; invisibly rez, add/replace the script, take back.