"Attach" event - lost?

[Domitan Redenblack]

I posted another thread about missing Attach events, and this was answered by Cerise (thanks!).

How do I continue that thread? No way to ask further related questions? Further discussion prohibited? Holy Carp!

Typical LL, why don't they allow this? Moral: DON'T TICK "Answered" for your questions. Take that, LL.

 

So: previous "answer" was: If the state is busy when the attach event occurs IT IS LOST! OMG!

I thought events were queued! There is only one state in this script, so how can an event be lost?

 

[Dora Gustafson]

---

Domitan Redenblack wrote:

I thought events were queued!

There is only one state in this script, so how can an event be lost?

---

The server could be held busy in some event.

This would happen if you occupy the server in an infinite loop.

The server has to finish one event before it can handle another.

[Void Singer]

events can be dumped on state change change it you are not careful (all queued events after the event a state change is called from, or any queued during a the state exit event).

the workaround is not to use state exit and to call a fast timer and state change from there, but events could still be lost if they queue up after the timer is called but before it is fired. the only other workaround is to never change states or never use events that can fire without you being able to handle them.

additionally, some events, if triggered before the previous one of the same type has fired, will be replaced the current one (not true for most events that support "detected" functions, IIRC sensor, does this, "target" events, and run_time permissions) [and/or may be ignored if they try to queue while it's firing (on_rez?, attach?), this part is not thoroughly tested]

and of course, if the script is set not running, those events won't be fired, and if it crosses a region boundry or goes back to inventory before being set to running again all queued events will be lost.

and IIRC if you are in a no script zone, and have not taken controls, events queued in that zone may be lost on region change.

 

I have never seen an attach event fail to fire outside of those circumstances though.

[Cerise1488303085]

Yes, attach() can be missed at rez time if the script was in the middle of a long loop when last saved. Independent confirmations are here and here.

[Domitan Redenblack]

Hmmmm....

I will have to run some tests. It does not seem that I am getting "attach" events at all.

Right now I am using llGetAttached() in the state_entry handler, which works fine...

If no new "attach" event occurs, is there any reason the original "attach" would be lost (no state change, no crossing sims, script running, active script zone yes, etc)

 

[Cerise1488303085]

What happens to your script after state_entry? Is it able to service any other events, or is it spending long times stuck in single event handlers? In the extreme case, an infinite loop in any one event handler will prevent the script from handling any other events at all.

[Void Singer]

 

---

Cerise wrote:

Yes, attach() can be missed at rez time if the script was in the middle of a long loop when last saved. Independent confirmations are

here

and

here

.

---

 

contrary evidence here.

looks like we need to go and test use cases on this =/

[Dora Gustafson]

---

Domitan Redenblack wrote:

I will have to run some tests. It does not seem that I am getting "attach" events at all.

Right now I am using llGetAttached() in the state_entry handler, which works fine...

---

I'm getting suspicious. Are you having an attach event handler at all?

Like this:

attach(key atato)

{

if (atato != NULL_KEY)

{

agents=[];

service( atato );

}

}

If 'yes' and you still are not getting "attach events"  you better show your code:)

 

 

 

 

 

[Cerise1488303085]

Here is a pathological example. It is compiled to LSO, the slower execution makes this easier to test. The loop is inside a user function, it is much easier to reproduce that way. The loop spends all its time flooding the event queue with link messages, and the flood causes the trouble.

If detach is a short time after a ping message prints, the "Bye!" and "Hello!" usually appear on reattach, after the loop finishes and the events can be processed.

If the detach is a few seconds after a ping message, but before a new one, the "Hello!" and "Bye!" tend to be skipped. The event queue is stuffed with the pending link messages so there is nowhere for the attach events to go.

The effect is not unique to self generated events or link messages, but this is an easy way to show what can happen.

 

 

integer gCount;MessageFlood(){    integer x = 0;    do { llMessageLinked(LINK_THIS, 0, "", ""); } while( ++x < 10000);    llOwnerSay("ping " + (string)(++gCount));}default{    state_entry()    {        llSetTimerEvent(.01);    }    timer()    {        MessageFlood();    }    attach(key id)    {        if (id)            llOwnerSay("Hello!");        else            llOwnerSay("Bye!");    }    link_message(integer sender, integer um, string str, key id)    {        integer y = 0;    }}

 

 

 

[Void Singer]

that's why I like you Cerise... you find the cases I miss....

although, to be fair, it's not the loop causing that, but the flood of pending link_message events maxing out the event queue (which is only 64 deep)