Entering a non Bluesteel region after being in a Bluesteel one causes some scripts to stop running
complete
Uggo Vieria
The problem was found in sailboats from "The Mesh Shop" made by Dutch Mainsails, I reproduced it in the "TMS Palain" but it happens in many other models from the same maker.
After sailing in Bluesteel regions and entering a region that is not Bluesteel, the script "BOSS radar" located in a child prim silently stops running (no stackheap collision nor any error reported).
Attempting to set it back to running from another script while still in the non Bluesteel region with llSetScriptState("BOSS radar", TRUE) fails with " Could not find script 'BOSS Radar'
going back to a Bluesteel regions and attempting to restart it with llSetScriptState("BOSS radar", TRUE) works.
the issue doesn't seem to happen if you remain in Bluesteel regions, even after sailing the boat during about one hour so it will probably be sorted out when all regions will have Gingerbread release but until then, it is a big issue for people sailing, TMS being one of the most common sailboat brand and I've heard issues recently reported with some planes that might be caused by the same problem.
Log In
This post was marked as
complete
Maestro Linden
FYI guys, this bug should be fixed with the RC update on Wednesday. We're temporarily returning the llSensor detected limit to 16 entries, but there's a fix in the simulator which should allow us to increase that limit in the very near future: https://releasenotes.secondlife.com/simulator/2024-02-21.7995320426.html
Timothy McGregor
This seems like it might also carry over to transport out of Blue Steel via inventory, not just region crossings. I'm having another issue in Blue Steel where the Change() event seems to stop firing randomly. I built a test set with the trouble script, linked it up and took it to inventory. Both the running and mono options were selected. Dropped it out in Pippen, and both were un checked. Dropped another copy of same item out back in Che Che (Blue Steel) and they were checked.
To add: Compiled the script in Pippen (Main Channel). It was running and mono. Went back to Che Che (Blue Steel) and rezzed it out. Script still Running and Mono. Took back to inventory. Rezzed back in Pippen, same. Script running. This time, went back to Che Che, opened the script, dirtied it and recompiled. Took to inventory. Dropped back out at Pippen, script not running, mono unchecked. So this issue definitely occurs with inventory transport of a Blue Steel compiled script to a non Blue Steel region.
Tetsuryu Vlodovic
I encountered a similar issue on aditi as well. It seems to affect scripts with touch events but not basic listen ones.
This is kind of a huge issue if you're dealing with no mod objects where you cannot reset or restart the scripts again, they're basically broken forever.
Maestro Linden
tracked
Signal Linden
The simulator version deployed to BlueSteel last week contains a number of scripting changes, including an expansion of the number of results returned to the
sensor
event (bumped from 16 to 32).I wrote the following script:
default {
state_entry() {
llSetTimerEvent(5.0);
}
timer() {
llSensor("", NULL_KEY, AGENT, 10.0, TWO_PI);
llOwnerSay("llSensor " + (string)llGetTime());
}
}
...and compiled it in a BlueSteel region. This script stops running once it enters a non-BlueSteel region. If there is no
llSensor
call then it continues to run.Uggo Vieria
Signal Linden there is surely no sensor involved in the boat script but yes, it's probably linked at some point. I think the heaviest actions in the boat scripts are repeated calls to llSetLinkPrimitiveParamsFast() to make all the parts move along seamlessly
EDIT
after checking with the boat maker, the script that stops runnin does make use of llSensorRepeat()