Hamburglin

If you look upwards one post above, you can see how I fixed it.

Awesome! So, I turned it into an executable so it could be run at windows startup. I type "shell:startup" into run and drop the executable in there. Otherwise... I thought there was an option or checkbox to make launchbox wait for the program to finish running before launching the game. If not, you could add a sleep timer to it as well. I believe that's on the startup script autohotkey section.

That's probably because it's a powershell script, needs to be have the .ps1 file extension, and needs to be ran by powershell. It's not a bat file that can be run by windows command line. I also think the very first directory at the top doesn't need the /Config part. It just needs to be pointed to the top level of the supermodel3 folder. If that doesn't do it... do you see all of those lines that start with Write-Output....? Those will show you if it's working correctly. Look at their output in the powershell command window after you run the script. Check that each step looks correct. Make sure to uncomment the final one at the bottom first, too. That will show you the entire ini file that's about to written. If that looks right and the gun lines look good, make sure that the file you're pointing to actually got written and matches that. Finally, did you also edit the registry to give your guns a name? Looks like you're using mouseGUN1 and 2 if so.

There wasn't a solution for doing the dynamic game mapping of buttons, no. But you can set all of the buttons to white with a custom animation. I cant remember how to do it exactly, but you set all of the buttons to white in the animation editor and it just reruns that single frame of white forever. Also, I highly recommend the IPAC boards if you're using xinput. It saves so much time and is less of a hassle than using an ipac board and mapping those to xinput via software.

Hey glad you found this. Try to follow it and let me know if you need help. You have to run it in powershell because AHK isn't a real scripting language. It just automates pushing keys. And yes, the config for lightgun games need to be set to raw input. I have two directories because of this. One for lightgun games and one for the others.

A more permanent fix can be found here:

A more permanent fix is here:

Mame has a problem choosing the correct monitor to run in if you have a setup that uses multiple monitors. Monitor indexes get changed in Windows but doesn't get updated in the mame.ini. This happens when you boot with one monitor off, or unplug one and plug it back in. This is frustrating when you're trying to host an arcade cabinet and have it "just work". My games end up on the marquee screens which is a show stopper because it requires editing a text file to fix. Here's a powershell script that permanently fixes this issue. You can turn into an exe via Invoke-PS2EXE and then put into your shell:startup folder to run on boot. It runs mame in verbose mode to grab your (primary) display and then correctly uses that to overwrite the current DISPLAY setting in the mame.ini file. It then immediately shuts down mame. Change the directories to yours: #Set working dir to mame directory so that it can read and write the mame.ini Set-Location -Path "C:\Emulation\Emulators\MAME 250\" #Get-Location #Run mame in verbose to grab display info. Wait 1 second so the file can be written $proc = Start-Process -FilePath "C:\Emulation\Emulators\MAME 250\mame.exe" -ArgumentList "-verbose" -RedirectStandardOutput output.txt Start-Sleep -Seconds 1 $inputs = Get-Content -Path 'C:\Emulation\Emulators\MAME 250\output.txt' #Write-Output $inputs #Find primary DISPLAY $primarydisplayline = ($inputs | Select-String "\(primary\)").Line $primarydisplay = $primarydisplayline -replace '.*(DISPLAY\d).*',"`$1" Write-Output $primarydisplayline Write-Output $primarydisplay #Read in mame.ini $content = Get-Content -Path 'C:\Emulation\Emulators\MAME 250\mame.ini' #Write-Output $content #Edit mame.ini mouse related lines #Update DISPLAYx with primary DISPLAYy $content = $content -replace '(DISPLAY\d)',"$primarydisplay" #Write-Output $content #Write new mame.ini file $content | Set-Content -Path "C:\Emulation\Emulators\MAME 250\mame.ini" #Kill mame Get-Process -Name MAME -ErrorAction SilentlyContinue | Stop-Process -Force #Make guns rumble so we know this all worked cmd.exe /c "echo F.1.2.1 > \\.\COM11" cmd.exe /c "echo F.1.2.1 > \\.\COM12"

I solved my vcop problem. The issue was that xinput = 1 in the m2 config literally breaks vcop and only vcop when trying to use a second gun with demulshooter. It needs to be set to 0. The only piece of evidence was that if xinput is set to 1, then the second player gun's shoot button is always activated when in the arcade settings menu. This created another problem. My arcade cab only uses xinput input via its pacto 4000t control board. No dinpit was possible. The solution to continue to let them work for vcop was using xinput plus. I made a new standalone copy of the m2 emulator directory for vcop and patched it with xinput plus to trigger dinput with xinput buttons and then rebound vcops controls.

Player 2 was only not working for vcop2, right? I think I had the same issue but thought it was vcop 1. Did you just slot the old demulshooter executable in for the new one and it worked?

Confirming that mame handles these paths fine but retroarch mame current does not. It happened in an update around the time I made this post initially. I'm manually editing the launch paths for my playlist one by one but in the future won't set the import to default to the USA version. Also, updating the playlisr xml files does nothing for the launch paths. It even leaves the old game path with the "u" at the end on them after I update the path and restart launchbox.

I literally just did that trick after adding big box as a "game" in the Radeon drivers. It works. Thank you!

Thanks. I'm using a nuc hades canyon that has an integrated Radeon card that has special radeon (and now intel) drivers that seems to never get updated. I'll try setting up a profile for big box and see if I can turn vrr off for it. That said, I don't think alt + tab fixes anything.

I updated the script to force the use of rawinput mode when grabbing the mouse ID's. Sometimes it would use directinput (no idea why) and not be able to find the gun IDs. Secondly, there was a bug if you only had MOUSE in the config instead of MOUSE2 or MOUSE3 and the regex wouldn't find the correct pattern to update with the gun ID.

Got it. I just checked again after doing a reboot and ensuring that VRR was enabled. Sadly, I was wrong. I'm not sure why it was smooth after a reboot yesterday. Maybe vrr was temporarily disabled. The framerste is still fought over as you can see with the fps changing (its not a performance issue), which causes the uneven scrolling. The video was taken after a fresh reboot. 20240429_095113.mp4