Any TIPS on getting a script to run after llGiveInventory()

[bmesh]

Hello,

I'm trying to load a 3rd party script onto some prims (hud comms). We know theres an access PIN somewhere in the prims scripts. However having a hard time getting a response from the original developer/creator and would really prefer to not to dump a script like this (just developer plugin would be nice!) on every prim and of course their scripts already there are nomodify (maybe a notecard telling me the PIN???)

So if anyone knows of any tricks to get a script to run after llGiveInventory() without using llRemoteLoadScriptPin(). I've never done this before and a little bit frustrated I with the mess involved with overwrite/delete the previous script everytime I do an update or bug fix!

Any tips would be great thanks!

Thanks.

[Innula Zenovka]

According to the wiki article on llGiveInventory

Quote

Scripts reach destination disabled (not running, and cannot be made to run unless the destination object is taken to inventory and rezzed again, or the script is recompiled). To send a running script to a prim use llSetRemoteScriptAccessPin and llRemoteLoadScriptPin.

 

[Rolig Loon]

There's a difference between "getting a script to run" and "resetting a script".  As the section that Innula quote says, scripts will always arrive in Not Running status, as a protection against griefing. To make the script run again, just put it in a rezzed object.  Assuming that the object is designed in a way that the script expects ( that is, it has buttons or moving parts that the script was written to use), the script should start running at exactly the same point where it was when it was used last.  That's probably not what you want, though.  You really want it to reset -- to start running all over again.  To do that, you need to actually reset the script.  If you are really lucky, the scripter designed the script to reset as soon as it changes ownership, or when it is rezzed.  Otherwise, you need to have mod permissions to reset it, or you have to have some remote system (possibly with llRemoteLoadScriptPin) to do it. 

[bmesh]

Yeah as I thought thanks. I've set up a remote PIN manually until the mesh creator gets back to me about better methods.

I'm not sure what you mean by "just put it in a rezzed object". The object(s) are attached prims/meshes and my script(s) will not start with llGiveInventory() by itself. Are you saying if they attach and reattach it will start?

Thanks.

[Rolig Loon]

I am saying that when a script is taken to inventory, it stops running in exactly the status where it was before it was taken.  When it is placed in an object in world, the script automatically picks up running in whatever state and status it was in before.  That is, the script is essentially in "suspended animation" while it is in inventory.  That presents some potential challenges for a scripter, because it means that the script will not behave as if it was straight out of the box, starting for the first time as a brand new script.  It will still have all of the previous parameter values stored in its memory, including things like avatar UUIDs, position and rotation values, elapsed times, and anything else that it was working on when it was paused.  To beat that problem, scripters very commonly use the on_rez event to reset the script deliberately. They can also use a changed event to reset the script if it changes owners or finds itself in a new region, or they may incorporate any number of other safeguards so that the script doesn't simply start up again as if nothing had changed. 

For all these reasons, when you receive a script from someone else, chances are pretty good that it will reset automatically when you put it in an object in world.  It might do nothing at all after that, because it's just sitting there, waiting for you to do something that provokes a response -- sending it a coded message, maybe -- but it will be reset and ready to work.  What I was saying before is that if it doesn't reset, and if it is no mod, then you won't be able to do a thing with it. It will still be doing whatever it was doing for the previous owner  -- quite possibly unresponsive to you.

[bmesh]

No its my script and I'm sending the script to prim objects from another creator.

OH I'm sorry! I'm the 3RD PARTY :). Sorry for the confusion. It's my script that needs to occupy the contents of a number of prims/objects that weren't created by me.

If the solution is for me to manually copy across a script (i.e. "SetPin") to each object then so be it. It is actually what I'm doing right now and it's working fine.

But the problem is expecting other users of this mesh that use my HUD/Scripts to go through the process of manually coping accross a "SetPin" script aswell.

If there are any suggestions of how I can avoid passing on that burden that would be great.

Thanks.

Edited September 22, 2017 by bmesh

[Innula Zenovka]

Can you be a bit more explicit about what you're trying to do here?   Someone has made some mesh objects.   You want to load scripts into them.   Who owns the objects into which you want to load the scripts -- you or people who've already bought these mesh objects?

Also, you say that 

4 hours ago, bmesh said:

We know theres an access PIN somewhere in the prims script

I am not 100% sure but I'm almost certain that an object (a component in a linkset, that is) can have only one PIN set, so if you set a PIN, you're going to overwrite any access PIN that the creator set, which may well break something -- I would certainly do some tests so you know exactly what will happen if you so start setting your own PINs.   

Why exactly do you need to set all these PINs, though?   You can do most things (not everything, but most things) by manually dropping one script into the object's root and using llSetLink* commands.

 

Edited September 22, 2017 by Innula Zenovka

[bmesh]

48 minutes ago, Innula Zenovka said:

Why exactly do you need to set all these PINs, though?   You can do most things (not everything, but most things) by manually dropping one script into the object's root and using llSetLink* commands.

That's exactly what I'm doing. I don't know what the PIN is. So I'm manually dropping in a "SetPin" script so I can run these scripts. There's obviously no way around that until the developer of the mesh(es) makes it easier for me.

I don't want users of the HUD+prim scripts I'm working on to have to do this and that is the core of my question.

I can populate the (more than one) objects root with my script (listener) - I was just asking if there was a known trick to get these scripts to run without any manual effort required.

It looks like it can't be done, but probably worth asking so I'm 100% certain there is no workaround.

Thanks for your help.

[Innula Zenovka]

The only other way to do it would be to give the script that sets your PIN (which is what I assume you mean by "a 'SetPin' script") to the target object using llGiveinventory and then for the object's owner to take the object back into inventory and then re-rez it and (as I recall) set scripts to running using the Build menu.    If the object is an attachment, it has to be rezzed on the ground when the scripts are injected (this is the case when you're using  llRemoteLoadScriptPin() too).

I'm still a bit confused, though.   I would have thought that it's almost certainly going to be easier just to drop in a single script that listens to your HUD and then use llSetLink* commands. After you have placed your listener script in the first place, I don't really understand why you would need to load any more scripts unless you're thinking of future updates.