skizzosjt

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

I maybe I got the controller's rumble to work with that example you mentioned too, but I def never got any actual button remapping work. Something seems so fishy about this because it's not like there is a lack of interest in it, yet there seems to be such poor documentation and discussion surrounding it. If ppl found a fix and workaround to use current AHK version on current/modern OS versions, I would think there would be more forums posts and discussions around such a topic.

Hi there @drw4013 I think you are trying to do something that is more or less impossible with AHK. I've looked into this quite a bit myself and never got anything worth while working as far as using AHK to remap xinput style controllers! Key word here is XINPUT! AHK seems to have for the last several years not been able to do what you are trying to accomplish. All Xbox brand or third party Xbox type controllers are going to be XINPUT rather than DINPUT. I cannot confirm if AHK can work at all or better with DINPUT but it may work with DINPUT style controllers in the method you're employing here in your script. When I want to remap my Xbox controllers I use a program like GlovePIE or UCR, these can read xinput for the input, therefore allows you to make the output to something like the keyboard, exactly what you're after! I would have suggested virtualcontroller here too but I realized recently it only reads DINPUT for input. I didn't notice this before because it seems to take an xinput button and put it into the program as a dinput button....but then I found out the output never happens in those cases since it really can only read dinput. virtualcontroller does work fine for DINPUT controllers though. antimicro might be another option, I checked it out after seeing users talk about it here on this forum. I liked it enough I never deleted it after testing, but I admit I cannot remember if it reads xinput for input (like GlovePIE and UCR), or only could use xinput for output? (like virtualcontroller) Here is a couple pages I found a while back that led me to finally wave the white flag and conclude this just ain't happening with AHK and xinput. All the posts I came across there were some ppl saying it works, from posts a decade ago lol, anyone recently is going "hey this isn't working anymore!?!" https://www.autohotkey.com/boards/viewtopic.php?t=61326 https://www.autohotkey.com/board/topic/35848-xinput-xbox-360-controller-api/page-4 @JoeViking245, or anyone at that, please correct me here if I am off in left field on my understanding of AHK and xinput. I would love the ability to do this AHK, so if it is possible, please guide me on some setup steps.

I don't know what "ReShadeManger.dll" does, I can guess it's some sort of manager for reshade lol. I have done basic setups with reshade when going through step by step guides, but otherwise know nothing about its actual operation process. I couldn't advise on anything specific beyond whatever you want to do in AHK

When you get into games, you cannot start what? Did you configure a button or some combination of buttons to trigger exiting the emulator? If you did not, it makes sense you cannot exit the emulator/game via the controller There are youtube channels dedicated to LaunchBox tutorials! Here's one of them! https://www.youtube.com/c/UnbrokenSoftwareLLC/videos If you need to change from default settings then yes you need to configure each emulator accordingly. Everything still needs to be setup in LaunchBox though. If you cannot select Retoarch as the emulator for SNES system then that suggests you never added Retroarch to your list of emulators in LaunchBox. It sounds like you made the SNES system/platform, but never added an emulator to play games you added to the SNES system/platform I suggest to get familiar with the tutorials. They will provide details you need on getting yourself setup.

🤣LMAO I don't know about patience of a saint, but yes, I'd look like a spider web of cracks after reading this thread! I think you're making a mountain out of a mole hill. Who cares if it hits "o" in the Retroarch menu? IT DOES LITERALLY NOTHING.......as long as you are not trying to type! Hit the o key on your keyboard a million times even, it doesn't matter, it doesn't engage with anything within the menu. The only time the script will genuinely frustrate the user is if you are trying to type in Retroarch. I can only think needing to type during something like changing hotkeys or controller remaps. I tested plenty of times with 1 second interval for the key press and just smashing keys on my keyboard, it does nothing. The only time it mattered was when I would go into the hotkey menu and no surprise to anyone, after I hit enter on a hotkey to assign a new key it would populate with "o" if you were not fast enough to hit a key prior to the script sending "o"! That is with a 1 second interval though! This wouldn't happen unless you sat there waiting for the change overlay interval you entered. You are going to be using 60 secs or larger intervals I imagine, so you got up to that interval duration to type before any extra key gets pressed via the script. Do you really think you, your friends or family are going to be running said script at 60 sec+ intervals and trying to change hotkeys and controller remaps? I don't buy it for a split second that you could, with a straight face, say you need the ability to do that. My point here being is I don't think it's a good idea to even have F1 pausing the script, that is what the "PauseHotkey" was for. I did get your request to work with using PixelGetColor and PixelSearch. Using these commands you can search an area or specific coordinates, even looking for variation tolerances. I did it in a way so it was always looking for the CRT TV bezel part that has the 4:3 aspect ratio, as well as looking for colors specific to when the Retroarch menu comes up in any of the corners. But the problem with this is it only works in a windowed mode. Not sure if it will work in a "fullscreen windowed mode" (I'm gonna test that, eventually...some feedback suggests it should work.....others said no so I gotta see for myself), best I could test with so far is it works when Retroarch is in a window or maximized but that is still technically a window. It most certainly does not work in exclusive fullscreen. Tons of threads out and about on this quirk with those commands if you or anyone wants to know the nitty gritty details.

Wow who could have predicted that! lmao glad it's working for you, but c'mon man that should have been checked first thing like I suggested. When troubleshooting you gotta start with the low hanging fruit first!

USE "PAUSEHOTKEY" IN THESE SCENARIOS! I'll say it again...

I did try to warn you about adding the BigBox pause screen hotkey and same train of thought applies here to the Retroarch menu toggle hotkey. There is a reason why I made a pause hotkey in the script! My thoughts were that was sufficient control. On the bright side, I did figure it out after taking a moment to review the script and AHK docs. The single change to fix this problem is highlighted in red RetroarchMenuHotkeyA = $F1 ;enter Retroarch Menu hotkey (physical) Other changes, WinActive function needs the quotes, changed syntax of ErrorLevel for better readability, used SendInput instead of Send. SendInput was my first idea to fix the hotkey issue that was ultimately resolved with the $ modifier symbol. SendInput is better but makes no real difference in this script I was happy to also figure out why certain keys worked like F12 and Left Control. SOME keys DEFAULT to use the keyboard hook instead of through the regular RegisterHotkey function. The $ modifier makes the hotkey use the keyboard hook instead! So that is why it resolves the problem! You can see what hotkeys are in the script and more info on them by clicking on the AHK icon and selecting "Hotkeys and their methods". You get a list like this for ex F12 and Left Control have no modifier, but shows k-hook for keyboard hook, hence why they worked by default during my troubleshooting....this was really confusing me for a moment. At the same time, it's why I figured it out. F1 shows k-hook because it's forced to use it after adding the $ modifier. Should you not want the extra pausing hotkeys on F1 and Pause keys (or whatever you have assigned them as), you can simply remove or comment out those specific lines. Here's what I'm calling the final draft of this. I'm happy with it now. It does what I want it to, I accomplished what you wanted, and I can confirm it all works properly since it got plenty of use over the weekend. I've wanted to do this ever since I noticed RocketLauncher had hotkeys for bezels. I thought it would be neat if it did it automatically rather than require the user to hit the hotkey. You had the same idea, but wanted it for Retroarch. Great minds think alike! Your request was the motivation to finally start, and complete, this project! ;*************************ENTER VALUES HERE************************************************************ OverlayHotkey = o ;enter Retroarch Change Overlay Hotkey secs = 60 ;enter number of seconds between changing overlay PauseHotkey = F12 ;enter key to toggle pausing the script RetroarchMenuHotkeyA = $F1 ;enter Retroarch Menu hotkey (physical) - USE $ IF NEEDED FOR COMPATIBILITY! RetroarchMenuHotkeyB = F1 ;enter Retroarch Menu hotkey (in menu selection) BigBoxPauseHotkey = Pause ;enter BigBox Pause Screen hotkey ExitHotkey = F11 ;enter key to terminate the script ;****************************************************************************************************** #SingleInstance, Force secs := secs*10 Hotkey, %PauseHotkey%, PauseHotkey Hotkey, %BigBoxPauseHotkey%, BigBoxPauseHotkey Hotkey, %ExitHotkey%, ExitHotkey Hotkey, %RetroarchMenuHotkeyA%, RetroarchMenuHotkey WinWait, ahk_exe retroarch.exe ;waits for Retroarch to exist before executing script Loop { Loop, %secs% { Active: If not WinActive("ahk_exe retroarch.exe") ;checks if Retroarch is active window every 1/10th sec { Sleep, 100 Process, Exist, retroarch.exe ;checks if Retroarch exists If ErrorLevel = 0 ;if Retroarch does not exist, terminate script { ExitApp } Goto, Active } Sleep, 100 } SendInput {%OverlayHotkey% down} ;Presses and releases the Change Overlay Hotkey Sleep, 50 SendInput {%OverlayHotkey% up} } RetroarchMenuHotkey: SendInput {%RetroarchMenuHotkeyB% down} Sleep, 50 SendInput {%RetroarchMenuHotkeyB% up} Pause, Toggle, 1 Return PauseHotkey: BigBoxPauseHotkey: Pause, Toggle Return ExitHotkey: ExitApp

except for when you want to search by any number of the various other sets of info as detailed by C-Beats.....

Yes but I found a quirk here, I don't know if it's my hardware which would be my keyboard, Retroarch or AHK. Didn't notice until your latest add on. Using F1 as a hotkey through AHK and having Retroarch use that as it's menu hotkey isn't working for me! It only triggers the AHK hotkey to pause the script, and not the hotkey behavior inside of Retroarch, actually toggling the menu. It seems to be some limitation of having the physical key have the same digital output as normal. If I make my physical key different, for ex F2 triggering F1 then it works. If I use different key/hotkey for both the physical input and the Retroarch Menu toggle hotkey it sometimes work, for example it works with both the physical key and Retroarch Menu toggle hotkey as F12 or with Left Control (but MANY keys I tried did not work when both input and output).....so this is why it might be how my keyboard is built or maybe this is standard issues for all users for all I know.... So you may need to change hotkeys in both the script and in Retroarch but this does work. All the previous stuff works fine still, that is solid, it's this new pause while toggling Retroarch menu being the oddball here Go to this comment for final version of script Old version of script

hi @Sbaby glad it's helping you out, but you should use this version instead. it works better and makes it easier for anyone to put their specific values in. Go to this comment for final version of script Old version of script

Under where the F12 hotkey is add in your BigBox Pause Hotkey so when you go into pause screen it pause the script. Though, I would think if the "o" (or whatever hotkey was assigned) is hit when on the pause screen it would do nothing, this shouldn't be an issue. You also would need to always leave the pause screen through hitting the pause hotkey or use the other AHK pause key to resume it. You're kinda adding an unnecessary layer. Regardless.... In essence you're making more than one hotkey do the same thing, pause the script. make sure to remove the comment marker ";" semi-colon at the start of the line when you do put in the BigBox hotkey so it executes that line I also added in a check to exit the script if retroarch closes Go to this comment for final version of script Old version of script

Setup Dolphin in its normal standalone emulator format, as in don't use the Retroarch core version, and see if the hiccups go away. Be sure to launch your games directly through the emulator, as well as through LB (but to the standalone emulator, not Retroarch core) to see if the behavior changes between them also.

The GPU, that is reasonable suspect to be tampered with if it is in fact only got 4GB of VRAM. I swear there is at least one rando new user every week signing up on TechPowerUp to go "help plz my GPU is fake how to fix!?" Too many ppl buying no name GPU's from China sold on Aliexpress!

I can help with Retroarch, but not MAME because MAME doesn't have a change bezel/overlay hotkey. I don't think Retroarch assigns a hotkey to the change overlay hotkey by default, you need to manually enter the hotkey. In this example I set mine up as "o". What were doing here is using a script to automatically change the overlay every 60secs while still giving the ability to change with the Retroarch change overlay hotkey. You can change the hotkeys and the timing to your own preferences. You will need to edit the associated game and/or core/system configs appropriately to have multiple overlays for this to work. Go to this comment for final version of script Old version of script