Attach event troubles

I am absolutely positive that this problem is related to some quirk of LSL that I am frankly just not aware of, but unfortunately I have no idea what the problem is and why it seems to work almost at random for some things and not others. Hopefully one of you kind forumgoers will be able to set me straight.

I have three objects. In these objects, I wish to have an "I have been detached" message announced, using the attach event, like so:

    attach(key attached)
    {
        if (attached != NULL_KEY)
        {
            llOwnerSay("Attached");
        }
        else
        {
            llOwnerSay("Detached");
        }
    }

I have three objects, A B and C. Object A is a complicated pet with a fair amount of code in her, utilizing multiple scripts.

Object B is a newer version of Object A, which contains (what I consider) streamlined and more efficient code; the overall amount of code and information and the complexity of said code are far more advanced than Object A, but Object B, in theory, should have more available runtime memory than Object A.

Object C is a prim with only the above script in its default event.

When I attach Object A, it works.
When I attach Object B, it works.
When I attach Object C, it works.

When I detach Object A, and there are no other scripts "running" (i.e. a script with particle events, a 'gun' mode active, etc.), it works.
When I detach Object A, if there are other scripts "running", it doesn't work, and the "deatched" message is displayed upon reattachment.
When I detach Object B, regardless of the states of the other scripts, and even if I put the above into a separate script by itself, it doesn't work.
When I detach Object C, it works.

My question is, why? Why does it work sometimes and not others? According to the LSL, each script has its own individual 16K memory allotment. LSL also says that "[a detaching object] will be given a limited amount of CPU cycles to run its attach event before it is derezed." How much memory is that, and how could I ensure that the attach event is given these CPUs before the others (other than putting duplicate attach events into all scripts and all states, which could cause problems with multiple detach messages)?

I've been messing with this for a while now and I just can't seem to figure out a solution to the problem; rather than continuing to shoot arrows in the dark, I figured I'd ask you kind folks for some advice and wisdom on the subject. Thanks in advance for the help!

Memory and CPU cycles are different things. Consider this script:

integer i = 0;

default
{
    state_entry()
    {
        while (TRUE)
        {
                // Do anything here
                i++;
        }
    }
}

This uses very little memory - the space for the code, and the space for one variable. But, it's an infinite loop - the state_entry function never returns. So if you had something else in there, say a touch_start handler, and someone touched it, the touch_start handler would never get called, because the script would never exit from the state_entry handler.

That's an example of 100% CPU use, where you're doing something ALL the time. You probably don't have an infinite loop like that, but you probably do have some other events that require a lot of handling. Remember that all events are added to a queue, in the order they are received. So, if for instance you have a fast timer, you could have several timer events in the queue. Or you have a fast sensor, or a listener - all of these put events in the queue. When you detach the object, the attach event (with a NULL key) gets added to the queue, behind any other events that are already in the queue and waiting for the script to process them. it's possible that the script never gets around to processing the detach event in the time it has available to it between the detach and the derez.

As a test, try dropping the object instead - if you find that working every time, then you can be pretty sure that your script is too busy processing other stuff to be able to get to the detach event in time.



That's interesting, and it means that the CPU cycles are split up between all running scripts in the object. Which makes sense if you think about it, I guess.

...

At least, that's what I think is happening. I could be wrong

Thanks, Ziggy. That certainly helps me to dig deeper into the problem, and you were right about the drop test: dropping the object always worked.

The question remains, though: what part of my scripts is keeping the CPU cycled tied up on detach in Object B that isn't doing it for Object A?

My design is like this: I have five scripts in Object B, one of which is a 'master control' script. This master control script, on attach or rez, resets. In its Default event, it uses llResetOtherScript() and a simple loop to reset all -other- scripts in the object (minus itself, of course). When each script is reset, the Default state initializes itself by pulling data from notecards and listening to 'global' variables passed on from the MC with llMessageLinked. Each script announces itself upon restart, and announces when it passes into a state called Waiting.

In the Waiting state for each sub-script, the script literally does nothing. There's an empty state_entry, and a link_message event. When the script receives a link message (like 'gun' or 'glow'), it jumps off to other states and performs the necessary functions... but until it receives those link_messages, the scripts are doing absolutely nothing.

When all is said and done, the object has only two running functions: a pair of closed Owner-only listens on channels 10 and 20 (one to accept commands, the other for a Ventriloquist script). No timers; no ParticleSystems; no dataserver calls. -Nothing-.

This is the same way that Object A works: MC script with sub-scripts. Object A's code isn't as clean as Object B's, and doesn't do nearly as many dataserver calls, but after initializing, Object A and Object B are pretty much doing the same thing: nothing.

So. What the heck is eating up my CPU cycles? For instance:

state waiting
{
    state_entry()
    {
        llOwnerSay("Particles initialized and waiting.");
    }

    link_message(integer sender_num, integer num, string str, key id)
    {
        if (str == "bling")
        {
            state bling;
        }
        else if (str == "particles")
        {
            state particles;
        }
        else if (str == "orb")
        {
            state orb;
        }
        else if (str == "ring")
        {
            state ring;
        }      
    }
}

The above is the most 'complicated' (has the most possible choices) of the waiting states of all the scripts. So where are my precious CPU cycles?!

I don't know, I would have to see all the scripts to make a guess From your description, nothing jumps out as a possible contender. And like you said, a complex if sequence inside a listen event doesn't use CPU cycles if that listen event doesn't get triggered. So if the scripts are just sitting idle, the main script should have the time to process the attach event.

You don't have any running timers, or repeated sensors? No control event handlers? Any chance you used collision instead of collision_start? Any of those could make a difference. One ugly way to debug this would be to put an llOwnerSay as the first line in every event handler in every state in every script. Make it say something that tells you which one it is. Maybe do the same for loops too. That might give you some clues, if you see some code executing when you don't expect it to.

Once an object is detached there are a very limited number of CPU cycles available to it's script.

Prior to 1.7 you could manage to get some simple things done in the remaining CPU cycles.

After 1.7 they have decreaed the priority of scripts so it is hard to reliably do ANYTHING in a detach event.