Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0008529opensim[REGION] Script Functionspublic2019-05-14 22:052019-05-19 13:37
ReporterSnootsDwagon 
Assigned To 
PriorityhighSeveritymajorReproducibilityrandom
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0008529: llSleep() Intermittently stops a script
DescriptionI've written several scripts using llSleep() as a pause agent. At random times this function will cause a script to freeze, requiring reset to continue. This has happened with so many scripts I've had to resort to using the much more complex llSetTimerEvent() with multiple flags to accomplish what should otherwise be a simple pause.

This seems to happen most often when multiple sleeps are used within a single event-- such as a touch_start() event that triggers several functions in specified time order. There's no need for a "sample script" since this is an intermittent and unpredictable situation. However when it happens, it happens often enough to cause problems-- especially in scripts that are the focus of an attraction.

I first noticed it in a Ferris Wheel script I wrote where the wheel was to start, play music, and stop at specified times. Second noticed on a Stargate script where the horizon event, particle emission, and sounds were scripted to execute in a specific order at a specific time. I've run several tests with llOwnerSay() flags to see where the script hangs-- and narrowed the problem down to the llSleep() function. Bottom line: when it sleeps, sometimes it doesn't wake back up.

TagsNo tags attached.
Git Revision or version number
Run Mode Standalone (Multiple Regions)
Physics EngineBulletSim
EnvironmentUnknown
Mono VersionNone
Viewer
Attached Files

- Relationships

-  Notes
(0035209)
BillBlight (developer)
2019-05-15 02:43
edited on: 2019-05-15 02:47

With Xengine this is a known issue, has been for a very long time, and evidently no way to fix it without refactoring the entire engine ..

yEngine does not seem to have this issue ...

look at llSleep on this page ..

http://opensimulator.org/wiki/LSL_Status/Functions [^]

(0035210)
SnootsDwagon (reporter)
2019-05-15 08:08
edited on: 2019-05-15 20:06

Thanks Bill. I have no problem switching to Yengine but have been cautious about that great big warning in the ini setup file. If I may inquire your personal opinion regarding the stability of the Yengine system, I wouldn't mind at all giving it a try if it's stable since llSleep() is a major function. Thanks for your help.

(0035211)
SnootsDwagon (reporter)
2019-05-15 08:10

Follow-up: thanks for pointing me to that function status page too. Hadn't seen it before. Very valuable resource for scripters!
(0035212)
SnootsDwagon (reporter)
2019-05-15 10:22
edited on: 2019-05-15 20:05

Follow-up follow-up. ;D

I checked the Opensim.ini file and read the Yengine specs. Terrifying stuff. Won't work on VARs (only one region per instance), script states reset on teleporting, cars stopping at various times, don't use this without constant supervision, etc. Tells me not advisable just for fixing the llSleep() function (which as you mentioned was specifically noted as a reason for Yengine in the documentation).

This does make me wonder however, why after all these years someone doesn't fix llSleep(). Or if that would be a major can of worms, perhaps write a new osPause() function that works and create an automatic jump from llSleep() to the new function.

"Can't be done" isn't in my codebook. ;D

(0035213)
mewtwo0641 (reporter)
2019-05-17 03:58
edited on: 2019-05-17 03:59

I've been running YEngine for a while now (For testing purposes of course, not in production) and I've had very little issues with it. Script states only get reset if you teleport from a YEngine to XEngine region (or vice versa) or if YEngine's API version changes, in which case, script resets are probably desirable anyway. The warning says it doesn't support multiple regions per instance but I've also observed no issues running it like that. I haven't tried on VarRegions or HG though.

Something to watch out for though is YEngine's script syntax is a bit more strict than XEngine's; so it is possible you may have a script that works fine on XEngine but won't even compile under YEngine unless you make some (usually minor) changes to the script.

(0035214)
SnootsDwagon (reporter)
2019-05-17 11:10
edited on: 2019-05-17 22:46

Thanks Mew. One of the things I'm trying to avoid is script updates, as I have some 5000+ scripts per VAR and no way to know whether they're still running or not without checking each individual script. Thus this Mantis and the need to fix a script function that can bring a script to a screeching halt llSleep(). I'd love to see either a fix to this, or a replacement function such as osPause() with a bridge created to re-route llSleep() to osPause() automatically. I know, more work for the devs and my earnest sympathies. But, llSleep() isn't a minor, seldom-used function. Having to script a timer() event with flags to trigger the proper function is about 10 times more complex than a simple pause. (It fixes the problem fortunately, but turns 2 minutes worth of scripting into 30 and a one-line function into half a dozen with extra flag variables).

Since Yengine states specifically it won't work with VARs or Megaregions or the Hypergrid, I don't consider it a viable alternative to Xengine. If it is more strict in its syntax (Xengine is already pretty strict), no telling how many hundreds of scripts it might break. And since I have two VARs and hypergrid access... Yengine isn't an option for me.

(0035215)
BillBlight (developer)
2019-05-17 14:18

Not so sound overly uncaring, but considering this has been an issue since opensim has been opensim, users should also take some responsibility in not having scripts that relies on a function with known issues .. It is not like this problem with llSleep just appeared overnight ...

it is a problem with the threading in xEngine, and not something that can be easily fixed or even "coded out" with a new function.
(0035216)
SnootsDwagon (reporter)
2019-05-17 18:46
edited on: 2019-05-17 22:52

Bill, something to consider is that not everyone has been active on Opensim since it opened... and not everyone is aware of this issue. Over the last year there has been quite an influx into Opensim grids from Inworldz and Second Life.

If llSleep() doesn't work, it should show up during coding as a non-supported function-- not on some obscure webpage. It's not like a scripter is likely to look it up and say "Hmmm I wonder if llSleep() is actually working?"

Thus, (with all respect) there is ZERO user-responsibility in this matter. llSleep() is a standard LsL function that should either work... or should not compile in the script engine (ie, manifest as an unsurpported function). You have no idea how many tedious hours and weeks and months I spent trying to debug scripts with no idea this function wasn't operational on Opensim.

I used llSleep() for years on Inworldz with no problems... and Inworldz was based on Opensim code. Evidently they managed to fix this problem. So my response to the statement "users should also take some responsibility in not having scripts that relies on a function with known issues" is this:

xEngine coders should not allow a basic system function to go unfixed for years on end. The responsibility is on the coders, not the users of Opensim. Saying users should have some responsibility in this is like stating the driver of a defective-from-the-manufacturer car is responsible for the resulting accidents due to automobile failure.

When a bug is known, it gets fixed. If it doesn't gets fixed, it gets replaced or redacted. That's how professional coding works.

(0035217)
BillBlight (developer)
2019-05-17 18:47

That is not an "OBSCURE" page it is the ll functions page ..

and the fix for it is yEngine ...
(0035218)
BillBlight (developer)
2019-05-17 18:48

Users not reading the documentation is NOT the coders fault ..


RTFM.
(0035219)
SnootsDwagon (reporter)
2019-05-17 18:58
edited on: 2019-05-17 22:56

The "fix" for this is another scripting engine with so many potential problems there are major warnings about it in the Opensim.ini code? Warnings that specifically say don't use Yengine without constant supervision. That's not really a good fix.

Bill, I'm not here to debate this. I was a professional RL coder for 30+ years. I taught cororate coding classes. I do know how coding and debugging works.

Stating that it was my responsibility to visit the Opensim-specific "LsL" page to see if a very standard function like llSleep() actually works or not is ludicrously counter-intuitive. This bug was known by xEngine coders to exist for years. Being well aware of it, the Xengine people should have fixed it long ago. Inworldz proved it is possible to fix it; they did so.

I'm a USER. I've reported the bug. That's what Mantis is for. That's as far as my obligation goes. No, I'm not going to keep using llSleep() in my code now that I'm aware of this problem. But know this: it is NEVER the user's responsibility when system bugs cause user and system problems.

In addition, there's never excuse for coders blaming users for coding errors. There's no warrant, excuse or rationalization for such a basic-function bug as llSleep() remaining on the system for YEARS. It should have either been fixed or redacted in the script engine itself. Fixing it admittedly may be "difficult". Redacting it until it's fixed? That's standard 10 minute industry procedure. At least then scripters won't be spending hours (or weeks) trying to figure out why their perfectly logical script won't function.

If Opensim ever wants a reputation as a reliable, professional project, this kind of garbage coding is going to have to be cleaned up. Weeds in the front yard are not attractive, especially when they've been there year after year. Makes the neighborhood look bad.

(0035220)
BillBlight (developer)
2019-05-17 19:01

Then fix it smart guy...

Everything seems to be "Easy to fix" to you, yet you never actually want to help fix anything , just complain about it ..
(0035221)
SnootsDwagon (reporter)
2019-05-17 19:19
edited on: 2019-05-17 19:34

Bill, I'm a user, not an Opensim system coder. I never said this would be "easy to fix". I said it's fixable... if someone wants to take the actual time and effort to do so. Barring that, write a new function that works-- with a branch. That is basic coding concept. Easy or not, it's a bug that needs fixed.

Looking back, it seems every time I've reported a bug on Mantis I've received this kind of crap from you. You tell me to fix this myself... when apparently you don't have the ability (or desire) to do so yourself. So no thanks.

The Mantis is for reporting bugs. Bug reported. Opensim either works or it doesn't. I'm a user. It's not my responsibility to code the system. It's yours.

(0035222)
tampa (reporter)
2019-05-19 04:18

The project currently only has a handful of people who are actually capable of even attempting a fix, even then the priority for it is relatively low given that over the years this bug has been present various ways have been used to circumvent potential issues. Given all that I have not really encountered much of what you describe using llSleep in my code. The "known" status of this has been around for so many years, if you ask anyone actually writing more complex scripts, they will tell you and what they did to work around it.

While I agree there is a need to clean up code and fix bugs, as is nature with a project in alpha-phase, at the same time, given the small amount of active people developing and submitting patches there are more pressing issues to fix. Not to mention that the project still heavily relies on code donations and people willing to spend their free time to help out and submit patches. What Bill, in his somewhat harsh way, is telling you is exactly that. If there is a bug so severe to you that a fix is require immediately, especially if you have experience in the field, then, if you have the time, attempt to create a patch or just a potential route to a solution, we greatly appreciate that.
(0035223)
UbitUmarov (administrator)
2019-05-19 06:41

llSleep issues are well known and intrinsic to Xengine architecture limitations.
each script event is executed on a full thread for engine limited pool. This can lead to threads starvation, potentially stopping all scripts. To prevent that events are killed after a timeout period, of course breaking the script.
llSleep has always been not recommended for opensim scripts.

The solution for this IS ANOTHER engine. This issues where in fact a major motivation for their development (aurora engine, phlox, xmrengine, etc).

Yengine, a derivative/subset of XMRengine is our current answer for those issues. Several people use it for sometime with minor problems, do its "danger" level is now reduced (until next time I break it..).
(0035224)
SnootsDwagon (reporter)
2019-05-19 07:30
edited on: 2019-05-19 08:27

LOL Ubit. And thanks Tampa for your kind explanation. It is as you mention, harsh treatment of Mantis reporters that makes reporting on Mantis problematic.

I greatly empathize with the limited and volunteer group of coders on Opensim. They have my respect and sympathy. Tough job, truly. But as a retired professional, here is my take on the above valid points:

Fix it, no excuses or rationalization.

I know that sounds harsh itself, but that is the reality of the coding world. We want Opensim to have a good reputation. Whether a new script engine (with its own bugs) is the answer... or fixing the existing scripting engine with some relatively basic fixes... that's for the coders to decide. I've never been one to trade one set of problems for another set. And in truth, considering the extensive warnings in Opensim.ini... I find it difficult to believe Yengine is the solution. It simply wouldn't work on my 5x5 VARs.

On the other hand, I could write a flowchart to fix llSleep() in less than 15 minutes. I'm pretty sure, based on that flowchart, a deep-coder could fix the problem in an hour or less. That's an estimate based on 30+ years of real life experience (now retired, thanks, enjoying it much). I agree it's a pain to fix bugs... but that IS what Mantis is about... and this is a pretty bottom-line basic bug that by all reports, has been known and unfixed for YEARS.

It works on Second Life (no caveats on their wiki). It worked on Inworldz, so apparently they were able to fix it. The question then follows: why hasn't it been fixed on Opensim?

(0035226)
BillBlight (developer)
2019-05-19 10:41

Inworldz did not fix it , they replaced it with Phlox ..

SL, why do you keep bringing that up?

Opensimulator fixing it with yEngine ..

And yEngine works fine on VAR regions, our meeting/testing place on osGrid is a var.

The comments are from early testing, now removed.

http://opensimulator.org/viewgit/?a=commitdiff&p=opensim&h=9c44dc3384cdc13bc11d6cff8e700e338c564d99 [^]
(0035227)
SnootsDwagon (reporter)
2019-05-19 12:11

Okay good deal. Worth a try then. I'll check out Yengine later today. That new comment section is far less alarming. : )

The reason I keep bringing up SL is because if Linden Lab's lame coding staff can make something work, surely Opensim can. I would think Bill, comparing Opensim to SL should be an OBVIOUS connection. "Theirs works, ours doesn't, step up your game." The goal is to offer a viable, functional alternative to SL, right? That was why Opensim was created in the first place. We even used their viewer as a base. How do you not understand that people will regularly make comparisons with SL?

Regarding Phlox: if Inworldz decided to replace Opensim's script engine with Phlox, that in itself is a comment on Opensim's engine and the need to proactively improve it, not make excuses for its failure. If Yengine is the viable "fix" for Xengine, then why is Xengine still being presented as the default script engine instead of Yengine?
(0035228)
BillBlight (developer)
2019-05-19 12:29
edited on: 2019-05-19 12:43

SL, Millions of dollars of dedicated development with dedicated teams for each aspect of the software ...(and we don't even actually know what their code is, only can reverse engineer it from the viewer)

Opensimulator, done by volunteers on their free time for FREE and still have to deal with being treated like they are slaves to people who are not happy with how things work.

Inworldz, was also started as a commercial project to make money.


So if people are not happy with Opensimulator, they are welcome to take the code, pay "Deep Coders", since evidently the people who have worked on this project don't know what they are doing in your assessment, and make their own.

This is exactly what Inworldz did.

(0035229)
BillBlight (developer)
2019-05-19 13:37

Closing:

This is a known issue, has been for years, and is intrinsic to the threading design of xEngine.

Without a refactor of the entire engine, chances of fixing , "Just this" are very slim to none .

The acceptable fix for this, which has been known and used for years, is to NOT use sleep and use timer functions.

The actual FIX (refactor) for this is in the form of yEngine, replacing xEngine.

Closed

- Issue History
Date Modified Username Field Change
2019-05-14 22:05 SnootsDwagon New Issue
2019-05-15 02:43 BillBlight Note Added: 0035209
2019-05-15 02:47 BillBlight Note Edited: 0035209 View Revisions
2019-05-15 08:08 SnootsDwagon Note Added: 0035210
2019-05-15 08:10 SnootsDwagon Note Added: 0035211
2019-05-15 10:22 SnootsDwagon Note Added: 0035212
2019-05-15 10:37 SnootsDwagon Note Edited: 0035212 View Revisions
2019-05-15 20:05 SnootsDwagon Note Edited: 0035212 View Revisions
2019-05-15 20:06 SnootsDwagon Note Edited: 0035210 View Revisions
2019-05-17 03:58 mewtwo0641 Note Added: 0035213
2019-05-17 03:59 mewtwo0641 Note Edited: 0035213 View Revisions
2019-05-17 11:10 SnootsDwagon Note Added: 0035214
2019-05-17 11:11 SnootsDwagon Note Edited: 0035214 View Revisions
2019-05-17 14:18 BillBlight Note Added: 0035215
2019-05-17 18:46 SnootsDwagon Note Added: 0035216
2019-05-17 18:47 BillBlight Note Added: 0035217
2019-05-17 18:47 SnootsDwagon Note Edited: 0035216 View Revisions
2019-05-17 18:48 BillBlight Note Added: 0035218
2019-05-17 18:58 SnootsDwagon Note Added: 0035219
2019-05-17 19:00 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 19:01 BillBlight Note Added: 0035220
2019-05-17 19:03 SnootsDwagon Note Edited: 0035216 View Revisions
2019-05-17 19:19 SnootsDwagon Note Added: 0035221
2019-05-17 19:24 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 19:26 SnootsDwagon Note Edited: 0035221 View Revisions
2019-05-17 19:26 SnootsDwagon Note Edited: 0035221 View Revisions
2019-05-17 19:28 SnootsDwagon Note Edited: 0035221 View Revisions
2019-05-17 19:33 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 19:34 SnootsDwagon Note Edited: 0035221 View Revisions
2019-05-17 22:43 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 22:46 SnootsDwagon Note Edited: 0035214 View Revisions
2019-05-17 22:52 SnootsDwagon Note Edited: 0035216 View Revisions
2019-05-17 22:53 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 22:54 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-17 22:56 SnootsDwagon Note Edited: 0035219 View Revisions
2019-05-19 04:18 tampa Note Added: 0035222
2019-05-19 06:41 UbitUmarov Note Added: 0035223
2019-05-19 07:30 SnootsDwagon Note Added: 0035224
2019-05-19 08:16 SnootsDwagon Note Edited: 0035224 View Revisions
2019-05-19 08:18 SnootsDwagon Note Edited: 0035224 View Revisions
2019-05-19 08:27 SnootsDwagon Note Edited: 0035224 View Revisions
2019-05-19 09:01 Allen Kerensky Note Added: 0035225
2019-05-19 09:15 Allen Kerensky Note Deleted: 0035225
2019-05-19 10:41 BillBlight Note Added: 0035226
2019-05-19 12:11 SnootsDwagon Note Added: 0035227
2019-05-19 12:29 BillBlight Note Added: 0035228
2019-05-19 12:40 BillBlight Note Edited: 0035228 View Revisions
2019-05-19 12:41 BillBlight Note Edited: 0035228 View Revisions
2019-05-19 12:43 BillBlight Note Edited: 0035228 View Revisions
2019-05-19 13:37 BillBlight Note Added: 0035229
2019-05-19 13:37 BillBlight Status new => closed
2019-05-19 13:37 BillBlight Resolution open => won't fix


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker