Skip to content
This repository has been archived by the owner on Feb 28, 2024. It is now read-only.

[BUG-233288] Scripts do not operate properly under this new server version 577942 #10402

Closed
sl-service-account opened this issue Feb 1, 2023 · 10 comments

Comments

@sl-service-account
Copy link

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
Field Value
Issue BUG-233288
Summary Scripts do not operate properly under this new server version 577942
Type Bug
Priority Unset
Status Closed
Resolution Triaged
Created at 2023-02-01T16:23:17Z
Updated at 2023-04-07T16:04:40Z
{
  'Build Id': 'unset',
  'Business Unit': ['Platform'],
  'Date of First Response': '2023-02-01T10:27:40.330-0600',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'System': 'SL Simulator',
  'Target Viewer Version': 'viewer-development',
  '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, it gets stuck reading its configuration notecard over and over.\r\n\r\nWhen editing the HUD and doing a reset of the scripts, nothing happens. It is like the reset request is being completely ignored.\r\n\r\nI have test it in 3 regions now. Blake Sea - Caribbean, Black Sea - Mediterranean, and Blake Sea - Cattlewater. Returning to a region running 577734 restores normal operation.\r\n\r\n\r\nWhen editing the HUD and doing a reset of the scripts, nothing happens. It is like the reset request is being completely ignored, because the touch menu still responds after the reset.\r\n\r\nTeleporting back to a region running 577734 restores normal operation. Anyone else?',
  '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.',
  'Where': 'http://maps.secondlife.com/secondlife/Blake%20Sea%20-%20Mediterranean/179/36/36',
}
@sl-service-account
Copy link
Author

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?

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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 integer clicks is reset to 0, and the script triggers state_entry() in state default, as one would expect.

[~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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

 

@sl-service-account
Copy link
Author

Maestro Linden commented at 2023-02-01T17:17:14Z, updated at 2023-02-01T17:27:56Z

Okay, I have something of a repro now:

  1. Rez a box

  2. Add this script to the box (this is the same as the original script, but adds the script name to all chat): ```Java
    integer clicks = 0;

    default
    {
    state_entry()
    {
    llSay(0, llGetScriptName() + " default state_entry(). Say 'other' to enter a different state.");
    llListen(0, "", NULL_KEY, "other");
    }
    touch_start(integer total_number)
    {
    llSay(0, llGetScriptName() + " default touch_start(): Clicked " + (string)(++clicks) + " times");
    }
    listen(integer channel, string name, key id, string msg)
    {
    llSay(0, llGetScriptName() + " default listen() - switching to state 'other'");
    state other;
    }
    }

    state other
    {
    state_entry()
    {
    llSay(0, llGetScriptName() + " other state_entry(). Say 'default' to enter the default state.");
    llListen(0, "", NULL_KEY, "default");
    }
    touch_start(integer total_number)
    {
    llSay(0, llGetScriptName() + " other touch_start(): Clicked " + (string)(++clicks) + " times");
    }
    listen(integer channel, string name, key id, string msg)
    {
    llSay(0, llGetScriptName() + " other listen() - switching to state 'default'");
    state default;
    }
    }

  3. Touch the box - verify there's a chat response from the script

  4. Click "New Script" in the build tool to add a 2nd, default script

  5. Touch the box, and note which chat appears

    Expected results:

  • Each touch event should trigger 2 messages:

    1. "New Script default touch_start(): Clicked 3 times" from the first script

    2. "Touched." from the 2nd/default script

      Actual results:

  • In the last step, only "Touched." appears in chat - the first script doesn't appear to be handling chat

  • If one says "other" nearby chat, the first script's listen() event triggers - as expected

    Other info:

  • If the 2nd script is deleted, the touch_start() event in the first script is not automatically reactivated

  • If the 2nd script is modified to remove touch_start() and saved, touch_start() event in the first script is not automatically reactivated

  • If the 2nd script is modified to add a listen() event handler, the 1st script's listen() event handler is still active

  • If the 2nd script is updated to match the source of the 1st script, only the 2nd script's touch_start() and listen() event handlers trigger

    • between the other findings and this one, it seems like the newest script's event handlers stomp the same event handlers found in other prims.

@sl-service-account
Copy link
Author

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.

@sl-service-account
Copy link
Author

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.

 

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant