skizzosjt

one additional line fixes that. now down key press is only sent if Big Box is the active window, this means essentially there is an automated pause occurring whenever Big Box is not the active window. +F12:: ;Shift + F12 hotkey to start script Loop { If (WinActive("ahk_exe BigBox.exe")) { ;Checks if Big Box is active window Send {Down down}{Down up} ;Send down arrow Key Sleep, 30000 ;Wait 30 secs (change time to what you want) } } !F12::Pause ;Alt + F12 hotkey to pause/resume script End::ExitApp ;End hotkey to terminate script

@paddyG it could be done with a script - this below will do the job. What you can do is have this script startup along with Big Box through the Startup Applications feature and then hit a hotkey (Shift + F12) to start the script, I've also assigned a hotkey (Alt + F12) to pause the script, and a hotkey (End) to terminate/stop the script. The pause hotkey is like a toggle button, so it will pause or resume. If you use the end hotkey the script will not start again until you close and then reopen Big Box. The script would continue to run while playing a game if you do not pause or end it first. So either pause or end the script prior to launching a game so you don't have random down key presses happen when you're gaming away! +F12:: ;Shift + F12 hotkey to start script Loop { Send {Down down}{Down up} ;Send down arrow Key Sleep, 30000 ;Wait 30 secs (change time to what you want) } !F12::Pause ;Alt + F12 hotkey to pause/resume script End::ExitApp ;End hotkey to terminate script Put this into a text file, then save as .ahk file extension. Go into LaunchBox Tools > Options Go to Startup Applications and add the .ahk file you just made as an application. I'd assume you would want it to just load when Big Box does so select that from the Start With? column drop down. Lastly make sure you have an application assigned to .ahk files. Check this by simply trying to double click on the .ahk file you made. If a prompt pops up asking what application you want to use to open it, that means there is no association set yet and you need to do this here. Click on More Apps, then scroll to the bottom and click on Look for another app on this PC and navigate to \LaunchBox\ThirdParty\AutoHotkey and then select AutoHotkey.exe

Use what Joe put in quotes. It will create a message box that will pop up and this is a good way to test scripts, debug and troubleshoot sorta thing. To be specific, this line would create what he suggested MsgBox, Keys sent Waiting for tmnt to exit this line isn't working for you. The extension used for a shortcut is .lnk. Since it's not an executable the method you used here would be trying to activate a window that doesn't exist. You would need to define the actual program's executable file name not the shortcut you made. So whatever program that shortcut is linking to, you need to use that exe's name instead since you are using the ahk_exe criteria variant Joe gave same advice - notice he said whatever the Gaming Keyboard Splitter executable is. You stuck in the shortcut link name with .exe tacked on the end instead

I would bet your resolution and refresh rate is instead being changed when you boot into the game, rather than on exit. Open Retroarch Quick Menu when in game and navigate to Settings > Video > Output > Screen Resolution to see what it is and change accordingly. You can take a look before booting and after exiting game too for having a direct comparison of what changed and when. It's possible the game or core has those settings defined and is doing what is expected. If this is the case you just need to change the setting and then make sure it is saved if you don't have the automatic save on exit function enabled So basically first asking you to confirm your res/refresh rate are being changed to something else for one reason or another that is unexplained. If everything is in order settings wise but you still have problems, then it makes sense to resort to using a script. Which I've included here should you need it. You may need to alter it accordingly for it to function as needed. This is an example that will change into 4K 60Hz when the game/emulator exits. WinWait, ahk_exe retroarch.exe ;wait for Retroarch to exist WinWaitClose, ahk_exe retroarch.exe ;wait for Retroarch to exit ChangeDisplaySettings(32, 3840, 2160, 60) ;color bitrate, horizontal resolution, vertical resolution, refresh rate - adjust resolution and refresh rate as needed ;Don't change anything below here ChangeDisplaySettings(cD, sW, sH, rR) { VarSetCapacity(dM,156,0), NumPut(156,2,&dM,36) DllCall("EnumDisplaySettingsA", UInt,0, UInt,-1, UInt,&dM), NumPut(0x5c0000,dM,40) NumPut(cD,dM,104), NumPut(sW,dM,108), NumPut(sH,dM,112), NumPut(rR,dM,120) Return DllCall("ChangeDisplaySettingsA", UInt,&dM, UInt,0) }

it's wishy washy funny business with AHK. Per AHK's docs it is not clear even lmao. The syntax example shows it with a comma....but then scroll down to the examples and they did not use a comma 🤷‍♂️ So just a FYI, in reality it works both ways, with or without a comma, at least in AHK v1

sorry for missing this initially. I dont emulate that system or use said emulator. Sounds more like the emulator itself has different keys assigned. if emulator A has keys save/load F7 and F8, but emulator B has save/load keys F6 and F7 and you want them something different then change that in the emulators settings. if not available in the emulator's settings you could use AHK to create a hotkey to change them. just make a simple one line hotkey like F7::F6 and on next line F8::F7 or whatever you need and put that in the emulators running script if that is the route you need to take. This line is messing things up for you The WinWaitActive line I quoted above is not doing what you think it is due to you did not define a window that will ever exist. Due to that your script will pause at this line indefinitely. As it reads right now, that line is saying "wait here until a window with a title of "tmnt.exe" exists". I know that game's window is not titled as such. You provided the executable name instead....but if you use the exe name you need to use the proper prefix which is technically called "ahk_ critera" - I've been calling these "WinTitle types" and that is not the proper term....I just noticed the proper term today as I referred to the docs as I wrote this comment lol. Please review this page, it goes into details about using various ahk_ criteria. If you were to use the exe name you need to use the proper ahk_ criteria that being the ahk_exe varient. https://www.autohotkey.com/docs/v1/misc/WinTitle.htm If you do this, your "SetTitleMatchMode, 2" line is not required because you're not really referring to a window title at any point in the script. If you would rather refer to the window title then you need to adjust to the window's title in the WinWaitActive line. Titles do not require a specific ahk_ criteria to be defined since if no ahk_ criteria is defined it defaults to searching window's title. When using window's titles they are always case sensitive but as you likely learned can be matched differently using the different modes of SetTitleMatchMode. 2 is a partial match, and the game window is actually "Teenage Mutant Ninja Turtles: Shredder's Revenge" so it needs to be that or some sort of partial match if left in mode 2. Troubleshooting tip. To see where your script is when running double click on the tray icon or you can select certain things by right clicking on it too. (right click > Open will take you to the same page as double clicking tray icon) it shows all the history of the lines that have executed and the time taken to do so etc. If you checked this you would notice your script stops at the same spot each time. Use this to aid with troubleshooting problems or just seeing the flow of a script, etc.

@KingSlayer420 assuming your user name refers to what I think it does....I love to partake as much as the next guy lol.....take a good rip of the good stuff and relax man. no one wants to get worked up over petty bickering here on LB. the community on this forum is far more friendly and cordial than any forum I've ever been on. so just keep that in mind, we're usually pretty friendly on here! just let it be in the past, water under the bridge sorta thing yuzu updater appears to be something that is not really affiliated with the official development....but I could be off in left field on that. with that said, whether it is or is not, typically developers that distribute their creations have a rep to maintain and if some sort of malware got infected into it they would have to explain to their users what happened if they wanted to do the right thing as no one would trust them in the future hurting their status. and with that said.....Windows Defender marks a ton of BS as virus and false positives of this and that. I would honestly lean more towards it was a false positive. But I understand your better to be safe than sorry reaction also, nothing wrong with that!

I'm afraid you again misinterpret and also misquoted me. I certainly did not suggest you have no business posting in the thread, I don't treat others like that. you really should not be jumping to conclusions so fast.....ask a question next time, I'd be happy to explain myself. Above is what I wrote It referred to the vast difference in sequential numbers between what is the latest mainline yuzu version 1486 vs what you wrote v3267 and then 3703 in your image.....as in how the heck do those numbers fit into the release cycle, how would you have versions that are literally a couple thousand ahead? I couldn't understand until I found that "yuzu updater" which I didn't know that it even existed, let alone, it only downloads early access versions. and for the record, and any moderator can "un-edit" my post if wish to prove this. I wrote I had no idea what that the 3rd icon was on Yuzu''s download page.....what I edited was me stating how embarrassed I was that I just then realized it was github despite how many times I've been to that website 🤦‍♂️, the edit is in the parenthesis. I also would have changed the text above the 3rd image which was originally "3rd image" and I changed it to "github" upon realizing what it was frankly if you wrote the exact version which would have been "Yuzu Early Access 3267" I wouldn't have been confused and you wouldn't have taken my "thinking out loud" post trying to connect the dots in such a misinterpreted hostile manner. no one here is trying to be hostile, I'm literally trying to explain myself to deescalate. have a good evening!

wow, you grossly misunderstand my previous comment. no hostility fellow emulation fan! you misunderstand whatever you perceived as hostility for clearing up my confusion. most users would go to the official site and download mainline versions. so when you post a version # that is out of line with the sequential # that in on their official site, that raised an eyebrow. once I realized what "yuzu updater" is and it gets early access versions (which I didn't even know existed for Yuzu until now) I could see why the number was so different (much larger number). I mean, I even said thanks for sharing even though I didn't understand why it was so different.... I just was confused for pete sake! the graphics API doesn't pertain to whether or not command line launching works. though, I do prefer Vulkan also for this emulator so it's good advice, just doesn't help one way or the other for the specific issue

@KingSlayer420 lol wtf I've never seen that nomenclature for Yuzu versions?! thanks for sharing but I have no idea how that fits into this. The latest version would be "yuzu 1476" per their gituhub and is seen on their website within the URL as another method to correlate these numbers. and they use the same version # for Linux, Windows, and....whatever that 3rd icon represents lol sorry for my ignorance there I have no idea what that is for (edit - it's github lol 🤦‍♂️ - how many times I've been on that site I've never once paid attention to github's logo) Linux Windows github Any Yuzu version I've ever used is named like what I am detailing. When I open the emulator the window is named in the same format "Yuzu XXXX" with XXXX being the version #. This all pertains to the mainline versions OK so just checked out YUZU UPDATER and this is apparently early access versions. So I'd like to believe this explains why the nomenclature is so different. If someone knows different please correct me. But this is good news as it would suggest it would be fixed in the next mainline release that uses the early access code-base.

To help the community, could users please share the exact Yuzu version(s) that is broken in this regard, launching games via LaunchBox / Big Box as in launching games via command line? This way users know which one(s) to avoid or which ones to rollback to Last one I've tried and stuck with is same from my earlier post. Its a build from a month ago. I've never experienced this issue. so I would recommend to try yuzu 1439 if you are on another version and it's giving you a hard time. I'll link to that version below. download the zip file I have circled (assuming you're on Windows and want a zip file that is!) https://github.com/yuzu-emu/yuzu-mainline/releases/tag/mainline-0-1439

@xardius99 if you followed the instructions to only have a single disk in the system when you do the Windows installation it would be impossible to have the EFI partition on disk 1 and the OS volume/partition on disk 2. This is what I am trying to help you change so I'm afraid it seems you didn't resolve this issue so far you have a RAW partition on disk 1 which means that partition's file system is non existent or corrupted. whether or not you can boot into Windows, that partition is useless for anything in its current state. it would require another reformat to be capable to be used again. It also has no drive letter assigned, hence why it doesn't show up in Windows File Explorer. And even if it does, it's not going to be accessible because its file system is RAW In context of all these issues and what is trying to be resolved, it doesn't matter if you can boot into Windows without being prompted for which install to boot to. you have continued to spread your critical installation partitions out over multiple disks, this is not desirable for your use case and needs to be corrected. Having a setup like means you are doubling your chances of having problems because now you have a 2nd disk that impacts how the other disk works. If something happens to that EFI partition disk, you cannot boot your PC anymore without again starting over from scratch. So this is a problem I strongly recommend to resolve. Even if your PC isn't shutting down randomly anymore and LB/BB runs fine you should not leave your setup in it's current state Follow these instructions carefully! READ THE WHOLE THING BEFORE STARTING! ASK QUESTIONS BEFORE YOU START IF YOU NEED ANYTHING CLARIFIED OR HAVE ANY CONCERNS! You will need to go through part of the installation process more than once. This is because you need to wipe both the NVMe disks on pass #1 of doing the installation. Once those drives are wiped, you will need to shutdown, physically remove the older NVMe disk and leave only the single NVMe disk in the PC which is where Windows will be installed on the 2nd pass Shutdown your PC and get that Seagate disk out of your system! You can reinstall it after this is all completed. You must have only the two NVMe disks, and the Windows USB drive physically connected when you start this process. This is as much of a requirement as it is a safety precaution to make sure you don't nuke your Seagate disk on accident. As well as not continuing to make the mistake of breaking apart EFI partition and main OS partition to multiple disks! Now with just the two NVMe disk physically installed and the Windows USB in one of your USB ports, start up the Windows install process from the USB drive When you reach the screen that asks which disk to install to do NOT do any deleting or removing or reformatting etc Press SHIFT + F10 to bring up a Command Prompt window Type diskpart and then hit enter Type list disk and then hit enter Review the generated list to determine which #s got assigned to the two NVMe disks. For sake of this example I will assume they are disk 0 and disk 1 Once you know those disk #s we need to select which disk to manipulate Type select disk 0 and then hit enter Type clean and then hit enter Now disk 0 is totally wiped but it is also not initialized. Stay in Command Prompt window to finish this Type convert GPT and then hit enter Disk 0 is now totally clean and initialized. Now you need to repeat steps #9 - 12 for the other disk, replace the disk # as appropriate At this point now both of your NVMe disks are totally wiped and finally ready to start actually installing Windows in a proper manner Shutdown your PC Physically remove the NVMe disk you do NOT want Windows to install to. You should have just the single NVMe disk you DO want Windows installed to and the Windows USB drive connected to your PC at this point. Start the Windows install process again Due to only having a single disk in the system that is totally wiped, everything will go as expected this time around Good luck!

@bradbradbrad I'm coming back with two different scripts for you. The first one was the brain child of fellow user @JoeViking245 and his script is very elegant and to the point. It allows for startup and shutdowns screens to work just fine since we will be using a pseudo emulator using a script as the emulator. It also has a neat feature to incorporate running other programs before and/or after the game exits. First we need to setup a new "emulator" that will actually be running the script. Here is the setup you will need to do to get this to work. To detail this you need the application path to point to an AHK executable. You can find the one included in LaunchBox in "LaunchBox\ThirdParty\AutoHotkey\AutoHotkey.exe". Next you need to set the default command line parameter to the actual script (.ahk file). It must have quotes around it! Be sure to check "Remove Quotes" and "Remove file extension and folder path" also. Also enable Startup screen and Shutdown Screen in the Startup Screen tab. You also need to enable the option "Hide all windows that are not in Exclusive Fullscreen mode". Lastly make sure you go into Associated Platforms tab and list the platform(s) you want it to be used (associated) with. Now we need to make games use this pseudo emulator. Do a bulk edit of the games you want to use it by selecting them, and then right clicking on them and go to edit, or use the hotkey Ctrl + E. Select the emulator field, and the value will the name of the pseudo emulator you just created. If you do it by one at a time you go to the Emulation tab and select the emulator from that drop down Joes Steam Launching Script If you have more games you want to use this with beyond Steam this script would be better suited for the job. Here is something I put together. What happens different here is it needs to specifically manipulate the game window and the LaunchBox Game Startup window, pushing/pulling them to the front/back of the window stack. I have found some games will be hidden behind a black screen unless they get a "AlwaysOnTop" option added too, and FYI, TMNT Shredders Revenge is one of these games. I created a GUI to use in perhaps an attempt to make it easier for people to use....I wrote this like a year ago and was mainly a learning project on how to use GUIs for me. So I've been using it for a while and it works well, but I hope if you try it, that it also works well for you. If there are issues, please let me know and I'll do my best to figure out what's going on to fix. This is going to work a little different to initially setup. First thing is you would need to take this script below and just run it. It will open up the GUI and will detect it's the very first time running so prompt you to navigate to your LaunchBox\Data\Platforms folder and select your Windows.xml file. I would assume you also have imported Steam games and other Windows games to a platform called Windows. If it is named something different native games that don't launch via a URL link like Steam, Uplay and Epic may not work depending on where you store them - but it would only take like 1 line of code change to fix so let me know if you run into troubles. To clarify Steam, Uplay, and Epic games will work fine even if platform is named something different, just other games may or may not work without a tweak to code. It will detect all the games in your platform and knows if they are Steam, Uplay, Epic, or other native games that may launch via various file types like .exe, .ahk, .bat, .lnk (shortcut links), and .url (Steam shortcut links). It will create two files in the same folder where the script is located. One is an ini file named "WPL Database.ini" that stores all the data related to each individual game and uses what I have defined as defaults initially. The 2nd file it will create is the actual script that does the launching which will be called "Windows Platform Launcher.ahk". I do it like this because it creates the Windows Platform Launch.ahk file with a path specific to your system. Use the GUI to edit any of the values for each game. Select the game via the drop down menu and then edit the desired fields and then click the edit button. You can remove and add games through this also. Whenever anything is changed via the GUI it will create another ini file called "WPL Database (Custom Entries).ini" which stores just the ones you have edited from default. I found this to be handy due to if you made a bunch of edits and then accidentally ran the setup again it would get rid of all your custom edits by returning them to defaults. So the handy part with this custom entry file is you can run the setup again as another method to add new games and it will retain all your previous custom edits by pulling in info from the custom entry ini to overwrite the default values that would normally be applied. Below I'm putting an example of what I used for TMNT Shredders Revenge. I customized the delay time to show the game window, and also needed to use the force window to always be on top checkbox. The "Title" field is the actual title it scrapes from what your game entry is named in LaunchBox. The "WinTitle" field will need to be some form of an AHK WinTitle variant of the game window. This is what the script waits for at the start, and waits for to exit. TMNT Shredders Revenge can use the same for both which is the default setting. But other games will need this WinTitle adjusted if their game window title doesn't match the title in LaunchBox. For example here is Doom Eternal. It's game window has no space and is instead "DoomEternal". One more example of using a different WinTitle type being the ahk_exe variant (the file being run). I found Mortal Kombat worked best using its exe instead. I also adjust the delay time to 0 since it must have been causing issues otherwise. Here's setup for the emulator. The application path needs to be to the AHK exe in "LaunchBox\ThirdParty\AutoHotkey\AutoHotkey.exe". Default Command line parameters need to be path to the actual launching script which gets automatically named "Windows Platform Launcher.ahk" when you run the setup button on the script below. Make sure to put that in quotes! Then make sure to check just "remove file extension and folder path". On the Startup Screen tab check "Enable Game Startup Screen", "Enable Game Shutdown Screen", "Hide Mouse Cursor" is optional but recommended, and this is the important one, need to check "Hide All Windows that are not in Exclusive Fullscreen Mode". I also like to move up the Startup Load delay a bit and use 10sec since the majority of games will load prior to that and take over with exclusive fullscreen anyways. But some games take a little longer to load and this usually is enough for them too. One last thing to do in this area is to go into Associated Platforms tab and list the platform(s) you want it to be used (associated) with. Very last step is assigning the games you want to use this pseudo emulator. Do a bulk edit of the games you want to use it by selecting them, and then right clicking on them and go to edit, or use the hotkey Ctrl + E. Select the emulator field, and the value will be the name of the pseudo emulator you just created. If you do it by one at a time you go to the Emulation tab and select the emulator from that drop down So my script is something I spent a handful of weeks tweaking just for my needs and as a result is as you can see a little more difficult to explain. Hopefully I got my point across but if you use this and need any help or have issues with it please let me know! If mine just sounds like a bunch of rambling nonsense I wouldn't hold it against anyone lol - Joes is easier to understand by far! skizzosjt's script - I call this "WPL Manager" - short for Windows Platform Launcher Manager. When this is run for first time or the setup button used it will create "Windows Platform Launcher.ahk" which is the actual script you put into the pseudo emulators Default Command line parameters field.

so your issue here with your OS install is you you did exactly what I described in my first post. your EFI partition is on a different disk than what the actual OS volume/partition is on. this means if you were to remove the disk (F:) that has the EFI partition on it, you literally couldn't boot to your C: drive. This is a sticky situation in my opinion depending on what resources you have available to you But just gotta say....3 recovery partitions on one disk.....well...at least you didn't half ass it lol! that's an impressive bit of borked there lol. this means you may have done this mistake twice because just one mistake should mean only 2 recovery partitions I think. (Edit: just googled this. I guess it is common for OEM systems - any chance this is a prebuilt system by someone like Dell or HP etc? If so those OEMs normally put their own recovery partition on there along with the one that is normally created by Windows....so it is possible this mistake only happened once) first and foremost make sure you have prepared a USB drive to install Windows using their Media Creation Tool. You will need to totally wipe BOTH NVMe disks and I think we need to do it from within the installation process. I thought weird for a sec too....then as I think more, it makes total sense. I believe Windows is smart enough to not allow you to literally nuke your currently booted OS install's EFI partition....or even the main volume/partition. This is a bit of a catch 22 you are in.....you need to wipe both of those NVMe disks, but you need both of them physically installed in order to even boot to Windows lmao. If Windows did allow you to reformat over something like that while it's in use it would mean the PC would likely just crash and then not boot. So I think Windows is not going to let you nuke your currently booted EFI partition I bet.....I think we need to do the wiping FROM the USB install drive! (ie as you go through the Windows install process) This is getting a bit involved, and it's getting late for me! I gotta tap out for tonight but will try to return to help more next day.

so you had at least two disks installed in your system when you did the most recent installation. with that said, if you can boot to multiple OS installs, you created them (whether you intended to or not is a different story). you will not be able to fix that without basically starting over from scratch. so you def got things messed up when installing Windows, please fix that problem first. and you're not really helping your story here by saying this whole random shutdown thing also happened on your older disk/OS install.....which means this issue goes across multiple disks and OS installs.....which could suggest something that is a hardware issue instead of software. but lets take one step at a time. you obviously don't really want multiple OS installs asking you to pick which one on boot, so lets fix this first. you will need to start by removing the disk (physically uninstalling it from the M.2 slot) that is just a data disk. first before you do that though. prove to yourself it really is just a data disk! Go to Disk Management and look at it in the bottom half of the window. Is there an EFI partition on it? If not, that is good and you can shutdown the PC and physically uninstall it. If there is an EFI partition on it, then there really shouldn't be and will continue to mess up booting. If this is the case you will need to wipe this drive FIRST and THEN shutdown the PC and physically uninstall it. Pic of mine for ex below. Disk 0 is my boot disk, notice the 100MB EFI partition (very 1st partition). Disk 2 and 3 are both data disks (not bootable - no OS installed), so take notice there is no EFI partition. Meaning if Disk 2 or 3 were selected as a boot disk it would just go back to UEFI ("BIOS") screen telling you no bootable disk was selected or keep going through your determined boot order until it got to a disk that is bootable and then boot that disk. So once you get past that, now at this point you should have nothing but the ONE disk in the system that you actually want the OS installed on. Then start over with the operating system install process and when you get to the point of selecting which disk you will only have one to choose. You will be able to wipe that disk clean on that same screen by deleting/removing all the existing partitions. When you select said disk that is totally wiped it will create the new partitions appropriately for Windows. Next time you boot, no more boot manager type screens will appear and it will instead boot to the single OS partition that exists. Once you go through that and the Windows Updates, THEN return to this LB/BB troubleshooting. If your OS is borked right now you're going to be chasing your tail and leading us on a goose chase trying to help. So, in my opinion, we gotta make sure the OS was a good install before blaming other stuff for your random shutdowns. Hopefully this next time goes better for you!

sounds like you didn't wipe the drive before making the recent install? operating systems don't magically duplicate, so I initially think it would be user error. Is Windows Boot Manager coming up? Some screen like one of these to choose between which one.....note these show different OS versions but if you made multiple installs of the same OS version the same thing would occur. (random images grabbed off google) If someone puts more than one installation on the same disk, you will be prompted to choose which one. Is that what is happening to you? I've also seen this when people make an OS install when they have multiple disks in their system. The EFI partition (which contains all the info about booting) gets written to disk A where an EFI partition already exists, but the OS partition gets written to disk B (where the user likely thought everything was being installed). User later then removes disk A from the system and then complains about why their computer doesn't boot anymore or states there is no operating system present. This could be user error like that. I purposely only do fresh clean installs with a single disk connected to the system to prevent any mistakes like this.

I recommend to change the line "Process, Wait, gameoverlayui.exe, 5" line to instead "Sleep, 5000" What Process, Wait does with that timeout is wait until it's true or times out, exceeds 5secs in this case. So if the Steam overlay was to load quicker for one reason or another it will mess up timing by continuing the script prior to 5 secs passing. Since it's dynamic (can be different each time) it potentially could mess up loading that profile properly. Using sleep instead, it's a static value and it will always wait that exact duration each time So my thoughts here were maybe we would get stuck on loading the profile thing (you did end up resolving this though)....I don't recall that being an issue when I used to run UCR but it's been a long time. I must have not used Startup screens at that point or found some workaround like you have detailed. If you are interested in giving it a shot it is on sourceforge.net and here is a direct link to the page. I get that it might look sketchy, but it's all clean, no virus type stuff to worry about here! https://sourceforge.net/projects/vjoy-controller/ Basics on how to use - example of using keyboard input being translated into xinput output Inputs can be selected here - Settings > IO Devices. On next screen make sure you are on tab Physical and then click Setup > Keyboard. On the next screen make sure it is enabled and I tend to use the LLHook API. Note your encoder may show up as something else, but this is where you would need to setup what device is the physical input. Once we have made sure our physical input device is selected and enabled we can move on to our virtual outputs. We want to make four separate Xbox 360 controllers. Return to the IO Devices screen and this time move over to tab Virtual. You likely will only see "Keyboard" listed here the first time. We need to setup the virtual controllers first. Click Setup > Xbox 360 Gamepad (vXbox). Next screen titled vXbox will need the checkbox Enabled checked. Also you will first likely need to install a driver to get this feature working. If the "Install" is not grayed out you will need to click Install to do that. Make sure to restart your PC when it says driver installation complete. Return to this screen when done doing the reboot. Now with it enabled, and driver installed, we can click on Configurate to setup the qty of controllers needed. On next screen also called vXbox you will have a device drop down with four different virtualized Xbox 360 controllers. Click on the ones you want to "plug in" and then click the plug in button. You will likely hear the "beep-boop" chime from Windows detecting an USB device was plugged/unplugged. Give Windows a moment to setup your new device. Rinse and repeat as needed. As you can see this is also where you can unplug a virtualized controller too. Important note that these settings are also saved per profile. As in you create a profile "A" that has 4 Xbox controllers plugged in, but then load profile "B" that doesn't have any Xbox controllers plugged in per its settings, it will act like they are all getting unplugged when profile "B" loads. This is actually pretty handy if you have games than need different type of devices or qty of devices plugged in When you close out of the windows and get back to IO devices you should now see the added virtualized controller(s). Here I added just a single controller Now lets actually remap stuff! Close the IO Devices window to return to the main Virtual Controller window. Go to Settings > Controls. From the Control window go to Tools > Quick Binding. On the Quick Binding window make sure you have selected the intended Output Device in the drop down menu at the top. In this example I made sure to use vXbox1 which is the first instance of a virtualized Xbox 360 controller. Then scroll through the list of the available outputs for this device, click on the associated Assign button for that input, and it will wait for input from the physical device. You can see in my example I made the space bar on my keyboard the input button which is translated into the virtualized controller's Y button You can get into much more detailed controls by exploring the Bind > Create window but for the majority of use cases the Quick Binding menu is that exactly, a quick and easy way to set things up. You can click on the individual lines to edit them further after being created through the Quick Binding too. When you close this window you will now see the Controls window has populated with all your remaps. Things will look like they doubled, this is due to the program detects between down press and up release, etc. This program auto saves whatever you have entered into the Controls window. So if you close right now and reopen, the same stuff will be there and is saved under the appropriately named profile "AutoSave.vcd" in the "Profile" folder. To save a profile return to the main Virtual Controller window and go to Settings > Save. Keep all your profiles in the designated Profile folder since it seems this is the only spot the program can properly load profiles when using AHK or launching with command lines. If you use the Settings > Load method to load a profile they can be stored anywhere though.....but that isn't very practical for our use case since we are trying to automate all this stuff! Let me know if you run into any headaches. I hope this program works out a little smoother compared to UCR if you do give it a shot! I know I like it better than UCR at the very least! Lastly here is an example of using AHK to run this and wait for a game to close to also close virtual controller at the same time. You can apply the stuff you learned in this thread for detecting when the game exists and then closes since as you are likely picking up on there are multiple ways to do that. SetWorkingDir, ..\Controller Remap\Virtual Controller Run, VirtualController.exe /load HOTD-Remake.vcd /run, , Min WinWait, ahk_exe The House of the Dead Remake.exe WinWaitClose, ahk_exe The House of the Dead Remake.exe WinClose, ahk_exe VirtualController.exe I found I also needed to set the work directory to the same directory that VirtualController.exe is in because this way the /load switch which is used to load the specific remap profile (same thing as the "-p" parameter for UCR) can just call out the profile name. Whenever I have tried it another way, as in not setting the workdir and using full paths, it DOES launch the program and DOES put it into run mode, but it never actually loads the profile.....whomp whomp You will also notice the /run switch. This makes the remapper "run" when it is opened, which is the equivalent of the profile being "activated" on UCR. Without the /run switch it would open the program, load the profile, but your controls wouldn't really be reamapped. Lastly is the Min option for the Run command and it does work properly on Virtual Controller! This means the program will launch totally minimized and you will never see it. Unless you restore it through it's button on the task bar. There is a ReadMe PDF included in the main folder of the program. The last page has good example of the syntax for command line which is basically same syntax we had to use in AHK too. There is even a "/minimize" switch built into this program but it actually puts it to the system tray, as in just a tray icon and no button on the task bar. Once you click on the tray icon it will be restored and the button reappears on the task bar.....if you minimize it again the task bar button again disappears and the tray icon reappears. This is just my personal preference to keep its task bar button present so I instead use AHK's Min option rather than Virtual Controller's built in /minimize switch. oh geeze....stuff just snowballs doesn't it!? lol well I don't have that program because I only use LB/BB for having a nice couch gaming setup.....someday.....someday, I will build a cabinet though! So I'm not much use here. The author of LED Blinky is on this forum (username = arzoo) so if my stab in the dark gets you nowhere and no one else chimes in I would see if he wouldn't mind giving you some help! Check out this thread....it's quite long but might suggest there were at least at one point known issues or quirks with Steam and/or Windows platform games. Page 4 and 5 talk about it. Did you ever adjust TMNT Shredder's Revenge applicationpath field? Or what did you actually adjust, probably just adding the additional app script "TMNT Launcher.ahk" ? To prove if that is the culprit I would remove it as an additional app and see if the problem goes away. You can always add it back again to see if the problem returns again, further reassuring yourself you found the issue. If that is found to be the smoking gun of your LED Blinky issue I'm sure that would help someone who knows more than me guide you to a solution. Let me know how that all works out for you and hopefully next time I post I can go over setting things up to use a single script for all your Steam games which enables Startup/Shutdown screens to work properly!

lol glad you put the wink in or else I would think I'm going nuts reading things that aren't there

might be a typo, did you mean /sfc scannow ?

this would suggest you don't have a default application assigned to open .ahk extension files. do the following to set that right click on an .ahk file go to "Open With" from the Open With menu select "Choose another app" then select one of the AHK executables from your AutoHotkey folder (I normally use "AutoHotkeyU64.exe") - you will likely need to click on "More apps", then scroll to bottom of the list and click "Look for another app on this PC" in order to find that file Edit: Just dawned on me you likely don't have AHK installed on your PC. LaunchBox bundles one of the exes with it though. So if you don't have AHK installed by downloading it from their official website you would instead need to navigate to "LaunchBox\ThirdParty\AutoHotkey" and select the file in there called "AutoHotkey.exe" be sure you have also ticked the checkbox "Always use this app to open .ahk files" (or it may instead show buttons like "Always" and "Just this one time" and if that is the case you want to click on the "Always" button) The above process will now make it possible for you to run AHK scripts by simply opening the .ahk file. This is my preferred way of doing things since you will be able to run them by double clicking on the icon or using a shortcut link, using AHK or CMD line to open the file etc. If you prefer compiling scripts I recommend to do that once they are set in stone. Compiling while still in a setup or troubleshooting phase can be a bit annoying I think due to needing to recompile each time you make an adjustment and then test run it. So this is weird! Your UCR screen looks the same as mine would when I had my "Test Case" profile load which all I had it do was remap a handful of keyboard keys like f is now b and a is now k sort of remaps. It was working as intended. You're right it looks like the profile is activated, the profile is in the window title and shows the stop button as selectable while the play button is not selectable, so the remapping should be doing its thing. I only tested the keyboard and didn't try to remap things in the same requirement as you need, going to the virtualized xinput controllers, so there might be more funny business to get around when those are in use. I'd have to test more myself to see what is going on Worst case scenario would be you see it for a blip of a nano sec and then it minimizes. Done so by waiting for window to exist and then minimize it. Otherwise the best case scenario would be there should be some method to launch it minimized from the get go. Try that by changing the run line to this below. This doesn't always work, some programs cannot be controlled like this by AHK, but what it will try to do is launch the program in a minimized state so it is never seen Run, "UCR.exe" -p "Steam", , Min I don't think it would impact what is going on with UCR not remapping things right for you, if that is what you meant. But I've seen weirder things so give it a test run with Startup/Shutdown screens checked off just to make sure. But thanks for the update. I will share the script I use since I use it for the same thing. Launching the games can be relatively simple with the script consisting of just a handful of lines that you said also worked for you! It doesn't need to get too complex when not using Startup/Shutdown screens. But when Startup/Shutdown screens get into the mix we need make things game specific since we need to manipulate the individual windows. Those being both the game window and the "LaunchBox Game Startup" window. I'll have to come back with directions/screen shots on setting this up. I would consider this a set it and forget it type of solution, I've been using it for a year now and adding new games after the fact is simple/straight forward too So I'm sorry to throw you a bit of a curve ball since I'm sure it didn't take just 1 min to remap all your controls in UCR, but would you be willing to try another remapper instead? The downside here would be you would need to reconfigure those remaps on another program. I used UCR for a while a couple years ago and eventually deleted it because I thought it was so poor compared to other remappers. Do you notice how long it takes for this program to start up for example? It also used to crash on me, and all these other quirks that are coming up, etc, are what drove me away. I instead would use a program called "virtual controller" to do what you need. To give you a sales pitch I find this program opens up instantaneously and has less overhead. It does everything UCR can and just my opinion a little easier to navigate and setup your remaps. It can open with or without loading the profile, I know it can be launched minimized, and it plays nice with AHK. If you figured out how to use UCR I'd bet figuring out virtual controller would be more of the same, but since I'm more familiar with virtual controller and actually still use virtual controller I can give better help on virtual controller.

thanks Joe! I'd like to think that would take care of it. My curiosity got the best of me though so I redownloaded UCR just now to actually test hands on. I haven't used this program in over a year. So after playing around for a bit now, UCR seems to have a quirk that requires the working directory to be set to the folder that the main exe is in. I couldn't get UCR to launch with the Run command until I set the working directory to the same folder it is located in. I can launch it without quotes, but Joe's advice is still good. Using quotes does no harm here Here's my test that got it working. I put a folder called "UCR Path With Space" on my desktop and unzipped the UCR zip file there. The script was located directly on the desktop (C:\Users\Scott\Desktop) SetWorkingDir C:\Users\Scott\Desktop\UCR Path With Space Run, C:\Users\Scott\Desktop\UCR Path With Space\UCR.exe This worked! But if I altered the working directory or omitted setting it, then nothing happens. Since I'm forced to set work directory to same directory as the main exe, this means I don't need to write out the whole path again on the Run line. So for this example I can shorten it like this. I also created a profile for testing of loading that automatically SetWorkingDir C:\Users\Scott\Desktop\UCR Path With Space Run, UCR.exe -p "Test Case" Quotes around the file path are fine and in reality are likely better to use than to omit. ie this below is also acceptable and working. notice the quotes around the file path, even though it's technically just the file name here SetWorkingDir C:\Users\Scott\Desktop\UCR Path With Space Run, "UCR.exe" -p "Test Case" @bradbradbrad hopefully now you too can get it working. Even though I got it to work that is an odd ball situation that even an absolute path doesn't work without setting the work directory. I recalled this program had it's quirks but this one I don't remember. I think this may be UCR's fault due to AHK would throw an error if it really couldn't find the file that is being told to run. When I try to tell it to run in such a location where the file doesn't exist I get the proper error reflecting that. I find this same issue when trying to run UCR with a batch file. Either the bat file needs to be in the same folder as UCR.exe, making that the working directory, or I need to set the working directory before telling it to open. If the work directory isn't set and even using a full absolute path when launching the bat file from a different location than UCR.exe, it results in the same big cup of nothing like what is going on with AHK too. So going off previous posts the script below would work for TMNT Shredder's Revenge. The way this is written you are allowed to put the script file (what you named "TMNT Launcher.ahk") in any location you want. SetWorkingDir C:\Program Files (x86)\UCR_v0.9.0 Run, "UCR.exe" -p "Steam" WinWait, ahk_exe TMNT.exe WinWaitClose, ahk_exe TMNT.exe WinClose, ahk_exe UCR.exe To make this so it is not game specific, but is instead just Steam specific, you can do this. Just tested this one too since it's been a long time since I did this method, it still worked fine! So this acts like a nifty way to tell only when a game is running SetWorkingDir C:\Program Files (x86)\UCR_v0.9.0 Run, "UCR.exe" -p "Steam" Process, Wait, gameoverlayui.exe Process, WaitClose, gameoverlayui.exe WinClose, ahk_exe UCR.exe How to set this up so it can work with all your Steam games and other native Windows games can change depending if you want to use Startup/Shutdown screens for these games. Is that something you're interested in or would you rather set this up without them? Let us know how you make out!

you need to put that script into a text file and then save as .ahk file extension. did you leave it as a relative path like what is shown in your last screenshots?! if so that explains why it does nothing. change it to an absolute path. this means include the whole path so start with the drive letter for ex C:\Path\to\something\UCR.exe because you're using relative path for ex ..\..\Path\to\something\UCR.exe it is looking in the wrong folder. change that script file to .ahk extension. the rest looks right! you just need to fix the path to the program in the script and make sure to save the script as .ahk. let me know if that fixes it

Those are the details I was hoping for! Thank you for sharing! I was wondering if there was not an easier method to execute your goal, but now knowing everything as a whole you def need a 3rd party remapper. Bummer Steam can really only use controllers for input, because you can remap controllers to keyboard keys....just not the other way around....now we know! I can try and help with your dilemma....one part is easy....the other part can get a bit more complicated For the first challenge, that being to close UCR automatically once the game closes you need to use a script to do that. I'm more familiar with AHK so I tend to use that over batch files. What needs to happen is an AHK script needs to also be added as an additional app that also launches prior to the game. It will wait for the game to exist, then wait for the game to not exist....at that point it triggers UCR to close. Put this into a script file and add it as another additional app, and check the checkbox to launch prior to game launching. I am going one step further to combine all this in one....you can also launch the remap program within the same script. I looked at the screenshot you posted earlier for the path and choosing profile syntax....please double check for accuracy. EDIT: actually on 2nd thought you should use an absolute path instead of relative path to launch UCR. The relative path will only work right if you place the script file in the proper folder location (same spot as LaunchBox/BigBox exe) or declare the proper working directory within the script....so for ease of use (unless you already know how to deal with all this stuff) I'd say change that to an absolute path. If you know how to deal with relative paths fine then you may need to adjust it depending on where you put it or run it from Run, ..\..\Program Files (x86)\UCR_v0.9.0\URC.exe -p "Steam" WinWait, ahk_exe gameEXEname.exe WinWaitClose, ahk_exe gameEXEname.exe WinClose, ahk_exe UCR.exe Please notice you will need to enter in the name of the individual game's exe file where "gameEXEname" has been put as a placeholder. So for TMNT Shredders Revenge.....I have that game too and I think its exe is "TMNT". We just need to use any "WinTitle" format here and in this example I am showing the ahk_exe variant. if the "ahk_exe" part was removed we could instead have the game's window title entered here. There are more variants....for more on that....https://www.autohotkey.com/docs/v1/misc/WinTitle.htm So that is the easy part.....the hard part is doing this for all Steam games as you have noticed the quirk of launching Steam games with LB/BB. There is always a window that pops up first when the launching/bootstrapping happens. "Launching...." So LB/BB perceives this window as the game and since it closes just moments later LB/BB thinks the game has closed and will in turn close any additional apps that were launched. This is why you notice things getting closed so quickly or why it looks like they never launched at all. To get around this you need to use scripts to tell LB/BB to wait and that is what the above script is doing.....but you cannot copy/paste that for all your games since you need something to be specific to that game.....catch 22 territory here. I'll outline a couple ways to do this in order of bad to best, but will need to come back at a later time to get into any details and provide actual scripts. #1 = make individual scripts for each game (good for a smaller library....bad idea for a large library due to lots of busy work) #2 = single script that waits to detect steam or steam's overlay exists, wait for it to exit, and then exit UCR. #3 = single script using AHK as a pseudo emulator which receives an argument from the command line parameters. this is how I do things. it can give more control to not only make sure the games launch, but also allows Startup/Shutdown screens to operate properly. If you want to use Startup/Shutdown screens this is the only method to use. I would recommend this route if you have a larger library and don't want to make an individualized script for each Steam game Sorry for not being able to help more right now but when I find the time whether later tonight or over the weekend I can come back with more details and the scripts themselves. I'm on my work laptop rather than my desktop where all those files are stored.

I was recently thrown a curve ball when I setup a new PC that was going to use a different display than my current main system. My main system display is 4K 120Hz but this other TV is 4K 60hz. I didn't expect any issues going to the 60Hz TV.....well boy was I wrong. Retroarch was acting like a SOB! Didn't have issues with other emulators or native games if I remember right....but I noticed Retroarch emulation was def messing up with slow gameplay due to slow frame rate. If I turned v-sync off it would run full speed but holy crap was the screen tearing unbearable to endure so that is not an option I would recommend. I could tell from Retorach's display menu that the resolution was rendering at 4K but only at 30Hz (or maybe 29.XXHz) since that is what was selected when the issue was occurring. I would keep changing it to 4K 60Hz and it would work at that res/refresh until it was closed. Next time it was opened the problem returns....I was chasing my tail!!!! Turns out it was my TV SETTINGS that were forcing Retroarch to adjust. In my TV's settings I can determine which HDMI protocol version to use, options available being Auto, 1.4, or 2.0 (it's a HDMI 2.0 capable port). I always left this on auto and never had an issue. However, once I changed this setting to exclusively use HDMI 2.0 the whole refresh rate dropping problem went away. So the problem was the port/cable was auto negotiating down to v1.4 which maxes at 30Hz when using 4K resolution (unless you use compression like 4:2:0). The bit that clued me in was because the problem also went away if I ran a resolution under 4K. Even just one increment down at 3200X1800 I could run 60Hz fine. Without that clue I'd probably still be looking for the solution lol. The other bit that helped was it looked like my TV was doing an extra "going blank" cycle....idk what to call it from a technical standpoint but it's that moment that the screen goes black in between making a resolution or refresh rate change. It was doing that at least one extra time so made me think the TV was auto adjusting when it was detecting there was a window using fullscreen. Telling my rambling story so others can also think to check their TV/monitor's settings since it may not be purely PC related when this kind of issue pops up.

My gut says you're missing something because Steam's remapper is by far the most intricate, detailed and expansive remap tool I've ever seen. Granted I don't use it basically at all myself I have checked it out multiple times just to know what is available and each time I dove down that rabbit hole it was overwhelming lol. All the different types of button press (normal, long, soft, combos, chords, etc) alone is nuts. If you can think it up, they have already thought it up it seems. So my gut thought there is no way the internet wouldn't have been up in arms if Valve dropped the ball and did not include the ability to remap multiple controllers or devices. But since I didn't ever try that before I had to see what is up, and it def can. Screen shot below shows two devices which both happen to be Xbox Series X style controllers. To be specific the first one on the left is a PowerA model, and the 2nd on the right is an OEM Microsoft model. As soon as I turned on the 2nd one it appeared here so it automatically detects what devices are connected. You can select which device to edit and can do this per game. Now if you are using a keyboard encoder I assume your PC sees that as a single device. I see no keyboard option available here on Steam and makes some sense given this feature is called controller remap. So I wonder if this feature is even usable for yourself given your hardware and situation. Do you get any devices to show up when you try to remap a game? Check on the same screen that I posted (check with any of your Steam games) So leads me to next question...or perhaps guess....are you using UCR to create a emulated/virtualized xinput controller? Normally when you for ex, push P1B1 on your cab it would output a keyboard key from your encoder for example "left shift". But you instead want when you push P1B1 it outputs xinput ala Xbox 360 style controller for ex "button A" ?