How to delete object B when object A is derezzed?

I have an item that consists of two pieces - Object A which is stationary and Object B which rotates. Object A creates Object B from its inventory when rezzed, and handles keeping things together if it's moved. But if I delete/derez object A, object B is left behind. I can't link them because both are multi prim pieces and the independent rotation would get screwed up. So how do I detect when Object A is derezzed and force Object B to die as well? LL seems to have skipped giving us an on_derez event.

Maybe have B contain a once every 10 second or so sensor event, to llDie() if A is no longer detected? And/or, depending on how Object A is de-rezzed, have Object A use an llSay on some channel that B is listening, to message "I'm about to die; you should die too."

(Please don't sense too much more often than that, for lag reasons.)

Presumably object A is updating object B every so many seconds. What I would suggest in this case is to have a timer event in B that derezzes the object and calling llSetTimerEvent with a time a bit longer than the time between updates (long enough to compensate for any expected lag) every time it is updated.

i.e.
Object A:

default
{
    state_entry()
    {
        llSetTimerEvent(1);
    }

    timer()
    {
        llWhisper(-123, "update info");
    }
}

Object B:

default
{
    state_entry()
    {
        llListen(-123, "Object A", "", ""); // Should have Object A's key too, but I've forgotten how to pass it through on_rez's start_param
        llSetTimerEvent(2);
    }
    
    listen(integer channel, string name, key id, string message)
    {
        llSetTimerEvent(2);
        
        // update stuff
    }
    
    timer()
    {
        llDie();
    }
}

Ack! Sensors? Timers? Listeners? I'm trying to play nice here and minimize the use of resources by this silly little trinket.

Let me clarify a little. The object is generally stationary, but I wanted to allow it to be manually moved as a unit for positioning and the like, so I cheated a bit. The base (Object A) creates the moving piece (Object B) upon rezzing. If A starts moving, it sends a die message to B. Once A stops moving (I use a timer here to try to make sure it's really stopped), it rerezzes B in it's new location. Thus, resources consumed = 1 listener and 0 timers most of the time, 0 listeners and 0 or 1 timers when the item is being moved.

So, not useful as is for, say, a propeller on a vehicle, but so far emminenty suitable for my toy.

Now, say the owner decides to pack up his toy and move. He selects it and takes it back into his inventory. Only B is completely enclosed in A, so when he selects the toy he always gets A (unless he uses the box surround, but why would he do that?) and when he deletes it, B is left behind happily spinning away.

Ick.

Ideally what I want is some way for object A to sense that it is being derezzed so it can kill object B on its way out. Simple, efficient, and low resource requirements. Is there no way to do this?

The alternatives all seem to involve relatively high resourse requirements having object B somehow determine that A is gone after the fact, either using a sensor to detect A for the entire life of B, or a timer-triggered self-destruct that relies on keep-alive messages from A to prevent premature detonation, again for the entire life of B. Pretty outrageous resource requirements for a simple decorative toy that should generally sit around inert for months on end.

Is there no better solution?

Sorry, 'twas well early in the morning and didn't read your post properly. You'll want to use the collision_end event.

Hmmm, novel idea, but collision_end never fires, presumably because neither object is physical, thus no collisions? I can't really make them physical either. In addition to adding server load, getting the two pieces to cooperate with one inside the other and (just barely not?) touching at one point would be a nightmare with physics enabled.

Ack. Sorry, shouldn't try to give advice when I'm hungover.

Think this might be one of those things that can't be done well.

Make it work first. Then worry about lag. My guess is that you won't see any from this simple script.

Build for the future, not for the present...it will be here tomorrow.

Scripts do not get any kind of event when an object is deleted or picked up. You can use llKey2Name() on a timer to see if the parent is gone without using a sensor. If you include the parent's position in its name you could replace your listen also. There is not really a reliable way to measure it, but since listeners have a goofy implementation and are always "active", you would probably come out about even in terms of resources.