Bug? Scripts passed with llGiveInventory?

I am trying ato design a system that will allow me to remotely update scripts on objects. The problem Im facing is, is that when a script is passed to an object, that script is not active at default. I tryed making a script that rezided on the object recieving the new script, to activate the new script, but thats not working. Perhaps its because of the new "have to re-save in order to make active" script bug. I know the script should become active because it shows no Syntax errors upon compilation... i dont know what to do...

I presume that it's "by design" that dropped scripts are not running be default. Otherwise any object that accepted inventory drops could be "taken over" or crashed by another object. Not good.

I think jake is right.

Perhaps a new ll call is in order? llStartScript(string scriptName) ? Which would lead to llStopScript(string scriptName) ...

Ama, sadly, theres already something like that in LSL,

llSetScriptState(string script, integer active)


it doesnt work though, with these scripts, I believe its a bug, and have already filed a report. I think its due to the problem, where the running checkbox wont stay checked on the transferred script (even though it was checked on the sender) unless you force reset the script (resave). This really puts a bad dent in my plans, auto-script update distrib out the window lol.

Ah I know about that method Chris, and was indeed asking for a new ll call because that method is to change the state of a script - but won't effect whether or not the script is running (because that isn't a 'state').

I think that scripts dropped onto an object or given to an object shouldn't be run automatically. It would make it too easy to take over someones object. However I do think there should be a way to manually turn on a specific script.

Am I making sense? I never know anymore.

Hey Wednesday chime in isnt this the result of a bug you reported a loooong ways back? where you said that dropping stuff on a object that accepts drops could be dangerous? I dont remember the specifics, but yea this does look by design. If I am talking out of my butt, don't mind me.

I tryed bypassing script updating all together, with the help of Xylor (not help, he was actually doing 95% of it lol) we tryed updating the object by having it get an updated object, rez it and die, which proved to be insufficiant, since locked objects (to keep object no-modify I had to lock it) cannot recieve inventory from other objects even if llAllowInventoryDrop() is true. Will someone help! Please!

Hey-o! Someone call my name?

Yes, a while ago I reported that it _seemed_ that you could drop a script in to an object that accepted inventory drops and that script would then be running, and could do all sorts of terrible things to someone elses object.

The answer was that this is not the case, dropped scripts are made not-running by (good, IMO) design.

BUT I'm going to quarrel with Ama here (quell suprise!) it seems to me that llSetScriptState is (supposed to be) used to make other scripts running or not, not make them move to another "state", it's just badly named. So a foolishly trusting object could choose to make any script dropped in to it's inventory run.

Also, what's what all the Omegas in this thread?

another mildly related bug

if an object gives another object an item, if there is an item in the recieving object inventory that has the same name, it is overwritten/replaced by the item that was just given to it. i.e if there is a notecard in the inventory of the recieving object named 'wood' and then another object passed a texture called 'wood', then the texture would overwrite the notecard.

Well.. I must disagree with Wednesday, I think the feature should be disabled by default, yes, but it shouldnt break llSetScriptState(). Nada, I think that may be by design, it seems as though automatically renaming something thats a duplicate in object inventory will mess up certain scripts... If any one has any suggestions to my problem above, please feel free to post one.

You see, I was thinking of getting around the llSetScriptState thing by having the OldObject rez a new object that was sent by UpdateManager. in order for NewObject to retain its non-modify permissions, it needs to be put into inventory as a locked object, and will therefore rez locked, and non-modable. HOWEVER, it turns out that locked objects cant recieve anything from llGetInventory() even if llAllowInventoyDrop() is TRUE. HOWEVER (again) avitars CAN drop inventory on the locked object, with llAllowInventoryDrop(TRUE).... which is an odd behavior.

Anyone have any other workarounds?

i am not sure about the by design part... i mean if it replaced same type of objects only i would toatlly buy that. it just seems odd to me that you can replace a notecard named wood with a texture named wood...