Script turned off during long test runs

I am scripting a train for a mall that roves around a sim. Twice now I have discovered it stopped on the tracks with its script turned off. Once early in development (which I shrugged off because that wasn't all that was wrong) and then again today after the train had run for most of a day.

When I brought up the edit dialog and checked the 'running' box, the train continued on its way happily. It didn't need a reset or anything. It was very much as if someone had simply unchecked the box.

However, this was on a private estate. And no one with access turned it off.

I've tried reproducing the scenario intentionally, but haven't been able to do it. A script crash or running out of memory causes the script to stop, but the running checkbox remains checked. So that's not a match for what I saw. There's a script command that can uncheck the box, but no such command exists in this train.

Someone suggested to me that scripts can get turned off during sim crashes. And I heard that this sim did crash today, so that's the only possible explanation I have. But it doesn't sound all that convincing.

Does anyone have any clues what's going on here?

Thank you.

PS: I did search the forum before posting this. I found old references to scripts getting turned off from 2003, but they were both old and described needing to reset or even recompile the scripts to get them to work again whenever this happened. And that wasn't the case here.

Is this on the main land or island? and if on an island do you own the island?

The reason I ask. I had a physical object floating around an island. Next day I came back to check somthing and found Physics off and the script set to not running.

It seems to me that SL has some not-too-obvious ways of defending itself against physical objects taking too much time and freezing the physics engine. If it detects an object that's interpenetrating another object, which is usually something that'll cause Havok to go nuts, I've seen SL sometimes proactively turn the object non-physical, or worse yet, turn the script inside it to not-running. Very annoying... sounds like it's what's going on here. It's even more annoying because glitches with physics happen all the time, and can result in a perfectly innocent-seeming physical object ending up interpenetrated with something.

I have had this happen daily with a physical vehicle on a track.
i think SL is turning off physical vehicle scripts onec daily
im working on a way to turn it on and off automaticly that may bypass
SL's shutdown of my script.
this could also be a physics collision problem that shuts down scripts
that are inside an object but when i find my object its never inside another
-LW

Thanks for the input. I have lowered the speed of my train, and it has run for days without failure now. So... while it's hard to say for sure unless a developer speaks up... all evidence from these long running tests suggest strongly that it happens when the physics engine ends up with an interpenetration with the train tracks. It appears to be a failsafe.

I wrote a monitor script to see if it could at least detect that the primary script got stopped in this circumstance (and possibly do something about it). But my testing determined that when this situation occurs _ALL_ scripts are set not running and reset on the physical object. In addition, the object loses its physical status. So it's dead dead dead and can't recover.

Slowing the train down some seems to have eliminated the problem. So it would seem that above a certain speed threshold, the sometimes 'moody' physics engine can mess up and cause this kind of failure. (Admittedly, this train was previously moving quite fast.. much faster than an avatar can fly)

I wonder if you could do something to remotely reload/reset the script (after attempting some type of communication test to see if the script is still alive)? I'm a pretty "new" scripter, but the llRemoteLoadScriptPin command looks like it might serve this kind of purpose: if it worked, you could have a script running in a non-physical object somewhere in the sim run periodic "are you alive?" tests and, if they failed, force a script reload on your vehicle.

I could see where slowing the vehicle down would reduce the likelihood of physical object "penetration" overload, and that might be adequate for your purposes in itself without any extra scripting.

That's a good idea. If the train continues to have troubles, I may try that. I would rather have a situation where the train doesn't biff in the first place though. And I think it may be there now.

Building a bullet train in SL?

Anyway, I have my own train/tram scripts that are available for sale (not packaged up yet, still need to write instructions), and haven't run into this problem before. Though, I've had the speed at a little less than avatar flying speeds.

It's possible the 'moody' physics got confused at the speed, and perhaps thought is moved down a bit into the track/ground. Hope it works better for you now.

You might actually want to have the train hover a very small distance above ground height. Then at least ground collisions will be lessened (particularly if you are going along smooth and level tracks).

I think there has been a change lately that is affecting this. Probably due to an exploit fix.

I've been having problems with scripts being stopped for no reason a lot lately, and none of these are using Physics. And I've done the remote load with Run set too, and still they end up getting turned off.