Issue with button mashing on game loading.

[nhaskins]

Hello!

So, this is an odd one that showed up in eh, production ? :D ... It seems players are mashing the 'back' button (escape key) on the cabinet, and it's causing issues:

• if you jam the escape button while launching a unity game, it will launch the game in the background behind Winnitron.
• If you jam the escape button while quitting a game, it will crash Winniton.

I've done some digging, and this mashing seems to effect the system in the small amount of time between when the player selects the game, and when the game loads. It might be something in Auto Hot Key...

I was wondering if anyone had experience with this issue, or has an idea of a solution? The machine is on public display, so the pressure is on here >.< - so any help is appreciated. Thanks!

Cabinet running Winniton at the St Louis Science Center:
https://media.discordapp.net/attachments/406541602178203649/499719259564539914/image0.jpg?width=859&height=645

[aaronklaassen]

Yeah this is my number-one bug, actually. I think it can be solved by changing the AHK script to throttle the number of ESC presses sent per second (or whatever).

If you want to hack at it yourself before I get a chance to, Launcher v2.4 supports custom AHK templates; you just have to specify your own template file: https://github.com/winnitron/WinnitronLauncher/wiki/Using-custom-AHK-templates

[aaronklaassen]

ORRRRRrrrr maybe it's triggering multiple ESC presses during the game-shutdown procedure? And fucking up that way? Another solution might be to disable all ESC keypresses until the Launcher is back in focus?

[nhaskins]

Well as of an hour ago... I've devised a work around that's preventing the issue so far... I made the escape key immediately kill the program (skipping past the holding down the button functionality). After that, mashing escape isn't an issue, as the program just exits on the first press. This works for our games, as none of them use the 'hold down escape' feature to quit.

The other issue is that player input from the buttons can cause the game window to lose focus on selection when mashed. I added a Loop to the AHK override template that pretty much keep assigning focus back to the game window. Seems to be running fine, and I've not managed to break the boot sequence yet by mashing.

The AHK command BlockInput was very tempting as solution, but I can't get it to work.. what I'm reading is it requires admin access to execute... that's not really an option here. I think in a perfect world scenario, something like capturing the input or disregarding it for a small amount of time while the AHK boot sequence does it's job would solve it buuuut.... I don't know AHK well enough to figure out that solution yet.

My testing has been on my laptop with a couple games, so far so good. The plan is to roll out the fix on the Winnitron cabinet in the science center on Thursday. If that goes smooth, I'll document the process and the changes, and send them along to you.

[aaronklaassen]

@nhaskins Awesome thanks. Yeah I'm back to Access To A Windows Computer Land (i.e., home) as of today so I'll be able to play with this now too.

Rather than BlockInput, it might work to map the keypress to a noop: ESC::return

[nhaskins]

I was able to get rid of the ‘button mashing’ issues on the science center cabinet!

It has been stress tested pretty well, a day seeing 30 bus loads of kids visiting the museum, and a VIP reception worth of players circulating though the exhibit space... no incidents. This looking promising!

There were 3 AHK issues to solve:

• From game selection screen, player button mashes escape or any input button to select the game. boot process would fail a lot, usually due to a focus loss.

• When a game was exited using escape, there was a low but consistant % chance that AHK would shut down the game, but not exist the AHK process, leaving Winniton hanging waiting for the process to end.

• It’s worth noting that all the games were programmed to ‘close’ when the escape key is pressed. ex: Application.Quit();

So, the solution for us was to use an AHK override template and edit a few things:
https://gist.github.com/nhaskins/7b739a25b1b0849b5000fdd39c93f724#file-gistfile1-txt-L34

• bypass the escape timeout sequence handling, ~Esc:: calls KillApp() immediately. (ln: 135)
• added a Loop that continues to give focus to the running game. (ln: 91-95)
• changed KillApp(), moved ExitApp to the first line of the function to bypass detection processes. (ln: 34)

I hope some of that helps!

[aaronklaassen]

@nhaskins Awesome. This was/is top of my todo list for THIS VERY EVENING 😅but you beat me to it

Thanks a lot for the research - looks like we were thinking along the same lines. I'll clean it up 👍

[nhaskins]

Well i think it's a patch but probably not a legit fix :)

I'm hearing there might be issues with some of the games not exiting out correctly, and continuing to run in the background.... (i have yet to go verify this, but will soon) I'm sure that has something to do with skipping the extra app kill steps.

[aaronklaassen]

@nhaskins Yeah that's why I want to do some more debugging before I merge to master - but it's still valuable seeing that this was helpful.

I'm curious though - after adding these early ExitApp statements, did you have issues with the Launcher/menu getting focus back properly? (e.g., #112) That's the main reason for those extra checks.

[nhaskins]

No issue there on this end... I think maybe Winnitron takes the focus back when it detects the AHK process has ended?

[nhaskins]

@aaronklaassen how did your code session go? I'm looking to go do work on the cabinet to solve the 'app not closing' issue for Friday. Figure I'd check in with you on developments before beginning to dig in :).

[aaronklaassen]

@nhaskins We had a Winnitron set up at a local game jam, so I was able to test your AHK draft on there in a Real Life setting. Everything went smoothly, so I cleaned it up a little bit and included it in v2.4.1: https://github.com/winnitron/WinnitronLauncher/releases/tag/v2.4.1

Thanks a lot for your help on this - if the "launch game, quit game, return to menu" is the hardest part of this project, so we're always open to bug reports/suggestions/etc. 🙏

[nhaskins]

@aaronklaassen oh awesome, glad to hear it was working out, glad to contribute. I'll take a look at the new code and give it a try. Thanks !!