Jump to content
Ample Clarity

Potential showstopping bug on many mainland regions. Anyone else experienced this?

You are about to reply to a thread that has been inactive for 111 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Posted (edited)

There's a bug on the server update - there is an event in scripting, it is triggered as soon as a script rezzes an object - and with the server update it seems that event is not triggered correctly anymore -  I put a message into that event right at start to see when it triggers - the message never appears

 

 

 

"On Tuesday, March 4th:

  • Around 30% of the total grid (equivalent to the 3 primary RC channels) will receive an update. Again, at the time of writing, no details were available, however, Simon Linden indicated there should be no user-visible changes, but the update will include fixes to lower level code that should help with scripts running and provide some better performance transferring scripts across region boundaries as well. This update has apparently been on simulators associated with the BlueSteel RC." @modemworld

 

Edited by Ample Clarity
  • Thanks 3

Share this post


Link to post
Share on other sites

I don't know the details, that's the thing. I don't know if a sim restart will solve the problem. I seen it on 2 mainland sims: Toroge and Fearly. I don't own mainland so I can't test on other sims. I tried some of the nearby sims near Toroge and rezzed a piano on the road and it worked.

Share this post


Link to post
Share on other sites

Maybe it was already known, but I TP'd around and can confirm that Taroge, Fearly, and Korzun are all running the RC release (537423) as mentioned in this week's deploy plan announcement. I hopped around a few other sims and some are running the non-RC server release (536748). I think about a third of all sims, both Mainland and Estate, are in an RC channel.

  • Thanks 1

Share this post


Link to post
Share on other sites

If you file A JIRA And post the link then we can watch it and monitor progress.

Share this post


Link to post
Share on other sites
1 hour ago, Ample Clarity said:

I'm not sure what's going on.

Contact the creator of the object and have them verify what the problem is exactly so they can file a bug report.

Share this post


Link to post
Share on other sites
20 minutes ago, Lucia Nightfire said:

Contact the creator of the object and have them verify what the problem is exactly so they can file a bug report.

I will find a scripter to help me debug.

Share this post


Link to post
Share on other sites
Posted (edited)
1 hour ago, Ample Clarity said:

I'm the creator and have access to all the scripts full perm. But I didn't write the scripts.

Then file a jira mentioning this and offer the scipts to the Linden that responds so they can investigate it.

Edited by Lucia Nightfire
  • Thanks 1

Share this post


Link to post
Share on other sites

I find it odd that 2020-02-26T20:56:18.537423 exists on random regions across the grid, but not on any of the RC "A" regions...

Share this post


Link to post
Share on other sites
14 minutes ago, Lucia Nightfire said:

I find it odd that 2020-02-26T20:56:18.537423 exists on random regions across the grid, but not on any of the RC "A" regions...

I'm guessing it's part of the trying to hide the RC channel names so they all got moved to Main Channel. That way we can't know what is running on which RC channel.

However, this thread highlights to me the utter stupidity of that decision.

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

I did GET & POST, http-in and http-out tests between 2020-02-14T20:17:32.536748 and 2020-02-26T20:56:18.537423 using bodies containing 1,2,3 & 4 byte characters with B64,MD5 & Sha-1 match checks and haven't found anything weird yet.

Edited by Lucia Nightfire

Share this post


Link to post
Share on other sites
Posted (edited)

it'S a bug on the server update - there is an event in scripting, it is triggered as soon as a script rezzes an object - and with the server update it seems that event is not triggered correctly anymore -  I put a message into that event right at start to see when it triggers - the message never appears

Edited by Ample Clarity
clarifying

Share this post


Link to post
Share on other sites
Posted (edited)

There have been complaints in this area recently. From the wiki:

"If an object is rezzed by another object then the object_rez event in the parent object does not trigger at the same time as the on_rez event in the child object and the order of the events is not guaranteed. See the examples in object_rez for how to reliably establish communications between objects when rezzing."

Trouble came from objects, typically guns, which rez other objects, typically projectiles, and then send a message to the projectile telling it where to go. There's no guarantee that the newly rezzed object is up and running when the gun sends the message to the projectile. But apparently that assumption used to work most of the time. Now, it doesn't. Properly, you rez the projectile, it sends a message to the gun asking "what do I do", and the gun responds "go here".

What's going on, I gather, is that there's work underway to make rezzing not impact performance so much, and that breaks an assumption made by some older scripts that rezzing has finished when the script which initiated it gets control back.

There was a discussion on this recently, but I can't find it right now.

Edited by animats
  • Like 3

Share this post


Link to post
Share on other sites
38 minutes ago, animats said:

"If an object is rezzed by another object then the object_rez event in the parent object does not trigger at the same time as the on_rez event in the child object and the order of the events is not guaranteed. See the examples in object_rez for how to reliably establish communications between objects when rezzing."

Trouble came from objects, typically guns, which rez other objects, typically projectiles, and then send a message to the projectile telling it where to go. There's no guarantee that the newly rezzed object is up and running when the gun sends the message to the projectile. But apparently that assumption used to work most of the time. Now, it doesn't. Properly, you rez the projectile, it sends a message to the gun asking "what do I do", and the gun responds "go here".

It's not about the order. The issue is one of the events doesn'T trigger at all.

Share this post


Link to post
Share on other sites
Posted (edited)

I've had to bypass relying on_rez() and even object_rez() in some of my apps due to random failures since November 2019's "script efficicency fix".

Here's a snippet of one way to have on_rez() functionality without the presence and/or reliability of the event itself:

key my_key = NULL_KEY;
default
{
    state_entry()
    {
        my_key = llGetKey();
        llSetTimerEvent(#); //adjust however slow or fast you need to trigger the timer() event after an actual rez/attach
    }
    timer()
    {
        if ((my_key = llGetKey()) != my_key) //if object's key changes, object was rezzed/attached since last check
        {
            //check llGetStartParameter() if needed
            //stop timer or adjust polling speed if needed
            //do stuff here
        }
    }
}

Also, the random 2 second delay LL started adding to scripts on rez/attach doesn't help either, especially with some scripts in a linkset having the delay while others do not...

Edited by Lucia Nightfire
  • Like 1
  • Thanks 1

Share this post


Link to post
Share on other sites

I confirmed that in Toroge, Fearly and Korzun, which are on 537423, the object_rez event doesn't happen.  The on_rez event does still work as expected.  But the object_rez event definitely DOES NOT work at all.

I confirmed with the same test that on_rez and object_rez still work as expected in 536748.

But I tested in Venrigalli, Sirrakuk and Nadelhorn, which are also on 537423, and both events work.  So the bug doesn't seem to depend on 537423.  But it's definitely a problem in Toroge, Fearly and Korzun which all happen to be on 537423.

I would test in Magnum Sandbox A, LeTigre Sandbox A and BlueSteel Sandbox A but you have to be premium to enter those now.  Magnum Sandbox 1, BlueSteel Sandbox 1, LeTigre Sandbox 1, etc. also block access.  So maybe someone else can test in those.

  • Like 2

Share this post


Link to post
Share on other sites
37 minutes ago, Sayrah Parx said:

I confirmed that in Toroge, Fearly and Korzun, which are on 537423, the object_rez event doesn't happen.  The on_rez event does still work as expected.  But the object_rez event definitely DOES NOT work at all.

I confirmed with the same test that on_rez and object_rez still work as expected in 536748.

But I tested in Venrigalli, Sirrakuk and Nadelhorn, which are also on 537423, and both events work.  So the bug doesn't seem to depend on 537423.  But it's definitely a problem in Toroge, Fearly and Korzun which all happen to be on 537423.

I would test in Magnum Sandbox A, LeTigre Sandbox A and BlueSteel Sandbox A but you have to be premium to enter those now.  Magnum Sandbox 1, BlueSteel Sandbox 1, LeTigre Sandbox 1, etc. also block access.  So maybe someone else can test in those.

You are a lifesaver! Thank you so much Sayrah!

Share this post


Link to post
Share on other sites

Huh. I started out testing at those "<release channel> Sandbox A" regions and they all generated object_rez() events, but then I went to Toroge, Fearly, and Korzun, and they too generated object_rez() events. I checked and those three haven't been restarted for almost 5 days (so that would be the RC channel restarts last week), so I don't know what could have fixed them. I guess we could compare rezzing scripts, but mine is trivially simple:

default
{
    state_entry()
    {
        llListen(22, "", llGetOwner(), "test");
    }
    object_rez(key id)
    {
        llOwnerSay("object_rez of "+llKey2Name(id));
    }
    listen(integer chan, string name, key id, string text)
    {
        llRezAtRoot(llGetInventoryName(INVENTORY_OBJECT, 0), llGetPos(), ZERO_VECTOR, ZERO_ROTATION, 0);
    }
}

... dropped into an object that contains some other object to rez when I type "/22 test" to chat.

Share this post


Link to post
Share on other sites

I noticed it looked like you were testing object_rez without testing on_rez inside the rezzed object at the same time.  So I tested object_rez with a non-scripted object and did get the object_rez event in those 3 regions.  So apparently if the rezzed object has an on_rez event then the object that rezzed it doesn't get the object_rez event in those 3 regions.

Share this post


Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 111 days.

Please take a moment to consider if this thread is worth bumping.

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.


×
×
  • Create New...