so I've been meaning to work on a particular problem for ages, and was recently spurred on to attempt it, by someone elses work in a similar vein. At the core of both ideas was adding dynamic memory to LSL scripting, the ability to add a script as needed to store information, without having to worry about the limitations of a single script. Sounds fabulous doesn't it? and I did it too, well almost.... You see, it's just not possible in LSL at this time...
Now I originally came to this problem as a problem of storing permissions, because each script can only hold permissions for one person. You may have noticed dance floors and personal dance orbs (chimeras) that can support X people. that's because each person needs to have given a script permission to animate them, and each script can only hold one set of permissions... if it changes permissions to someone else, it must ask for them again.... so these devices have one script for each person they can animate..... that's one running script for every person they COULD animate, even if they aren't animating anyone...
now wouldn't it be nice if instead of all those extra running scripts, you didn't have any more than you needed at the moment? wouldn't it be grande if there was no limit to how many you could animate, right up to the limit the sim could hold? that's what I was thinking, and so I came up with a way to do it, but I never got around to testing it, and now I wish I never had.
The plan was simple, give the object a new script every time it needed more storage space. each storage script would label itself internally as it started up, using it's own name as the label. if you've ever added the same thing to a prim more than once, you'll notice it gets a number after it's name for each new copy, so the storage scripts can number themselves easily this way, and in fact I've used this method before, and it works well.
ah but you can't just give a script to an object using llGiveInventory, because the given script won't automatically load, and in fact takes a few tricks to get it to load at all. but there's another function, llRemoteLoadScriptPin, which WILL allow you to give a script and have it run. Great, but it has 2 problems. the first problem that it has, is that it will replace any script of the same name, in it's target destination. that won't work for us, because we need it to make new copies, not overwrite old ones. the second problem is that it can only work by giving the script to ANOTHER prim, it can't give itself a copy.
so we need to give the new copy to another prim, and somehow rename it in the process. ok, back to llGive inventory, this WILL allow you to give to the prim you're in, great, even if it won't make active copies... as it turns out, Remote Load WILL activate copies created with Give Inventory, so there we go, we use give inventory to create our copies, which should renumber their selves, and then activate them by giving them to another prim... oops we forgot a detail... remote load has to have a script in the recieving prim, that sets up a pin number, to be used when loading an active script.... hmm ok
to takle this and avoid having to wait on a new storage script I decide to always have one more script than I need, ready to use. When the script gets used, it asks for a new copy to be made, and sets the access PIN which it sends in a message to the controller. the controller makes a copy, and uses the PIN to load a new active script, the new active script, clears the PIN when it starts, and boom, no security holes and we've just added new storage. and this is where it all falls apart....
Now you remember I mentioned before how dragging copies of the same object into a prims inventory added numbering labels for each new copy? that's such a great feature, really. unfortunately llGiveInventory doesn't do this.... in fact, if give inventory sees that there is already a copy of the object being given, it just doesn't bother.... that means no duplicates, no numbering, and no way for the name to be changed so that it doesn't just wipe out the previous storage script.
The whole brilliant project, sunk like a lead balloon filled with rocks and shot down by a cruise missle... all because there is absolutely no way to rename a script in an objects inventory, using lsl.... so just for fun, here's the permission controller code I came up with... it wasn't quite done, it'd only handle 100 people safely (if it'd worked) and would have blown up SPECTACULARLY if the scripts ever got reset (I'ts missing clean up code), but here it is....
