Main Restorations Software Audio/Jukebox/MP3 Everything Else Buy/Sell/Trade
Project Announcements Monitor/Video GroovyMAME Merit/JVL Touchscreen Meet Up Retail Vendors
Driving & Racing Woodworking Software Support Forums Consoles Project Arcade Reviews
Automated Projects Artwork Frontend Support Forums Pinball Forum Discussion Old Boards
Raspberry Pi & Dev Board controls.dat Linux Miscellaneous Arcade Wiki Discussion Old Archives
Lightguns Arcade1Up Try the site in https mode Site News

Unread posts | New Replies | Recent posts | Rules | Chatroom | Wiki | File Repository | RSS | Submit news

  

Author Topic: QMamehook - The Cross-platform MAMEHOOKER-compatible alternative for PCLightguns  (Read 6748 times)

0 Members and 1 Guest are viewing this topic.

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Coming off of the recent GUI release for my GUN4ALL system, since I was learning QT at the time, I had a passing thought--or, really, an impatient desire for something I'd wanted ever since I initially implemented MAMEHOOKER support.
Something along the lines of...
How easy could I make that, but for MAME's newer network output standard so I can use it on my Linux system?

The answer: in one day.
Meet QMamehook:
the most "we have MAMEHOOKER at home" thing you'll ever witness.

The whole purpose of this app is to do one thing, and one thing semi-cromulently: route MAME's network feedback output to light guns.

The perks are that QMamehook is:
  • Cross-platform: Works just as well on Linux as it does on Windows.
  • Modern: Made in C++ and built with the modern QT framework, supporting both QT5 & QT6.
  • Simple: Connect your guns, launch QMamehook, load up MAME (or anything using the MAME network-compatible standard), and annoy your neighbors with game-controlled force feedback. No admin privileges or COM port configuration needed.
  • (More or less) a Drop-in Replacement: Mainly useful for Linux users who can't use MAMEHOOKER with their native emulators (yes, there's Wine, but... it's complicated lol), QMamehook uses MAMEHOOKER config files directly - no need to change anything, other than dragging them into a different folder!
That being said, don't go expecting to replace MAMEHOOKER for everything:
  • It's only made for light guns: it only looks for and supports the "cmo/e/w #"-type commands, and it only outputs to serial devices.
  • Only works with the MAME Network Output standard: this means MAME (standalone and RetroArch cores), Flycast (standalone) and Windows games/emulators hooked with DemulShooter v12.0+ are compatible. TeknoParrot is not supported until they also follow MAME's network output standard.
  • You will have to change one thing: QMamehook indexes COM devices based on how many are detected at start time, not based on physical COM address like what you may be used to in MAMEHOOKER (i.e: all port writes start at Port 1, up to Port 4). So any com port commands will need to be adjusted so the number correlates directly to its intended player slot.
  • It's simple to a fault: no app-specific configuration of any kind.
  • It's made by an idiot: seriously, I did this as a challenge to myself as a complete newbie to QT--the whole thing is one C++ class rn and the final output is ~50kb. It's really that simple.
Video demonstration of (a somewhat earlier edition of) the program running on my Linux desktop here (shamelessly pulled from my social): https://mstdn.games/@ThatOneSeong/111979386248741717

So, yeah! If you have any comments or suggestions, or would like to contribute to this alternative, uh... leave a comment here or post on the repo? I primarily made this for myself for my own personal use, but I appreciate any feedback regardless!
And for any comments about how bad the code is: be kind, this is literally the first of two things I ever made from scratch for desktops.
« Last Edit: March 07, 2024, 07:08:29 pm by ThatOneSeong »

argonlefou

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1006
  • Last login:Today at 12:52:30 am
Oh, this is a great news.
I had this in mind also (cross platform, network output to replace old windows messaging....) but the main stop for me was the non-access to all led/hardware materials supported by other software

A lot of people have leds on top of lihtguns, so it may be a no-go for them to switch software
Or they'll need to run both at the same time, if COM port are differents.

As for DemulShooter, I'll add network output like MAME....this was also on my mind for some time ;)

I'll report back once I'll be able to test  :applaud:

kim_sama_999

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 15
  • Last login:May 21, 2024, 02:53:39 am
  • SHOTA NATION
    • YouTube
Will my previous Mamehooker ini's work with this? And will newer emulated Mame games will work with it?
YouTube: @KimSamaVideos

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
a LEDWIZ support should be cool .
Thnaks for your works

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Will my previous Mamehooker ini's work with this? And will newer emulated Mame games will work with it?
Yep! I've made sure to test with mamehooker inis I've found floating around on the forums here. It just so happened that Mamehooker's config syntax fit perfectly with QT's settings framework. %s% and | syntax behaves the same.

On the technical side, the only thing that should be changed are the port designations for the com port write/open/end - with this program, the com ports map always starts from 1 for the first serial/gun device detected, and goes up linearly based on number of players, regardless of physical number on Windows. I made sure that it looks for and filters specifically my gun system and GUN4IR's based on the vendor ID (which I believe in JB's case is hexadecimal 0x2341?), though that could be wrong as I uh, don't personally use them.
EDIT: to clarify, though I didn't check this, I believe the devices are still indexed based on COM device number, from lowest to highest, so I guess you'd still have to tinker with fixed COM port settings if you want to reserve a fixed relative order for multiple guns. But there will always be at least a port 1 for the first valid gun device.

a LEDWIZ support should be cool .
Thnaks for your works
I don't personally have or am aware of an LEDWiz, which would make that difficult for me to implement. Aside from that, LEDWiz looks to be hardware designed for actual arcade cabinets, which is also something I couldn't personally take advantage of!
Hence the disclaimers, that MAMEHOOKER would still be a better fit if you have a more elaborate setup - this is mostly for home users or normies who want force feedback sync without much other frills.

Oh, this is a great news.
I had this in mind also (cross platform, network output to replace old windows messaging....) but the main stop for me was the non-access to all led/hardware materials supported by other software

A lot of people have leds on top of lihtguns, so it may be a no-go for them to switch software
Or they'll need to run both at the same time, if COM port are differents.

As for DemulShooter, I'll add network output like MAME....this was also on my mind for some time ;)

I'll report back once I'll be able to test  :applaud:
Aaah, that's one heck of an endorsement to get, really! (^^;

But yeah, having DemulShooter support the network output would be wonderful! And I also just checked to be sure--using the native version of this tool on Linux for the Windows build of MAME through Wine works the same as the native version, which means it would make DS work much easier for the supported Windows/Tekno/JConf games running on Linux through e.g. Proton or Wine.

Though, like I said, I'm not making this necessarily to replace Mamehooker in all aspects--other devices support outside of pure lightguns would be tricky, given I really don't own any of the other devices. It might be possible to support them in the future, and I would be open to that, assuming that communicating with those other devices aren't too difficult (I'd definitely have to clean the reading method up a bit to accommodate more than just Lightgun devices, or the code will be even more of a mess than it is ahaha).
But hey, never say never, right? Still, thank you for the kind words! It should work with Wendies machines and multiple guns.
« Last Edit: February 26, 2024, 02:27:04 pm by ThatOneSeong »

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Hey all! I just pushed a small update - which namely adds properly creating blank gameName.inis if none is detected, and will push any new detected input channels to the config file's [Output] group if not registered (with a blank value obvi, for the user to input in as they please afterwards). It also offers a verbose output switch (-v) which will print whatever QMamehook's receiving from whatever app is sending its output--could be potentially helpful methinks. The OP has been updated accordingly to reflect this.
« Last Edit: February 27, 2024, 12:17:43 am by ThatOneSeong »

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
got it work  :applaud: with this arduino code  :applaud:

void setup() {
  Serial.begin(9600);
pinMode(1, OUTPUT);
pinMode(2, OUTPUT);
}
void loop() {
  while (Serial.available() > 0) {       
    byte serialQueue = 0b00000000;   
    int pin = Serial.parseInt();
    int value = Serial.parseInt();
  if (Serial.read() == 'x') {
    digitalWrite(pin, value);
    Serial.println();
    }
  }
}
mamehooker have some feature like keystroke and waiting command , do you thing you 'll add this ?
« Last Edit: February 27, 2024, 07:09:09 am by bandicoot »

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Oh look, another update. This one fixes/now handles comma reading, streamlines how state changes are handled and is generally more robust against whitespace and illogical combinations (like state breaks inside of lines already containing command breaks). Believe this should make QMamehook handle just about any combination of commands and breaks you throw at it.

got it work  :applaud: with this arduino code  :applaud:

void setup() {
  Serial.begin(9600);
pinMode(1, OUTPUT);
pinMode(2, OUTPUT);
}
void loop() {
  while (Serial.available() > 0) {       
    byte serialQueue = 0b00000000;   
    int pin = Serial.parseInt();
    int value = Serial.parseInt();
  if (Serial.read() == 'x') {
    digitalWrite(pin, value);
    Serial.println();
    }
  }
}
Not sure what this is for? Lol.

Quote
mamehooker have some feature like keystroke and waiting command , do you thing you 'll add this ?
Can't really say I have any idea what those are either, tbh.

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
i'm curious to test your alternative , cause with mamehooker and two positionnal gun , when i shoot at the same time  it's seem lost sometime,
the part of code you see is not complete , but with this i can manage Qmamehook and my solenoid , there's not joystick code  in this example ^^ but it's just for me to test recoil on solenoid ;)
« Last Edit: February 27, 2024, 02:03:43 pm by bandicoot »

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
i'm curious to test your alternative , cause with mamehooker and two positionnal gun , when i shoot at the same time  it's seem lost sometime,
the part of code you see is not complete , but with this i can manage Qmamehook and my solenoid , there's not joystick code  in this example ^^ but it's just for me to test recoil on solenoid ;)

I see! Gotcha, gotcha.
I looked a bit into KeyStates but unfortunately, that might be something a bit out of scope for what I want this to be. Main limiting factor is that it would necessitate making QMamehook into essentially a keylogger - and on Linux with the coming Wayland transition going on in particular, that would be a bloody nightmare to maintain. Also, since this is purely a CLI app/daemon with no GUI atm, there's no immediately obvious QT libraries I could use to facilitate this.
I'm sure if someone else wanted to expand this app in, say, a personal fork or a frontend going over QMamehook, perhaps exposing and making use of Global Hotkeys (which, again, Wayland) and making it more MAMEHOOKER-like, it probably could be done? But since it's not in my personal field of interest, I don't have the same motivation to work on a feature I wouldn't use. But PRs or forks are certainly welcome.
Again, in theory, LEDWiz support wouldn't be impossible? But I don't have such a thing atm to test, and I certainly don't trust myself coding something up blindly for something that I can't physically test on.  :laugh:

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
if you want to test LEDWIZ
here's a open source code
https://github.com/cithraidt/lwcloneu2
and for compile it this post can help
https://www.ukvac.com/forum/threads/custom-arduino-firmware-lwcloneu2.56901/
 ;)

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Again, I don't have an LEDWiz to even test with, lol.
Also the driver code in that repo only has source code for a Windows library, which aside from inherently not being cross-platform (no Linux support) is also way outside of my wheelhouse (of frankly limited knowledge).

Again, though, I'm accepting PRs if anyone wants to try.  ;)

Pushed another update out tonight; aside from some code plumbing, it includes contingencies for Flycast (standalone) and its out-of-spec outputs behavior. Shouldn't affect people using frontends for the most part, but still.

Aaaaaaaaaaaaaaaand yet ANOTHER update! Turns out that Flycast's implem revealed some weaknesses in the older design of the socket reading mechanism, so this version should make outputs ever so slightly more consistent in most cases (and mainly fixes Flycast, or other games with weird simultaneous outputs).
To get around a QT bug on Windows, this does mean the Windows binary now checks the socket every 1ms to accommodate for that platform having a random timeout issue. But even on my old i5 6500U laptop, the difference in idle usage was imperceptible, and should only effect the slowest of slow embedded-class 64-bit machines. Still, should be noted. It was either that, or have the connection erroneously dropping out and having PTSD panic attacks from my MAMEHOOKER on GUN4ALL saga...
« Last Edit: February 29, 2024, 12:07:24 pm by ThatOneSeong »

baritonomarchetto

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 811
  • Last login:Today at 02:02:47 am
i'm curious to test your alternative , cause with mamehooker and two positionnal gun , when i shoot at the same time  it's seem lost sometime,
the part of code you see is not complete , but with this i can manage Qmamehook and my solenoid , there's not joystick code  in this example ^^ but it's just for me to test recoil on solenoid ;)

This is more likely related to the very specific charge/discharge timing of your gun solenoid vs emulating game's oroginal hardware. Add to this USB latency and, voilą, you lose some message.

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
I can't speak for all (gun/feedback) systems obviously, but I don't think it's the USB latency that's a factor (at worst, it should just delay messages, not lose them outright). Self-promotion aside, I know it's not an issue with GUN4ALL for instance.

The problem seems to be MAME itself sometimes loses very quick channel update messages if done in rapid succession. It should be important to note that MAME does in fact do some concatenation of simultaneous messages, which QMamehook has to account for - you notice this most in games with a BEVY of different LED outputs working in tandem with one or two recoil channels, e.g. timecris, or games with rapid recoil mechanisms, e.g. term2/revx.

I've done all I could to ensure all messages received are split and processed sequentially, but nothing can be helped by the source itself neglecting some of those events.

argonlefou

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1006
  • Last login:Today at 12:52:30 am
I've updated DemulShooter with Network outputs supports. No official release yet, as I still have to clean some things before. but I'm attaching a version for you to test.
Just go in DemulShooter_GUI and enable Network outputs in the outputs tab

It should behave similar than MAME (at least it's what a network sniffer shows)

I encountered some bugs with your app though: if I run it when DemulShooter is already running and already has hooked the game, QMamehook mix all arriving string into the rom name.
Looks like OK if QMameHook connects before DemulShooter hooks the game

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
I've updated DemulShooter with Network outputs supports. No official release yet, as I still have to clean some things before. but I'm attaching a version for you to test.
Just go in DemulShooter_GUI and enable Network outputs in the outputs tab

It should behave similar than MAME (at least it's what a network sniffer shows)

I encountered some bugs with your app though: if I run it when DemulShooter is already running and already has hooked the game, QMamehook mix all arriving string into the rom name.
Looks like OK if QMameHook connects before DemulShooter hooks the game
Thank you so much! From what I can tell it's definitely working.
Though from what I'm observing with bugs, my case is exactly the opposite - having QMamehook open before DS hooks locks it into the `__empty` profile, which is my bad; I don't have it set to detect mame_stop as it should, since I've just been relying on the server disconnecting for every instance change, which is what MAME's done so far. I'll fix this up real quick shortly. Fixed this behavior in v1.5.

Connecting it after the game started running seems to work fine though. Though perhaps I just haven't checked with enough games. I'll keep an eye out for the game string weirdness.
« Last Edit: March 03, 2024, 12:47:58 pm by ThatOneSeong »

argonlefou

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 1006
  • Last login:Today at 12:52:30 am
Here what I noticed with your latest 1.5 update :

QmameHook_01.png :
When I run QMAmehook before running the game : It detects the '___empty' game (which is the same behavior as MAME when you run the program alone without any rom running), then succesfully detects mamestop and mamestart with the new game name, then the list of outputs.


QmameHook_02.png :
When I run QMamehook while DemulShooter is aleady hooked to a game : mamestart rom name is made of the whole list of outputs

I don't know if it's QT related or not - the behavior was the same on my computer before your last update - as I have a couple of QMameHook-alike tools I made years ago (.NET, not QT) that are not showing any of this

Glad to know you can confirm it working though, DS will be updated during this week
« Last Edit: March 03, 2024, 02:57:19 pm by argonlefou »

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Here what I noticed with your latest 1.5 update :

QmameHook_01.png :
When I run QMAmehook before running the game : It detects the '___empty' game (which is the same behavior as MAME when you run the program alone without any rom running), then succesfully detects mamestop and mamestart with the new game name, then the list of outputs.


QmameHook_02.png :
When I run QMamehook while DemulShooter is aleady hooked to a game : mamestart rom name is made of the whole list of outputs

I don't know if it's QT related or not - the behavior was the same on my computer before your last update - as I have a couple of QMameHook-alike tools I made years ago (.NET, not QT) that are not showing any of this

Glad to know you can confirm it working though, DS will be updated during this week
WEIRD! Hrm...
Just to note that I do all my primary testing on Linux (so DS thru Wine), and the only physical Windows machine I can use to run any "real" games barely has space on its Windows partition for things. I definitely haven't run into this with Wine when starting mid-game, so it could very well be another small difference in QT platform implementation.

I think I can see the problem though, with part of the "1" from what I assume is the MAME-start command getting left in, so I think something must've gotten wacky with the message splitting when getting the initial receipt from the socket buffer. Does this happen with other games too?
I'll see about fixing this one too, aha. Thank you again for the visual demonstration.

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Ah.

I see the problem.

DS seems to dump a lot in its first message when the client connects - and in this case, once the game's been hooked, it'll always use a stop command as the first message, which is not something I've found in MAME's behavior (in that the first message is always an isolated `mame_start =` message before any of the outputs loads).

But then my fault was always assuming that the first message is a MAME start command with nothing else afterwards, so it did a dumb match/save. I pushed another update to my repo for QMamehook to also do de-concatenation even when it's searching for a game name to load. This should resolve the problem.


Thanks to Argonlefou's generosity, Windows games are now supported in this application when using the latest version of DemulShooter. The repo readme and OP have been updated to reflect this. Your move, Teknogods.  ;)
« Last Edit: March 07, 2024, 07:10:21 pm by ThatOneSeong »

dgrace

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 341
  • Last login:April 27, 2024, 01:53:30 pm
  • I want to build my own arcade controls!
This sounds very cool. Would this be compatible potentially with the Aliens Extermination mounted guns? They essentially act as joysticks and have potentiometers. I currently use mamehooker with them, but it can be quite buggy at times. Thanks

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
No for that it should works with HID Interface Writes , like LEDWizz it's doesn't support  :cry: , hope one day this two thing will be add
« Last Edit: March 25, 2024, 12:34:56 pm by bandicoot »

IntegrumRetro

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 4
  • Last login:May 22, 2024, 11:53:48 am
  • I want to build my own arcade controls!
This is a fantastic tool! I've been dying to use retroarch with mame_libretro. I had to use standard MAME to support outputs which was a mess having games using different emulators. So far the tests work great! Well done!

I especially like you auto assign based on ORDER, not by COM port, that helps save some automation of dealing with that when writing the .ini files dynamically.

Two small requests/asks?

1) How do you determine the serial number? I always had to assign device order by HID_VID detection
2) Can you make the .ini location a command line parameter for windows? I wrote automation to autoconfigure all the .ini files and keeping it in the source directory, or a relative directory to where QMamehooker is put is ideal. Ex. "-c ./QMamehooker/ini"

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
1) How do you determine the serial number? I always had to assign device order by HID_VID detection
The COM devices list is filtered against a builtin whitelist for compatible devices (right now, this checks for GUN4IR's VID, and GUN4ALL's VID - naturally, since that is also a thing I made and primarily use/test against :P ).

As for the exact order, I believe that is still technically based on the COM port number (from lowest to highest) - so if the first compatible gun is detected @ COM1 (Wendies) or ACM0 (Loonix), it will take virtual port no. 1, then if the next's @ COM4 goes to port no. 2, and so on. At least, that's how I assume and what I've vaguely observed QSerialPort handles it.

Quote
2) Can you make the .ini location a command line parameter for windows? I wrote automation to autoconfigure all the .ini files and keeping it in the source directory, or a relative directory to where QMamehooker is put is ideal. Ex. "-c ./QMamehooker/ini"
Suppose I could add an arg for that, ye. We'll see.
« Last Edit: March 26, 2024, 12:15:02 am by ThatOneSeong »

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
@IntegrumRetro, I guess your new answer is here you go!

v1.6.1 adds custom paths support - invoked with -p followed by a path either absolute (starting with a drive letter on Windows, or root on Linux) or relative (specifically to the path that QMamehook is launched from).
Tangentially, this release also contains a fix to the redundant (now default) Windows path; now, the full default path is %LOCALAPPDATA%\QMamehook\ini - just as it should've been.

From my limited testing it should work as expected on both platforms, but do let me know how it goes for you!

Would this be compatible potentially with the Aliens Extermination mounted guns? They essentially act as joysticks and have potentiometers. I currently use mamehooker with them, but it can be quite buggy at times. Thanks
No for that it should works with HID Interface Writes , like LEDWizz it's doesn't support  :cry: , hope one day this two thing will be add
Unfortunately, if I don't have the hardware, I wouldn't exactly be able to trust myself to blindly implement something that I can't verify works as it should. :(

Then again, that is the beauty of open-source software: anyone is free to work on the code and implement such things if they have the desire, equipment, and time to do so. And I will happily take pull requests (given that it doesn't break any preexisting functionality, lol). It is a nice thought though, hearing so many people find usefulness in the idea of this weird thing I made mostly for myself. :>
« Last Edit: March 26, 2024, 01:54:09 am by ThatOneSeong »

IntegrumRetro

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 4
  • Last login:May 22, 2024, 11:53:48 am
  • I want to build my own arcade controls!
@IntegrumRetro, I guess your new answer is here you go!

v1.6.1 adds custom paths support - invoked with -p followed by a path either absolute (starting with a drive letter on Windows, or root on Linux) or relative (specifically to the path that QMamehook is launched from).
Tangentially, this release also contains a fix to the redundant (now default) Windows path; now, the full default path is %LOCALAPPDATA%\QMamehook\ini - just as it should've been.

From my limited testing it should work as expected on both platforms, but do let me know how it goes for you!


Tested and it works great on mame_libretro on windows. Ran into a snag with demulshooter 12.0 and Flycast it seems to be appending a portion of the actual .ini file as the rom name, including display data? Here is the output

Enabling verbose output!
Found device @ "\\\\.\\COM5"
Assigning port no. 1
Waiting for MAME-compatible Network Output @ localhost:8000 ...
Connected to output server instance!
Detected game name!
"1\rmame_start=deathcox\rOrientation(\\\\.\\DISPLAY1)=0\rP1_LmpStart=255\rP2_LmpStart=255\rP1_Ammo=0\rP2_Ammo=0\rP1_Clip=0\rP2_Clip=0\rP1_CtmRecoil=0\rP2_CtmRecoil=0\rP1_Life=0\rP2_Life=0\rP1_Damaged=0\rP2_Damaged=0\rCredits=255"
Error loading file at: "C:/Launchbox/Scripts/qmamehooker/ini/1\rmame_start=deathcox\rOrientation(\\\\.\\DISPLAY1)=0\rP1_LmpStart=255\rP2_LmpStart=255\rP1_Ammo=0\rP2_Ammo=0\rP1_Clip=0\rP2_Clip=0\rP1_CtmRecoil=0\rP2_CtmRecoil=0\rP1_Life=0\rP2_Life=0\rP1_Damaged=0\rP2_Damaged=0\rCredits=255.ini"

Here are the contents of the ini file being loaded:
-------------------------------------------------------

[General]
MameStart=cmo 1 baud=9600_parity=N_data=8_stop=1, cmo 0 baud=9600_parity=N_data=8_stop=1, cmw 1 S6M1.1.M3.0., cmw 0 S6M1.1.M3.0.
MameStop=cmc 1 M1.2.M3.0E, cmc 0 M1.2.M3.0E, cmc 1, cmc 0
StateChange=
OnRotate=
OnPause=
[KeyStates]
RefreshTime=
[Output]
P1_LmpStart=
P2_LmpStart=
P1_Ammo=
P2_Ammo=
P1_Clip=
P2_Clip=
P1_CtmRecoil=cmw 1 F0.%s%.1.F4.%s%.255
P2_CtmRecoil=cmw 0 F0.%s%.1.F4.%s%.255
P1_Life=
P2_Life=
P1_Damaged=cmw 1 F1.%s%.255.F2.%s%.255
P2_Damaged=cmw 0 F1.%s%.255.F2.%s%.255
Credits=



ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Ugh, again? :banghead: Would you advise in what order are these being started? Is QM being started before or after DS?
Because unfortunately I have never been able to see this reflected under Linux, and I don't have a good enough test system for DS to see how it works on a native Windows environment.
EDIT: I guess this laptop does (barely) have the specs to run Flycast, and yeah I can see the problem here too. Seems to be another Windows-specific issue, as I definitely cannot reproduce this kind of funky behavior on Linux. Fun.
« Last Edit: March 26, 2024, 11:37:48 am by ThatOneSeong »

bandicoot

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 116
  • Last login:May 22, 2024, 01:53:20 am
Unfortunately, if I don't have the hardware, I wouldn't exactly be able to trust myself to blindly implement something that I can't verify works as it should. :(

Then again, that is the beauty of open-source software: anyone is free to work on the code and implement such things if they have the desire, equipment, and time to do so. And I will happily take pull requests (given that it doesn't break any preexisting functionality, lol). It is a nice thought though, hearing so many people find usefulness in the idea of this weird thing I made mostly for myself. :>
i've totally understand ;) like you say it's open source , hope someone had this feature in future  ;)

ThatOneSeong

  • Trade Count: (0)
  • Full Member
  • ***
  • Offline Offline
  • Posts: 79
  • Last login:Yesterday at 03:19:57 pm
  • Just your average Seong.
    • Twitter
Whelp, that was the longest couple of minutes I've spent. It was the whole morning, for the record.

v1.7 is the hottest of hotfixes that SHOULD finally resolve that issue with Windows users getting a whole lot of hogwash as the gameName - turns out, I forgot to update one value name in the v1.4 refactoring, which I guess on slow enough clients was enough to be a problem. I also found an issue where Windows users would have their clients randomly crash when connecting to/exiting from a DemulShooter instance--so that's fixed too.

I'm already tired, lol.

IntegrumRetro

  • Trade Count: (0)
  • Jr. Member
  • **
  • Offline Offline
  • Posts: 4
  • Last login:May 22, 2024, 11:53:48 am
  • I want to build my own arcade controls!
Whelp, that was the longest couple of minutes I've spent. It was the whole morning, for the record.

v1.7 is the hottest of hotfixes that SHOULD finally resolve that issue with Windows users getting a whole lot of hogwash as the gameName - turns out, I forgot to update one value name in the v1.4 refactoring, which I guess on slow enough clients was enough to be a problem. I also found an issue where Windows users would have their clients randomly crash when connecting to/exiting from a DemulShooter instance--so that's fixed too.

I'm already tired, lol.

Well done! Flycast is good, in fact even if demulshooter is running and the game hasn't started, Qmamehooker says there is no rom found, but once the game is fully up it finds the rom and does it's thing perfectly! OG mamehooker was much more finicky. I'll continue to test all the other demulshooter tested games and Blamcon.