onInputDown issue with layered sprites

[TonyB]

Forgive me ahead of time if I miss the obvious. I have been working on a whack-a-mole style game recently and chose Phaser for creating this game. I came across an issue with the 'onInputDown' event that I have applied to a sprite hiding behind another sprite. Basically a person that pops up behind a desk and you whack them with your mouse or touch on a mobile screen. The issue is that I can click on the desk on the layer above the sprite and the 'onInputDown' event triggers.

 

I have searched the forums and online documentation and just can't seem to find any related issue or solution to work from. I am assuming I will kick myself once I find the answer, but any help would be appreciated. So far this platform has been pretty impressive, but I am also coming from a Flash/Actionscript background and this sort of issue isn't a problem in flash.

 

Thanks from a newbie to Phaser!

Tony B.

[piedrahitac]

I'm dealing with this same situation... Does anyone have an answer?

 

Thanks in advance!

[lewster32]

I know this isn't a direct solution, but could you not add a check in your handler to determine if the desk is open first before calling your 'mole was whacked' routine? That certainly removes any ambiguity from the logic.

 

I can't comment directly on what's causing the input issue as I've not explored the input mechanics much, but I assume that this signal is being dispatched whenever the pointer is over the item and down, regardless of what's in the way - which if you think about it is accurate to what it's saying it does, if not entirely expected given the usual input mechanics.

 

I don't know if input priority will help here? I think maybe it will: http://examples.phaser.io/_site/view_full.html?d=input&f=input+priority.js&t=input%20priority

[piedrahitac]

I know this isn't a direct solution, but could you not add a check in your handler to determine if the desk is open first before calling your 'mole was whacked' routine? That certainly removes any ambiguity from the logic.

 

I can't comment directly on what's causing the input issue as I've not explored the input mechanics much, but I assume that this signal is being dispatched whenever the pointer is over the item and down, regardless of what's in the way - which if you think about it is accurate to what it's saying it does, if not entirely expected given the usual input mechanics.

 

I don't know if input priority will help here? I think maybe it will: http://examples.phaser.io/_site/view_full.html?d=input&f=input+priority.js&t=input%20priority

 

In my case the logical check in the handler should do the trick, but I'm using the hand pointer in clickable sprites so enabling and disabling it results in a lot of code clutter...

 

And yeah, I guess the input mechanics are working as the framework intended. I think it's not the input itself that is the issue, but maybe the stacking of sprite layers in a hierarchical order, so in a way the input priority seems like a good start, and while it still allows the input event to happen in the bottom object if the sprites aren't on top of each other, I guess playing with it might provide a solution...