Possible bug. Touch is touching everything underneath an object as well

  • I am making a game for my kids and I have an issue.

    As you can see from the picture below there are multiple sprites on top of one another. For each sprite, it says the same of the sprite and plays a sound file.

    The problem I am having is that it when I touch one of the sprites, they all play the sound file. For some reason, I am touching all of the sprites simultaneously. Has anybody else experienced this?

  • Do you mean sprites directly underneath where you are touching? If so, that's as designed.

  • What I mean is that when I touch the owl I also touch the tree and I hear the words owl and tree at the same time.

  • That's expected if the tree collision box is directly under the owl, it looks like this is the case.

  • For whatever reason, I feel that this is new. Either way, I'll put in some logic to deal with the issue.

    It might be good to fix this problem, design-wise it could cause some issues.

  • No. This touch collision logic of touching multiple objects at once (if they're overlapping) always existed.

    Solutions, as you would already be aware are:

    1) Modify collision polygon of tree to not overlap with the polygon area set for owl. etc.

    OR

    2) if Touch is down: sub-events: if Touching Owl, Play_Owl, else if touching Tree, Play Tree, else if. and so on. Priority based on what's on 'Top' perhaps.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Just a couple of threads below yours is mine "Why is touch propagating to other objects and how to prevent this?" that is about exactly this same problem.

    I also asked the same thing a couple years back and the answer hasn't changed since then -- you have to logic around the touch "leaking" every time you have overlapping touchable objects (including pop-up windows; menu bars; sprites like in your game).

    For me personally this is just counterintuitive and opposite to what should be the default so it's either:

    a) this is a specific design choice made for reasons I am not aware of

    b) it is problematic to solve due to Construct's/HTML5/JavaScipt/whatever architecture

    c) it is not considered to be an issue in the first place (or if so, a super low priority one)

    As I said in the other topic I would postulate that in 99% cases you want the touch NOT to activate anything below what you intend to click/touch.

    Ashley Could you perhaps drop in a word or two on this?

  • A and C. The whole event system is designed around the idea of "filtering" by picking, or narrowing down what you want to interact with. IMO it's always better to have more control over the exact behavior you want, the way it is now. It is simple enough (and you have several options) to add conditions to specify the specific object you want within a stack of picked objects such as when touch overlapping objects.

    Look at it from a different perspective. If the touch behavior was changed as you specified, what do you do when you DO want touch to interact with overlapping options? If the objects below the top instance are already filtered out, how would you interact with them by touch?

  • I like the argument that the system is designed with an idea in mind; this is elegant. That said the solution (if any) should not be changing the way it works by default now (it would break compatibility for a lot of projects). Rather than that what I had in mind is adding a behavior or property (or a layer setting?) like "stop touch" as a small convenience feature. It would not break anything while getting rid of the hassle once and for all.

    I don't mean to rant in any case but with numerous projects containing numerous overlaps managing "click transparency" quickly stacks up to a small chore. After all how <div>s work in web development is they do not let touch through; maybe that's why it's how I sort of expected it to be...

  • I think the easiest solution would be that if sprites are overlapping, the touch will touch only the sprite on the top of the layer it's currently on.

    That's the way I thought it worked.

  • I think the easiest solution would be that if sprites are overlapping, the touch will touch only the sprite on the top of the layer it's currently on.

    That's the way I thought it worked.

    That's not the way it works but you can add logic to make it work like that, if you group all pickable objects into a family and use 'pick top'.

  • I think the easiest solution would be that if sprites are overlapping, the touch will touch only the sprite on the top of the layer it's currently on.

    That's the way I thought it worked.

    The problem is, that would break all past projects that actually rely on touching multiple things across the Z axis at once. I do think this is hardly ever the case but surely there are some creative ideas that use this as a feature.

    That is why I propose just a tick box or something to disable this on the object- or layer level.

    While the problem in question is usually work-around-able there are situations where it seriously gets in the way. Imagine a game like Simcity with loads of clickable buildings and a bird travelling over in a random direction.

    Now we want the player to click the bird to get a coin, but not mess with any random objects that happen to be below it. Since we don't know where the bird will be at the moment of clicking; and we want everything else to stay interactive we now need to go to every single object on the board and check if it's not overlapping with the bird (good luck if you have multiple object types). And in case of PARTIAL overlap it's not possible at all (or at least requires some serious complicated multi-event mechanics).

    I know this is possibly a contrived example but still all of this would be solved instantly with just being able to make the object/layer non-touch-transparent.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)