Event timeout issue-- scripters are revolting! ;D

Creating scripts
User avatar
Snoots Dwagon
Posts: 422
Joined: Mon Jul 30, 2018 9:45 pm
Has thanked: 442 times
Been thanked: 779 times

Re: Event timeout issue-- scripters are revolting! ;D

Post by Snoots Dwagon »

Christine Nyn wrote:
Fri Mar 26, 2021 10:09 pm
An alternative approach might be to calculate the distance from A to B before starting, figure out how many individual steps at a given speed it would take to complete the move (we'll ignore the method of movement here) and then allow a timer to regulate the implementation of each move towards completion.
I felt this statement warranted a respectful and honest answer. What can be summarized in a few lines of English often takes dozens of lines of complex coding to properly execute.

Yes, one can do what is described above. Instead of using a standard loop structure (which would be the go-to method in almost any language), instead in LsL we have to:

1. Take the initial position
2. Identify the relation of the destination location
3. Perform multiple distance calculations, depending on the direction that destination happens to be
4. Calculate how long, at the current movement speed, the vehicle will take to travel that distance
5. Determine if that is longer than the 30 seconds the Opensim system allows before Event timeouts
6. Divide that distance into smaller distances that fall well under 30 seconds so that we have wiggle room in case of unforeseen lag
7. Make several moves instead of one single move
8. To make this all work, design an alternative to the timer() event, because that event pauses script operation 1/2 second every time it's called

... just to make a basic concept work correctly so it doesn't crash the script.

Many caveats that exist within LsL will require similar work-arounds to accomplish the desired goal. We wind up with a script that's more complex than it would have to be under standard coding conditions. You should see the FakeSleep() and FakeTimer() subroutines I had to write to side-step those major issues.

So yes, a competent coder can write alternative code to accomplish the goal desired, and we do-- regularly. But it does tend to make the code significantly more complex.
~~~~~~~
I'm a dwagon in real life too. (Ask my sister, who totally agrees.)

~~~~~~~
User avatar
John Mela
Posts: 91
Joined: Tue Feb 04, 2014 9:50 pm
Has thanked: 139 times
Been thanked: 127 times
Contact:

Re: Event timeout issue-- scripters are revolting! ;D

Post by John Mela »

To return to the idea of a script that gets a vehicle from A to B, and to extend that into an analogy:

You have a car in the real world, and you're driving it on your personal, land. Because you're rich and you have a lot of land (or at least BASIC on a C64 or Python on a Raspberry Pi or whatever). You can drive without interruption from A to B - the roads are empty because they all belong to you - and no need to stop.

Or if you want to stop, you can do so - no need to park up, just stop in the middle of the road. We'll calling stopping in the middle of the road llSleep(). It's not like you're bothering anyone else.

All is fine in your own world. But you decide you want company, and so you pack up and move to the nearest city. Let's call the city "OpenSim".

And here you find yourself among thousands of other people, many of them with cars. And you find yourself encountering things you've never seen before, such as traffic lights. You miss being able to drive from A to B without stopping, like you could on your own land. But you keep meeting these red lights that force you to apply your brakes and come to a stop, and then to have to put the car back into first gear and drive off again when the lights turn green. "Why," you ask, "can't I just drive from A to B without stopping, like I could before?".

The answer is that there are other road users, who have to share the same resources (roads, infrastructure) as you, and who have equal right to those resources. So, in order for traffic to flow smoothly, you have to learn to stop at red lights ... and you learn that if you don't stop at a red light, the police will force you to stop before you reach your destination. This is called "event timeout" and, while it's very inconvenient for you, it does help keep the traffic flowing in the city. So you adapt and understand that you're no longer on your own here (and thank goodness, you're in great company and love the city!), so you need to adapt your driving style. You even learn to allow people to merge in when you have right of way!

Oh, and while you still can stop in the middle of the street (remember llSleep()), it's not actually a traffic offence, and the police won't do anything about it. But you are holding up traffic while you do so, and so a good citizen will avoid llSleep() at all costs.

Analogies have a habit of breaking under strain, but I think this sums up the difference between using a FOR/NEXT loop in BASIC on a single-user machine and using a threaded, event-driven environment such as OpenSim/LSL.

And it's not just OpenSim/LSL, either. For example, if you use C# in the Unity3D framework, each C# program will need to be aware that it's sharing its environment with other such programs and behave accordingly. The difference is, you're supposed to abide by the rules by yourself in Unity3D, so there is no police force. Events don't time out, but too many long-running events will bring the system to a halt.

To fit my own gripe about OpenSim into this analogy, and to stretch the analogy a little, it's like there being a minimum speed limit which is enforced by police. The police do this by measuring how long it takes you to drive between two points in the road - if it takes you longer than a minute to drive half a mile, you're doing less than 30mph and you're pulled over, your vehicle impounded, and so on. This is another way of looking at an event timeout.

My gripe is that there might be heavy traffic preventing your from driving at 30mph, even though you're driving a fast sports car. The OpenSim police don't care about mitigating circumstances such as those big trucks doing 10mph (maybe they're doing llSleep() stops!), you get stopped and fined anyway. In other words, OpenSim should not be using elapsed time as a measure when deciding to stop threads. It should use some other measure such as the number of operations or CPU cycles or something, that will remain constant for your vehicle and driving style regardless of traffic (existing CPU load).

That said, I don't know how realistic it would be to implement checks like that instead of elapsed time, and having some police in a multi-user environment such as OpenSim is necessary, so elapsed time is better than nothing.
These users thanked the author John Mela for the post (total 2):
Snoots DwagonIlan Tochner
User avatar
Snoots Dwagon
Posts: 422
Joined: Mon Jul 30, 2018 9:45 pm
Has thanked: 442 times
Been thanked: 779 times

Re: Event timeout issue-- scripters are revolting! ;D

Post by Snoots Dwagon »

I really enjoyed those analogies John. And like you said, while analogies are seldom perfectly parallel, they do get the idea across.

I agree with you about the "script police" messing with you no matter what you're doing, but even then there's a real life analogy to that. The speed limit on the highway in my city is 70mph... but there's a lower limit of 40mph. If you're doing slower than that it's even more dangerous than if you were traveling over the speed limit (in fact, doing 40 would be pretty dangerous).

Still yes, there should be better ways. I'm not sure of all the technical details, and where it's employed or not employed, but Tranq once explained to me (in layman's terms) time slicing he set up on Inworldz. Scripts as a whole could only take up so much of server time-- so it was impossible for any script to lag the sim itself. All the scripts had to share time equally, each script only being allowed a certain slice of time. If there were too many scripts or badly-behaved scripts it was possible for one script to lag itself (too many internal processes) or in some cases the scripts as a whole lagging the whole script system (too many scripts trying to share the time slice). But that did seem a logical way to do things. And like you said in Unity... leave it up to the sim owner to manage scripts. (Note: I'm not sure how accurate this paragraph is; Tranq didn't go into details. But I liked the whole idea as a concept.)

That's what I dislike about Event Timeouts as a concept. It's very much a "LL" solution: treat the symptom rather than the disease.

I heard a rumor (from more than one person) that llSleep() not only pauses the script it's in, but every script on the region (ie, it puts the entire scripting system to sleep). While I would find that difficult to believe, sadly I don't really find it all that difficult to believe. I do know from personal experience that llSleep() can randomly cause a script to fail, but in addition (somehow) damage it so badly that sometimes the script itself has to be totally replaced (it literally breaks the script), and sometimes the entire object has to be replaced (so take regular backups of creations). Thus my personal rule: never use llSleep() for anything, ever. Which after all these years is a shocking situation, considering how very often a function such as llSleep() needs to be used (ironically to prevent a script from working too fast).

So yes, your analogies fit pretty well. And mind you, I'm not griping about the scripting system. It is what it is and we learn to work within the structures and constraints. This thread is basically to let people know about something that's come up recently, mainly because Ilan and Oren decided to let scripters know that something was going wrong when otherwise we'd have had no idea. And I do appreciate that-- and Ilan giving me the go ahead to mention it on these forums so that scripters would be aware of the event timeout issue.

And okay, yeah, I am griping about the scripting system. /me. kicks. the. scripting. engines. in. the. hiney. butt.... repeatedly... grrrr.

:roll:
Last edited by Snoots Dwagon on Tue Mar 30, 2021 6:47 pm, edited 2 times in total.
These users thanked the author Snoots Dwagon for the post (total 2):
Ilan TochnerJohn Mela
~~~~~~~
I'm a dwagon in real life too. (Ask my sister, who totally agrees.)

~~~~~~~
User avatar
Ilan Tochner
Posts: 6503
Joined: Sun Dec 23, 2012 8:44 am
Has thanked: 4942 times
Been thanked: 4454 times
Contact:

Re: Event timeout issue-- scripters are revolting! ;D

Post by Ilan Tochner »

Xengine doesn't do preemptive multitasking which is why timeouts are necessary to avoid a few scripts bringing the system to a halt. That said, when you introduce preemptive multitasking you also significantly increase the likelihood of deadlocking shared resources which can also bring the system to a halt (which again forces you to use timeouts as a way to overcome such issues). A system where you are able to control all the components can be created without such issues but OpenSim enables user-generated scripts and the interaction between those requires using timeouts to avoid system lockups.
These users thanked the author Ilan Tochner for the post (total 3):
Snoots DwagonJohn MelaIain McCracken
Post Reply