Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

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

Alchemy Cyannis
Registered User
Join date: 18 Mar 2009
Posts: 12
07-24-2009 14:45
Argent, I've done this, but again, you cannot use Remote Pins to load scripts into no mod objects. The object that you are passing things to must be mod. This is thing that's been driving me nuts.
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
07-24-2009 15:56
From: Darien Caldwell
Link in a prim to your design which we will call the update-node. It should be a child prim.
I can't get in-world to try this out, but I guess the idea is that a script within an object can call llRemoteLoadScriptPin() even though the object is no-mod to the owner, whereas scripts in external objects with the same owner can't do that.

So if this works, then one limitation might be the ability to update the update-node itself, possibly requiring another "auxilliary-update-node" in the linkset, based on this from http://wiki.secondlife.com/wiki/LlRemoteLoadScriptPin:
From: someone
If target is the scripts parent (target == llGetKey()) then "Unable to add item!" is shouted on DEBUG_CHANNEL.
(assuming it not only shouts but doesn't add the script).

[Edit to add the following:

But wait... how does llAllowInventoryDrop() work with scripts, as suggested by:
From: Darien Caldwell
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...
Is this the "drag a folder containing these scripts" voodoo mentioned in the OP?]
Darien Caldwell
Registered User
Join date: 12 Oct 2006
Posts: 3,127
07-24-2009 16:51
From: Alchemy Cyannis
Argent, I've done this, but again, you cannot use Remote Pins to load scripts into no mod objects. The object that you are passing things to must be mod. This is thing that's been driving me nuts.


When I checked, the scripts were in the proper places, so were transferred, but indeed I forgot to check if they were running. (I originally was intending this for moddable items). Let me go check again and see if they are running or not.


And Qie, yes, this is a form of that, only it's not people dropping anything, as much as a scripted item giving inventory to another scripted item. But the concept is the same. Because of the automation, it's done quickly enough that outside interference is unlikely.

EDIT: Okay my apologies. I seem to be the victim of that permission bug that's going around. even though the item said it was no mod, I found it actually was still moddable.
After making darn sure it was no mod, the updating didnt' work. Sorry for the false hope. :( Works great on moddable items though, and my original goal was to allow updating directly without giving the customer an update box, works good for that too. :)
_____________________
Alchemy Cyannis
Registered User
Join date: 18 Mar 2009
Posts: 12
07-24-2009 17:11
Thanks anyways, Darien : )

Testing things we build using using friends or alts with mod permissions on our stuff will allow a lot of this stuff to work, because they have mod rights. That's why I thought for a long time that what I had created was working. I had to use an alt with absolutely no mod rights whatsoever on my stuff to realize that none of these things click.

Unless Linden Lab enables llSetObjectPermMask or suddenly allows llRemoteLoadScriptPin to work on no mod objects at some point (both unlikely for security concerns, which I definitely understand), I don't think I'm going to find the solution I was hoping for.

It does seem my best bet is to simply uncouple the controller prim from the rest of the structure, and make that one piece mod, and tuck a bit of code in to check to see if either it or the structure moves throwing things out of alignment. Not ideal, but do-able.

Thanks again, everyone, for the time you took to toss ideas in here. I've really appreciated it.

-- Alchemy.
Nexii Malthus
[Cubitar]Mothership
Join date: 24 Apr 2006
Posts: 400
07-26-2009 07:30
Hm, what about tackling the problems that updating with scripts is meant to handle?

The networked-approach; Say the textures on the wall, the sound of a door, these are all simple things that can be externalized to a webserver. Not to mention the niceties that come with being able to update your products universally in an instant when you have a new pack of wallpaper textures out for example.

Or another alternative way of doing the update dance, object-based approach;
Larger updates could come as actual objects, perhaps via some simple object to object communication, replacing an object by the user rezzing the new copy next to it (checking for the visually closest object that the user intended for upgrade/replacement), transfering position and rotation data, deleting itself and letting the brand new rezzed copy take its original position and appearance. For example replacing that door with a better target-omega-rotation based door, you rez it next to the original door, does a dance behind the scenes and takes the position of the original door, as well as assuming the appearance, say that glass-door texture you chose for it originally before.

I'm sure it would be better if the user could update a complex living structure object by object if they'd so prefer if an object contains some more features or an older object contains personally favourable behaviours.
_____________________

Geometric Library, for all your 3D maths needs.
https://wiki.secondlife.com/wiki/Geometric

Creator of the Vertical Life Client
Alchemy Cyannis
Registered User
Join date: 18 Mar 2009
Posts: 12
07-26-2009 10:42
Hi there, Nexii : )

Really great suggestions. We're actually doing much of this now. Textures, for instance, are delivered in a tool that gets loaded into the rezzer. There are our packs, and also a version of the tool that customers can load their own textures into as well. Same thing with doors, drapes, the fire for the hearth and other objects. Lists of rezzables are maintained along with their positions, rotations and states. The structure is definitely object based and highly customizable, with themed add-on packs, furnishings and room add-on's being delivered via update objects.

There remains, however, a need to update the core scripts from time-to-time, and this is a problem so long as our structure is no-mod. This is why we're having to uncouple the controller that manages most of the interaction and enable it to talk to the rest of the structure on a permanently open negative channel.

Regarding web-side serving: we tend to avoid that when possible because if, for some reason, web service was down, or if we were no longer in business, we don't want to leave customers with a hobbled structure. Updates are certainly maintained server-side, but the core functionality is grid-based to protect our customers to the extent that we can.

Really appreciate the terrific ideas you were kind enough to share, Nexii! Thanks very much.

Alchemy.
1 2