[BUG-233288] Scripts do not operate properly under this new server version 577942 #10402
Comments
Lucia Nightfire commented at 2023-02-01T16:27:40Z, updated at 2023-02-01T16:28:34Z Do you have a link to where this product is sold? As there are many "banline detector" HUDs on the market. Better yet, do you have a bare bones repro script? |
Jasdac Stockholm commented at 2023-02-01T16:40:34Z, updated at 2023-02-01T16:52:38Z Can confirm. After this update, compiling a script DISABLES all other scripts in the same prim. I think this may also affect remoteloading. The other scripts can't be re-enabled unless you compile them again, leading to a catch-22 where nothing works.
Example code: default
{
state_entry()
{
llOwnerSay(llGetScriptName());
llMessageLinked(LINK_SET, 0, "test", "");
}
link_message( integer link, integer nr, string s, key id ){
llOwnerSay("Got "+s+" >> "+ llGetScriptName());
}
} Put it into multiple scripts in the same prim, only the most recently compiled one will work. Edit: Tested on 2023-01-20.577734 and it works there. It's definitely the new version that breaks scripts. |
triple.peccable commented at 2023-02-01T16:40:50Z No bare bones repo yet, I have a feeling a rollback is coming before I could narrow down the problem and create a script. The HUD is sold at http://maps.secondlife.com/secondlife/Bay%20City%20-%20Falconmoon/36/6/26. But I have just confirmed the reset script problem applies to all objects, not just this HUD. |
Maestro Linden commented at 2023-02-01T16:51:51Z, updated at 2023-02-01T16:52:04Z I can't reproduce any problems with this fairly basic script in 2023-01-27.577942: integer clicks = 0;
default
{
state_entry()
{
llSay(0, "default state_entry(). Say 'other' to enter a different state.");
llListen(0, "", NULL_KEY, "other");
}
touch_start(integer total_number)
{
llSay(0, "default touch_start(): Clicked " + (string)(++clicks) + " times");
}
listen(integer channel, string name, key id, string msg)
{
llSay(0, "default listen() - switching to state 'other'");
state other;
}
}
state other
{
state_entry()
{
llSay(0, "other state_entry(). Say 'default' to enter the default state.");
llListen(0, "", NULL_KEY, "default");
}
touch_start(integer total_number)
{
llSay(0, "other touch_start(): Clicked " + (string)(++clicks) + " times");
}
listen(integer channel, string name, key id, string msg)
{
llSay(0, "other listen() - switching to state 'default'");
state default;
}
} When I reset the script with Build -> Scripts -> Reset, the global [~M.Peccable] if you could provide more specifics about what's going wrong (or as Lucia suggested, provide or let us know where to find a script that demonstrates the issue), that would be quite helpful. In the meantime we are pausing the simulator RC rolls. |
Lucia Nightfire commented at 2023-02-01T16:55:24Z, updated at 2023-02-01T16:56:53Z Ok, what I see happening is, when I drop a script from my inventory into an HUD root link that has other running scripts, those scripts are internally set to not running and extrenally have their Mono flags unchecked. I have not tested any other method yet. |
triple.peccable commented at 2023-02-01T16:55:25Z, updated at 2023-02-01T16:58:39Z I have found that any object rezzed from inventory on the ground will not respond to a script reset. The reset request is completely ignored. That should be easy to reproduce. |
Zi Ree commented at 2023-02-01T17:01:35Z I can confirm that clicking "New Script" in a prim that already has a running script will disable the previous script. Resetting does not work until editing the script and setting it to "Running" again.
|
Maestro Linden commented at 2023-02-01T17:17:14Z, updated at 2023-02-01T17:27:56Z Okay, I have something of a repro now:
|
triple.peccable commented at 2023-02-01T17:26:00Z, updated at 2023-02-01T17:26:30Z I was working on a very similar repo, but yours is better :). But there is more, because the "Running" box is also definitely becoming unchecked under certain conditions as reported above. |
Lucia Nightfire commented at 2023-02-01T17:33:45Z Yeah, in many cases, I have to remove the "offending" scripts in order for the running checkbox to show unchecked. Adding them back causes the Running checkbox to show checked again, but the script isn't running. IDK if this is a quirk of Firestorm's object inventory caching protocol or not, though. Sometimes the Mono flag is unchecked too. A solid repro is difficult atm.
|
What just happened?
My Ban Line HUD does not operate under this new server version 577942. It is hard to describe all the symptoms and the things it is doing wrong. One thing that is repeatable, when attaching it from inventory, is that it gets stuck reading its configuration notecard over and over.
When editing the HUD and doing a reset of the scripts, nothing happens. It is like the reset request is being completely ignored.
I have tested it in 3 regions now. Blake Sea - Caribbean, Black Sea - Mediterranean, and Blake Sea - Cattlewater. Returning to a region running 577734 restores normal operation.
What were you doing when it happened?
Using a boat to travel from region to region. The HUD operates normally in regions running 577734. The HUD malfunctions in regions running 577942.
What were you expecting to happen instead?
The HUD scripts should function the same in all regions, and resetting of the scripts should work in all regions.
Other information
Original Jira Fields
The text was updated successfully, but these errors were encountered: