search

winnitron / WinnitronLauncher

The official Winnitron launcher! The meat and potatoes of the Winnitron.
winnitron.com
MIT License
34 stars 7 forks source link

Issue with button mashing on game loading. #110

Closed nhaskins closed 5 years ago

nhaskins commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:

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

I hope some of that helps!

aaronklaassen commented 5 years ago

@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 :+1:

nhaskins commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

nhaskins commented 5 years ago

@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 commented 5 years ago

@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 commented 5 years ago

@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 !!