Collisions and Trigger once....

Discussion and feedback on Construct 2

Post » Wed Jan 14, 2015 6:54 am

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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Wed Jan 14, 2015 8:28 am

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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Wed Jan 14, 2015 1:08 pm

"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".
Scirra Founder
B
395
S
231
G
88
Posts: 24,367
Reputation: 193,684

Post » Wed Jan 14, 2015 10:24 pm

@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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Wed Jan 14, 2015 10:54 pm

That's why you should use "states" of objects. Just a variable.
My professional Royalty Free Music at Scirra Assets Store
--------------------------------
Specs: i5 2500, 16gb of ram, gtx 770, win 7, Focusrite Scarlett 8i6, Mackie mr8mk2, Alesis 320, browsing the net on chrome.
B
89
S
29
G
22
Posts: 1,984
Reputation: 19,997

Post » Wed Jan 14, 2015 11:04 pm

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.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Post » Thu Jan 15, 2015 12:29 am

jayderyu wrote: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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 10 guests