llSitTarget and llGiveInventory

two seperate, unrelated questions:

Can a prim's sit target be changed while an avatar is sitting on it? If so, does the sitting avatar move to the new sit target? The idea is an ejector seat that doesn't use llPush and doesn't require any sort of exit hole or prim movement.


Can llGiveInventory be used to move inventory from one prim to another in a linkset? It seems that it can be used to allow a child prim to be able to give something to the root prim, but I'm looking for child to child or root to child transfers. The idea is to temporarily copy into prims certain scripts that do some stuff to those prims (usually llSetPrimitiveParams) on a link message or something like that, then die. This could cut down significantly on the number of active scripts in some projects.

http://lslwiki.com/lslwiki/wakka.php?wakka=llGetLinkKey would help you get the key, particularly if you know the link number...

If it's for sale and modable, llGetLinkName will let you grab the names and link numbers to get the right keys as long as you name each prim differently.

I had an idea how you can still get this to work. When the ejection sequence is started have the script rez another copy of the seat in the same spot as the one the AV is sitting on. Then have the alpha of the seat the AV is sitting on set to 0% (so it's invisible). Then just do a WarpPos or SetPos (whichever looks best for what you want) of the chair the AV is sitting in to the spot you want to "eject" them too. Then kill the chair they are sitting on.

It might need some fine tunning, but the effect should be the same as you want because even though you have prim movement, it won't be seen. You could even throw in some particle effects, sound effects and maybe even an animation if you want to make it look even cooler.

[/color]
llGetLinkKey() could be probably utilized for this like pointed out, however a thing to note would be, llRemoteLoad() has built-in 3 seconds delay per call... not sure if that's security measure or indication how expensive this function is for the sim, but either way it's sort of a show-stopper... ^^;

So, changing the sit target won't move an avatar... Ok, then how about this: make the seat alpha 0 and move the seat wherever, then unsit the avatar that's on it, then move it back and set its alpha back to 1.0. That should take 2 llSetPrimitiveParam calls and an unsit avatar call for a total delay of 0.4 seconds, only 0.2 of which will actually be noticeable (since it's not going to be doing anything after it returns). Would that actually work? If I move a child prim with its own sit target, does the avatar sitting on it move with it? Would unsitting the avatar cause any problems?

OK, so giving scripts via llGiveInventory won't work, but llRemoteLoadScriptPin would... so the complications in that are that you have to set the pin on the prims first. OK, suppose I set the pin for the object at the root prim. Would that set the pins for each prim, or just the root prim/object? Otherwise, I'd have to have a script in every prim that sets the pin, then have it llDie or something... I forget how scripts can delete themselves from inventory. Oh! The wiki says "As of SL 1.5.14, the PIN is now treated as a property of the object." Does that mean the PIN is preserved across all copies of the object after pins have been set in the original? In that case, I could just run scripts on every prim, delete the scripts, then continue working on the object as normal with no need to have such scripts stay in copies. The 3 second delay could be a problem when I'd need delivery to multiple prims, unless I set up a multi-give system of course (which would probably defeat the purpose).

I was thinking of a workaround with the llGiveInventory thing. llSetScriptState can't set inactive scripts to active that are inactive because they were given through llGiveInventory. But what if, after giving them, I then used llSetScriptState("scriptname",FALSE) on them? llSetScriptState is explicitly stated to work on things that it has set inactive. Would it then be possible to use it on a script it has "deactivated" in this manner?

OK, so the first idea seems to be nixed. One last question, I think: if the sit target is changed, does the avatar unsit at the new sit target, or the one he initially sat at? Otherwise, it looks like I'm going to have to do some caging or something. Blah.

As for the second idea, I just realized that creating scripts (by copying them, in this case) creates new assets. So, I'd be creating and deleting assets pretty often, which strains the asset server. Since the whole point is to reduce load, that seems to me to be a bad idea. Instead, I think what I'll do is have deactivated scripts already in the prims, then deliver just one script that activates the others, has them do their thing, deactivates them, then dies. Or maybe it could just stay there, awaiting a link message or something. Hrm...

OK, that leads me to a question then. Suppose you have a script that needs to do something on a certain event, like on a link message or something like that. Is it more efficient to have one big script always active, or to have a small listener script activate the big script, deactivate itself, then have the big script reactive the listener and deactivate itself? In the latter case, the active script would be very small, which seems to me to be a good idea. I don't know if there's any actual difference, though.

This leads me to another idea: have a very small universal script activator script set inactive in the sender prim. Have a sender script send it to wherever it needs to go, sending it in active mode, and using the start_param as an indicator of what scripts to activate. Have it iterate over all scripts with llGetInventoryName, setting it to scripts. This wouldn't activate all the scripts at the same time, but according to the wiki, there's no script delay for llSetScriptState, so it should still be quite fast.

I'll end up having to try this to find out which is better, but this then leads me to wonder, which would be better?

I am working on a project that will have several scripts, including one that llListen(0, "", NULL_KEY, "";

Since this tends to be a resource hog, obviously I don't want to use that listen all of the time, but only when needed, so I was going to use states in the one script that uses that listen, and have a llMessageLinked to change states, or add/remove the llListen as needed.

So would switching to a state that only responds to a link_message or simply removing the llListen be more resource hog than one that is activated/deactivated with the Start and Stop Script functions?

I'll go into game and see if I can figgure out how to get the script resource information on land that I own, and see if I can find a difference.

::EDIT::
Ok, the sim in which I own land has some 1600+ scripts running, which makes trying to get the script time impossible, since it's already bouncing between 11.5ms and 19.5ms.. So this is something that will need tested by someone who owns an island, or knows someone who owns an island.