skizzosjt

OK so all that confirms the script is doing what you told it to do then. You tied the context sensitive hotkeys to a window (MySplash) that shows up for a moment and then is "destroyed" just a few lines later when "Splashimage,1,off " is ran. The only time those "do nothing hotkeys" will work as you intend them to is between creating them and the time it takes Splash2 window to appear, which is before any game is launching, hence why you're inputs are still being detected while the game boots. That Splashimage off command destroys the window which the context sensitive hotkeys that are supposed to be blocking joypad inputs are dependent on. So they will not work anymore, meaning your inputs WILL be detected. This comes down to needing to design the script structure better so it suits your needs. There are options to get it done. A couple being the context sensitive hotkeys need to be tied to another window that exists during the whole duration you're are trying to block inputs. Or you could leave the current MySpalsh window existing for a longer period of time. Or you can tie them to the current MySplash window as you currently are but when MySplash is destroyed, create the hotkeys again but tie them in context to "Splash2" window existing, etc. You will have to experiment to see what method works best for you, I'm sure there are other ways to achieve the goal beyond what I just mentioned also. To clarify, I wasn't saying you need to remove that line, I was pointing out I think that it is the main culprit of why the do nothing hotkeys aren't working as you intended. Which you have confirmed this is the case. It's the culprit, how you go about fixing it will be up to you but now you know why it's doing what it's doing.

looks like you already tried what I would have suggested, using context hotkeys with something like #IfWinExist. I'm surprised that wouldn't get the job done. But I would use #IfWinNotExist and the context would be a WinTitle format of the game, you couldn't use ahk_exe gameoverlayui.exe since it creates no window! The hotkeys being linked to nothing would do nothing during the boot, and once the game window appears the context hotkey is now invalid and the joypad sends inputs as intended. Not seeing anything super obvious right away. Using this method works for me, so should for you too then...right? I used different keys since I don't have a dinput joypad but worked fine using keyboard keys. I tested with Notepad and the game Streets of Rage 4, having those context sensitive hotkeys only enable if those windows existed. That splashimage should work, but why doesn't it work already? Does "MySplash" close when "Splash2" opens? If so, I think that's your problem.... Looks closer.........BINGO....I think it does... here on line 53! Wouldn't this make those context sensitive hotkey invalid as soon as this line runs? SplashImage,1:off

Yes, create a "playlist" and add the games you want to see in that particular playlist. You can also create playlists that auto generate off a bunch of different parameters, one for ex is recently played

Scroll up to the top of this page and click on Premium and then Get Premium With Big Box to get yourself familiar with what the differences are. It's going to be subjective (this looks nicer than that), and objective (what do you want out of your frontend) reasons for making a decision to stay on LB or upgrade to BB. There are some more functions available in BB, and it has more customization for making a clean frontend experience that many enthusiasts prefer especially when putting their systems in an arcade cab

Edit Game > Startup/Pause > Override Default Startup Screen Settings Then click click Customize to adjust to your liking Startup themes are totally optional. No need for scripting because there is already a feature that lets you customize these settings down to as fined tuned as the per game level. In your case you could try turning up the delay time on the slider so the startup screen displays longer for the games that take more time to startup, or turn them off completely if that is all you're after.

there is a built in feature....have a look in the tools menu. With that said, setup a hotkey for it and you're all set. For ex below making the home key the hotkey. Making it go to other platforms when in a platform sounds tricky. If you wanted to select random games from the entire library I'd suggest you go into the category "All" and use the hotkey there Home:: Send {LCtrl down}{LAlt down}{q down}{q up}{LAlt up}{LCtrl up} *Edit* Apologies...I had LB open and tested this there and it works. But using that designated key combo doesn't seem to part of BB. So I went looking for a BB equivalent assuming there was one. Doesn't appear to be an exact 1:1 equivalent. BUT, there is under BB options > Keyboard Mappings you will find a setting called "Spin Wheel While Pressed" so you can assign that to any key you want, press it and does exactly what it says, spins the wheel. Kinda neat, it keeps momentum going briefly after release, much like it has a natural deceleration. So this could be used to randomly select anything in BB, categories, playlists, platforms, or games.

yes, sorry I didn't elaborate any further because kiinkyfoxx did such a thorough job 👍 I had nothing of value to add other than to say "mine works OK". But since you're still having trouble, I'll add what I can For yuzu, I see a small change I doubt is the cause but pointing it out. I do NOT have "Attempt to hide console window on startup/shutdown" in the Yuzu emulator details tab in LB. But again, this shouldn't matter because If I toggle these settings I cannot recreate your issue. Still on yuzu.....Seeing how I can get this to work with less settings, did you try turning this stuff off too? a 5 second slider time is what I use for the delay. When I enable these settings it seems it is hiding the window that shows the shaders compiling so puts a black screen up during that portion should the start screen already faded out. So again not so sure this is helpful, because I didn't totally recreate the issue. Even putting a silly long delay of 30 secs yuzu should be launching into exclusive fullscreen which will take over the display and steal focus. Therefore cutting off the startup screen prematurely from it's user setting.....just like the notes are described by the developers in LB. the "-f" parameter is what launches yuzu as fullscreen, but it doesn't designate exclusive or borderless, that is done in the emulator. When I entered 30 secs yuzu still displayed the game in ~10 secs which is on par with the time it takes my system to compile the shaders and launch the game normally, working exactly as intended as the devs describe in the LB notes. Are you using EXCLUSIVE fullscreen here in yuzu? borderless fullscreen can cause problems like this. I got stuck on a black screen after the startup screen faded out using it, and if I clicked the mouse, the shutdown screen appears and does it fade out and now the game window visible. Sooooo sorta sounds like the same problem you're having? I hope this is the culprit, it would totally explain the problem if this fixes it! Does seem like the smoking gun if you will I'm not finding a smoking gun for RPCS3 quite yet though. Doing our due diligence we should check the equivalent setting in RPCS3 here. It should be off....but I'll admit this didn't recreate the issue if I enabled it just now. My startup and shutdown screens worked the same prefect way with this on or off....but to be clear off is better, exclusive fullscreen is superior. I got the other screens too, some other settings are used, but I don't think they come into play with your issue (hiding the mouse settings for example shouldn't impact this). The fact you can "get control" back from hitting escape means the emulator is running in the background so you are exiting it as intended through your exit hot key (which you should change the same exact script you had in yuzu. don't close emulators via the process command since it is the equivalent of nuking them through task managers end task. so ONLY use that as an absolute last resort to close an emulator. RCPS3 works fine with the script you have in yuzu). Otherwise....sorry....I'm not finding anything else yet that sticks out that causes your issue with RPCS3. I think I've scrutinized every setting you and KiinkyFoxx shared. If I didn't share my specific settings, it's because they were the same as shared by kiinkyfoxx. I tried to only point out my differences. By the way, sorry to go off on the tangent as you're looking for help, but I really like the theme you are using here, your favorite as you described, but I didn't catch the name of the theme? Can you please tell me which theme this is? Nvm....I shoulda used the search function before asking, it was easy to find!

I'm not using the fullscreen parameter and I am using DX, looks like it was the default being the top most in the list. I'll try Vulkan since I got an AMD GPU, they seem to usually pair well together on emulators. I do have Render to Main window checked. Drum roll please......🥁 Sweet, it works! 🎉 Now my problem is I cannot recreate the issue lmao because I wanted to figure out what change fixed it. Render API change doesn't matter, works with DX and Vulkan. I did my silly setup to hide GUI flashes and not get stuck on a blackscreen, but this looks even smoother at start up, immaculate actually....as intended of course. No reasonable explanation from me on wtf I did wrong initially to make the normal fullscreen parameters not work. I could have sworn I tried all this stuff without success hence why I wouldn't have used these intended developer designed methods, but glad they are working now after your advice. Either way, thanks for the help again Overlord!

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