Jump to content
Sign in to follow this  
Wandering Soulstar

Script Not Found - But is there

Recommended Posts

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

@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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Profaitchikenz Haiku
stopy

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...