Preventing loops with button presses

[Asholay]

Can anyone help - looking for the optimum way to code the following:

It's a game setup screen which follows from your character selection and starts with two options (tournament or single-play) which you can move left and right between. Then when you select one or the other by pressing A on the controller, it should move you to the next option down (Timed game, last man standing, etc), and so forth into map selection, etc. - I can get this to work nicely, but when you press B on the controller to go back one level, the code loops itself and reverts right back to character selection from wherever you are.

I know why it does this, as I was using an alterable value to determine which option you were currently selecting and adjusting, and pressing B on a particular level sets the value down one - it's just that the pressing B lasts for a good few loops of program, so it keeps adjusting the value until it's at 0 again.

Anyone have a better solution of doing this sort of thing - I don't want to do a really convoluted method and there must be an easy way!!

Cheers

[Popcorn]

I am not sure if I understand your problem. Is the problem that you use the condition While B is pressed instead of Upon Pressing B? The latter will test for a single press, while the first will test for keypress until you release the button.

[Asholay]

This is using the XNA platforms Xbox gamepad item condition upon pressing button B (essentially the same as when B is pressed) - it's not a problem with the button press though, the problem is with my inefficient coding, which contains closed/circular loops.

[SolarB]

I think if you provided an example file it would really help this.

[DavidN]

The event list runs all the way through from top to bottom before drawing every frame of the game (with some exceptions like immediates and fastloops) - if you have something like:

- Cursor is on section 3
- User presses button B
-> Move cursor to section 2

- Cursor is on section 2
- User presses button B
-> Move cursor to section 1

- Cursor is on section 1
- User presses button B
-> Move cursor to section 0

- then you'll find you skip straight from 3 to 0, because the "user presses button B" is true all the way down the list (it goes from 3 to 2 to 1 to 0 in one run of the event logic).

You can get around this by ordering the events backwards:

- Cursor is on section 1
- User presses button B
-> Move cursor to section 0

- Cursor is on section 2
- User presses button B
-> Move cursor to section 1

- Cursor is on section 3
- User presses button B
-> Move cursor to section 2

In this way, as "User presses button B" is only true when the user first presses the button down, only the event you want to fire will fire - the event list is organized in such a way that pressing button B never moves the cursor to a section that is checked by an event further down the list.

To avoid having to re-order events, you could use a check to make sure only one of them fires, using some alterable value somewhere that I'll call cancelPressed:

- Always
-> Set cancelPressed to 0

- Cursor is on section 1
- cancelPressed is 0
- User presses button B
-> Move cursor to section 0
-> Set cancelPressed to 1

- Cursor is on section 2
- cancelPressed is 0
- User presses button B
-> Move cursor to section 1
-> Set cancelPressed to 1

- Cursor is on section 3
- cancelPressed is 0
- User presses button B
-> Move cursor to section 2
-> Set cancelPressed to 1

[Asholay]

Ah yes - that's the sort of response I was hoping for thanks David, will have a play with those - I quite like your last idea.

[Asholay]

David, I tried your methods and for some reason they didn't work particularly well (well, at all) - I think it's because I'm programming an xbox project and the button pressed commands are slightly different - I'm also using lots of groups, so re-ordering is a pain.

I did get a good solution however, which others might like - which was to have a deactivated group called button pressed, with one condition inside - every 0.5 seconds deactivate the group. Then whenever you have a button press, check that the group is deactivated, and then activate the group.

It works in the same way as your second suggestion, but doesn't get affected by order of events.

[DavidN]

Hmm. I'll try it myself, I recently got the Xbox exporter - the button conditions in the Xbox Controller object trigger continuously rather than once when the button goes down, which is probably the issue here.

[Danny]

Asholay - I used a similar system in IGX. You have to use the 'only one action when event loops' however I haven't seen your code so can't say for sure.

As DavidN said, button presses are triggered and maintained until it's released rather than just testing for the push and that's it. I used a self-coded delta-timing system to determine the up/down/left/right/button press system.

[Asholay]

Hmm. I'll try it myself, I recently got the Xbox exporter - the button conditions in the Xbox Controller object trigger continuously rather than once when the button goes down, which is probably the issue here.

The Xbox button triggering is certainly a bit excitable - you get many loops from the quickest single press. The Xbox exporter is great stuff - I never thought I'd have something of mine running on a console!

Asholay - I used a similar system in IGX. You have to use the 'only one action when event loops' however I haven't seen your code so can't say for sure.

Yes bud - this makes sense as there's no 'repeat while held' condition on the XNA exporter, just a button press so like you say, a quick limit condition sorts that out. The problem isn't with the action repeatedly firing though chap, it was the fact that pressing a button at runtime would activate every button press event in the code. Sorted though, I've just added checks to each one, such as whether that particular option is visible, etc and it sorts it out nicely