May sound like a conspiracy theory but...

[Ichi Rexen]

It seems that as of the last couple of months there now appears to be some kind of delay when it comes to creating scripts, saving scripts and scripts running their initial state_entry and messages being sent, processed and received. This isn't something only I have noticed but two of my scripter friends also. It doesn't matter what region we are on either.

For example if we create a new prim, then create a new script, usually the script would appear and "Hello Avatar" would be output in local. Now however the script is created and there is a short delay of a few seconds before the script is set to running and state_entry fires. If you take the object before this short few second delay the script is set to not running and not mono when you re rez it.

Saving a script used to save and then instantly run whatever it had coded inside of it where as now there is also a delay of up to a few seconds between saving and running the code. And I don't mean the usual delay where you are waiting for it to save. This is after.

Overall we have noticed that scripts also seem more sluggish with messages output over channels feeling like they are taking longer than we are used to, to get from point A to point B. 

We have tested this in multiple sims, empty sims, reset sims, each of us have our own separate net connection, different viewers. Result is always the same.

Has anyone else noticed this?.

[steph Arnott]

4 minutes ago, Ichi Rexen said:

 

Have not noticed any issues worth caring about.

[Rolig Loon]

1 hour ago, Ichi Rexen said:

Has anyone else noticed this?.

No, I can't say that I have.  I have been in holiday mode for the past week or so, so I haven't been scripting quite as much as usual.  Still, when I have been working, I haven't noticed any odd delays like you describe.

[Wulfie Reanimator]

Edit: Actually, I apologise. I badly misread Steph's post and I've removed the part of my post that was in response to it.

 

As for me, I have noticed something similar, where I would create a new script and then immediately open it in-viewer and click the "open in external editor" button. Two things happen; when the script is opened, it is still set to "not running," and opening it externally saves the script which keeps it in the "not running" state. If I were to wait and reopen the script instead, it would be set to running and function normally.

I always brushed this off as mainland lag though. It's probably not even the same thing as this happens before "Hello, Avatar!"

Edited December 31, 2018 by Wulfie Reanimator
Finally got to a computer to clean up the quote box.

[Ichi Rexen]

1 hour ago, Wulfie Reanimator said:

As for me, I have noticed something similar, where I would create a new script and then immediately open it in-viewer and click the "open in external editor" button. Two things happen; when the script is opened, it is still set to "not running," and opening it externally saves the script which keeps it in the "not running" state. If I were to wait and reopen the script instead, it would be set to running and function normally.

I always brushed this off as mainland lag though. It's probably not even the same thing as this happens before "Hello, Avatar!"

Might be might not be. We had it happen on mainland but its also happening on private sims as well. It's only been in the last two months, before that everything worked perfectly. Curious what could be causing it to happen,do you think it would be worth submitting a ticket of some kind? or a Jira?.

Edited December 31, 2018 by Ichi Rexen

[Profaitchikenz Haiku]

I have noticed some delays when generally editing whilst in a premium sandbox: when I highlight an object, edit it, then close the edit floater, the highlighting remains for several seconds. I have also noticed a delay when dropping a script into a prim to do tasks like replacing the plywood and blanks with my own textures, the start time for the script is long enough for me to sometimes think the script is in a stopped state. I looked at the ping sim time but it was no different to island where I rent a parcel, so it isn't internet delays. I also hadn't noticed this issue anywhere else. However, I don't know if the premium sandboxes are effectively isolated mainland or private islands, and I would also expect this sort of behaviour in places like sandboxes where there is a lot of editing and updating going on.

 

Maybe the next restarts will cure the problem?

[Ichi Rexen]

1 hour ago, Profaitchikenz Haiku said:

I have noticed some delays when generally editing whilst in a premium sandbox: when I highlight an object, edit it, then close the edit floater, the highlighting remains for several seconds. I have also noticed a delay when dropping a script into a prim to do tasks like replacing the plywood and blanks with my own textures, the start time for the script is long enough for me to sometimes think the script is in a stopped state. I looked at the ping sim time but it was no different to island where I rent a parcel, so it isn't internet delays. I also hadn't noticed this issue anywhere else. However, I don't know if the premium sandboxes are effectively isolated mainland or private islands, and I would also expect this sort of behaviour in places like sandboxes where there is a lot of editing and updating going on.

 

Maybe the next restarts will cure the problem?

Possibly, its been going on for two months at least now though. Will have to see after the next restart. Maybe it is specific types of sims though. I will have to do some more tests and see if it only happens on certain release channels / simulator versions..not too sure if that would be too much of a thing but I do remember some issues in the past in SL being specific to it being on either Magnum, Le Tigre, Bluesteel etc

[Whirly Fizzle]

I suspect whatever changed is also what caused BUG-225839 - Firestorm bridge script is set to not running on creation on Second Life Server 18.11.01.521329

[steph Arnott]

1 minute ago, Whirly Fizzle said:

I suspect whatever changed is also what caused BUG-225839 - Firestorm bridge script is set to not running on creation on Second Life Server 18.11.01.521329

That issue has zero to do with the 32bit Firestorm or the LL official veiwer.

[Ichi Rexen]

35 minutes ago, steph Arnott said:

That issue has zero to do with the 32bit Firestorm or the LL official veiwer.

It doesn't state 32bit it states 64bit on the Jira, it also states its Firestorm only. Lastly it could very well have something to do with it, if there are those of us experiencing a similar issue and as of late theres issues with the bridge script not being set to running also it logically concludes that there MIGHT be a connection. Note the word MIGHT. 

[Lucia Nightfire]

1 hour ago, steph Arnott said:

That issue has zero to do with the 32bit Firestorm or the LL official veiwer.

I'm currently on 32bit FS and see the issue. Thought it was mostly due to my current crappy bandwidth more than anything.

[Wulfie Reanimator]

2 hours ago, steph Arnott said:

That issue has zero to do with the 32bit Firestorm or the LL official veiwer.

The bug is about the Firestorm Bridge script. You're correct that it doesn't have anything to do with viewers or 32/64bit (Like Ichi/Lucia mentioned), but the JIRA that was linked is about a script being set to "not running," the same issue as what some of us have encountered here. There is a strong enough correlation that it can be said that it might be the same issue.

Edited December 31, 2018 by Wulfie Reanimator

[Whirly Fizzle]

LL changed "something" in server version 18.11.01.521329 (confirmed by LL) that caused a race condition that affected how long it took for a script to be set to running or totally broke a script being set to running under certain circumstances.
LL won't discuss what that change was for, so it's likely to be a security fix (just my assumption).
LL confirmed that bug was a race condition.
The bug is not specific to the Firestorm bridge script - it's just the way the bridge script/bridge attachment is created is the perfect storm for triggering that race condition.

So, knowing this, it's not a stretch at all to suspect the OPs issue is likely to be caused by the same change that affected the bridge script if those who have seen the OPs problem think it also started with servewr 18.11.01.521329.

2 hours ago, steph Arnott said:

That issue has zero to do with the 32bit Firestorm or the LL official veiwer.

I don't know WTF you mean.

1 hour ago, Lucia Nightfire said:

I'm currently on 32bit FS and see the issue. Thought it was mostly due to my current crappy bandwidth more than anything. 

Is that on the 6.0.1 Animesh beta Lucia?
It's supposed to be "fixed" in FS 6.0.1 by adding a delay - http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/06ed4589dd3d

[Lucia Nightfire]

8 hours ago, Whirly Fizzle said:

Is that on the 6.0.1 Animesh beta Lucia?
It's supposed to be "fixed" in FS 6.0.1 by adding a delay - http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/06ed4589dd3d

Firestorm 6.0.1 (56538) Dec 13 2018 19:42:18 (32bit) (Firestorm-Beta) with Havok support

Could still be my crappy connection as I'm not seeing it atm.

[steph Arnott]

10 hours ago, Wulfie Reanimator said:

The bug is about the Firestorm Bridge script. You're correct that it doesn't have anything to do with viewers or 32/64bit (Like Ichi/Lucia mentioned), but the JIRA that was linked is about a script being set to "not running," the same issue as what some of us have encountered here. There is a strong enough correlation that it can be said that it might be the same issue.

Hs nothing to do with Firestorm. That issue has been resolved.

[steph Arnott]

9 hours ago, Whirly Fizzle said:

LL changed "something" in server version 18.11.01.521329 (confirmed by LL) that caused a race condition that affected how long it took for a script to be set to running or totally broke a script being set to running under certain circumstances.
LL won't discuss what that change was for, so it's likely to be a security fix (just my assumption).
LL confirmed that bug was a race condition.
The bug is not specific to the Firestorm bridge script - it's just the way the bridge script/bridge attachment is created is the perfect storm for triggering that race condition.

So, knowing this, it's not a stretch at all to suspect the OPs issue is likely to be caused by the same change that affected the bridge script if those who have seen the OPs problem think it also started with servewr 18.11.01.521329.

I don't know WTF you mean.

Is that on the 6.0.1 Animesh beta Lucia?
It's supposed to be "fixed" in FS 6.0.1 by adding a delay - http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/06ed4589dd3d

Yea, whatever.