A question about collisions

[Donovan Michalski]

Now that I have my flag system working properly, I have another general question.

Auto racing in SL that takes place on a closed circuit - meaning the race is made up of multiple laps around a track - usually involves some type of lap counter/timer system.  This system keeps track of how many laps each driver has completed, as well as their individual laptimes, sometimes also storing their best individual laps or other data.

I have a lap counter system I got from someone in Opensim a few years ago.  I brought it into SL and it has been a side project I've been tinkering with when I'm not busy with other things.

For the most part it works great, but the other night when we were doing some test races for the previously-mentioned flag system, the lap counter missed a few instances where drivers passed through, meaning they were suddenly displayed as being a lap behind everyone else.

Although I couldn't see the exact circumstances for each driver it happened to, I have an idea what might be going on since it happened to me as well.  I'm thinking that if two drivers collide with the lap counter at nearly the same time, it may only detect one of them.

The counter is 0.5m thick and using llVolumeDetect, with the detection process being on a collision_start event.

The LSL wiki entry for "Collision" itself says that the smallest repeat rate is about 0.13 seconds...is it possible that's what we're running into here?  Two cars pass through the gate fast enough that it only has time to detect one?

The main reason I ask is because there are other, existing lap counter systems that don't seem to have this problem (and their detection prims are thinner than the 0.5m I set this one to), but not being privy to how they're scripted I don't know what might be different.

Edited February 28, 2022 by Donovan Michalski

[Fenix Eldritch]

53 minutes ago, Donovan Michalski said:

I'm thinking that if two drivers collide with the lap counter at nearly the same time, it may only detect one of them.

It will detect both, but I suspect the script as currently written might only be processing one.

The integer seen in a collision's event handler* is an index into a table of all targets that collided with it on that frame. You need a loop to iterate through them all to process them.

default
{
    collision_start(integer num)
    {
        llOwnerSay("total collisons detected in this event: "+(string)num);
        integer x;
        for(x=0;x<num;x++)
        {
            llOwnerSay(llDetectedName(x));
        }
    }
}

Rez a prim and resize it to have a large horizontal area. Drop the above script into it.
Then, rez two more prims above the first, making sure they are at the same elevation. Give them unique names and then turn both physical. Let them drop - they should hit the first prim at the same time and demonstrate the effect.

*and it's not just collision events, this is used for others as well, like touch.

Edit: You can probably set up a similar test with your existing gates, even if you don't have access to the script. Orient the gate horizontally so that you can position and drop two prims through it from the same height. If you don't get two signals, then it's likely that it wasn't scripted to handle multiple simultaneous collisions.

Edited February 28, 2022 by Fenix Eldritch

[Donovan Michalski]

Good to know - I'll give that a look next time I'm on.  Thanks!

[Quistess Alpha]

A year or so I wrote some lap counters that didn't use collisions, but as they were a commission for someone, probably can't share them.

The basic idea is that if the racers go around a simple track that isn't too complicated, you can calculate the 'compass angle' from the center of the track to each racer, and use that as their position along the track. You can also set way-points in the code for more complicated tracks and use that to calculate a distance along the track, but that's much more involved.

[Donovan Michalski]

On 2/28/2022 at 9:32 AM, Fenix Eldritch said:

It will detect both, but I suspect the script as currently written might only be processing one.

The integer seen in a collision's event handler* is an index into a table of all targets that collided with it on that frame. You need a loop to iterate through them all to process them.

default
{
    collision_start(integer num)
    {
        llOwnerSay("total collisons detected in this event: "+(string)num);
        integer x;
        for(x=0;x<num;x++)
        {
            llOwnerSay(llDetectedName(x));
        }
    }
}

Rez a prim and resize it to have a large horizontal area. Drop the above script into it.
Then, rez two more prims above the first, making sure they are at the same elevation. Give them unique names and then turn both physical. Let them drop - they should hit the first prim at the same time and demonstrate the effect.

*and it's not just collision events, this is used for others as well, like touch.

Edit: You can probably set up a similar test with your existing gates, even if you don't have access to the script. Orient the gate horizontally so that you can position and drop two prims through it from the same height. If you don't get two signals, then it's likely that it wasn't scripted to handle multiple simultaneous collisions.

So I made the adjustment to the gate, adding the for loop to the collision_start section.  You were correct in that it was initially scripted to only act on a single collision. 

Unfortunately it didn't seem to clear up the issue - we still had a number of missed collisions, resulting in drivers not being recorded correctly.

I did what you suggested in terms of a basic test as well - using the code above in a new detection prim, along with a couple of physical prims dropped from various heights, and it DID pick up multiple collisions per event, reporting the object names as expected. 

The script for the gate seems to run really well aside from these occasional missed collisions;  I'm going to have to keep digging to figure this one out.

[SarahKB7 Koskinen]

I think the only place I've ever seen a lap counter was at the start/finish line at the vehicle testing sandbox in Brilliant region.

[Donovan Michalski]

1 hour ago, SarahKB7 Koskinen said:

I think the only place I've ever seen a lap counter was at the start/finish line at the vehicle testing sandbox in Brilliant region.

For most racing groups, the gate from Les White is the most commonly used.  It works great, honestly.  The only issues most of us ever run into are that it has a limit of 12 drivers per race, and it only supports race distances set by lap count, rather than by time (race for 20 minutes, see who makes the most laps in that time period).

The time-based races are the main reason I've been working on this other one.  It had that built in from the start when I picked it up, and that part worked great with very little modification required.

[Mollymews]

13 hours ago, Donovan Michalski said:

You were correct in that it was initially scripted to only act on a single collision. 

Unfortunately it didn't seem to clear up the issue - we still had a number of missed collisions, resulting in drivers not being recorded correctly.

The script for the gate seems to run really well aside from these occasional missed collisions;  I'm going to have to keep digging to figure this one out.

when an object is moving faster than the current server frame rate then is possible for  an object to pass thru another object and for the collision to not register (not be collision detected) as the entry and exit happens within the same frame. Back in the day weapons used to be made to take advantage of this to defeat shields and deflectors

the workround was to make the detector prim thicker/wider, so that the collision detection space is wider. The idea being that it requires at least 2 server frames for the travellng object to pass completely thru the detection space, on which the collision is detected