skizzosjt

meh it's what I had in my script. must have been some experiment I did and never reverted back to something not so nonsensical.... after you're now pointing it out this is totally unnecessary. thanks! I set this one up when I was still on free version of LB and if I remember right was an attempt by me to hide a couple random flashing windows during start and shutdown. Little more difficult without the features behind the paywall. I tried using "normal" settings now, and these screens pop back up again . for ex this is at launch...black screen with two white screen areas, this happens even with batch parameter on either the nogui or standard exe version. To clarify, the game window pop ups momentarily after seeing this so just want to make sure no one thinks this is one of those stuck on a black screen problems. just a brief flash of this screen. and on shutdown I see a fullscreen flash of the "nogui" screen....(how ironic 🤦‍♂️) if using the nogui version and selecting games to launch in fullscreen. but if selecting the standard exe, I don't see the GUI flash at shutdown as long as the -batch parameter is included. this is what I see flash after game shutdowns, but prior to shutdown screen appearing when using nogui version OK so I know I'm talking about startup and shutdown screens, but this is related to hiding the GUI. What I've found I had to do was use standard version rather than the nogui version, additionally, I need to start in windowed mode. Starting in fullscreen must be turned off. I then use this in emulators running script to make it go into fullscreen at launch. A normal send command works too FYI. I was doing even more silly shit that I deemed unnecessary during my initial experiment months ago like using a shortcut link, telling that to launch the emulator minimized, and using control send to send those keys to the right part of the window so it would actual toggle fullscreen since send only goes to an active window, and I was trying to send it to a minimized window. So I just left that in, it's not harming anything being more specific where the keys are sent. It's the "classNN" title of the window section that is the actual game area. WinWait, ahk_exe duckstation-qt-x64-ReleaseLTCG.exe ControlSend, Qt610QWindowIcon5, {RAlt down}{Enter down}{Enter up}{RAlt up} And I think this is more or less default setup in the emulator "Hide All Windows that are not in Exclusive Fullscreen Mode" option I think could be optional. Investigating just now, it looks like if it is off all it does is not hide the standard exe game selection window, but causes no other screen pop up flashes, and you never actually see this GUI window at startup or shutdown (as long as "-batch" parameter is used) Am I overthinking all this? Any chance you have a less complex method to avoid the couple pop up screen flashes (aka hiding the GUI) and still get startup and shutdown screens working? To clarify, this setup works perfectly for me, but I'd always appreciate a simpler approach when/if one exists

For duckstation, batch does work exactly as intended hiding the GUI. I just tested for a sanity check. as to using a key press to exit, you will want to reassign the exit key in the emulator and then setup a hotkey so it triggers that emulator exit key (or just hit the exit key you assigned in duckstation). I made it End in duckstation and then made escape a hotkey to end for ex: $Esc::End I use PCSX2 1.6 for the need to have light gun support so idk about 1.7 but I can vouch for 1.6 working as intended also.

I'll 2nd this works perfectly fine without any special convoluted setup requirements. Just normal enabling the options. Though I wouldn't agree you need to check "hide all windows that are not fullscreen" or "aggressive start up window hiding" or turning the slider up to a very long delay since I am not using those settings.

OK that is good news! Should be as easy as letting it download the most up-to-date metadata and update your MAME/Arcade library metadata. Fingers crossed! 🤞

Sorry, when I said "whole library" I should have said whole MAME/Arcade library. I didn't mean to reimport your entire LB library of likely many platforms lol. oh boy, that's interesting. you're problem isn't exactly lining up with a scenario I can wrap my head around now. this doesn't make sense to me at this moment. to explain, if things like description and genre were populated it pulled in data from the database and it should have the database ID# in the top right of the game edit window. if that is there it should have pulled in ALL metadata, I don't think there are options to have it only populate certain fields so that is why I think this problem sounds bizarre. do you see that database ID# being filled in, and the link takes you to the correct game webpage?

keep in mind you can always copy those backup archives to another folder to keep a true forever backup. you don't have to leave them in the default backup folder where they will get get cycled out with newer backup versions the more you open/close the program. So on 2nd thought, why the hell did the ROM's import and assign a "title" as the file name instead of the game title? It suggests you did not "scrape" the ROM's against the correct platform, therefore would not populate metadata and therefore leaves the ROM's file name as the title and more or less everything else blank. Is this what in fact happened, all metadata was empty basically besides the title field, which was populated by the file name? If so, please try re-importing again and be sure you are scraping using the intended platform which would be Arcade. If you wanted you could test with just a single ROM and if that is all it was to fix you up then do your whole library.

try seeing what is in Launchbox\Backups. when you made the accident you should have reverted then. hopefully you didn't open/close the program so many times it cycled out a save that would have your library in the good state.

I got no secrets so never feel afraid to ask for sharing from me! I really just went off what you and others shared already. What I did do that is a little different that I don't think anyone brought up yet was the incorporation of an ini file. Here's the AHK Steam Launcher template script, which is really the scripting method shared about how to get startup and shutdown screens working well! The main takeaway is using an ini file to pull in variables, rather than make a butt load of game specific scripts. IniRead, exe, C:\Users\Scott\Desktop\Steam Database.ini, %1%, exe SteamID = %1% Run, steam://rungameid/%SteamID% WinWait, ahk_exe %exe% SetWinDelay, 3000 WinActivate, ahk_exe %exe% WinSet, Bottom, , LaunchBox Game Startup Sleep, 500 WinSet, Bottom, , LaunchBox BigBox WinSet, Bottom, , LaunchBox WinWaitClose, ahk_exe %exe% SetWinDelay, -1 WinActivate, LaunchBox Game Startup WinSet, AlwaysOnTop, on, LaunchBox Game Startup ExitApp Emulator Setup for this. Personally my experience is I cannot get variables to be passed if I put the actual script file as the application (like what you and many others do on here I have noticed). I seem to need to put the AHK exe as the app, and then either have the individual script launched via the command lines or as a ROM file. (the key is having the exe as the app for me) But nevertheless it doesn't matter really because I can still just put the script in the command lines even when extra variables or parameters were required. Here is the associated ini file. The TOP portion is when I was using "%gameid%" variable. So that is what that long string of randomness is, these are the "ID" #'s that are in the platform's XML file for the individual game. At the time, the template script would have had one additional line for the ini which was pulling in the SteamID key since I was not yet using the dummy files The BOTTOM portion is when I started trying using the "dummy file" method for the ROM file, the method you detailed. This would not need any LB/BB specific variables used like %gameid% since we are creating a game specific variable, the SteamID, through naming the dummy ROM file as such [cf71371c-b6c8-4c07-b151-9a4302336254] SteamID = 1203710 Title = UnMetal exe = unmetal.exe [7ec62344-b6b3-4718-b587-bf1c5e1dfb24] SteamID = 609110 Title = Blazing Chrome exe = Blazing Chrome.exe [c50e2993-621b-48f7-bf34-cf7fcd83d74c] SteamID = 1361510 Title = Teenage Mutant Ninja Turtles: Shredder's Revenge exe = TMNT.exe [fea789b4-8b3a-4858-9270-5b9b1d38b8d3] SteamID = 1244950 Title = Battletoads exe = Battletoads.exe ########################################### [1203710] Title = UnMetal exe = unmetal.exe [609110] Title = Blazing Chrome exe = Blazing Chrome.exe [1361510] Title = Teenage Mutant Ninja Turtles: Shredder's Revenge exe = TMNT.exe [1244950] Title = Battletoads exe = Battletoads.exe Technically I am not using the "Title" key for anything in my script. It's just there so I know wtf game "cf71371c-b6c8-4c07-b151-9a4302336254" or "1203710" is without having to cross reference to other files If you're familiar with RocketLauncher the bottom part is literally 1:1 what you do in their PCLauncher module's "SteamID" ini file. So this hopefully walks you through seeing why I wanted the ini file. It gives the ability to control game specific windows during the launch and shutdown sequences, which I applied the games exe into the %exe% variable. Don't forget that Overlord said we need to check "Hide All Windows that are not in Exclusive Fullscreen Mode", this is critical also for this whole plan to work as intended.

did you happen to try each side of your screen? it looks like you might have only tried top and the right hand side. give the left hand side a shot if you not yet. I too was only working with one side and the top, though I tried bottom too, it wasn't until I put it on the right hand side it worked for me. Maybe in your case you need the left hand side? your situation sounds super similar with stuff rendering at a much smaller resolution than the screen with the marquee displaying also. the thread I made to help troubleshoot this and what was the final solution for me is here:

Yes I did it in LaunchBox/BigBox. I did more or less the same that you and others have shared, it's mainly all about using AHK as the emulator and passing something that is unique to the game so it knows which game to launch. When no other LB/BB specific variables are used %1% defaults to the "ROM" file which is what your script does. I wanted to try a method using the %gameid% because I was using it to make a template launcher. I used AHK as an emulator, and would have every single Steam game use a "ROM" file that is a single AHK file....a template for launching Steam games. ie 100 Steam games would all have the same "Steam Launch Template.ahk" as their "ROM". In this situation I used that gameid variable since my "ROM" was a script. The way you created something unique is through those dummy files as the "ROM". We took different roads to get to Rome, the end result is the same. But this was my first idea, and perhaps not the best idea. I then tried the dummy ROM file method, which required me to put my AHK Steam Launch Template into the emulators command lines instead of the ROM file....BUT my problem is I still need to use either a game title or exe name to have best control over the startup and shutdown screens. That's the kicker for me, those screens. Many Steam games work fine with the startup/shutdown screens without doing this extra step....but some games don't behave well. If you need to use lines like WinWait and WinActivate for the game you cannot do that with a non-existent window that is a background process like gameoverlayui.exe. This is why I went the route to implement a ini file, so those lines could have the proper window identified. The ini file was purely to make the whole plan come together on getting startup and shutdown screens working as intended for all games, rather than a portion. Though in reality it seems any path you take, there is going to be some exceptions and hoops to jump through. If my anal retentiveness wasn't so severe then the ini file wouldn't be required and the dummy ROM files would be sufficient lol RocketLauncher......is why I'm here now with LB/BB 🤣. But.....I'll give credit where it is due. It does have a leg up on LB/BB on a few things. The way that program implements bezels for example is handier by comparison in my opinion and I love the option to change them on the fly...it's better than Retroarch's implementation bc RocketLauncher will dynamically adjust the window/viewing area so the bezel does not cut off part of the game window when not in fullscreen mode. But my main point of bringing it up was as I started putting my setup template setup together with the ini file it dawned on me...."I've seen this before". I was literally recreating the same implementation that RL uses. But, the plus side is you don't need to actually use RL lol it's still all through LB/BB I've run into sporadic issues with Steam games not liking it when they are launched directly from their exe. Like running at 5 FPS, crashing once they get past the opening splash screen, it's the exception rather than the norm, but this is why I don't normally launch from the exe for Steam games. It's OK for a last resort, but even then it might not work. I think it's really odd a game launches fine when you click PLAY in Steam....but if you launch directly from the exe it messes up, even when launching from Windows rather than from within LB/BB.

I just implemented this, it's basically the same thing that RocketLauncher does from what I can tell. For even better control, I went the same route and made an INI file to have the game's exe and SteamID included somewhere in the script for better handling of the startup and shutdown screens in LB/BB. It works fine without this extra step, but there are some games that are an exception to this rule. I def read this from others sharing their ideas....I doubt I came up with this myself. You can also use the %gameid% variable, check that against your Platform.xml file in this instance it would likely be "Windows.xml" which has that gameid value in it. Then use an INI file same way that RocketLauncher would. GameID = InsertRealGameName which uses exe ABC and SteamID XYZ. But I kinda like this method of making dummy files with the SteamID too. The dummy file method I think is better if I wasn't being so OCD about the startup and shutdown screens, because you still need an INI file to list out the title and/or exe to control the various windows and prevent the shutdown screen from prematurely exiting. Now I gotta pick a lane and stay in it, I'm not sure which method I want to devote to since both need custom setup and jumping through hoops, but neither have any real life advantage. Each give me the ability to get the start up and shutdown screens working after getting advice from @Your Friendly A.I Overlord found here in this thread

lol man I am losing track of stuff I have already trialed and investigated! Taking a second to think about it, I've launched Steam games via RocketLauncher through LB/BB's "intended" way and through RocketLauncher in an "unintended" way by using RocketLauncher's exe as a standalone application instead of an emulator and sending parameters to it manually, Steam game's exe file, Steam URL, AHK as an emulator and standalone application.....I'm connecting the dots now after your reminder! I think I was confusing if startup and shutdown screens work and are scripts actually able to launch and FULLY run without being instantaneously terminated. I never have actually employed that Windows script launching option so, having a brain fart in the moment, thought it would behave different 🤷‍♂️🤦‍♂️🤣 TLDR =

go into the manage > emulators page and open RPCS3, open the left hand side tab Startup and uncheck the boxes to disable the Startup Screens. This will disable them for every game launched through this emulator.

THIS is the key part of your solution! I glossed over this very important bit reading through the first time and setup everything else as you described, which for me really meant just making the AHK script the ROM file instead of the actual ROM file being the ROM file. So I came back here to see where I went wrong. Mimicking the scope of your script though, that did make it work. Thanks for sharing! I noticed there is a little...err..."flash" of screens upon start and exit though. OCD is triggered lol. Do you have this "issue"? (it's purely cosmetic and subjective) I made two small adjustments for myself to mitigate said flashing issue. A short 1/2 sec sleep after waiting for the game window to be detected before sending the LaunchBox Startup Screen to the bottom prevents a flashing between LB/BB and game at start up. I think what is happening is game is detected before fully finishing being drawn on the display so sending the LB startup screen to the back too early means I get to see a flash of LB/BB before the game fully appears. Also instead of having the script wait for the game to close, it waited for an "exit" button press, which would FIRST activate the LaunchBox Startup Screen window to the top and THEN close the game window. This way I don't get a quick flashing back and forth between LB/BB and the game window at exit. Same idea, I think it just instantly closes the game before the LB startup screen can really be sent to the top, so I would end up with a flash between screens on exit too. This exit plan works fine for emulators, but might be problematic for some PC games since it would need to do something like detect F4 from an ALT+F4 close and that isn't the preferred way to close majority of PC games.... Found a better path by still going off the closing of the game rather than a button press. Just need to send the "LaunchBox BigBox" window to the bottom AFTER sending LaunchBox Startup Screen to the bottom. This way upon exit of the game, the screen that it "flashes" to is the intended screen to be seen! I tested with steam game Blazing Chrome and some Dolphin emulator games. For example, just the meat and potatoes part.... WinWait, ahk_exe Blazing Chrome.exe Sleep, 500 WinSet, Bottom, , LaunchBox Game Startup Sleep, 500 WinSet, Bottom, , LaunchBox BigBox WinWaitClose, ahk_exe Blazing Chrome.exe WinActivate, LaunchBox Game Startup WinSet, AlwaysOnTop, on, LaunchBox Game Startup You are in the right spot if you want this script to run for every game launched from the "Windows" platform. We need to make sure the games you claim your script isn't working with are being launched from a platform titled "Windows"? I don't think the script will execute if you launch a "Windows" game if you put it under any other platform name like "PC Games" or "Windows 10" or "Windows 98" and so on. I don't use this method, but I tested with a basic MsgBox, SoundBeep, and opening notepad files just now and it launched up with a couple "Windows" games....aka NON-STEAM games that are PC games (required me to edit the script to be triggered off "{{{StartupEXE}}}" instead for non Steam games). However, I'm noticing not once did it work with a STEAM game. Going further, I can confirm what you shared....script works fine with a STEAM game if launched externally from LB/BB. Your use going off the GameOverlayUI is weird, but neat at the same time! So something is fucked up with how this LB script window interacts with STEAM games. I cannot find fault anywhere with your script. I would try making them additional apps and see how that goes. My guess is the script is being prematurely terminated due to how Steam bootstraps games into launching. Steam launches a "launcher" itself so when LB/BB sees that "launcher" exit as the game begins to actually boot it terminates the script. Meaning script doesn't even really run most likely. I couldn't even get a MsgBox, SoundBeep, opening notepad etc kinda basic tests to see if the script runs for Steam games. But if you launch the script from Windows instead of LB/BB, it works as expected.

first I would want to prove if it's hardware, or software problem. I'm not sure how things are hooked up in these, but taking a set of PC speakers (or any compatible speakers) and plugging them in would be a good troubleshooting exercise. if the other speakers work just fine you proved software is working fine, which then def means it's a hardware problem. that would mean an issue with the speaker or the cables, something in that audio signal chain. can you actually adjust the volume via a hardware control? Idk if they are pots like potentiometers or buttons, but if your volume adjusting device doesn't work anymore, I'd be leaning towards hardware problem. can you adjust volume via software? even using the basic volume control in the bottom tray icon would suffice here. make sure that isn't turned down real low, and would also be good to check if software can raise/lower the volume. even if it's already really low, if you turned that slider down you should still hear your speakers get even quieter or basically turn off completely

Since toggling full screen, the menu, and fast forwards are all hotkeys that may suggest the hotkeys got changed for those actions. you can have multiple inputs do the same hotkey output. for example, F key on the keyboard, and any button (or trigger or joystick too I believe) on the controller could simultaneously both be made to toggle fullscreen. if you went about this where you removed the keyboard key to replace it with the controller button, that would explain why the keyboard doesn't seem to work for that stuff anymore. Check hotkeys under Settings > Input > Hotkeys. Change them to your desired keys and make sure to save the config file prior to exiting Retroarch

Thanks for this bit! I always wondered why I would sometimes get duplicate tray icons that magically disappear when hovered over. I also don't think I tried the method of importing the script as the ROM. I bet this piece of info is the fix to certain exotic launching configs I made that have the startup screen work fine, but the shutdown screen prematurely closes a handful of seconds after the startup screen fades out

My MAME bezels got put under overlays\ArcadeBezels while every other system was placed under overlays\GameBezel*insert system here* (just like where you described) So if you haven't checked it already and actually have such a folder, take a look at that ArcadeBezels folder If that isn't helpful, I would look at Retroarch\config\MAME and review any of those files. They list where the overlay config file is. So if the overlays are still coming up, this will tell you exact which overlay config they are using (which lists it's file path) so you could then delete them

I've never once seen Windows 10 (I don't have 11 to test) recognize the Guide button in "Game Controllers" properties test window, but in your defense I bet it would be button 11 also since (in no particular order) A, B, X, Y, back, start, LB, RB, LThumb click, RThumb click would be 10 buttons....the next logical spot for a button like the Guide button would be #11. Now it's not that Windows 10 cannot see this button pressed at all, it works some how with the Xbox Game Bar or whatever overlay comes up when you click it, it's AHK that is being a finicky SOB about reading it. But I swear, it has never lit up button #11 or any button # at that in the Game Controllers window I got that much myself from reviewing the key history in AHK, since the Guide button is literally the only xinput button that is pseudo recognized by AHK as a key press. I had to make sure the key board hook was installed with the "#InstallKeybdHook" line for the button to even come up with that virtual key address along with it's key name always being "not found" I found more stuff too and was piecing away at it over the last week but I've not had luck with getting the Guide button to do anything. I did not have the Game Bar disabled until tonight, repeating my tests this didn't change anything though. I also am on the latest version of AHK 1.1.34.03 and frankly think shit is getting silly with how many versions I need for this very reason....as AHK continues to mature it may break old scripts. I normally fix up the old scripts to work with new AHK versions because I already got three I keep on my system, I don't want more. AHK already is trying to work its way to version 2.0 and LaunchBox includes version 1.1.24.03 so I didn't have the version that user claims is required for their script to work. I mean, this script doesn't even launch (on newer versions) due to having an invalid hotkey putting in the virtual key code like that....IDK if AHK really changed something that much between versions or what......BUT.....if you want to find that very specific version that script does seem to work......with that very specific version is the key bit to take away. Besides the fact that the #If(Not)WinExist functions are deprecated, I'm not seeing anything else as old/deprecated. So I'm not sure what else would need changing if making any changes would get the Guide button script to run on newer versions. The #In(Not)WinExist lines are not the issue , it's recent versions don't recognize that virtual key as an acceptable hotkey. Furthering my point, taking the new working scripts and trying to run them on the older version that user directed us to, doesn't run like that either. The info I found suggested you needed to further alter Xinput.ahk "library" to include additional DLL files, which I did, and also added in the Guide button to the constants. Recall I said it wasn't in there? I figured it would be as easy as identifying it and adding in these additional lines....I was wrong. It still doesn't work for me after making all the adjustments. So now the only time I can say the guide button was able to be used with AHK is that one specific AHK version, 1.0.48.05, and the accompanying script that same user shared This is great work again! A little help has turned into doing all the heavy lifting here lol. I am up to speed and confident of the scripts behavior and logic, but I still didn't have the experience to do what you just added on. I would have eventually got the joysticks working after narrowing down the dead zone I wanted, but this bit I didn't even think about going down the path you implemented to deal with what I would call "anti auto fire". I really like the idea to store the trigger variable into triggerprev so you can do a check if they change. Funny enough I just made a script for the first time "storing" variables like this, but this is where I don't have experience yet to understand how to use all the tools at my disposal. Little help like this goes a long way in teaching me new concepts and methods to get past a coding challenge. This community is specifically what convinced me learning AHK is worth my time. I've learned so much from studying others scripts on here along with the AHK forum so I appreciate the continued help and lesson you're giving me here!

yes you need to change that in Retroarch. If you want it on the analog stick exclusively or simultaneously with the d-pad, you need to manually configure that in Retroarch's input/controls settings. Be aware you can save input/controller remaps globally, per system/core, per game, or I think even per directory (folder where game is loaded from). Globally would be done from the Main Menu > settings > Input > Port X controls (X being the player/port #) If you wanted it per system/core, game, directory, those are done once a game is running. Then you do the same thing except from the quick menu. Quick menu is something that comes up with options specific to the system/core running. So in the Quick Menu, scroll down to Controls/Inputs and go to Port X controls and change them accordingly. Make sure to save your changes once finished. edit: imagine a SNES controller, no analog stick.....that is why Retroarch doesn't automatically map the d-pad to the analog stick of a modern controller. Retroarch does the auto mapping by what makes the most sense, so older consoles that just had d-pads are going to have those buttons default auto mapped to d-pads. so gamers need to manually configure it if they would want to use the analog stick. You will find this is how it works with other retro systems too should you add more of them I think Retroarch DEFAULTS to saving all changes upon exit....and I hate this. I like to be able to fiddle around, and I'll save when I know everything is all good. Beware if you have it saving changes upon exit since anything you alter whether you meant it or not will be automatically saved when you close the program. Kinda makes it hard troubleshooting and trialing settings with such an option on. I make sure this is set to OFF and save manually whenever I need to make adjustments. I think it's under settings and configuration file.

Well now you just taught me something. If you open Task Manager and select "Windows Explorer" in the "PROCESS" tab it will change the "End Task" button to "Restart", so I've always thought it could only restart (resurrect itself) this way But now I see what you're talking about. If you go over to the "DETAILS" tab and select "explorer.exe" the button stays as "End Task" and that will in fact kill it for good....do not ask me how to get it to run again from here though (without the use of the hotkey script). The hotkey does work to manually run/resurrect it....however, without such a hotkey I wouldn't know what to do. Whenever I have had explorer get stuck in a killed state, I've had to log off, shutdown, or restart. You effectively have no way to navigate throughout the OS without it So no I don't know how to do exactly what you want, but there probably is a way since we can manually navigate to such an action. If AHK can distinguish between a restart and end task through Task Manager it would be possible. The standard Process, Close command seems to be acting like it is done through the "Processes" tab meaning explorer gets restarted. It needs to send such command to the "Details" tab so it does "End Task" EDIT: oh duh didn't think of this right away lol....since you got it working with a batch file you could easily have an AHK script tell this batch file to run. Something like this.....replace the Process, Close...... line with running the batch file instead. SendMode Input ;; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ;; Ensures a consistent starting directory. eProc = explorer.exe ^!e:: Process,Exist,%eProc% If ErrorLevel != 0 Run, PATH/TO/BATCH/FILE/TO/PERMANENTLY/KILL/EXPLORER If ErrorLevel = 0 Run, %eProc% Return

Sure, try this out. I just tried this and it works fine. I tested it with MS Paint and Windows Explorer. Please note that closing Windows Explorer this way results in it restarting immediately afterwards. It's no different than going into task manager and kill the process that way. It automatically resurrects itself If you really need that keywait line, add it back in. But I didn't think it was required, same goes for the WaitClose line. I'm not exactly sure why anyone would want to process kill Windows Explorer? SendMode Input ;; Recommended for new scripts due to its superior speed and reliability. SetWorkingDir %A_ScriptDir% ;; Ensures a consistent starting directory. eProc = Explorer.exe ^!e:: Process,Exist,%eProc% If ErrorLevel != 0 Process,Close,%eProc% If ErrorLevel = 0 Run, %eProc% Return

thanks a lot for your help here with the script add on and clean up! Unfortunately on my end I have had no luck with using the method detailed in the AHK docs you're asking about. I went about it from every angle and interpretation I could think of without success. I never did get that that MsgBox to show up! I think this is a very useable script, but I'm finding some flaws going this route. Not surprisingly if the timer is set too quick it will poll the buttons so frequent you will almost certainly get multiple outputs per a single input. If you set a key delay or the timer too slow/long, now you've missed your inputs and it will feel the game is unresponsive. I don't know if there is a good set it and forget it position. Depending on the game and the gamer, it will need to adjusted accordingly. It doesn't understand a held down button the way I imagined, but it may not matter. Holding a button down will send multiple outputs. Sure keyboards do the same, but I'm not 100% if that is how controllers work. As in holding button "A" to make your character jump higher is different than tapping "A" a dozen times, with this script behaving in the tapping a dozens times method. The tapping action may not register with the game the same way a held down button does. I had a feeling this might be the case, but I think it will be frustrating for most to use this since it doesn't mask the inputs. For ex if you for some reason you no longer want the "A" button on the controller to make your character jump, you want it to be "B", which is normally fire weapon......then when you hit "B" it will still read the normal button press of fire weapon AND the new one jump. This may not be super useful to the average gamer as a result. It will do just fine in certain scenarios though

First part of your comment it was select and start lol?! Maybe just a typo mixing up start and enter? However, if you are actually hitting enter on the keyboard, that is the default for the virtual pad in Retroarch for the SNES core's START button. ie you hit ENTER on your keyboard it's like hitting a SNES controller START button, which in 99.99% of cases will pause the game if you were in the middle of playing. This makes sense if I understood you right. Don't get discouraged, you will get it sooner or later. Plenty of help out there through guides and tutorials and this here community! This is in Retroarchs controls menu when you have a SNES game running already. Since I have an Xbox One controller connected it also detects that besides the keyboard. The WHITE text are my INPUTS. The GREEN text is the output! The "menu" button (start button) on the Xbox controller, and "enter" on the keyboard both trigger the SNES virtual pad "start" button. That is why if you hit enter it would be pausing the game edit: also if you did not in fact setup the controller hotkey right the first time around, then the start button on the controller would obviously behave like the start button....as in pausing the game.