I’ve been developing a 2D vertical scrolling rhythm game, with notes as gameObjects falling into a 2D clickable object with a 2D collider (not a UI button).
I want some code to execute when both are true: the note is above the *clickable object (*achieved with the colliders and OnTriggerEnter2D() ) and the clickable object is pressed.
And using OnTriggerEnter2D() and OnPointerDown() works, but not always. There tends to be times where the OnPointerDown() method completely misfires when the clickable object is pressed and is not executed.
Is there a conflict between using OnPointerDown() and OnTriggerEnter2D(), or is there anything about their behaviour that I’m missing that may influence their performance?
Note: Same behaviour has been happening when using OnMouseDown() instead.
Hi, thank you for your reply. I’m still quite confused about why the click will get lost, because what we are doing is to set a clicked bool to true after clicking, and a triggered bool to true after the collision trigger, and then make something happen when both are true, so from the first time triggered becomes true to when we click there is quite a long time gap, so we don’t think the trigger will “overwrite” the click in some way.
I’m sure that I still have some misconceptions, so I’d be grateful if you could clear me out a bit more.
Also I didn’t quite understand what you meant by to buffer the mouse intent, could you explain further please?
Store the fact that it happened in a local variable.
And yet it doesn’t work.
What is often happening in these cases is one of the following:
the code you think is executing is not actually executing at all
the code is executing far EARLIER or LATER than you think
the code is executing far LESS OFTEN than you think
the code is executing far MORE OFTEN than you think
the code is executing on another GameObject than you think it is
To help gain more insight into your problem, I recommend liberally sprinkling Debug.Log() statements through your code to display information in realtime.
Doing this should help you answer these types of questions:
is this code even running? which parts are running? how often does it run? what order does it run in?
what are the values of the variables involved? Are they initialized? Are the values reasonable?
are you meeting ALL the requirements to receive callbacks such as triggers / colliders (review the documentation)
Knowing this information will help you reason about the behavior you are seeing.
You can also put in Debug.Break() to pause the Editor when certain interesting pieces of code run, and then study the scene
You could also just display various important quantities in UI Text elements to watch them change as you play the game.
If you are running a mobile device you can also view the console output. Google for how on your particular mobile target.
Here’s an example of putting in a laser-focused Debug.Log() and how that can save you a TON of time wallowing around speculating what might be going wrong:
I’m the co-developer here, we eventually re-wrote the entire thing with Input.getTouch() and to compare the coordinates between the touch and the buttons, and it worked perfectly. The only difference I can think of is that this time we actually put the input detection in Update(), though it’s still unclear why our previous version didn’t work…
Thanks for your advices though, the debugging methods are helpful
If in the previous version it WASN’T in Update(), then it wouldn’t work, so that’s pretty clear.
Look again at the timing diagram and realize that Update() and FixedUpdate() are NOT kept in sync by design, so if you check for edge-trigger type input outside of Update(), you’re gonna miss input.
