QMamehook v2.2 - Ryan

The RS3 Release

• RS3 guns are now whitelisted and supported.
• EDIT: Windows binary updated to specify the RS3's Guns, not the Hub device.

Note

On Linux systems, you'll have the manually probe the usbserial module to expose this device's serial port, as follows (run this as root/with sudo privileges):

# modprobe usbserial vendor=0x0483 product=0x5750

QMamehook v2.1 - Baxter

The Sorting Types Release

• Added new option -s <sort type> which allows specifying the desired port assignment order. Sort types can be either:
  • pid-ascending: The current default as of v1.9.3, sorting from lowest product ID to highest.
  • pid-descending: Sorting from highest product ID to lowest.
  • port-ascending: The previous default from < v1.9.3, sorting from the lowest system-assigned port name to the highest.
  • port-descending: Sorting from highest system-assigned port name to lowest.
• Reorganized help output.
• Stronger protections around potentially bad arguments; bad args will only show relevant ERROR rather than printing -h over and over.
• Devices sorting (which could be potentially slightly intensive) is only done with different new device lists, marginally reducing idle usage.

QMamehook v2.0 - Martin

The Dynamic Ports Update

Just one change this time, but a fairly significant one:

• When not connected to a server, the list of Serial Devices will be refreshed every so often - the new devices list being compared to the current one, and if either the counts differ or a new device isn't detected in the current mapping, then QMH will update serial port mappings.
  • This removes the (never properly working) requirement of devices needing to be found at bootup.

Also kinda sorta forgot to leave a release binary for Windows. Oops.

QMamehook v1.9.3 - Blanco

The "Oh Parace, it's been THAT Long?" Update

Apologies for the time since releases. I've been very busy with OpenFIRE developments, plus some life happenings. I only managed to get enough free time starting this week to actually bundle everything up into a new release, because there's been a LOT of developments:

• Devices are now sorted based on device Product IDs, courtesy of @samuelballantyne
• Device strings (in VID:PID @ portPath format) are now printed whenever a specific port is referenced
  • Initial implementation courtesy of @samuelballantyne, with some added polish by myself
• Device info for whitelisted devices are printed at startup, courtesy of @samuelballantyne
• The current QMH version is now printed at startup
• QMH should now build fine with Qt5 or Qt6
  • Initial implementation courtesy of @samuelballantyne, with some added "polish"(?) by myself
  • If your system has more than one Qt version installed, you can force the specific version to be built against by adding -DQMH_QT_VERSION=Qt# to your initial cmake .. command before building.
• QMH now has help text! This pops up when either inputting an incorrect custom path (-p) or calling for it with -h/--help.
  • This will also display QMH's default location where it searches for .inis appropriate to the OS it's running on.
• Custom paths -p are now checked to make sure they actually exist, and throw an error if it doesn't.
• A lot of minor optimizations - or rather, pruning of some bad coding practices from past-me.
• When closing a connection (either voluntarily or because of a mame_stop command), QMH will now actually try and use the defined MameStop field, if any.
  • If it doesn't find a MameStop field (or at least one that can be read as a list of commands), then it falls back to the old behavior of simply sending E to all devices before closing them.
  • QMH will also check after a configured stop script if there were any devices left over that haven't been closed yet, and force-close them as appropriate with a notification in the console log.

QMamehook v1.8 - Bertrand

The Ammo Counts Update

May 28th Hotfix: Patched for three digits states support

Simplifies the buffer reading system, as state placeholders can be any number. This effectively adds support for sending Ammo & Life Counts to certain supported clients.

Wonder what that could be...

QMamehook v1.7 - Soleil

THE FIXES™ release

A lot of fixes for problems either introduced by v1.6 or weren't made apparent until now.

• Fixed the gameName situation for good, so the name/file being searched shouldn't ever become a whole mess of the current network buffer again.

  • This was a very embarrassing oversight from v1.4's refactoring away from TCP Socket signals to polling--but the solution is also a slightly more robust method of isolating the game name that should also be more robust across both OS's. For some reason, the index of the = sign in the gameName isolation bit is always 1 character off between Linux and Windows, so leaving in the whitespace until the end compensates for this strange behavior.

• Also fixed strange edge cases where the Windows build would crash either loading or exiting a session if DemulShooter is the output server.

...or should I call you Abacus?

QMamehook v1.6.1 - Kantaris

The File Paths Update release

New to QMamehook, and by request, is custom paths support!
Invoking QMamehook with -p will use whatever path is fed into it. Relative filepaths will be converted into absolute paths as appropriate.

Additionally, the redundant QMamehook\QMamehook\ini default path for Windows users has been resolved: it is now %LOCALAPPDATA%\QMamehook\ini as it should be. This does not affect Linux users.

QMamehook v1.5.1 - Antlion-fix

The mame_stop & mame_start fix release

Settings are now flushed and current game is cleared if mame_stop is detected - which should resolve cases of switching titles without the server disconnecting.

• Reported by DemulShooter dev argonlefou, thank you so much!

Also a small tweak to the way settings are populated if they aren't detected, blank entries will be pushed to the current settings map to prevent possibly duplicating commits to the current game's settings file.

Update: ALSO also fixed the GameSearching method's dumb method of assuming every initial message is a start command; it will now perform the same de-concatenation as the in-game reading method, to ensure the start command is isolated and read properly. The rest of the initial read buffer is promptly disregarded after a start command has been read, if any data is left over afterwards.

QMamehook v1.4.1 - Dog of the Wild Variety

Release updated at 2/29 12 PM for a small tweak to the socket check.

The Flycast apology update*

Turns out, Flycast actually revealed a fatal problem with the older signal/slot-based architecture! Simultaneous outputs actually caused stream congestion, which is the source of Flycast's outputs being horribly desynced for seemingly no reason. So, another refactoring of the way we check for data: using the blocking waitForReadyRead() method exclusively to wait for data, and then only check after we've exhausted the current buffer. Lather, rinse, repeat until an error from disconnection.

HOWEVER, turns out that QT on Windows has a bit of a problem erroneously timing out sometimes when waiting to read an input. So, Windows specifically has a 1ms socket check implemented, and only aborts the socket connection when the error is explicitly RemoteHostClosedError - which should be fine with no discernible difference in performance, but the idle checking may have possible performance implications for very slow machines?**

*In case it isn't obvious, I don't have any problem with Flycast, lol. Just poking fun at my slight overreaction--though they should still fix their outputs implementation anyways.

**I've checked on an i5 6500U, and QMamehook seemed to have no visible CPU usage difference when just waiting on new inputs. Most 64-bit processors shouldn't have an issue with this.

QMamehook v1.3 - Moz

The Flycast update

For whatever reason, Flycast does not adhere to the established syntax standards set by MAME at all, so this release resolves some of the problems caused by connecting to this particular instantiation.

• Code touchup, using two distinct search paths for when a game isn't and is loaded (possible search speed improvement(?) when in-game, since it won't be singling out for start commands while already started)
  • Also technically fixes crashes when attempting to write to a settings file that hasn't been instanced yet from getting non-gamestart outputs before a gamestart has been declared.
• Added check for Flycast's super-duper-special game start indicator alongside mame_start.
• Fixes crashes when attempting to load a new game while one is already loaded.
• Fixes segfaults when disconnecting a session that hasn't loaded a game yet.
  • Technically this one isn't Flycast's complete fault, but using a bad search condition of checking for a settings object that may not always exist--it's just that MAME never allowed this circumstance to happen.

There is technically a known issue in that a new game start discriminator can't be detected as such while in-game, but this is something that only happens in Flycast--and is really a bug on their side, not ours, for not following the MAME network output spec properly, for there is no other way of detecting that a session has ended without being explicitly notified (or at least cut the connection). Besides that, most arcade players using this are probably using some kind of launcher anyways, which means they are closing and re-opening Flycast between game launches anyways so the client will be disconnected regardless, filling in that gap.

Still, mrgrgrr...