[Suggestion] Layer input Option

Discussion and feedback on Construct 2

Post » Tue Dec 16, 2014 12:37 pm

I agree with @spongehammer and would like to make a similar suggestion.

I finally figured out how to work around the issue by simply adding two conditions to my input events:

On touched <object>
AND <object> is visible
AND Layer <object.LayerName> is visible

However, I would like Construct 2 to automatically take care of this for me for the reasons that follow. The solution could be to make invisible objects or layers not respond to input events, or have an Enabled property that governs that.

Why I'm making this suggestion:
1. To keep the code clean and simple. Users shouldn't have to add additional conditions to every touch/input event.
2. This is a trap for bugs. Looking at the forum posts, there are people who run into this and are puzzled. They tend to think invisible objects should be treated as if they're not there. After all, the game player wouldn't see anything to touch or click. A "pause layer" that covers the game is one possibly common way to run into this problem.
3. As simple as the workaround may be, it still took me a good amount of time searching for forums to understand the issue and look for a fix. I'm sure Scirra wants to let its users focus on developing the game play, not these finicky details.

If you don't take this suggestion, could you please at least mention in the reference manual that the touch events *do* fire for invisible objects or and objects on invisible layers? That way at least we are warned.

Thanks for reading.
Posts: 2
Reputation: 204

Post » Tue Dec 16, 2014 1:11 pm

@alexhui without talking about breaking changes (as some might say it is a breaking change, which would basically negates entirely the demand) with no reason, an invisible object just means it is not rendered. As for the manual, it does not state either that non rendered object do not respond to touch and mouse inputs.

however, having a "respond to inputs" kind of state for objects in C2, could simply do that trick, As low priority as it can be, I am more into the "respond to inputs" state addition rather than modifying what "invisible" means really.

And that is why you shall respect the bug reports guidelines, not only giving a capx is making the bug reproductible in one click in a situation they can work with (less time wasted trying to reproduce vague instructions) but also it helps filtering false positives.

Game design is all about decomposing the core of your game so it becomes simple instructions.
Posts: 2,044
Reputation: 14,685

Post » Tue Dec 16, 2014 4:00 pm

Despite the workarounds it still makes sense to me to have a toggle which allows objects on an invisble layer not to respond to inputs. There would be no reason i can see where this would be an issue. I know this is an old post but i think its still a valid point.
Posts: 1,096
Reputation: 10,988

Post » Tue Jan 19, 2016 1:12 am

Interesting conversation.
I agree with @Blymi, this is a situation I have to deal with all the time.
Maybe a behavior could be created for layers, like "Intercept input", meaning actions could not pass through this layer and affect everything underneath (except what could be visible through transparent parts of the layer).
And "Disable input and obstacles when layer is invisible", meaning input could not be registered on this layer when it is invisible as well as obstacles won't be taken in account by pathfinding and physics.
What do you think ? @Ashley, could it be implemented in a future beta ?
Posts: 185
Reputation: 3,785


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 8 guests