[Suggestion] Layer input Option

0 favourites
  • 13 posts
From the Asset Store
Total customisation of the input! You can combine inputs from all peripherals. Make your game accessible for everyone!
  • Hi,

    i guess this question is aimed Ashley really.

    Is it possible or viable to add an option to the Layers properties to disable input on that layer. It would make it so much easier if you could hide a layer and also disable any mouse clicks, touch or keyboard events related to that layer/layers.

    Thanks

  • You mean during runtime, design time has the little locks. I currently add a condition to my events like: "Is layer visible?" that way if it's hidden, the clicks don't fire. But if that ability was there, I would definitely use it.

  • At edittime: this is already supported

    At runtime: why not just add a condition to the event detecting input? E.g. if you have 'On object clicked', add a 'Object is on layer X' and 'Is global variable LayerXEnabled = 1'.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I did mean at runtime actually. At the moment even if the layer is hidden any object getting input such as a mouse click or cursor over etc still gets it.

    I already use workrounds but it means every input needs to be qualified.

  • I don't think this is a feature that will be needed widely enough to implement. Just my opinion.

  • I have to work around this problem all of the time - I'm sure others do too. In the majority of cases you don't want hidden layers to be active with Touch or Mouse.

    Would be perfect to have a 'Touch/Mouse Input when hidden' enabled/disabled option on layer settings. Save so much hassle.

    Ideally, should have this option for hidden objects too.

    Regards, Anthony.

  • To solve this, could the system regard all objects in the same layer as a subjective kind of "Family"? So you could activate all functions that usually regard a family using the specific Layer name you want to affect/disable/enable.

  • It's quite easy to do actually

    +System: Layer "menu" is visible

    ++ do your event

    ++ Mouse: On Left button clicked,

    ++ Keyboard: On any key pressed

    ++ anything

    That way those events will be valid only if actual layer is visible.

  • shinkan

    doing it that way means turning off all layers other than the one you want to accept the input which is not always desired.

    If i have a game layer and layer with a menu on. I should just be able to make the menu visible without having to make other layers invisible.

    It may be difficult or break other things i dont know but it seems logical to me to have a simple toggle which disables all input to a selected layer or layers.

  • 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.

  • 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.

  • 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.

  • 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 ?

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