|
|
|
I agree that _RESTART would be darned near impossible and when you get down to it, what's the diff between _RESTART and _START
_STOP is another matter, if nothing else it could be triggered on the restart messages (5, 4, 3, 2, 1, seconds) for 'controlled' shutdowns, on a crash, yeah, no way to do that but... does a sim know if it had crashed when it comes back up??? then a _CRASHED in addition to a _START could be useful (script: ok I'm gonna start up but oh crap I crashed, better check on a,b,c..etc..) I like the _CRASHED idea. How about _SHUTDOWN instead of _STOP, no confusing a shutdown with a crash then.
This aspect is just pie in the sky, ideas thrown out to get us all thinking. My priority is to get the constant renamed before it hits the main grid (and we get stuck with it). It seems like everything except for _START have issues but even _START would be great to have.
I think CHANGED_REGION_SHUTDOWN would better be triggered from the restart messages sent to the sim. Yes you would get one at 5,4,3,2,1 min, 45, 30, 15, etc seconds... just need to pass the 'countdown' to the event handler. Also somethign for 'shutdown cancelled' (-1 for the countdown) for the 'never mind' situations where a restart is cancelled/postponed.
I broke the constant name change of _RESTART to _START from the rest of this, since I can do that part now but not the rest.
I have no problem with that. I saw the change hit the Trunk along with all of HTTP, I've updated the wiki accordingly (though some work is still needed on the individual pages). Good work all around, thanks for your efforts.
I think _START and _STOP is all that's needed. (I don't see a big diff between stop/shutdown I just like shorter words
but "crashed" and other anomalies can be determined by the scripter given just start and stop and a global variable. I'm alittle confused how it would be possible for a region to be started for the very first time and there be any scripted object already in it??? But if so, the script would receive only a START event and the global would be null. During scheduled maintenance, the script would receive a STOP and can set the global to indicate this. So when the script gets a START, if the global is set it knows it has just experienced a restart. The global could even store a timestamp to calculate if the restart was short lived. If a script receives a START and the global is anything other than the stop indicator, it knows a crash occurred and can attempt to figure out what to do about that. How to handle this condition would vary dramatically by the script's purpose. I don't think it is realistic to expect the server to issue a CRASHED event...seeing as it just crashed it may not have state for that. At any rate, I would really really like to see at least one STOP event triggered by the "This server is going down in X minutes" mechanism. It would help with http-in in that your dyndns solution could be notified to switch to an "offline" page or fallback server. I assume vendor creators would also find it very valuable to temporarily suspend transactions during "iffy" periods. actually, I think just four(three) are needed
CHANGED_REGION_START _START and _CRASH are an either/or... either the region is _STARTing after a normal shutdown or the region or _CRASHED and is coming up after an abnormal shutdown, you get one or the other, not both. _SHUTDOWN comes at the 2 minute warning for a manual restart (since you can get either a 2 or 5 minute delay, choose the common one) _SHUTDOWNCANCELLED is.. well, if you "DELAY" the restart LESS THAN 2 MINUTES BEFORE the restart goes off, you get a _SHUTDOWNCANCELLED.. since that one is, but you may get another one in an hour, which will give you the 2 minute warning _SHUTDOWN |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
LSL: CHANGED_REGION_START
Resolved
_RESTART is not currently feasible since regions simply do not know if they will be coming back.
_STOP I'm really hesitant about since the only time it would work is on a planned and pre-announced stop, even then I'm not sure how much knowledge the sim really has that it is shutting down. I suspect very little which may make this unduly difficult. Even then it wouldn't get every stop - crashes and immediate shut downs offer no time to give scripts extra cycles. I think the inconsistency would lead to scripter frustration.