Are Collision Events Unreliable?

i put this script into a 2x2x0.5 meter block:

default {
    state_entry() {        
    }

    collision(integer num_detected) {
        llWhisper(0, "collision");
    }

    collision_start(integer num_detected) {
        llWhisper(0, "collision_start");
    }
    
    collision_end(integer num_detected) {
        llWhisper(0, "collision_end");
    }
}

when i walk across the top i get an equal spam of "collision" "collision_start" and "collision_end". when i step off the block i sometimes get "collision_end" and sometimes not. if i stand in place on top of the block touching it it usually dies down and i get a final "collision_end" but if i turn in place it goes crazy again. sometimes when i step off it i get "collision_start" then five more "collisions" and when i first touch it the next time it starts with "collision_end".

1. does walking across the top of an object count as colliding and uncolliding repeatedly? i thought it cared about my bounding box or somethind and not my feet (which don't simultaneously leave the block anyway).

2. any reason why when i stop colliding with it i sometimes get "collision_end" and sometimes not?

3. is there any way to get "collision_start" when i first touch it and nothing at all until i stop touching it at which point i get "collision_end"?

all of this was done in a fairly lag free environment.

Recently the collision behavior was changed (roughly five patches ago). From what I can tell:

"collision" is called repeatedly, so long as an object remains collided with the surface in question (avatars, prims, etc).

"collision_start" is now slightly less reliable, usually calling when an object begins to collide with another one, but also roughly every so often with avatars if they move about on the object in question.

"collision_end" is more of a wildcard in my experiences, and is the least useful of the three that I've seen.

In general, "collision" appears to be the most reliable call it this point, whereas before the patch that changed the behavior, "collision_start" was the way to go.

Something I've never seen answered is this: how often does the collision() event fire? Ideally, collision_start() fires once when objects begin colliding, collision_end() fires once when objects stop colliding... but how frequently does collision() get called during the collision? oO

As is my understanding of it, roughly 0.1 second intervals. Let's see.

*tests in world*

Yes, roughly 0.1 second intervals. I did make one mistake, though - "collision" is only called while the colliding object is still in motion. If it stops, the event is no longer called.

ugh. there goes another idea. thanks for the info guys. i bug reported this and i would appreciate if you want to use those collision events if you would report them too. i need real live working reliable collision_start and collision_end events for so many things it's not even funny.

Actually, Zuzi, using a timer based on the "collision" call usually works well enough.

Example:

integer is_collision = FALSE;

collision(integer total_number)
{
is_collision = TRUE;
llSetTimerEvent(1.0); //Overwrites for every collision call
}
timer()
{
is_collision = FALSE; //When we're not colliding for a second, call this.
}

My personal experience:

Bug This

As with that problem, Al - the only suggestion I can give you is to use states, timers, and llGround(ZERO_VECTOR) versus llGetPos() if land_collision isn't working for you. In my experiences, it usually works fine - but then, I'm not sure what, exactly, you were testing.

Example:

integer interval = 5.0; //time between checks

state_entry()
{
llSetTimerEvent(interval);
}

timer()
{
vector pos = llGetPos();

if(pos.z <= llGround(ZERO_VECTOR) + 5.0)
deployLandingGear();

else
raiseLandingGear();

llSetTimerEvent(interval);
}

... the state part coming in when you're flying or not.

Jeff, once again - huh?

Read back through those threads, land_collision worked fine for quite some time. Then, as of a specific rev. it started misfiring. Pretty clear. I'm not the only one reporting that.

That's why what I just posted is a workaround that doesn't use land_collision. If it's not working now, and you want to fix it without waiting on the Lindens, that's the way to do it.

Edit: Although, it seems someone had already, ehm... suggested that.

I'm going to check on this one in-world. See if it's still problematic.

Edit #2: Same findings as "collision." It's called every 0.1 seconds until the object has stopped moving along the surface. That said, either they fixed it or:

- Check your script to see if it gets caught in a loop when land_collision is called. I've done that a few times before.
- Is the script in the master prim?

That is, if it's not working for you presently.

There's another problem with collisions related to llGetVel.. If you check the velocity(llGetVel) after the collide events sometimes you get the speed either before or after the collision randomly (a 0.1 second sleep will fix, but then its not realtime)

Jeffrey thanks for the advice. i'll look into timers but they might be a lil bit more "active" than i wanted. i'm really looking for something that will (for example) turn a prim red when i start colliding, do nothing while i'm colliding, then turn back when i stop colliding. seems like the timer thing would just make it flash red the whole time. not to mention the script is going crazy the whole time instead of sitting passively until an event fires.

True enough - it's not an "elegant" function because it relies on the "collision" event - but as far as being noticibly bad from a lag perspective - this would only cause a real problem if your object is intentionally going to be colliding all of the time - and left that way. Short durations aren't too bad, since this pretty much flips a variable and refreshes a timer. Plus, you can put your core functions behind an "if" relying on "is_collision" (or whatever) so it only fires when the variable changes state.

Now, if you wanted it, say, calling a colorchange/move/rotate/say simultaneously, over and over, that would be different. I'll agree that actual state changes would be a lot better... but eh, I think this should do fine.

yep.

that's why i want a reliable collision_start and collision_end. so it fires once when the collisions start and once when they end and doesn't worry about the majority of the time when collisions are continuing.