Collisions and Trigger once....

Are less than useful in my opinion.

Spent a good deal of time trying to understand why my timers were not working among other things.

Turns out my trigger once events were triggering every tick still. How useful.

I had events like so:

detect collision. trigger once -> stop the objects on top of each other(one would think this keeps them touching/in a collision) set timer.

The fault was in collision detection. I guess it is like having two objects right next to each other. It randomly decided if they are touching or not. Sometimes yes, sometimes no.

TLDR:

Can we have a true trigger once event? Where it will run a single time and never again?

(yes I know i can set some variables and such....slightly annoying though)

Anyways I fixed my issue by checking animation states instead of using a trigger once.

Wont be using trigger once with collisions ever again....not very reliable it seems.

Ok couple of things.

Collision works best at the root events. Ie not a sub event.

OnCollision only occurs when Object A and B collide. Once overlapping OnCollision will not fire again until A and B are seperate.

IsOverlapping occurs everytick while A and B poly's are overlapping.

Unique collider poly shapes may cause unique results.

So

OnCollision + Trigger once. Is useless as both meet the criteria of once.

IsOverlaping + Trigger once. Is more desirable, but if that is the case. Then just use OnCollision.

can you provide a minimal capx.

"detect collision" is ambiguous, are you using "On collision" or "Is overlapping"? "On collision" has an internal "trigger once" so it only fires once per collision that occurs, so it's kind of meaningless to put "trigger once" after it, so I wouldn't expect that to do anything useful. And as jayderyu pointed out if you're using "Is overlapping" followed by "trigger once", you may as well use "On collision".

Ashely

I was using "is overlapping at offset" followed by a trigger once event.

Collision wouldn't work because I needed the offset.

I put the event together thinking it would act like a collision and only run once, but actual results ran the events indefinitely.

I made a quick capx to try and duplicate the problem, but using the exact same events resulted in different results......

Going to assume it is because of animations or collision shapes. Of my actual project.

Regardless, it isn't behaving reliably for me, working in one project but not another would just add to my frustration using it.

I got around the issue by checking animation states instead, disregarding the trigger once condition.

I guess the purpose of my post was to say there are times where we(I) want events to run a single time. Once if true can run many times, if the last tick ever becomes false.

Having a condition that after the event triggers doesn't allow that event to ever run again might be useful.

That's why you should use "states" of objects. Just a variable.

If you animating a sprite say a character walking or something that just animates a lot. Your better off creating an object for collision set to invisible. then pin the the animated sprite to the collision sensor.

Using a high animated character for collision checking isn't good design. This is covered in the the primers.

If you animating a sprite say a character walking or something that just animates a lot. Your better off creating an object for collision set to invisible. then pin the the animated sprite to the collision sensor.

Using a high animated character for collision checking isn't good design. This is covered in the the primers.

I already use basic polygons for all or most of my collisions.

It is possible the error was family conflicts, spriter/animation based, or something else entirely however it is set up so incredibly simple I find it unlikely.

To keep the thread from getting unnecessarily long:

I worked around the issue, the cause is still unknown.

I couldn't duplicate it in a new capx, so I say simply move on from it.