Script Not Found - But is there

[Wandering Soulstar]

Hi All,

I have a re-occuring error, though not one that happens constantly. I believe I know the reason, and have a clunky work around, but was hoping someone might have a better solution. What happens is on two scenarios I have either of the following Code Snippets that at times shout an error on Debug that file 'x' was not found

A)

    listen(integer channel, string name, key id, string message)
    {
        list params = llParseString2List(message, [FUNC_SEP], [EMPTY_STR]);
        string function = llList2String(params, 0);

        if (function == F_SCR_DATA)
        {
            gScripts = llParseString2List(llList2String(params, 1), [DATA_SEP], [EMPTY_STR]);
            //disable them
            integer num = llGetListLength(gScripts);
            string script;
            //need to wait a moment to allow inventory lists to catch up <sigh>
            llSleep(2.0);
            while (num-- > 0)
            {
                script = llList2String(gScripts, num);
                if (llGetInventoryType(script) != INVENTORY_NONE){llSetScriptState(script, FALSE);}
            }
        }
    } 

This one gives the error occasionally when I make a copy of the object this code is in. The start of the script makes a call to another object (HUD) to get the list of scripts, so you would think that the prim has loaded everything .. but no. Even dropping an llSleep before the While does not avoid this error 100%.

 

B)

    changed(integer change)
    {
        if (change & CHANGED_INVENTORY)
        {
            //need to wait a moment to allow inventory lists to catch up <sigh>
            llSleep(2.0);
            //check if a change in the scripts
            integer curNum = llGetInventoryNumber(INVENTORY_SCRIPT);
            integer scrNum = llGetListLength(gScripts);
            string name;

            //if added
            if (curNum > scrNum)
            {
                gScripts = [];               
                //get the name(s) and add to the list, stopping them
                while (curNum-- > 0)
                {
                    name = llGetInventoryName(INVENTORY_SCRIPT, curNum);
                    if (name != ME){gScripts += [name]; llSetScriptState(name, FALSE);}
                }
                
            }
            //or removed
            else if (curNum < scrNum)
            {
                while (scrNum-- > 0)
                {
                    if (llGetInventoryType(llList2String(gScripts, scrNum)) == INVENTORY_NONE){gScripts = llDeleteSubList(gScripts, scrNum, scrNum);}
                }
            }
            
        }
    }

Here it comes, as you can see, when scripts are dropped into the object. Again, not continually happening, but just once in a while. 

In summary, although using LLGetInventoryType to check, or actually pulling the name from llGetInventoryName, calling the LLSetScriptState on occasion fails. I do not want to be putting the script to sleep for ages .. and so was hoping someone had a solution.

Thanks!

Wanda

[Wandering Soulstar]

Even stranger, in the Scenario B) above, I just was doing some testing, and though it threw up the error '[10:26] Could not find script 'X', Script X was set to not running

[steph Arnott]

5 minutes ago, Wandering Soulstar said:

Even stranger, in the Scenario B) above, I just was doing some testing, and though it threw up the error '[10:26] Could not find script 'X', Script X was set to not running

I do not do mine like that. The HUD contains the original object with virgin scripts in the objects and rezzes a copy from the HUD.

[Wandering Soulstar]

@steph Arnott  Just to be clear, Scenario B occurs when dropping scripts into a prim. Scenario A is the one when copying prims. And whilst my HUD as well contains primswith the scripts, when building you more often than not want to make a copy of an existing prims, that has already been made to a size, textured, etc.

[steph Arnott]

Just now, Wandering Soulstar said:

@steph Arnott  Just to be clear, Scenario B occurs when dropping scripts into a prim. Scenario A is the one when copying prims. And whilst my HUD as well contains primswith the scripts, when building you more often than not want to make a copy of an existing prims, that has already been made to a size, textured, etc.

Maybe true but i found that passing scripts from a copy to another copy was too unreliable.

[Wandering Soulstar]

@steph Arnott In Scenario B I am not passing them from one object to another, I am dropping them on the prim, manually. In any case the point is that for some reason the code is raising an error even though it is working ...

[steph Arnott]

Just now, Wandering Soulstar said:

@steph Arnott In Scenario B I am not passing them from one object to another, I am dropping them on the prim, manually. In any case the point is that for some reason the code is raising an error even though it is working ...

Try pasting the script code into a fresh script and use that as the usage script. An edited script can retain corruped data.

[Wandering Soulstar]

2 minutes ago, steph Arnott said:

Try pasting the script code into a fresh script and use that as the usage script. An edited script can retain corruped data.

Have done that, multiple times .. this is not occuring in a single script, and has occured in other scripts I have in the past that do something similar. I raised this on the forum some years ago, and at the time was told that there is some delay between what the Inventory 'contents list' has and the items actually being fully loaded to inventory. Putting in the llSleeps where I have reduces the occurrences of this, but still can occur.

[steph Arnott]

Just now, Wandering Soulstar said:

Have done that, multiple times .. this is not occuring in a single script, and has occured in other scripts I have in the past that do something similar. I raised this on the forum some years ago, and at the time was told that there is some delay between what the Inventory 'contents list' has and the items actually being fully loaded to inventory. Putting in the llSleeps where I have reduces the occurrences of this, but still can occur.

Well i use a timer and each is loaded every 0.1. Can not see what a script stall would achieve as population is subject to the servers priority protocols. Dropping transfer when it decides to.

[Wandering Soulstar]

@steph Arnott I think you are missing the point here. Independent of how the scripts get into the prim .. the fact is

Scenario A - Scripts are already loaded, the prim is a copy made using viewer build tools. The name has been checked using llGetInventoryType, so it 'exists' in the Prim's inventory, yet throws an error (occasionally .. not all the time) when setting the state

Scenario B - The name of the script is retrieved using llGetInventoryName, so again it 'exists', and again throws an occasional error.

[steph Arnott]

3 minutes ago, Wandering Soulstar said:

@steph Arnott I think you are missing the point here. Independent of how the scripts get into the prim .. the fact is

Scenario A - Scripts are already loaded, the prim is a copy made using viewer build tools. The name has been checked using llGetInventoryType, so it 'exists' in the Prim's inventory, yet throws an error (occasionally .. not all the time) when setting the state

Scenario B - The name of the script is retrieved using llGetInventoryName, so again it 'exists', and again throws an occasional error.

Okay. I have not had the problem you describe so either there is something in the script or something you are doing and i have no idea what that is.

[Profaitchikenz Haiku]

14 hours ago, Wandering Soulstar said:

@steph Arnott I think you are missing the point here. Independent of how the scripts get into the prim .. the fact is

Scenario A - Scripts are already loaded, the prim is a copy made using viewer build tools. The name has been checked using llGetInventoryType, so it 'exists' in the Prim's inventory, yet throws an error (occasionally .. not all the time) when setting the state

Scenario B - The name of the script is retrieved using llGetInventoryName, so again it 'exists', and again throws an occasional error.

This may be caused by server loading issues? In which case it is going to vary from sim to sim and even from day to day, and any sleep values you set are going to be a compromise.

I've seen what you describe quite often, it is worse in prims with a lot of items in them. Your time delay is probably the best fudge possible. My own fudge for the application where I was seeing the biggest problems with this was to make the script in question issue a link message to say it was present and available for data to be sent to it, and the other scripts waiting for that message. In some instances they waited and waited and I needed to reset the script in question from the build menu.

 

In Scenario A, don't forget that shift-drag copying causes a sort of inventory change in one of the two , so the scripts in it might need to all be reset manually if not all of them detect inventory_change and reset themselves.

In Scenario B, the script you've dragged from your inventory to the prim inventory has come in with whatever saved condition is had when it was taken back to your inventory in the first place, so it  may also need a manual reset.

Edited March 20, 2019 by Profaitchikenz Haiku
stopy

[RozWright]

On 3/19/2019 at 1:29 PM, Wandering Soulstar said:

Even stranger, in the Scenario B) above, I just was doing some testing, and though it threw up the error '[10:26] Could not find script 'X', Script X was set to not running

During the Winter holidays, I created a total waste of resources called "Script Battle Royale" where you throw 3-5 scripts in a empty prim and they delete each other until only remains.  It turned out that the surviving script was much more accurate in revealing what remained in the prim's contents than using edit and checking out the prim inventory with my own eyes.  It took a while (if at all) for the contents to update, and I could see 2-3 scripts in the prim inventory, where one script would open without issue and the others would give me the "Could not find script" error when I tried to open them.  Those ghosts of Christmas scripts past that gave the error remained in name (and icon) only.  Some of the "ghost scripts" hung around for a few minutes or until I got bored and tossed several more scripts in the prim.

[Wyvern Dryke]

I have discovered this error as well.  I am creating a postbox that can send anything to its owner, including (disabled) scripts.  Nearly 100% of the time, it throws an "Unable to find script <name>" error as soon as any script is dropped in.  This happens whether the script is transferred manually or by another script's action.

Note: there is a very large time-delay before the postbox tries to "mail out" the received script (sometimes more than an hour) so the script is not GOING anywhere.  It's right there in the postbox's inventory.  But the postbox claims not to be able to find it! LOL

This is clearly a bug.  My postbox has no problems with ANY other type of inventory, other than scripts.

[Jenna Huntsman]

1 hour ago, Wyvern Dryke said:

I have discovered this error as well.  I am creating a postbox that can send anything to its owner, including (disabled) scripts.  Nearly 100% of the time, it throws an "Unable to find script <name>" error as soon as any script is dropped in.  This happens whether the script is transferred manually or by another script's action.

Note: there is a very large time-delay before the postbox tries to "mail out" the received script (sometimes more than an hour) so the script is not GOING anywhere.  It's right there in the postbox's inventory.  But the postbox claims not to be able to find it! LOL

This is clearly a bug.  My postbox has no problems with ANY other type of inventory, other than scripts.

This post is from 3 years ago!

Anyway, you should post a snippet of your script for us to review. More often than not, it's a mistake, not a bug.

[Lucia Nightfire]

2 hours ago, Wyvern Dryke said:

I have discovered this error as well.  I am creating a postbox that can send anything to its owner, including (disabled) scripts.  Nearly 100% of the time, it throws an "Unable to find script <name>" error as soon as any script is dropped in.  This happens whether the script is transferred manually or by another script's action.

Note: there is a very large time-delay before the postbox tries to "mail out" the received script (sometimes more than an hour) so the script is not GOING anywhere.  It's right there in the postbox's inventory.  But the postbox claims not to be able to find it! LOL

This is clearly a bug.  My postbox has no problems with ANY other type of inventory, other than scripts.

This is an ancient issue with non-running scripts after a region restart or in objects/attachments introduced to a region or crossing into another region.