Timeout Function and Event pair.
Anna Salyx
Currently if we need to set a timeout for script logic, a timer event needs to be created to check the status of the script logic. If multiple logical timeouts are needed concurrently, a more constant, fast(er), timer needs to be created to loop through each logic condition and determine if a timeout for each has occurred.
I propose a new Function/Event pair. A function to setup a timeout condition, and an event that would be raised when this condition is met. Scripting wise, it'd be a matter of simply calling the function to turn on a timeout check and responding to the Event if it's raised. The calling function will be used to turn off the timeout check if the script logic dictates. See examples below.
Function:
llExpire(string Event_tag, integer duration_in_seconds) -- if Duration is 0 or a negative number, remove that event tag.
to turn on an expire event:
> llExpire("listener_01", 30);
to turn off a defined expire event:
> llExpire("listener_01", 0);
provided that an expire tag has not raised the Expired Event,
it can be reset with a new value (this would turn off/remove
the event tag and apply it again in one step)
> llExpire("listener_01", 15);
Setting multiple timout event would a simple as:
> llExpire("listener_01", 30);
> llExpire("change_color", 15);
> llExpire("rotate_object", 60);
Event handling would be as follows.
Event:
Expired(string tag)
Example in use would be
> Expired(string Tag)
> {
> if (Tag == "listner_01")
> { // do the things desired on timeout; }
> }
if two timeout events expire at the same time, two Expired event would be queued up, one after the other, to simply logic.
Additional notes:
Any timeouts defined by the llExpire would only raise one event then be discarded.
Alternatively, it maybe that llExpire events could be made to repeat on the defined interval and it'd up to the script to turn off a given expire tag in the Expired Event if needed. This would prevent the timeout from being lost if the even queue got over filled.
Log In
Jeremy Duport
Although I can see the interest in a user determined tag, it should probably just be in the usual integer handle return form for reasons of least surprise.
float duration.
wrt signatures, a nod to terms in wide use-
integer llSetTimeout(float duration);
void llClearTimeout(integer handle);
timeout(integer handle) {}
integer llSetInterval(float duration);
void llClearInterval(integer handle);
interval(integer handle) {}
or alternatively, dropping one word or the other,
#define TIMEOUT_REPEAT 0x1
integer llSetTimeout(float duration, integer timeout_flags);
Furious Soup
Why limit to just the timeout use case? Allow us to set multiple concurrent timers with handles, à la llListen() / listen.
Anna Salyx
Furious Soup it's not really limited to a timeout if you think about it. It's just the name and base concept of implementation that was in my mind when I wrote it out. making a "llTimerEventNamed( string Name, float duration)" would work just as well, but it would still maybe require a new event. I'm not sure if updating the current event "timer()" to return the timer name would be feasible or if it would break existing content. probably not but it'd need to be studied.
Anna Salyx
added thought - re: expire events being discarded after use. Much like a sensor event there could be two versions:
for a single one time event trigger
> llExpire(string tag, integer duration_in_seconds);
for a repeating event trigger
> llExpireRepeat(string tag, integer duration_in_seconds);
dismissing the repeat event early, or turning off, would be the same as described in the original post: set the duration to zero
> llExpireRepeat( "tag", 0");
Done this way gives more intuitive flexibility maybe.
Peter Stindberg
Check this older suggestion: https://feedback.secondlife.com/scripting-features/p/llsetalarmclock-function-and-alarm-event
Anna Salyx
Peter Stindberg I had skimmed over that one but it seemed (to me at least) to have more of a focus on actual times of day to trigger rather than as a countdown trigger for a given number of second/minutes into the future. The return event seemed to be more time on the clock oriented as well ("hey it's 3:30pm"). Now, I didn't get too deep into the comments on my skim, so didn't see where some of the discussion touched on my thoughts there. I can certainly see the similarities between the two, and it might be that some sort of merging of the ideas would make both some better maybe.
That said, I do like the simplicity of my idea of the implementation better. I think it's more intuitive in use. Most times a set of timeout events are set up on an as need not as a group and so passed list is less than an ideal way to setting those up. I'm not discounting your idea. As a way to set up specific time of day repeating triggers it's awesome, No, I just think it has less application as a multi-timeout countdown trigger replacement. if that makes sense. But that might just be me.
Peter Stindberg
Anna Salyx I should not write comments before I had breakfast. You are right, it's two different things. I didn't notice when I first saw it.