|
|
|
llSetTimerEvent(0) should always stop a previously set timer-event.
======= // timer() ======= // no_sensor() if (timer_triggered) { // the bug was triggered, restart the script llOwnerSay((string)sweep_time); llResetScript(); }else { // the bug was not triggered, raise the time a bit, and try again sweep_time *= 1.01; llSensor("you won't sense me", "", AGENT, 1, PI); } } } ======= Is this a timer-bug, or a llSleep-bug? In the llSleep-sweep script, you can see the longer the base_time is, the longer the sweep_time must be to trigger the bug. ======= Second Life 1.21.2 (96080) Sep 9 2008 09:42:01 (Second Life Release Candidate) //
// Resetting never triggers the timer default { state_entry() { llSetTimerEvent(0.01); llSetScale(<1, 1, 1>); llSetTimerEvent(0); } timer() { llSay(0, "timer triggered"); }} Isn't llSleep() supposed to stop the progress of the [timer that triggers the] timer-event?
I wouldn't think that llSleep should stop the timer progress. To me, that's the whole point of event queuing, the system is too busy (sleeping in this case) to handle the raised event. I wouldn't want llSetTimerEvent to clear an event queue completely, though if it could clear only timer events from the queue, I could see how that would be helful. Maybe a new function is needed, though so that we have both options.
1) llSetTimerEvent(0) stops any further events from being raised, but currently queued ones will still be processed. 2) llClearTimerEvents() clears any queued timer events. llSetTimerEvent(0) is meant to stop the timer from triggering. however if the timer has elapsed before it is clearned with will have placed a timer event into the cue. If this even in the cue is not cleared when the timer is stopped, as it did before MONO, the result is lot of scripts out there that are triggering a timer even when they should not.
A typical use might be to read an external database (say for a stargate teleporter). the script sets a timer event as a timeout while requesting data using a HTTPRequest. The timer is cleared in the HTTPResponce event when the data is received. if the data is not received the timer() even will trigger and the script can re-request the data or give an error message. If the timer is not cleared in the HTTPResponce correctly under MONO (as with this bug) the result can be an error message being raised when there was no error. Locking a script into an endless loop of requesting data. The llSleep command does not, has not, and should not pause the timer. All a llSleep does is give up it's share of the scripts processing time to other scripts until the x.x seconds have past. llSleep is not related to this problem, it is only used to simulate the timer taken by other processes that may be going on while the timer event is set. ie. the HTTPRequest used above. You could use a llEmail in place of a llSleep, or any event that will last more than 5 seconds so the timer is due to be triggered at the point that it is reset to a new value. Darling Brody Hmmm, that's funny
We have a new server now, and the bug doesn't seem to repro anymore. ======= Second Life 1.21.2 (96080) Sep 9 2008 09:42:01 (Second Life Release Candidate) darling brody said:
"A typical use might be to read an external database (say for a stargate teleporter). the script sets a timer event as a timeout while requesting data using a HTTPRequest. The timer is cleared in the HTTPResponce event when the data is received. if the data is not received the timer() even will trigger and the script can re-request the data or give an error message. If the timer is not cleared in the HTTPResponce correctly under MONO (as with this bug) the result can be an error message being raised when there was no error. Locking a script into an endless loop of requesting data. " I thought this to be the issues as well, so I tried some testing. Seems as it is not a bug but more a result of an incorrect use of the http_response time out. I used the following script: default timer() { llSetTimerEvent(0.0); k = llHTTPRequest("http://xxx.xxx.xxx.xxx:xxxx/somethingtest.php",[],""); } http_response(key r, integer i, list l, string b) else if(i==499) { llOwnerSay("server stopped responding"+" - "+llGetSubString(llGetTimestamp(),11,18)); } } This produced the following results (as expected): You have to remember, the http_response timeout is 60 seconds, therefore any timer that uses the llHTTPRequest will still be fired. What I did here was to stop the timer temporarily and then only refire if the server was active. You are clearing, (llSetTimerEvent(0.0)??), the timer on valid response. Well the timer is still running while waiting for the http_response event to receive a 499 status code. I hope this helps your coding, I had trouble with this as well when I first started to use llHTTPRequest. @Cappy Frantisek
You dont understand the problem. probably because I didnt descript it properly. let me try again // excuse any compile errors, i typed this directly into the JIRA without testing it in world // the main script calls the UpdateGate event to re-fresh it's details in the database when it gets a link message or some other trigger that has no bearing on the below code. state UpdateGate http_response(key r, integer i, list l, string b) { <---- do some stuff here to check we got the correct information. llSetTimerEvent(0); // stop the timer because we got the information we asked for. <--- and this is the timeout that can trigger when it shouldn't }timer() // failed to get data. try again { k = llHTTPRequest("http://xxx.xxx.xxx.xxx:xxxx/somethingtest.php",[],""); llSetTimerEvent(120); // give server 120 seconds to respond before retrying }} As you can see the timer is being used to detect when HTTPRequest fails to get a responce. Of course you would have a lot more error checking in a real script, but you will still have a false fail if the timer is not reset and all pending timer events are cleared. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The timer is set to 5 sec, and after 10 sec, you clear it. This will result in one timer event being triggered, and it does?