Wandering Soulstar Posted April 1, 2014 Share Posted April 1, 2014 Hi All, In the midst of debugging and have another one ... I have a script in a prim and one of the things it wants to do is watch for new scripts being added to it and stop them running. The code that does this is as follows: changed(integer change) { //Could be that scripts have changed .. need to turn them off if (change & CHANGED_INVENTORY) { integer num = llGetInventoryNumber(INVENTORY_SCRIPT); string name; integer x; for (x = 0; x < num; x++) { //If it is not me turn it off name = llGetInventoryName(INVENTORY_SCRIPT, x); if (name != MY_NAME) { llSetScriptState(name, FALSE); } } } } what is happening is that when I drop a script on the prim say called 'new_script' the execution of llSetScriptState raises an error to Debug saying: Could not find script 'new_script'. Now it is obviously there as the only way I find its name is as shown, iterating through the inventory of Scripts. So what am I doing wrong??? Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 1, 2014 Author Share Posted April 1, 2014 Just found that as well this is occuring (on occasion) in the default state entry code when I make a copy of a prim with the scripts in it. state_entry() { //Get my comms channels HUD_CHAN_CALL = 0x80000000 | (integer)("0x"+(string)llGetOwner()); HUD_CHAN_RTRN = HUD_CHAN_CALL - 1; //My Name MY_NAME = llGetScriptName(); //Get all the scripts in the prim //Set them all (except me) to not running integer num = llGetInventoryNumber(INVENTORY_SCRIPT); string name; integer x; for (x = 0; x < num; x++) { name = llGetInventoryName(INVENTORY_SCRIPT, x); if (name != MY_NAME) { llSetScriptState(name, FALSE); } } } Link to comment Share on other sites More sharing options...
Jenny Siddeley Posted April 1, 2014 Share Posted April 1, 2014 Your script will detect a change as soon as another script is added inside but the contents are really updated a fraction of a second later, so it might be better to just add, if possible, a short llSleep function at the beginning of the changed event. As short as 0.5 or even 0.25 should do the job. 1 Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 1, 2014 Author Share Posted April 1, 2014 Thanks Jenny .. I'll try as soon as I get in world, though it does seem strange that the LLGetInventoryName brings back the name and just the actual call to set the ScriptState fails. And that makes some sort of twisted sense in the changed event ... but in the state_entry when the script is just starting up? Link to comment Share on other sites More sharing options...
Xiija Posted April 1, 2014 Share Posted April 1, 2014 not sure if this helps at all ..... state_entry() { //Get my comms channels HUD_CHAN_CALL = 0x80000000 | (integer)("0x"+(string)llGetOwner()); HUD_CHAN_RTRN = HUD_CHAN_CALL - 1; //My Name MY_NAME = llGetScriptName(); //Get all the scripts in the prim //Set them all (except me) to not running integer num = llGetInventoryNumber(INVENTORY_ALL); string name; integer x; integer type; for (x = 0; x < num; x++) { name = llGetInventoryName(INVENTORY_ALL, x); type = llGetInventoryType(name); if (type == INVENTORY_SCRIPT) { if (name != MY_NAME) { integer scriptState = llGetScriptState(name); do { llSetScriptState(name, FALSE); } while( llGetScriptState(name) ); } } } } changed(integer change){ //Could be that scripts have changed .. need to turn them off if (change & CHANGED_INVENTORY) { llResetScript(); } } Use a do-while to keep trying to change the script state...till it finally turns off Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 2, 2014 Author Share Posted April 2, 2014 Thanks for the suggestion Xiija, but not the nice solution as this just means that I keep getting the little floating script error advises popping up. And in the changed I cannot restart as the script has other information in it that it has received .. appreciate the thought though! Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 2, 2014 Author Share Posted April 2, 2014 Jenny .. putting the sleep in both the changed and the state_entry events worked ... strange really but hey if it works :-) Link to comment Share on other sites More sharing options...
Jenny Siddeley Posted April 2, 2014 Share Posted April 2, 2014 Strange but to be honest, when it comes to object inventory, nothing really surprises me. :smileyhappy: About it working in the state_entry event, I think it was giving you the debug message because you were making a copy of your object, so making a copy of its inventory too, which also takes a fraction of a second before it's ready. If you try adding your script after the script supposed to be turned off, you shouldn't need a llSleep function in your state_entry. Link to comment Share on other sites More sharing options...
LepreKhaun Posted April 2, 2014 Share Posted April 2, 2014 Wandering Soulstar wrote: Jenny .. putting the sleep in both the changed and the state_entry events worked ... strange really but hey if it works :-) Not too strange when one understands what's happening. The sim server, which is running your script, doesn't directly keep your inventory but has to request it from the asset servers. Without the llSleep(), the local copy that your sim server requires isn't updated fast enough and by the time it does have that information, script execution has gotten past that point it was needed. Link to comment Share on other sites More sharing options...
Wandering Soulstar Posted April 4, 2014 Author Share Posted April 4, 2014 I do undersdtand about the time it takes to retrieve the inventory, but what makes it strange to me is that, as the code shows, I am first requesting the list of names from the inventory, and then trying to access the script. So it seems that the object gets it's metadata, i.e. list of what it contains, prior to it actually having said object. Link to comment Share on other sites More sharing options...
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now