Mono Missing on_rez ?

I'm seeing this occasionally now.

Moved script back to non-mono works like a charm

clarify?

on_rez event isn't firing reliably when running mono.

Put the the enclosed script in a prim and rez from inv. Sometimes the event fires, sometimes not.

In non mono, fires every time

integer Live ()
{
if (llGetAttached() != 0) return TRUE;
else return FALSE;
}

default
{
state_entry()
{
if (Live ())
{
llSetPrimitiveParams([PRIM_PHANTOM, TRUE, PRIM_SIZE, <0.01, 0.01, 0.01>]);
llSetAlpha(0.0, ALL_SIDES);
}
else
{
llSetPrimitiveParams([PRIM_PHANTOM, FALSE, PRIM_SIZE, <0.5, 0.5, 0.5>]);
llSetAlpha(1.0, ALL_SIDES);
}
}

on_rez(integer start_param)
{
llResetScript();
}
}

Is it possible that the llGetAttached is not firing properly or otherwise throwing a wrench into the works? Might try a test by putting a small delay in your Live() function before calling llGetAttached. Just a thought...

Report the bug with the repro - or it likely won't get fixed.

/esc

first search jira, especially for attach events, seems I remember this being reported, already worn attachments skipping on_rez.... if not there proceed.

if it doesn't reproduce reliably, check it on a few different sims, could be server version dependent, or load dependent, and make sure you recompile for each sim to be sure it isn't a compile issue (doubt it, but who knows).

Actually I wouldn't have expected the sample to work reliably in the first place. It is relying on a sequence of events happening that are not necessarily documented to happen that way.
If the attachment status is set immediately after the on_rez, but before the on_rez event has finished processing the llResetScript then the attachment status will be lost in the reset.

I don't see that it could be described as a bug, rather a quirk that happened to work pre-mono.

I don't follow your logic regarding the sequence of events there.

The script as shown should reset on_rez.

Then as it resets the first thing it should do it fire the state_entry event. This should then test the attachment state.

Why would that not work or be considered a 'quirk' other than being a bug

I am basing it on the assumption that the attachment state is set when the attachment event is fired. So if the on_rez is fired, then the attachment event is fired, this may be being processed prior to the llResetScript being called.

I'm not using an attachment event [assume you mean change event].

I'm testing the current attachment status, I would have thought that should return the current attachment state ?

I want to make sure I understand this before I post in jira [which I am searching atm]

Posted in Jira

https://jira.secondlife.com/browse/SVC-3431

I'm not following this, not that I'm a great expert in attachments.

How can an object get an on-rez event other than being rezzed as part of the user selecting it to be worn from their inventory? That is, is there a way for an attached object to be rezzed in an operation different from when it is initially attached?

If not, then it would seem that when an object is selected to be worn, the order of events could be either rez then attach, or attach then rez couldn't it? It would be a race condition which occurred first.

How do you know the on-rez event isn't firing? Your code assumes that the attach event comes before the rez event, but if the order of events is rez then attach, you'll get the state of not being attached.

You might try just doing an llOwnerSay in the on-rez event handler to test if the event is firing.

Its not an attach event, its checking the attach status in the state_entry event.

Now it does appear if could be either the attach query failing or the on_rez event.

Am checking that now

I can't get this to reproduce at all, in Mono or LSL2.

You are at 260201.3, 249481.0, 4085.9 in Bug Island located at sim3884.agni.lindenlab.com (63.210.156.42:13001)
Second Life Server 1.24.9.98659

No matter how many times I try.

Code re-pasted in tags for clarity and those who use GreaseMonkey:

integer Live()
{
    if (llGetAttached() != 0)
        return TRUE;
    else
        return FALSE;
}

default
{
    state_entry()
    {
        if (Live())
        {
            llSetPrimitiveParams([PRIM_PHANTOM, TRUE, PRIM_SIZE, <0.01, 0.01, 0.01>]); llSetAlpha(0.0, ALL_SIDES);
        }
        else
        {
            llSetPrimitiveParams([PRIM_PHANTOM, FALSE, PRIM_SIZE, <0.5, 0.5, 0.5>]); llSetAlpha(1.0, ALL_SIDES);
        }
    }
    
    on_rez(integer start_param)
    {
        llResetScript();
    }
}

Of course today I can't replicate it.

I think a bad time dilation makes it worse, so I'm trying to get to the location where I first discovered it. They had a TD of around 0.6

Yesterday this was reproducible, today can't do it

I believe the sequence of events is 'on_rez' followed by 'attached'. I wouldn't count on llGetAttached() returning a true value until 'attached' is fired, though it might. Resetting the script in 'on_rez' clears all pending events, which I would GUESS includes the 'attached' event. At some point llGetAttached() should return a true value, but as others have stated it's probably a bad idea to count on it in the way the original script does.

Why not just remove the script reset and put a little logic in both 'state_entry' and 'attached' handlers?

The LSL language is documented as running each event to completion before handling the next event.

However pending events are not documented as being saved over script reset.

All the more reason to think it's a race condition.

When I said attach event, I didn't mean firing an event, I meant when the system decides something is attached. This all happens sequentially, but with processes running in parallel with no defined order of completion (AFAIK) so if you do a "simultaneous" rez and attach, there's no guarantee of what order these occur in, but they definitely aren't simultaneous.

Did you try just putting an llOwnerSay in the rez event handler? That will tell you if it really is missing the event firing.

That makes more sense.

Even so it should still work reliably, the environment should be up once the State_entry event is fired. if it isn't it is most defiantly a bug.

As for the trace suggestion, that was the next thing I tried and of course I got nada. Cannot replicate this now.