collision_start in Firestorm vs the standard viewer

[Hooten Haller]

I have a dance floor. When people walk onto it I expect a collision_start event so I can welcome them. In the standard viewer it's great because I get just one event. In Firestorm I get dozens of collision_start events as the avatars walks around the floor. I think I'll need to maintain a list of UUIDs and maybe timestamps that filters out excessive events over a short period of time. Does anyone have alternative ideas?

[Love Zhaoying]

Trying to remember who is the Firestorm guru..maybe @Beq Janus?

[Rolig Loon]

Collision* events typically behave like that.  It's not the viewer's fault.  If you have to use collision_start, you're going to have to filter somehow.  One straightforward way is to maintain a list of avatars who have already collided and then query

if ( !~llListFindList( lEveryone, [ llDetectedKey(0) ] ) )
{
     lEveryone += [llDetectedKey(0)];
}

The big problem with maintaining a list like that is removing people from the list when they walk off the floor or TP away or log out.  All of the filtering to figure out where avatars are and when they aren't interesting anymore can get to be tedious.  It's not impossible; just annoying.  

EDIT: It might be easier to stop using collisions to get your information.  Use llGetAgentList on a timer (say, every 15 seconds or so) instead, collecting the UUIDs of avatars in the parcel.  Then use a function to determine whether each avatar is within a 2D polygon that defines your dance floor.  You still have the filtering problem when you want to remove names from the list, but you won't have to deal with multiple collisions.

Edited June 5, 2022 by Rolig Loon

[Mollymews]

if is for the purpose of greeting then a list of previously greeted persons is a good idea

a way to help with triggering the greeting with collision_start is to layer over the floor, or border the floor, a transparent-textured volume_detect object ( with some depth so that the avatar's feet are inside the volume_detect layer)  https://wiki.secondlife.com/wiki/LlVolumeDetect

with the visitors list, set it to some max length for the last N number of visitors. Then manage the list as a first in, first out queue

OnCollision (collison_start). Check if person is on list 

if not on list: say Welcome. Add to list: visitors += [visitor]

if on list: say Welcome Back.  Remove from list, then add again to list (as most recent visitor)

when the list is full then delete the 1st list entry.  visitors = llDeleteSubList(visitors, 0, 0)

this way we don't have to worry about timestamps

to conserve space with N = large list then we can store the hash of their key:  https://wiki.secondlife.com/wiki/LlHash

edit add:  When we have a really large N. Say 1 or 2 thousands then when full delete about 10% of the first entries like: visitors = llDeleteSubList(visitors, 0, 99). Saves a little bit of thrashing on full lists

Edited June 5, 2022 by Mollymews
typs

[animats]

That's strange. collision_start is entirely server side. The viewer should not matter. Maybe default hover height is different?

Any kind of greeter needs to track whom it has greeted, or it becomes annoying. My NPCs keep a list of whom they've greeted, reset the timer each time they detect an avatar already greeted, and remove the item from the list after 15 minutes of not seeing the avatar. (Except for Cindi at Vallone, the one with the "Trainee" T-shirt. She's an early model.)

If that's too complicated, just make your greeter a thin object on the ground that triggers on a collision_start.

Ding! The black hose across the driveway triggers a bell. Avatars and vehicles will trigger it. Full service gas stations once had these.

[Hooten Haller]

A quick test shows llVolumeDetect does exactly what I need even with Firestorm users: just one event when they enter the volume. Thanks, Molly.

(This the second case I've found that Firestorm events vary from the standard SL viewer. FS does not make me happy.)

[Profaitchikenz Haiku]

7 hours ago, Hooten Haller said:

In Firestorm I get dozens of collision_start events as the avatars walks around the floor.

This is to be expected, and I'd suggest an alternative method of working out who's on the dance floor that will involve far fewer collisions to be processed.

Surround it with a hollow prim about 1 metre high, with the inner edge set just outside the dance floor perimeter.  Use llVolumeDetect as already suggested above to detect avatars passing through it. The number of collision events will be reduced to just those avatars entering or leaving the dance floor.

It will of course not detect people TP-ing in or out, or flying in or out, that's one drawback.

 

ETA just realised Molly has already suggested the idea of a border.

Edited June 5, 2022 by Profaitchikenz Haiku

[Beq Janus]

50 minutes ago, Hooten Haller said:

A quick test shows llVolumeDetect does exactly what I need even with Firestorm users: just one event when they enter the volume. Thanks, Molly.

(This the second case I've found that Firestorm events vary from the standard SL viewer. FS does not make me happy.)

This doesn't make much sense to me, as people have noted the viewer should be entirely out of scope for script events. What was the "first" case of differing events? Something unexpected is happening here, hover height was suggested that is plausible I guess. 

I'll see if I can run some tests when I get a moment.

 

[Polymath Snuggler]

2 hours ago, Hooten Haller said:

A quick test shows llVolumeDetect does exactly what I need even with Firestorm users: just one event when they enter the volume. Thanks, Molly.

(This the second case I've found that Firestorm events vary from the standard SL viewer. FS does not make me happy.)

Collision events trigger the exact same regardless of what viewer the user is using.

You often get two collision_start triggers as an avatar wanders into a prim.  Once for when it hits the edge of the prim then a second for when it lands on the top surface.

https://gyazo.com/39451e795fb1e018a203abe0cb23cab8

 

If the prim is close to the sim terrain and the sim terrain is uneven, then the avatar might collide with the sim terrain and jitter them up and down based on the terrain value, rather than the prim bounding box, also making them 'tap' the top of the detection prim frequently.

This, again~ doesn't have anything to do with the viewer that the person who is triggering the collision_start event is on.

SL Standard Viewer triggers just as many "random" collision events as Firestorm does. It's always done this, and quite frankly I think this is an excellent example of how innate biases get repeatedly "confirmed" when no one bothers to check the facts.  If you dislike X, suddenly everything that goes wrong is X's fault.  Doesn't matter whether the boogeyman is Firestorm, the Federal Government ~ or  "thems aliens that's always watching us".

No one is saying you have to love Firestorm, but please keep your confirmation bias out of this.

[Mollymews]

adding on to what polysail mentions

when we make our collision prim too thin (and not volume_detect) our avatar can hit the side, get pushed out and up (avatar's forward momentum)  then drop back down on the prim, creating two collision_start events

with a thicker volume_detect then the avatar hits the side, and goes into the prim. Is no push out/up, so doesn't collide with the top while walking/running

[Qie Niangao]

I'm inclined to believe the OP is experiencing some real distinction between conditions, where the viewer is coincidental to those conditions. Hypothetically, for example, there could be a scripted AO that causes the avatar to physically hop a bit when it encounters an llGetAnimationList populated by a TPV's built-in AO. It wouldn't be that the viewer itself changed a server-side behavior but it could cause something else to behave differently.

Not sure there's any reason to track it down, though, because a volume-detect object generally works for me, or "de-bouncing" logic where I don't want to add a separate volume-detect object.

[Polymath Snuggler]

Except collision_start has always worked this way, for as long as I can remember.  Sometimes it just generates hit events constantly for things walking on the prim.

Not Hypothetically at all.

https://gyazo.com/83519adcd8f031c818e2dee643efb6db

It's simply not a "viewer thing".

Edited June 6, 2022 by polysail

[Hooten Haller]

It has only happened with firestorm viewers. I don’t have a large test set to confirm it is only firestorm or always firestorm. The code was simple and’s very small so I can post it if a anyone wants it. For all I know it t be related to avatar characteristics. It is interesting enough that I will put this on my list to investigate further. 

Edited June 6, 2022 by Hooten Haller

[Lucia Nightfire]

On 6/5/2022 at 8:51 AM, Hooten Haller said:

I think I'll need to maintain a list of UUIDs and maybe timestamps that filters out excessive events over a short period of time.

You should be doing this anyway.

Collisions are never perfect in SL. There are far more caveats and bugs than you've already encountered.

[Hooten Haller]

Yes, I do have, but it was a bit more complex than a simple in-memory list so it was swamped by the unexpected flood. Each day I learn something new. Thanks.

[Polymath Snuggler]

So ~ this has been nagging at the back of my mind now for quite a bit...

I'd proved to myself beyond a doubt before even making my first post here that it wasn't a Firestorm specific thing. I'd gotten a large number of collision events on SL Release Viewer, but I did notice a rather stark disparity between wearing an AO HUD and not wearing an AO HUD, and I could not figure out why that would be the case.  This led me down a bit of a rabbit hole~ so I'll try and keep it fairly concise, but this is a bit of a story.

All tests for this were done on Second Life Release 6.6.0.571939 (64bit), so that completely removes Firestorm from the equation.   However, it'll come back into this later~

I made the following code for the ground prim, it just says "Bonk" anytime someone walks on it.  Putting this code in a large flat prim and standing on it creates what I call a "Bonk" prim, as it goes "Bonk" when you walk around on top of it quite frequently.

default
{
    state_entry()
    {
    }
    
    collision_start ( integer bonk ) 
    {
        llOwnerSay ( "Bonk " + llGetTimestamp () ) ;
    }
}

Interestingly enough when walking around on this prim without a HUD based AO ( IE a ZHAO style Animation Override HUD ) I got tons of random collision events, ( as you can see in a few posts above ).  However when I wore an AO HUD, the prim I was walking on no longer gave me random "Bonk" messages as I was walking over it.  This was the mystery that has been bothering me...

I solved it today by making the following script and putting it in a basic prim and wearing it as a HUD:

vector UNIT_VEC = < 1.0,1.0,1.0> ;
default
{
    state_entry()
    {
    }

    collision_start ( integer hudBonk )
    {
        llSetText ( "HUD BONK Start " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
    
    collision ( integer hudBonk )
    {
        llSetText ( "HUD BONK MID " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
    collision_end ( integer hudBonk )
    {
        llSetText ( "HUD BONK END " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
}

This is what it looks like while running : https://gyazo.com/a756c77d1bdd7ed19e64e63d574d9afa

Note how the SetText on the prim is constantly being triggered by the HUD collision code.  It's updating every fraction of a second.

While wearing a HUD with the above code running in it, if you walk on the prim with the "Bonk" code in it, events cease to trigger.  I am assuming that the HUD is monopolizing every single collision cycle the server is willing to give that avatar, and thus the prim on the ground can't manage to trigger an event, except for very large collisions, as it seems not all collision events are treated equally.  Large "Bonks" gain more priority and get event priority over tons of small ones.

"But Liz, what does this have to do with Animation Overrides?"

Let's have a look inside ZHAO code :

ZHAO-II-Core   Code lines 1038 -1048 

    collision_start( integer _num ) {
        checkAndOverride();
    }

    collision( integer _num ) {
    //   checkAndOverride();
    }

    collision_end( integer _num ) {
       checkAndOverride();
    }

This is the main update loop for a ZHAO ( and ZHAO derivative ) AO.  This architecture was used widely by most AO's prior to the AO scripting updates, and as such many are still widely in use today.  So ZHAO AO's flood the server with constant collision update checks too...

This is all provable with code ~ Now back to the problem at hand...

This brings us back to Firestorm.  Firestorm has a built in AO that does not saturate the server with constant collision event updates requests.  This leaves the server to have cycle time for that avatar to process other collision events such as our "Bonk" prim.

Not all Firestorm users use the built in AO, but I'm willing to bet that enough of them do, that it becomes "statistically relevant" that on average, Firestorm users are less likely to be using ancient ZHAO style AO's.  So ~ statistically, it's likely that Firestorm users aren't flooding out their collision events more often than Non-Firestorm users.  Sooo ~ I'm guessing that Firestorm users "cause more random collision events" on "Bonk" prims because the prim can get enough server cycle time to process it's collision events, whereas it's drowned for anyone wearing an old HUD based AO.

Ironically ~ this "problem" of random collision event triggers is because Firestorm fixed something...

Anyhow !~!  That's all from me ~  Take Care!

- Liz

Edited June 8, 2022 by polysail

[Lucia Nightfire]

11 hours ago, polysail said:

So ~ this has been nagging at the back of my mind now for quite a bit...

I'd proved to myself beyond a doubt before even making my first post here that it wasn't a Firestorm specific thing. I'd gotten a large number of collision events on SL Release Viewer, but I did notice a rather stark disparity between wearing an AO HUD and not wearing an AO HUD, and I could not figure out why that would be the case.  This led me down a bit of a rabbit hole~ so I'll try and keep it fairly concise, but this is a bit of a story.

All tests for this were done on Second Life Release 6.6.0.571939 (64bit), so that completely removes Firestorm from the equation.   However, it'll come back into this later~

I made the following code for the ground prim, it just says "Bonk" anytime someone walks on it.  Putting this code in a large flat prim and standing on it creates what I call a "Bonk" prim, as it goes "Bonk" when you walk around on top of it quite frequently.

default
{
    state_entry()
    {
    }
    
    collision_start ( integer bonk ) 
    {
        llOwnerSay ( "Bonk " + llGetTimestamp () ) ;
    }
}

Interestingly enough when walking around on this prim without a HUD based AO ( IE a ZHAO style Animation Override HUD ) I got tons of random collision events, ( as you can see in a few posts above ).  However when I wore an AO HUD, the prim I was walking on no longer gave me random "Bonk" messages as I was walking over it.  This was the mystery that has been bothering me...

I solved it today by making the following script and putting it in a basic prim and wearing it as a HUD:

vector UNIT_VEC = < 1.0,1.0,1.0> ;
default
{
    state_entry()
    {
    }

    collision_start ( integer hudBonk )
    {
        llSetText ( "HUD BONK Start " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
    
    collision ( integer hudBonk )
    {
        llSetText ( "HUD BONK MID " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
    collision_end ( integer hudBonk )
    {
        llSetText ( "HUD BONK END " + llGetTimestamp () ,UNIT_VEC , 1.0) ; 
    }
}

This is what it looks like while running : https://gyazo.com/a756c77d1bdd7ed19e64e63d574d9afa

Note how the SetText on the prim is constantly being triggered by the HUD collision code.  It's updating every fraction of a second.

While wearing a HUD with the above code running in it, if you walk on the prim with the "Bonk" code in it, events cease to trigger.  I am assuming that the HUD is monopolizing every single collision cycle the server is willing to give that avatar, and thus the prim on the ground can't manage to trigger an event, except for very large collisions, as it seems not all collision events are treated equally.  Large "Bonks" gain more priority and get event priority over tons of small ones.

"But Liz, what does this have to do with Animation Overrides?"

Let's have a look inside ZHAO code :

ZHAO-II-Core   Code lines 1038 -1048 

    collision_start( integer _num ) {
        checkAndOverride();
    }

    collision( integer _num ) {
    //   checkAndOverride();
    }

    collision_end( integer _num ) {
       checkAndOverride();
    }

This is the main update loop for a ZHAO ( and ZHAO derivative ) AO.  This architecture was used widely by most AO's prior to the AO scripting updates, and as such many are still widely in use today.  So ZHAO AO's flood the server with constant collision update checks too...

This is all provable with code ~ Now back to the problem at hand...

This brings us back to Firestorm.  Firestorm has a built in AO that does not saturate the server with constant collision event updates requests.  This leaves the server to have cycle time for that avatar to process other collision events such as our "Bonk" prim.

Not all Firestorm users use the built in AO, but I'm willing to bet that enough of them do, that it becomes "statistically relevant" that on average, Firestorm users are less likely to be using ancient ZHAO style AO's.  So ~ statistically, it's likely that Firestorm users aren't flooding out their collision events more often than Non-Firestorm users.  Sooo ~ I'm guessing that Firestorm users "cause more random collision events" on "Bonk" prims because the prim can get enough server cycle time to process it's collision events, whereas it's drowned for anyone wearing an old HUD based AO.

Ironically ~ this "problem" of random collision event triggers is because Firestorm fixed something...

Anyhow !~!  That's all from me ~  Take Care!

- Liz

https://jira.secondlife.com/browse/BUG-231589

[Profaitchikenz Haiku]

Just got told I don't have permission to view that bug, must try and become a super-user so I can snoop more

 

[Polymath Snuggler]

Thank you for the JIRA link Lucia.

Commenting on that JIRA made me realize that my test wasn't entirely thorough here, as you will note in the code snippet above, it does not contain a "collision"  event, only a collision_start  event, as that was the topic of this thread.

If you add a "collision" and "collision_end" event handler to the "bonk" prim as well and do some tests, a new picture of what's happening emerges.

If you drop a physical cube on top of a prim with a collision detect event setup in it,  the collision_start event triggers on impact, collision continues to issue updates until the physics engine makes the cube comes to a rest and then the collision_end event happens.  Working as intended.

Avatars w/o a collision HUD do the same thing.  When the avatar hits the prim collision_start triggers, collision event continues until the avatar is stationary and at rest, then collision_end triggers.  Same as the prim. Working as intended.

Avatars WITH a collision HUD behave differently. When an avatar WITH a HUD hits the prim, collision_start triggers, then collision events continue to trigger 8 times per second, no matter what the avatar is doing.  The avatar can be perfectly still, and motionless for hours, and it will still be triggering "collision" 8 times per second.  This happens both in the HUD collision event, and in the "Bonk" prim.  Both scripts stream updates at 8 updates per second with their "collision" event until the avatar vacates the "Bonk" prim either by walking off or flying, wherupon the collision_end event triggers.  This may be more ideal for how the original poster wanted collision events to be handled, but it is not what the system is designed to do.

The reason why collision_start and collision_end stops "randomly happening" while the avatar moves around on top of the surface is because it's trapped in an endless (erroneous) collision loop, from which there is no escape.

TLDR; Avatars collision HUDS don't "suck up all the sim time" and prevent new events from happening, they throw the ground prim into the same error state that they're in.

Edited June 10, 2022 by polysail