A Problem with volume detect?

Hello all, Im experiancing some weirdness. Ive been experimenting with how volume detect handles linked objects. If you have an object with a cross section like this:

 ___________________________
|                           |
|                           |
|      ______________       |
|      |             |      |
|      |             |      |
|      |             |      |
|      |             |      |
|      |_____________|      |
|                           |
|                           |
|___________________________|

Passing a volume detect cube through this object, will first trigger a collision_start for the outer cube, then a collision_start for the inner cube, a collision_end for the inner, and finally a collision_end for the outer. This seems reasonable, save for one crucial aspect, llDetected data. Currently, all values give information about the parent of the linked set, no matter which prim, child or parent, triggered the event.

The way volume detect works now only makes sence for linked sets whose prims
do not interpenitrate one another, like this one, for instance:

 ______________       ______________       ______________       ______________
|              |     |              |     |              |     |              |
|              |     |              |     |              |     |              |
|              |     |              |     |              |     |              |
|              |     |              |     |              |     |              |
|              |     |              |     |              |     |              |
|______________|     |______________|     |______________|     |______________|

I find vol detect's behavior with the former irritating - the set should be treated as a unit, when it enters the volume detect prim, it should trigger a collision_start event, and if and only if the entirety of the link set is outside of the volume detect prim, should it trigger a collision_end event; one pair of collision_* events per object, not per prim.
Either that, or the current behavior should remain, with one exception - child prims will give their llDetected data to the collider, not the data of the parent. Though if the latter is implemented, we would need a way to know if one prim is the child of another.
==Chris

Volumedetect is just plain odd with collisions. With physics, it appears to work similar to the way collision_start used to work (firing repeatedly), with several strange quirks here and there.

For starters, volumedetect needs to be fixed with actual physical calculations, because doing the wrong thing with it can really screw a sim's performance.

As for volumedetect's behavior, one thing I've noticed is when physical, the desired object can interpenetrate just slightly and trigger a collision_start event... as well as a collision_end.

Now, the workaround I've built for this is to take the key of the last collided object and run it against the current one. Like so:

key collided = "";

// ... ... ...

collision_start(integer total_number)
{
     integer i;
     for(i = 0; i < total_number; ++i)
     if(llDetectedKey(i) != collided)
     {
           // Do stuff
           collided = llDetectedKey(i);
     }
}

... thus keeping the calls in-line, repeatable, and without the dropped calls I was receiving with other collision methods.

If you feel like testing this further, our game (Primmies) makes extensive use of VD, physical cubes. Remind me to send you a debug version.

I cant' help specifically with your problem, but I can add another curiosity to the list of llVolumeDetect() behaviour.

Two truncated pyramids linked back to back so you get a pseudo-cone of detector volume, just like a detector for an automatic door. If you walk through the cones with the obvious coding the door opens but does not close. A little error checking reveals that both cones fire collision_start() events, but only when you leave the second cone does the collision_end() event fire.

I sorted it with a bodge around, but it was a little confusing at the time.

I'm finding that collision_start events aren't firing when an avatar sits on the scripted object until the av stands (which then of course initiates both _start and _end events all at once). I was looking at volume_detect as a possible work around but it sounds wonky based on some of these comments.

Having searched for "sit" and finding little to nothing related to this issue, is what I'm describing already a known issue? and is there a common work-around? perhaps using volume_detect? My script is going into a fair number of objects so I'd rather avoid sensors which from my reading seem to be the popular solution.

I've been thinking about this - one question is why you want volumedetect anyway...

But regardless of that thinking about sit-hacking suggests that when you sit on a object you don't strictly travel through the intermediate space, at least not in a normal fashion. You don't collide with walls, doors etc. either...

When you stand up, you *do* stand up in place - and so you do trigger the collisions normally.

Makes home security rely on sensors I suspect. But the changed() event is famously (maybe infamously) triggered on sitting and standing of course, will that help your particular application?