If LL prevented you from saving scripts in LSO format(non-Mono), would it impact you?

[Lucia Nightfire]

In the last Server meeting, LL hinted they had interest in sunsetting the ability to save LSO(non-Mono) scripts.

They would leave the interpreter running so existing LSO(non-Mono) scripts could still function, but you will only be able to save scripts as Mono going forward after the change.

There would be no Mono flag in the editor and/or no functionality unchecking Mono and saving.

How would this impact any of you?

 

[Rolig Loon]

I haven't knowingly used LSO for a very long time, so I can't see it making any difference to me going forward.  Especially if they let existing scripts that have already been compiled in LSO continue to run properly, I don't imagine that there would be many legacy problems either.  All in all, not a big deal.

[Love Zhaoying]

I click "Mono" off once in awhile by accident when I am disabling a script from running.  Annoying! ("Why do I get a script-heap collision error now? Ohh! Geeze have to recompile it again under Mono AFTER touching the code AND rechecking "Mono"..")

 

[Love Zhaoying]

25 minutes ago, Lucia Nightfire said:

How would this impact any of you?

I HOPE that none of my "purchase items" with read-only scripts are pre-Mono!

[Quistess Alpha]

practically speaking it wouldn't, but I've heard anecdotally that lso scripts can perform better at region crossings. If anyone knows some vehicle makers, maybe poke them about this?

[Rolig Loon]

15 minutes ago, Quistess Alpha said:

I've heard anecdotally that lso scripts can perform better at region crossings.

I've heard the same.  I have written many vehicle scripts that's not my normal interest so I've had no incentive to test it.  One person to ask would be @animats.  He's probably put more effort into region-crossing problems than most scripters have.

[Coffee Pancake]

At this point, if LSO scripts work better on region crossings that's a bug.

LSO should be retired entirely.

 

[Fenix Eldritch]

I would have no problem with sunsetting LSO.

A big reason LL would like to do this is because it would make expanding and enhancing LSL a lot easier if they only had to focus on the Mono runtime.

As an example, Rider explicitly mentioned that freezing LSO and going forward with Mono-only would allow them freedom to do things like implement null parameter datatypes (I believe for stuff like bypass constants in the bundled llSLPP calls).

[Love Zhaoying]

2 hours ago, Fenix Eldritch said:

A big reason LL would like to do this is because it would make expanding and enhancing LSL a lot easier if they only had to focus on the Mono runtime.

As an example, Rider explicitly mentioned that freezing LSO and going forward with Mono-only would allow them freedom to do things like implement null parameter datatypes (I believe for stuff like bypass constants in the bundled llSLPP calls).

ZOMG! It did not occur to me that all this time, LSO has been supporting "new functions" as they are added to LSL. I wonder how much "extra" work that takes for each LSL change, to make sure it works both for Mono and LSO?

Weird!!!

[Darling Brody]

There are some behavior differences in LSO and MONO which might break content with some examples in this link under VM Detection. I am sure there are many more undocumented gotchas too. https://wiki.secondlife.com/wiki/LSL_Hacks.

LSO scripts also seems to be less likely to break due to things like the "log out due to failed teleport bug", which makes them perfect to build a self repair platform from.  I have several products that have a little LSO script in them that reboots broken mono scripts.  Of course this shouldn't be something we need to add, but it is until some long standing bugs are fixed.  Given that LL are not adding new functions to LSO I can't imagine it creates a lot of extra work to maintain, and I would rather they spend the time swatting some long standing bugs rather than re-coding the viewer and regions to take something away which might send the rest of us scampering to fix stuff for years to come.

All that said, it will only really effect long suffering creators who were around before MONO, and probably has some advantage in making server code smaller.  I'd support it if it meant scripts would start working the moment an object is rezzed.  Scripts used to start instantly until a couple of years ago when a bugfix introduced a lag into newly rezzed scripts. That is the biggest scripting issue I have been waiting for LL to fix.  It makes simple things impossible or requires laggy workarounds where temp-rez objects need to be pre-rezzed so their scripts are running, just in case they are needed.

[Darling Brody]

@Coffee Pancake - Retiring LSO entirely would break all content from the first 10 years of SL.  It will unfairly impact the most loyal Residents and Creators who have been here the longest and spent the most money in SecondLife!

@Quistess Alpha / @Rolig Loon -  Larger scripts on vehicles and avatars can hinder region crossings and teleports, with the later known to kill mono scripts to the point they need to be replaced, or repaired with a LSO auto-repair script.  The problem is related to the amount of memory that needs to be allocated in the new region for both vehicle scripts and those worn by the avatar. Taking off scripts or using LSO in the vehicle has been the only thing that fixes the problem.

@Fenix Eldritch - From what I can see LL are not adding the new functions to LSO & MONO.  In the wiki all the new functions are mono only and have been this way for years. https://wiki.secondlife.com/wiki/Category:LSL_Functions

I would be fine if all the new data types and functions were mono-only and LSO was left with its original behavior and functionality. LSO only needs to support the legacy code written in it so that creators can recompile LSO to maintain it in situations where mono is less desirable.  Perhaps a first step might be to make the LSO/MONO checkbox into an Advanced menu option that is off by default.  So those of us who are maintaining legacy code can turn it on when needed.

[Wulfie Reanimator]

1 hour ago, Darling Brody said:

Retiring LSO entirely would break all content from the first 10 years of SL.

You missed this part: "They would leave the interpreter running so existing LSO(non-Mono) scripts could still function"

 

Regarding the region crossing speed, one reason LSO scripts are better/faster is in the way their memory space is handled. The following is ancient (for better or worse) knowledge:

• LSO scripts will always be allocated exactly 16KB of memory, regardless of what they actually use. This should make it pretty trivial to transmit the script between sims.
• Mono scripts have dynamic memory, meaning that during region crossings, the potential memory area needs to be scanned (accounting for memory fragmentation and garbage collection) and serialized in a more complex way for transfer.

Whether that difference still holds up after the move to AWS and the massive improvements we've seen to region crossings, who knows.

I won't be affected by it and don't have any significant use-cases besides the above, and actively maintaining some old scripts. (I guess that's what the question is. Who are the people doing this maintenance, why is LSO the better alternative, and is there no way to achieve the same thing under Mono?)

 

Edit: Wait. I do know a relatively common/important one that's still in active use. Rezzed scripts.

Scripted weapons used by SLMC (Second Life Military Communities) in LLCS (Linden Lab Combat System.. the thing with avatar health) will generally fire physical projectiles, and Mono scripts are just not viable in projectiles. Mono will initialize much slower, especially during sim lag, and this will cause projectiles to bounce off of surfaces and be a much bigger pain to work with in general. (These weapons will fire hundreds of projectiles a minute, at minimum 150m/s.) The most basic script will call llDie() on collision to make the projectile disappear if it hits any surface, but many will need do other things like play sounds, effects, rez things, etc.

There's still the issue of Mono scripts sometimes taking several seconds to receive any event (even on_rez) after being rezzed.

I used to be a dedicated developer for an SLMC group, have made several things for many others, and still have connections to those groups.  Being forced to use Mono would definitely cause "a wailing and gnashing of teeth" in this case as Rider said, because it would be a significantly breaking change. 😅

Edited October 26, 2022 by Wulfie Reanimator

[Gabriele Graves]

No, I doubt I would notice very much.

[Coffee Pancake]

1 hour ago, Darling Brody said:

@Coffee Pancake - Retiring LSO entirely would break all content from the first 10 years of SL.  It will unfairly impact the most loyal Residents and Creators who have been here the longest and spent the most money in SecondLife!

I would be fine with that. Everything with an LSO script just died and the creator had to issue an update, or other creators had to step up and replace what was lost with new product, awesome. That would be a huge injection of new life into the platform and remove a lot of "sentimental" garbage. 100% fine. Burn it all down.

I've been here 17 years and stuff I've made would be affected.

But that's not what's happening, just the ability to create new LSO scripts.

Oh well. 🙃

[Qie Niangao]

8 hours ago, Coffee Pancake said:

At this point, if LSO scripts work better on region crossings that's a bug.

As I understand it, that would be a bug at the deep architectural level of "what is a region?" To "fix" that, somehow Mono script state would need to serialize, transfer, and deserialize across region boundaries as quickly as an LSO script can be simply bit-copied and started. Or at least that's what I think I recall @Argent Stonecutterexplaining way back when.

That said, region crossing problems aren't really due to the absolute delay so much as to the robustness of the process to wide variance in that delay, and that process is what needs fixing now.

I don't see much reason to cling to the old compiler, especially because old already-compiled scripts will keep working. (As a scripter, I wouldn't care about that, either, but it would be too confusing for folks who encounter old, broken scripted content, so I'm glad all that old kruft will keep working.)

 

[Fenix Eldritch]

14 hours ago, Darling Brody said:

Given that LL are not adding new functions to LSO I can't imagine it creates a lot of extra work to maintain

 

13 hours ago, Darling Brody said:

@Fenix Eldritch - From what I can see LL are not adding the new functions to LSO & MONO.  In the wiki all the new functions are mono only and have been this way for years. https://wiki.secondlife.com/wiki/Category:LSL_Functions

I'm not sure what you mean by that... Because LL most definitely are back-porting new functions to LSO. Are you referring to the newer functions labeled as not having an LSO function ID?  I

If so, that isn't saying these functions are only available in mono (or if it does, that isn't accurate), it's just saying they don't have an LSO ID, or if they do, it's not known to the wiki. Those functions still work in LSO compiled scripts. I just spent the last hour going through each one of those functions and compiling their sample scripts under LSO. I got to the newest LinksetData functions before I stopped (and I did test those on the beta grid as well) and I can confirm that all of those I looked at worked without issue in LSO compiled scripts. I am confident the remainder do as well.

Double check what was written in the original post: LL is not suggesting shutting down LSO scripts. They would still keep that interpreter/runtime. Existing LSO scripts will continue to run as they always have. What they're considering is stopping people from compiling new scripts as LSO.

Edited October 27, 2022 by Fenix Eldritch
typos

[Rolig Loon]

1 minute ago, Fenix Eldritch said:

What they're considering is stopping people from compiling new scripts as LSO.

And, as Rider said, they are really just at the spitball stage, starting to wonder how important it is to keep the LSO compiler available.  That's why Lucia posted the question here, to see what scripters think.

[Quistess Alpha]

While we're in the spitballing stage then, what about making new functions/capabilities mono-specific, but allowing scripts to be compiled lso if they don't use any future capabilities? the main/only problem I see there is making sure documentation is clear on which functions/capabilities are mono-only?

Or, just a bad thought, add a third checkbox for mono+[not-yet-created-functionality].

[Marvin Benelli]

I would say: stop compiling to lso for new scripts after fixing region crossing as suggested by Animats

[Wulfie Reanimator]

3 hours ago, Marvin Benelli said:

I would say: stop compiling to lso for new scripts after fixing region crossing as suggested by Animats

And the start-up speed of Mono scripts in general.

[Coffee Pancake]

At this point, mono is what it is, so are region crossings.

We need the illusion of a seamless region crossing, not the actual technical movement of data to be magically extra instantaneous.

Fake it so good no one notices regions even have borders anymore.

Edited October 27, 2022 by Coffee Pancake

[Rolig Loon]

2 minutes ago, Coffee Pancake said:

We need the illusion of a seamless region crossing, not the actual technical movement of data to be magically extra instantaneous.

I think most residents would be more than pleased with that. They have no idea what's involved in the mysteries of data transfer, load balancing, and all. They'd just like to treat the grid as if it were what it generally appears to be visually -- a continuous expanse rather than a patchwork of tiles sewn together roughly at their edges. Being unseated or sunk into the ground, and even the little hiccup as you wink out of existence momentarily, breaks immersion.  I've been experimenting with some of animat's techniques recently and am pleased by how much he is able to minimize those problems, but there's still a lot to do.

[Love Zhaoying]

16 minutes ago, Coffee Pancake said:

At this point, mono is what it is, so are region crossings.

We need the illusion of a seamless region crossing, not the actual technical movement of data to be magically extra instantaneous.

Fake it so good no one notices regions even have borders anymore.

This reminds me of a real acronym Microsoft used for some of their cross-platform software a few years back: IJW, or literally, "It Just Works".

(The context for "IJW" was when going between managed (.Net) and non-managed code.)

[Wulfie Reanimator]

1 hour ago, Coffee Pancake said:

At this point, mono is what it is.

If we're going to throw our hands up in the air like this, then LSO cannot go away as an option for new scripts as it serves a tangible purpose.

I would invite you or anybody else to join some SL combat, then trying it again after all the scripts are switched to Mono. (Or heck, just switching your own scripts to Mono.)

Edited October 27, 2022 by Wulfie Reanimator

[Coffee Pancake]

The answer to better combat is not the existing lesser of two evils. 
 

Its client side scripting.