Keyboard triggers - Why doesn't this work?

0 favourites
  • 10 posts
From the Asset Store
Total customisation of the input! You can combine inputs from all peripherals. Make your game accessible for everyone!
  • I'm making a keyboard-controlled start menu for my game. Currently there are just two options - New Game and Controls. I have a Torch sprite that hovers by the currently selected option, and I'm also using its text instance variable "Selected" to determine which option is selected. Below is the code I'm using to try to make this happen, and for the life of me I can't figure out why it's not working

    I mean, I think I understand why nothing's happening - you press Down Arrow from "New Game" and it switches to "Control", but then Construct immediately triggers the same action for "Control" and it ends up where it started. But why? As I understand, keyboard commands are triggers - they should fire once at a time, so the second one shouldn't be firing. Any help please, I'm sure I'm missing something but this is driving me mad

    By the way, Torch.Selected is set to "New Game" by default, so that can't be it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • When I have done this type of thing I have used the "up" & "down" arrows to just add and subtract from 1 variable. Then use this variable to decide what menu item is selected.

    Also without opening Construct wouldn't it be better if you had one "up arrow" pressed & one "down arrow" pressed triggers and then the "selected=" tests as sub events.

  • Yep, I've tried it with adding and subtracting variables and that works. I just don't understand why this way doesn't - like I say, the logic shouldn't be letting the second one fire.

    RE the ordering of the events, yeah I've tried it both ways round (neither work, this was just the second one I tried!)

  • I have a clue here:

    Done this way around it works, at least going up and down, though going up from "New Game" doesn't bring it back to "Controls" and vice versa as I want it to. I understand the way the logic's flowing - if you put the unfulfilled condition as the first sub-event, it's 'skipped' and the second sub-event fires. If the first sub-event's already fulfilled, though, they both fire, which isn't what I want

    It's not a huge deal as I can do it the other way with numeric variables, I just find this way neater and it *should* use fewer events. It seems like such a simple thing to do, but I can't figure out the logical way around it.

  • It works here like I suggested.

    [attachment=0:14yb6zi1][/attachment:14yb6zi1]

  • Ah I see... but it still won't work when pressing Up Arrow at the top/Down Arrow at the bottom (I added in the right events but it just seemed to break it )

    Anyway, all in all it seems it's less of a faff to do it with a numerical variable so I'll just do it that way. Thanks for helping

  • Here you go working as expected.

    [attachment=0:2qo4ljel][/attachment:2qo4ljel]

  • Brilliant, thank you! I think I understand why it's working now, sure is a weirdly complicated thing to do though...

  • Both of the examples you posted as images should be fixed by using the "Else" condition between the "Selected = asdf" conditions. Though I agree with you on the first one, it shouldn't be necessary because triggers are supposed to run only once.

    I'm thinking that because of the nature of triggers, whenever you fulfill the condition of a trigger, it gathers all triggers of the same kind, queues them and checks if they are able to run because of previous conditions in order, so by the time they check the second one, the "Selected" condition is also true for that one, and it runs anyway.

    Else should be your solution

  • Both of the examples you posted as images should be fixed by using the "Else" condition between the "Selected = asdf" conditions. Though I agree with you on the first one, it shouldn't be necessary because triggers are supposed to run only once.

    I'm thinking that because of the nature of triggers, whenever you fulfill the condition of a trigger, it gathers all triggers of the same kind, queues them and checks if they are able to run because of previous conditions in order, so by the time they check the second one, the "Selected" condition is also true for that one, and it runs anyway.

    Else should be your solution

    Yeah, that's what I (finally) came to realise. I just find it odd that something apparently so simple is fairly complex to execute - I'm not sure if the multiple-triggering thing qualifies as a bug exactly, but it's certainly a bit counter-intuitive and I'm surprised I haven't run into it before.

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