skizzosjt

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.

I don't see anything for the guide button in the library, so that may not be possible. To make sure we're on the same page, this is the same button to power on/off the wireless controllers? The rest is already done though! So far, I'm having luck here! I got all buttons working, A, B, X, Y, Left Shoulder, Right Shoulder, Back, Start, Left Joystick Click and Right Joystick Click. Having a tough time figuring out wtf is going on with the joystick axis though. I got it to...."work".....but it's not exactly doing what I want it to. Still trying to figure out what the script is doing here with the axis and what the values are when it's moved to different positions. So I think the joysticks axis is the last bit of this puzzle! Here's what I got playing around tonight. I'll have to come back at this after letting it stew in the old noggin' for a bit. Perhaps someone else with more AHK experience will dissect this and give me a good lesson! *Beware, after seeing Joes cleaned up script just now, mine looks like a nightmare! 🤣 Also please keep in mind this is just playing around troubleshooting work in progress! I'm well aware all these outputs make zero practical sense, I just needed to see something different happen so I could keep track of what's working as I go about this #Include Xinput.ahk #Persistent #SingleInstance, Force SetTimer, checkForJoy1, 10 checkForJoy1: ;******** ;A BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { a_pressed := state.wButtons & 4096 if(a_pressed) { ;Msgbox, Does this work [%a_pressed%] ;Sleep, 2000 Send {k down} Sleep, 50 Send {k up} } ;******** ;B BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { b_pressed := state.wButtons & 8192 if(b_pressed) { ;Msgbox, Does this work [%b_pressed%] ;Sleep, 2000 Send {p down} Sleep, 50 Send {p up} } ;******** ;X BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { x_pressed := state.wButtons & 16384 if(x_pressed) { ;Msgbox, Does this work [%x_pressed%] ;Sleep, 2000 Send {d down} Sleep, 50 Send {d up} } ;******** ;Y BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { y_pressed := state.wButtons & 32768 if(y_pressed) { ;Msgbox, Does this work [%y_pressed%] ;Sleep, 2000 Send {e down} Sleep, 50 Send {e up} } ;******** ;D-PAD UP ;******** XInput_Init() state := Xinput_GetState(0) if(state) { dpadUP_pressed := state.wButtons & 1 if(dpadUP_pressed) { ;Msgbox, Does this work [%dpadUP_pressed%] ;Sleep, 2000 Send {Up down} Sleep, 50 Send {Up up} } ;********** ;D-PAD DOWN ;********** XInput_Init() state := Xinput_GetState(0) if(state) { dpadDOWN_pressed := state.wButtons & 2 if(dpadDOWN_pressed) { ;Msgbox, Does this work [%dpadDOWN_pressed%] ;Sleep, 2000 Send {Down down} Sleep, 50 Send {Down up} } ;********** ;D-PAD LEFT ;********** XInput_Init() state := Xinput_GetState(0) if(state) { dpadLEFT_pressed := state.wButtons & 4 if(dpadLEFT_pressed) { ;Msgbox, Does this work [%dpadLEFT_pressed%] ;Sleep, 2000 Send {Left down} Sleep, 50 Send {Left up} } ;********** ;D-PAD RIGHT ;********** XInput_Init() state := Xinput_GetState(0) if(state) { dpadRIGHT_pressed := state.wButtons & 8 if(dpadRIGHT_pressed) { ;Msgbox, Does this work [%dpadRIGHT_pressed%] ;Sleep, 2000 Send {Right down} Sleep, 50 Send {Right up} } ;********** ;START ;********** XInput_Init() state := Xinput_GetState(0) if(state) { start_pressed := state.wButtons & 16 if(start_pressed) { ;Msgbox, Does this work [%start_pressed%] ;Sleep, 2000 Send {S down} Sleep, 50 Send {S up} } ;********** ;BACK ;********** XInput_Init() state := Xinput_GetState(0) if(state) { back_pressed := state.wButtons & 32 if(back_pressed) { ;Msgbox, Does this work [%back_pressed%] ;Sleep, 2000 Send {B down} Sleep, 50 Send {B up} } ;************* ;LEFT SHOULDER ;************* XInput_Init() state := Xinput_GetState(0) if(state) { LShoulder_pressed := state.wButtons & 256 if(LShoulder_pressed) { ;Msgbox, Does this work [%LShoulder_pressed%] ;Sleep, 2000 Send {L down} Sleep, 50 Send {L up} } ;************** ;RIGHT SHOULDER ;************** XInput_Init() state := Xinput_GetState(0) if(state) { RShoulder_pressed := state.wButtons & 512 if(RShoulder_pressed) { ;Msgbox, Does this work [%RShoulder_pressed%] ;Sleep, 2000 Send {R down} Sleep, 50 Send {R up} } ;************** ;L-THUMB CLICK ;************** XInput_Init() state := Xinput_GetState(0) if(state) { LTClick_pressed := state.wButtons & 64 if(LTClick_pressed) { ;Msgbox, Does this work [%LTClick_pressed%] Send LEFT THUMB CLICK } ;************** ;R-THUMB CLICK ;************** XInput_Init() state := Xinput_GetState(0) if(state) { RTClick_pressed := state.wButtons & 128 if(RTClick_pressed) { ;Msgbox, Does this work [%RTClick_pressed%] Send RIGHT THUMB CLICK } ;********** ;L-TRIGGER ;********** XInput_Init() state := Xinput_GetState(0) if(state) { LTrigger_pressed := state.bLeftTrigger ;the "& [insert # here]" part doesn't seem to be required for the triggers if(LTrigger_pressed) { ;Msgbox, Does this work [%LTrigger_pressed%] ;Sleep, 2000 Send LEFT TRIGGER } ;********** ;R-TRIGGER ;********** XInput_Init() state := Xinput_GetState(0) if(state) { RTrigger_pressed := state.bRightTrigger ;the "& [insert # here]" part doesn't seem to be required for the triggers if(RTrigger_pressed) { ;Msgbox, Does this work [%RTrigger_pressed%] Send RIGHT TRIGGER } ;******************* ;L-THUMB Y AXIS DOWN ;******************* XInput_Init() state := Xinput_GetState(0) if(state) { LT_Yaxis_Down := state.sThumbLY & 3000 if not(LT_Yaxis_Down) { Msgbox, Does this work [%LT_Yaxis_Down%] pressed down } /* ;******************* ;L-THUMB Y AXIS UP ;******************* XInput_Init() state := Xinput_GetState(0) if(state) { LT_Yaxis_Up := state.sThumbLY & -32000 if not(LT_Yaxis_Up) { Msgbox, Does this work [%LT_Yaxis_Up%] pressed up } */ Return ;The number of closed braces below will match the number of buttons/triggers/joysticks being checked above } } } } } } } } } } } } } } } } } ;} ;this brace is commented out currently due to commenting out "L-THUMB AXIS UP" section F11::ExitApp F12::Reload F10::Pause, Toggle ; These nubmers are decimal conversions from the hexidecimal values in Xinput.ahk "Constants for gamepad buttons" section ; 4096 = A button ; 8192 = B button ; 16384 = X button ; 32768 = Y button ; D-pad UP = 1 ; D-pad DOWN = 2 ; D-pad LEFT = 4 ; D-pad RIGHT = 8 ; Start = 16 ; Back = 32 ; LEFT SHOULDER = 256 ; RIGHT SHOULDER = 512 ; LEFT THUMB CLICK = 64 ; RIGHT THUMB CLICK = 128 This is excellent! Sooooo much easier to read! Thanks for doing it, and for sharing! I will def use this execution as I keep poking away at this. The buttons/triggers were kinda easy....but the joysticks are proving to be a bit more of a challenge.

wow....fuck me......this.....works! 🎉 There's no restriction with needing the AHK tray icon window open to read the controllers input! You also need the Xinput.ahk library for this to work of course! I'm still not 100% convinced this is going to be better than existing methods using other various remapping programs, but this is a HUGE hurdle that both of you have helped out with! Here is me testing with adding in additional buttons. all 4 face buttons work here, A, B, X, and Y. The values are hexidecimal in Xinput.ahk so needed to be converted into decimal format apparently in the main script. I encourage others to play around with this and come back with their experience! After I kid you not, months of random intervals of investigating this.....this is the first time I've gotten anything even remotely useful working! Thanks so much @JoeViking245 and @drw4013 👏😁 for coming along on what feels like a crazy roller coaster of info pulling us in different directions! #Include Xinput.ahk #Persistent SetTimer, checkForJoy1, 10 checkForJoy1: ;******** ;A BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { a_pressed := state.wButtons & 4096 if(a_pressed) { ;Msgbox, Does this work [%a_pressed%] ;Sleep, 2000 Send {k down} Sleep, 50 Send {k up} } ;******** ;B BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { b_pressed := state.wButtons & 8192 if(b_pressed) { ;Msgbox, Does this work [%b_pressed%] ;Sleep, 2000 Send {p down} Sleep, 50 Send {p up} } ;******** ;X BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { x_pressed := state.wButtons & 16384 if(x_pressed) { ;Msgbox, Does this work [%x_pressed%] ;Sleep, 2000 Send {d down} Sleep, 50 Send {d up} } ;******** ;Y BUTTON ;******** XInput_Init() state := Xinput_GetState(0) if(state) { y_pressed := state.wButtons & 32768 if(y_pressed) { ;Msgbox, Does this work [%y_pressed%] ;Sleep, 2000 Send {e down} Sleep, 50 Send {e up} } Return } } } } ; 4096 = A button ; 8192 = B button ; 16384 = X button ; 32768 = Y button

I think we're on the same page. That user, evilC, is the author of UCR and seems to be a knowledgeable authority on these topics. I did like JoeViking's idea we should test with a MsgBox, I don't think I tried that. I always was trying to map for example the "A" button aka "button 0" (usually it's 0, some programs might start at 1 instead of 0) to output a keyboard key like "f". I didn't ever succeed doing this. And I also agree with Joe that there is no way AHK to output an xinput button press. That is how to got turned on to programs like virtualcontroller I agree on that! I never went through these troubleshooting steps detailed in the AHK docs. Take a look at this here: https://www.autohotkey.com/docs/KeyList.htm#SpecialKeys I was aware of that detailed page JoeViking shared, but I didn't have success implementing those methods So I shared that link because I figured I could find out if AHK was detecting a button press at all this way.....and it doesn't see squat from any of my xinput controllers. There is one exception, I noticed the large Xbox "X" logo button at the top of these controllers (to turn them on/off and bring up home screens and the like) that would always come up "not found". Otherwise it did not detect a single face button, trigger, or joystick whether it was joystick position or clicking them down. I tried all those huge libraries that were using commands like GetKeyState, anything and everything I've attempted has came up as a failure. I too was not capable to get a MsgBox or anything to run via AHK via an xinput button press on any of my xinput controllers. I appreciate your advice and tips here @JoeViking245, but I've got to side with @drw4013, I think this whole xinput and AHK being capable of working together has been broken for X time....either both DRW and I are on the wrong path together or AHK just isn't a feasible tool to use to remap xinput right now....in my humble opinion. I am on Windows 10, for what that is worth. And tried with Wired Xbox 360 (OEM Microsoft), Wireless Xbox One (OEM Microsoft and third party PowerA), and Wireless Xbox "Core" (Xbox Series X) controllers. All produced the same disappointing results. lastly here is a snip of the AHK key history detailing what I was talking about with no buttons detected. I hit the "LButton" left mouse click to go into the script in notepad, click on the Xbox controller "X logo" button once, and then hit every single key, trigger, and joystick twice in that 16.19 secs, and then hit the "X logo" button again. As you can see absolutely nothing was detected in between those "X logo" button hits. The LButton and F5 afterwards was to get to the key history page and update it to see the list. I repeated this test again today, also tried hitting the controller buttons with the AHK open window as the active window.....makes no difference in my case, nothing was detected besides the "X logo" button. Jesus christ.....after I write that dissertation length post I finally got something to work! But still not in a practical way. That stackoverflow page you linked to (https://stackoverflow.com/questions/66219307/detecting-joystick-buttons) worked if I HELD THE "A" BUTTON DOWN WHILE CLICKING ONTO THE SCRIPT TO RUN IT! I altered it a bit to see if it would in fact output something practical like a keyboard key and it did! This allowed me to run the script and have enough time to bring up notepad and send some keys. The commented out lines are fine to include as well and sent back the right button number of 4096 #Include Xinput.ahk Loop { SetTimer, checkForJoy1, 100 checkForJoy1: XInput_Init() state := Xinput_GetState(0) if(state) { a_pressed := state.wButtons & 4096 if(a_pressed) { ;Msgbox, Does this work [%a_pressed%] ;Sleep, 2000 Send {k down} Sleep, 50 Send {k up} } } } Return So perhaps there is some way to make this work better. It seems this users script just instantly exits otherwise. I'm missing something here from an AHK standpoint....this script looks like it should keep checking for if the A button is pressed every 100ms until I explicitly terminate the script. If I put a loop in I can keep it running, but get an occasional error about the Return being out of the braces if I hold the A button down for a long time. This is super easy to send too many outputs as is. Meaning this would be great for some rapid autofire kinda option, but otherwise needs a different approach so you do not send like 4 keys with 1 button press. So.....perhaps there is some messed up convoluted way to get all this shit to work but wtf who wants to go through all this?! I could have set this up with GlovePIE or UCR in less than a minute! All those K's are from my Xbox One controller! I didn't need any specific AHK window open to make those button presses be seen by AHK or send the k key! I don't grasp why this exits immediately (seeming immediately, if the MsgBoxes I added were not there), nor why it produces two MsgBox's here.....its like there is a "Loop, 2" line somewhere. This is how the script seems to behave by default, goes through the check and exits without any user intervention. You click OK on the "front" MsgBox (2nd one to pop up) it keeps popping back up....You gotta click on the the 1st MsgBox, then the 2nd to get the script to terminate. Hoping someone can give me a lesson on what I am missing here! Maybe there is something going on in the included Xinput.ahk file EDIT: So I figured that out...maybe....I put a "#Persistent" line in this script and that seems to get it to work in a practical fashion without a loop! I'm not sure if this is the "correct" way to deal with it though, I'm still really green to AHK so there might be a better approach

farted around with this last night. Retroarch actually has internal settings for this I didn't know about. I was already using windowed fullscreen, so Retroarch's implementation of window fullscreen and exclusive fullscreen both make stuff like detecting pixel colors with AHK wrong. Not really Retroarch's or AHK's fault, it's just how graphic API and the hardware work, seems to bypass talking to the OS which makes sense, exclusive fullscreen prevents needing to render all that OS related stuff behind the game you're playing. I even used AHK to change Retroarch's window style to be completely borderless, no menu bar and all that stuff.....messed up part here is the second I did that it also screwed up how detecting pixel colors works.....even when it is windowed and not fullscreen. So, sad to say this method only works when in a standard window mode, which I would think 99.99% of gamers are not going to want to have to sacrifice having to play their games with window menus and icons and toolbars etc still showing on the display