Providing Customers with the Ability to Update Components of Non-Mod Objects?

I have a bit of a scripting dilemma that's been driving me crazy, and at the moment, no ideal way of solving it. I was hoping that by sharing what I'm attempting to do, and how I've tried to solve it, someone else might be able to see either a flaw in my logic or an alternative I've not considered. I would be incredibly grateful for any help on this.

My partner and I create and sell items that are copiable, non-transferrable and non-modifiable. Because we are committed to constantly improving what we create, we offer free updates and a system that allows the customer to check for these and have them automatically delivered at any time. While this works well for smaller items, it's not particularly practical for larger ones, like a prefab home.


What do I need to do?

Create an update system for a prefab living structure that allows me to deliver new modules and updates to a customer and for them to easily apply to the existing structure, including:

1. new and updated scripts
2. new and updated objects
3. new and updated textures

At the moment, there is no really good way of doing this. Setting mod rights on the structure is not an option, because it's a complexly scripted prefab with position and rotation dependencies, as well as prim name and description dependencies. Giving a customer mod abilities will lead to this structure being broken and create a customer service nightmare.

Here is what I'm sort of stuck with at the moment:

1. Load new scripts into a non-mod object

No reasonable solution.

- llRemoteLoadScriptPin requires mod rights. I considered making the controller component mod and then unlinking it to facilitate the update loading through llRemoteLoadScriptPin, then relinking it to the parent when done, but unfortunately the controller, as a child prim, seems to inherit the parent's permissions on linking, making it non-mod again, rendering this useless.

- llAllowInventoryDrop doesn't permit loading scripts and shouts "Not permitted to edit this!". While I realize you can drag a folder containing these scripts to work around this, they are loaded in a non-running state, and without mod rights on this object, the customer cannot set them to running. (Setting them to running also requires taking the loaded object back into inventory first, before setting them to running, and this is not practical if the item you're loading new things into is your home.)

- llGiveInventoryList loads the scripts from an update prim to the final structure in a non-running state, and the owner cannot set them to running if they do not have mod rights.

The only workaround I can think of at the moment is to have the controller be a separate prim detached from the rest of the structure, and to have this be moddable. Downside is that this requires a constant open listen between this controller and the rest of the structure to handle requests, and an additional resource hit to have a sensor to make sure this prim is constantly aligned properly with the structure so that the rezzables it contains rez in the correct positions/rotations.

While I've considered loading the rezzables into the main structure, this would require customers to use the "drag and drop" system to apply updates through llAllowInventoryDrop, and this is far from user-friendly or reliable, and can lead to inventory loss if they drop the wrong thing in.


2. Load new objects into a non-mod object

llAllowInventoryDrop. Far from ideal. This is not a user-friendly feature, and besides causing confusion, it also involves the risk of a customer losing irreplaceable inventory if they accidentally drop the wrong thing in, and it's not copiable.


3. Load new textures into a non-mod object

llAllowInventoryDrop. Again, a flawed solution. Textures dragged onto child prims instead of the parent appear to go into the contents of the child, even if the script allowing the drop is in the parent. This would mean having to have a script in every single child simply to watch for this and move drops into the parent via llGiveInventoryList, and having a script in every single prim of a complex build isn't practical.

Kind of hoping that someone may see something that I'm doing that's out of whack, or not doing that I should be. Thanks in advance for any ideas people might be willing to share on this.

-- Alchemy Cyannis.

you can set other scripts to running with llSetScriptState
http://www.lslwiki.net/lslwiki/wakka.php?wakka=llSetScriptState
you would need to somehow communicate the name of the new script to the old one so that it can turn it on

Hello, Ruthven : )

I've used this before, but in this case I wasn't able to because it cannot start a script that has been added into the object directly from another object, as I was doing through llGiveInventory/llGiveInventoryList.

Wondering if I might be able to with the llAllowInventoryDrop method. Hadn't considered that. Off to try. Thanks!

Alchemy.

Option 4: don't make them no-mod?

@ Ruthven ... no joy.

Wrote a quick and dirty little test script to see if the basis would work, and it seems to be subject to the same limitations as llGiveInventory. Using llAllowInventoryDrop is just a dicey shot for me regardless, because even on testing I accidentally dragged an unintended folder full of non-copy items in, and of course could not recover them. If I was to use this I could probably write something in to keep a running list of all the contents, and give back anything dropped in that was non-copy based on a list compare and using Perms Mask, but it's just such a messy option at all.

The other problem is that scripts are not supposed to be draggable using llAllowInventoryDrop, and I'm guessing the fact that I can get around this by dragging them in a folder instead is likely a hole waiting to be plugged by Linden Lab, leaving me with a broken product.


Thanks again, Ruthven.

Hi, Argent. I actually addressed this in my post. It's really not an option in this case. The structure is complexly scripted, and depends on positions, rotations, prim names and descriptions not being changed. Giving customers the ability to mod this structure will lead to a support nightmare.

We've intentionally included the ability to mod virtually every single aspect of this product through menu options and rezzable tools.

One of the things I had mentioned above was considering uncoupling the controller that handles everything, and making just that piece mod. In the end, unless there is an alternative that I am missing, this is likely what I'm stuck with. Besides the constantly open listen that requires between it and the structure, it means also having a sensor in it that detects if either it or the main structure have moved, or the things that it rezzes will be out of place.

The reason I am not putting the rezzables in the main structure is because it cannot be mod, and the entire point was to be able to offer upgrades and add-ons, along with the ability for customers to add their own tools/options in along the way, hence, the need for this upgrade system.

Wish there was an easier way, but I think I'm stuck with this.

Thanks again,

Alchemy.

I sell a plane like that, with scripts that depend on the distance between prims, scripts that have to be reset after you adjust the angle of the flaps, and so on... and it's a plane... and hardly ANYONE sold moddable planes when I released it. I have had *zero* customer support calls from people who have modded it and screwed it up.

Thanks for the reassurance, Argent. I appreciate that.

I suppose we'll have to weigh the pro's and con's of going with the uncoupled controller versus a moddable structure if there doesn't appear to be a reasonable way of delivering updated scripts to a non-moddable object.

Spent days combining the script wikis and these forums before turning here for help, and unless Linden Lab goes live with llSetObjectPermMask (which seems unlikely) to let us temporarily set the structure to mod during updates and turn it back off when done, it just doesn't seem like there's a way to do it.

The only time I'd buy a no-mod object is if it's by mistake. Of course, not everyone feels that way.

Coincidentally, I'm finishing up a scripted structure right now. I'll release it copy+mod, but I understand the hesitation. In my case, I'm not so concerned about the possibility of customers breaking the scripts (although they could if they rename, unlink, or remove the wrong prims); rather, I've been agonizing over how to explain all the things they shouldn't try to change because the scripts will just change them back again. It's a finite list, but it's so intricate that I'm tempted to just not even try to explain it. Let it be a "surprise".

If you decide to stick with no-mod, there is one virtue for updating: because they can't change it, you can know exactly where everything is from the position and rotation of just one of the component objects. Because they can't have changed anything, they've got nothing to lose by having the old structure completely replaced by a new one. So, each of the component objects have to be able to move into place when rezzed, simply offset from one of the existing objects, and to llDie() when they're replaced.

I'm reminded of some hair I got recently, that had a very over active coloring script in it.... I'd color all the prims I wanted, then take it to inventory, and on rez it reset all my color choices o.O took me three times of that before I realized what was really going on (first time I thought the settings just didn't take as SL so often does to me) and stripped out the coloring script (it was a convenience thing someone added)

What will happen to no-mod things that are highly scripted when parcel script limits come in?

Complexly scripted does not mean containing many scripts. On the contrary. I've deliberately used llSetLinkPrimitiveParams wherever possible to apply changes to many things instead of nesting scripts in child prims, and I have tried to be conscientious about not having a bunch of open listens, sensors and other practices that create latency on either the server or the client side.

This is why I am asking for assistance here.

Complexly scripted does not mean containing many scripts. On the contrary. I've deliberately used llSetLinkPrimitiveParams wherever possible to apply changes to many things instead of nesting scripts in child prims, and I have tried to be conscientious about not having a bunch of open listens, sensors and other practices that create latency on either the server or the client side.

This is why I am asking for assistance here.

I bought a HUD not long ago that is driving me nuts with updates. It's no-mod. Following the instructions never seems to result in getting a properly updated copy. I keep getting additional copies of folders of the unboxed item that are name "Such and Such Thing [BOXED]". The various release notes, information notecards, and other things that have version numbers in them never agree with each other.

I have no useful ideas on how to do updates right, but I will say, doing them in the way this product (the thing I bought, not the OP's product) does will greatly decrease repeat business and good word of mouth.

The exercise in highly scripted structures with which I'm currently engaged is specifically intended to reduce the amount of script memory people use on their land by subsuming utility functions into scripts needed anyway for the structure's features.

Working on it, I encountered my first direct exposure to the nastiness ahead when script limits do not discount for shared Mono program segments. Here's what I mean:

By adding just a bit of code, perhaps 1K, I can make two fairly large scripts be identical, such that they share that program footprint and save memory. But with parcel memory limits not reflecting that shared savings, I'm left with the choice of doing it anyway, which penalizes the user by the increased memory needed to make them sharable, or keeping them distinct, which increases actual memory usage in the sim. Not a happy choice.

In this particular case, I'll do it anyway because there's little likelihood that the incremental memory needed to make these scripts identical will push them into the next level of per-script memory allocation (assuming there are discrete levels--as I think inevitable).

Awhile back I was working on an updating system, but shelved it because I closed my store. But after reading this I think the possibility exists that it could work for no-mod items, even though that wasn't my original goal. I'll drag it out and check it over, if it does work for that purpose, I'll release it.

Have Linden Lab officially published what the exact limitations will be on number of active scripts / script memory allocation per parcel /full service sim /homestead sim, and when this will be put into effect?

No, they have to perform a bunch of measurements to figure out what those will be, and they just put the code in to SUPPORT that measurement fairly recently.

Thanks so much, Argent.

Thanks so much, Argent.

Edit: found it doesn't work, disregard

Well, my updater works for no mod items. However, given the complexity the system, I'm reluctant to release it. It would require a lot of cleanup and documentation, and I hate writing documentation. I will outline the concept and maybe that will lead people in their own direction however.

Link in a prim to your design which we will call the update-node. It should be a child prim.

Inside would be a script that handles turning llAllowInventoryDrop() on and off at specific times, long enough to allow a non-running script to be sent to that prim, which is verified by detecting using the changed() event (checking for CHANGED_INVENTORY). The node is told what should be coming, turns on AllowINventoryDrop, and as soon as an item is detected, turns it back off. It then verifies the validity of the item. (the nice thing about enabling allowinventorydrop in a child prim is, you can only drop items on that one prim, not the whole object. it's safer.) Of course the object sending the update must have some way to identify the update-node and handshake with it, chat would work, or may be a great applicaton for the new HTTP-IN.

Once it's determined to be valid, the update-node then uses llRemoteLoadScriptPin() to send the new item to whatever prims are specified *in it's own linkset*. Is this allowed in LSL? yes it is. You just need the keys for the specific prims.

And I must give some props to Yumi Murakami for giving me the original idea, so very long ago.

So in effect, the update-node acts as a proxy for the update. The plusses are, you can update no mod items, and you can send updated scripts to items you don't own. The Minuses are, it opens the possibility for people to do something malicious. But With the proper precautions, that chance is negligible. You can bury the node deep in the item, so even if someone had the ability to know exactly when the AllowInventoryDrop was on for those couple of seconds, they still couldn't drop anything on it. And by checking the dropped items for characteristics of your choosing, you can further limit the possibility for mischief.

I have working code if anyone really wants it, but I'm not going to document or support it, thus it's by request only.

Can't you avid the AllowInventoryDrop step by delivering the update in an "updater box" with an authentication script that knows a magic word, and have it talk to a script in the target and use LoadScriptPin to actually do the delivery?

Darien, this is a really clever idea. Unless I really screwed something up (and this is certainly possible ... lol) it doesn't work. I tried this earlier this week and hit the wall with scripts not being able to be set to running when loaded from another object.

I did have a test set up to turn llAllowInventoryDrop to true, and used a timer to shut it off again, along with detecting the change in inventory to trigger the update prim to try to

1) set the scripts to running (failed for the reasons mentioned above),

2) use llGiveInventory/llGiveInventoryList to pass the scripts from the update prim to the final prim (no joy on no mod), and

3) use the remote pin method to pass the scripts on to the child prim, but again, the inability to set them to running kills it.

If you've found some way to allow scripts passed to a no-mod object to be set to running, that's the wall I'm hitting my head on right now. Would you be willing to share how you did this?

Thanks so much to everyone who continues to add to this conversation. I really appreciate all the ideas and opinions that people have shared.

-- Alchemy.