skizzosjt

prove to yourself you are using the proper commands by launching a game with the emulator directly from the command prompt. this will take LaunchBox out of the equation. if it's not launching a game from the command prompt it suggests you are not using proper commands correctly. if it does in fact launch a game OK directly from the command prompt, then it makes sense to look closer at LaunchBox settings.

marcosgaming is already using the correct AIMTRAK software that is meant for their specific light gun. they are different branding, but otherwise they both do the exact same thing. assign player #s, assign buttons, calibration, etc. I don't see a benefit of downloading another brands software, if it's even compatible. I wouldn't mess with it because I would believe firmware is not the same and if wrong firmware gets updated you may break them from ever working again. marcosgaming, in general the scope of questions you ask here and in PM is already shared in deep detail. I'll try to clarify some of your questions, but, otherwise, it sounds like you should return to existing guides to better understand the setup processes. this is totally up to you. there is no right or wrong way. you need to understand the layers you are going through though. if you set the gun's trigger to be button1 then MAME needs to have the trigger/shoot input be the corresponding button. if it were set to a mouse button in MAME, then that wouldn't work because there is a disconnect in that example. you pull the trigger, it sends "button1" but MAME expects "left mouse click", nothing will happen in that example. you just need to make said settings consistent between the light gun software and the game/emulator. on the same note, if the player 1 controls in a game are expecting inputs from "Gun 1", then that needs to be aligned between the light gun software and the game or emulator. for ex, if you have your light gun as player 5 in the light gun software, but player 1 in MAME expects inputs from player 1 (for ex "GUN 1") then that is a disconnect. nothing will happen. so hopefully you understand it is critical that things are aligned between these different programs. to fix that specific example, you either change light gun software to have the light gun be player 1, or in MAME make player 1 receive inputs from "GUN 5" the light gun is a mouse and controller. aiming the light gun is just like moving a mouse around. the trigger/buttons on the light gun can be mouse clicks, or controller buttons. meaning, any game or emulator that can receive these mouse and/or controller inputs will work with the light guns. you see "JOY" button in MAME because you assigned a controller button to that specific light gun button in the light gun software. given the info you shared, that seems normal. the other buttons may be mouse clicks and I think depending on how you do the device remap, should show up as "GUN". again, seems normal.

completely optional. you can choose to not opt into it. I always have it disabled. nothing sneaky about that. they ask you at setup of the emulator

well there was that fiasco with Dolphin not being released onto Steam. with some arguments stating the, I think it's considered decryption keys (don't quote me on this) were included in the emulator for Wii games. The article calls it "Wii common key" So they (Nintendo) are again citing the same offense. Anti-circumvention.....yet at same time allege they (Yuzu) didn't steal any keys. The anti-circumvention argument has some merit with Dolphin, which I personally think they (Nintendo) would loose in court. So this Yuzu ordeal sounds like it has even less merit on the anti-circumvention complaint. I think this has more to do with this conspiring....Aren't they gearing up for a Switch 2 release? If users can keep gaming through illegal means, less incentive to buy the newest console. Also some high profile games got leaked recently like Super Mario RPG was on the web several days, if not weeks before release. That kind of stuff they see as cutting into their bottom line. Nintendo is a business and like any business, they don't sell video games, or consoles, or services. They are in the business of making money. If they don't make money, no business exists. They could have went after Yuzu or the other Switch emulator Ryujinx years ago. Why now? Well, that's why I think now. But lets be real, that problem starts from within. Unless they got hacked, they have people working for them that are willing to sneak copyrighted and NDA software out of their facilities and studios and put it on the web for millions to obtain. Worry about that, Nintendo! Frankly Nintendo's argument could go after programs like LaunchBox / Big Box. They argue the software promotes and facilitates piracy. I've read the threads about Pay Pal regarding LaunchBox / Big Box not being able to do business due to the same exact view point. So, be careful for what you wish for if you're thinking Nintendo is in the right here. It will set the precedent to argue that software like frontends that promote and facilitate the use of illegal emulation, hence piracy, are just as bad and should be subject to lawsuits too. Frankly, dumber laws have been passed. If you want to keep being a fan of emulation, and in part, frontends, do not side or sympathize with Nintendo here. Period. I would take offense to that. Where the hell does Yuzu actually link to the product keys?! or even the websites that host said links?! That seems like a flat out lie rather than a skewed opinion.

I see the issue. It copies the default config Retroarch.cfg as soon as you go into "Process Retroarch" within the app. It takes Retroarch.cfg and turns it into "Retroarch.cfg.bkup" and then populates a brand new version of Retroarch.cfg. So, it does change overlays settings, turning them off, seems counter productive given what the app is. All I have to do is click "Process Retroarch" within the app and it changes my default config file. I don't even need to actually proceed with downloading and installing the bezels. Some of my custom settings stick, but others, notably input_overlay_enable = "true" is not even found in the newly created Retroarch.cfg. So, this certainly explains the behavior. I did test it just now, making sure 100% that this setting was enabled and present in the default config. I then go into Process Retroarch and it creates the backup file. I then check the contents of the backup file which still has input_overlay_enable = "true" in it. I then check the new default config and it no longer does. (makes some sense....so far at least) Then once the download finishes, another copy happens and I'm now I'm left with the default config and backup config being identical files (same exact contents and file size), except they are both the newly created config file version. as in no input_overlay_enable = "true" is present in either of them. Now we are at the part where it doesn't make sense, to me at least. Surely this is not what any user would want. Your app is changing my settings, in fact, flat out removing the overlay setting from the config rather than just changing its value. My experience with your app seems to contradict your comment. My overlay setting within the default config did not stay saved through processing. Either way, I really appreciate you taking a moment to respond. Thanks for the explanation! With that sad, consider it an area for improvement should you ever release a revision. The overlay setting should be getting enabled via your app rather than disabled. If I a missing something obvious and shooting myself in the foot here, like, creating this issue myself then please let me know where I am going wrong and I'll promptly insert my foot into my mouth lol

Windows App. That is at least what I can confirm is seeing this auto turn off overlays behavior. There have been a handful of users on here recently seeing similar behavior. Some were doing it through LaunchBox. I cannot personally confirm it's doing the same thing with that method, but given the circumstances I would hazard a guess both methods are seeing the same behavior.

potentially a flaw of the bezel project. every time you run it to install a new set of bezels it turns OFF overlays which seems the opposite of what you would expect. I just went through a resetup of Retroarch for several platforms and every time I had to turn overlays back on. ie install bezels for platform A, turn on overlays. install bezels for platform B.....overlays are off again.....turn overlays on manually. install bezels for platform C.....overlays are off again......turn overlays on manually, and so on. @dragon57 is this intended behavior? maybe Retroarch changed something over the years that impacted this? my assumption would be you would want overlays to turn on automatically. also, making assumptions you're the author for the bezel project, so forgive me if I am confused here. I know the OP indicates like they did this through LB running the bezel project, but I see same behavior when running it stand alone downloaded from the github. Referring to this one specifically for Windows https://github.com/thebezelproject/BezelProject-Windows/releases

there may be some better way to get to your goal, but I think a way to accomplish your goal to have multiple sources attached to a single game would be to create a custom field. maybe call it something like "Secondary Source". So if your entry for DOOM 3 has its source as Steam, its Secondary Source would be GOG. or just flip flop them around if it's the other way. then whether you search for Steam or GOG, the game entry for DOOM 3 should pop up in the results. the badge reordering thing sound like you would need to customize the theme to your liking.

not sure what to make of the errors, but in my experience, those symptoms (highlight a game and then get an error and crash) have meant a corrupted media file exists for that game. if that is the case you simply need to delete that file, or files, that are messed up. with LB closed, try renaming the \LaunchBox\Images folder to "Images1" for example. LB will no longer load any images. you can change the name back after this troubleshooting step. if you can then highlight the game without error/crashing, that would indicate that is the issue and you need to hunt down the offending file(s)

Make use of the startup applications feature You can select the file so it only launches if Big Box launches. This way it will not launch if LaunchBox is opened instead. But the catch is the file needs to be an AHK script that will do these basic steps due to the action must take place when Big Box closes: -Wait for Big Box to exist -Wait for Big Box to exit -Run the video file Just an example - better to run it through VLC rather than opening the video file as it will not close automatically that way without some further scripting tricks. Running through VLC you can use vlc://quit param which will close the video player at end of the video playing. and fullscreen param obviously does just that. WinWait, ahk_exe BigBox.exe WinWaitClose, ahk_exe BigBox.exe Run, \Path\To\VLC\VLC.exe "\path\to\video\file.ext" --fullscreen vlc://quit

LaunchBox and Big Box have separate settings for controller mapping. So, you should check your Big Box controller mappings. In Big Box it is instead called "Close active window"

did some more testing this week. I'm setup with Retroarch 1.16.0 as my main instance from a recent upgrade. I test with both LaunchBox and Big Box now with the newer Retroarch version. And though there are still issues with the startup screens as I previously describe, it didn't require the ALT+TAB input when a game is launched from Big Box. But it has constantly needed that type of input/user interaction if games are launched from LaunchBox and is so far repeatable with any core or game. So there is a noticeably different behavior between launching games via LaunchBox, or Big Box when using Steam Launcher, at least regarding using Retroarch. For Retroarch, I tested with systems such as NES, SNES, N64, Genesis, Master System. Cores would be nestopia, snes9x, both N64 cores paraLLEI and MupenPlus-Next, genesis plus gx So to summarize all testing so far, here is what I observe LaunchBox: Startup and Shutdown screens are both funny, they lose focus so you see the desktop/LaunchBox. Startup screens start OK, but lose focus prior to the emulator/game loading. Shutdown screens are delayed in starting, so you see the desktop/LaunchBox and then after X secs the Shutdown screen shows up. Retroarch loses focus at game startup so requires some user input to get it in actually focus. The emulator/game is visible and on top of all other windows from what I can tell, but just not in focus. As in, if I have the option to pause emulation if Retroarch is not in focus enabled, the emulator is in a pause state and you see the pause sign on the on screen display in top right corner. Big Box: Startup screens are funny in the same way as described for LaunchBox. However, Shutdown Screens, at least with Retroarch, behave as expected. I did not notice it to flash back to the frontend for X seconds before the Shutdown screen appears. Also unlike LaunchBox, Retroarch did not lose focus at game startup so no additional user input required prior to actually playing the game. Let me know if there are any additional specific things I can check to help pass along more info.

Yes, Retroarch was the emulator that lost focus at startup and needing to ALT+TAB as a result. I'm not sure of exact timeline of my testing I previously detailed because I did recently update Retroarch to newest stable release at time when I downloaded it, which I know is 1.16. nightly/dev version was at 1.17 but I went with stable release - I see 1.17 is now the stable release I will do some more testing because unfortunately for me, my memory is a little hazy on if I tested anything since this Retroarch upgrade. To be thorough on my end, I'll need to test some more on my up to date version of Retroarch. I can come back with some more feedback after I get that completed. I know when I made my first post I was def not on a recent version so I'll do my due diligence here for sure by testing with the recent release version.

no apology required. I figure so much that it's a lot of programs more or less trying to play a digital version of king of the hill to see who is in focus lol. thanks for taking the time to get back and offer more help.

this would, I think, deserve their attention. updating metadata is a standard feature even for the free version. so, it really should work regardless of how old of a version you are on. if what these posts suggest is you cannot update metadata, meaning your local metadata file will never be updated with revisions or new additions, then you're losing a function that was intended to work forever. scraping will be not fully working. if you have not already you should fill out a bug report. use the help and support > report a bug button at top of this page they did just recently revise the database, based on that coincidence, there is a possibility the recent changes have had a negative impact on older versions of LaunchBox. metadata comes from the database. with all that said, it's plausible this is a legit bug that needs to be addressed.

my initial suggestion was correct, you have more than one installation. the initial post shows your Retroarch as version 1.9.0 and this one is version 1.9.7. both of those are several years old - as old as 2020. you should consider if you want to iron out the confusion you made of multiple installations or if you should get rid of these old versions and install the newest version of Retroarch. the install instance that you linked with LaunchBox shows cores downloaded already....I wanted the same menu as you had in first post which is the Core download menu. but never the less, that all lines up as expected. cores in THIS instance of Retroarch align with your LaunchBox Associated Platform window. No surprises there. you can download the cores you need, but you still need to fix up you confusion between having multiple installs edit: If you need to figure out where that one is installed look at the application path in the Edit Emulator window.

Need to correct my previous comment here. I had to use this feature tonight, and it did not work as I remembered, I got this wrong. LaunchBox only gives you one of two options here. Either update no games to the new default emulator, or update ALL games to the new default emulator, meaning, even customized game entries using non-default emulators. This is a crummy experience, as I now have a boat load of customized stuff to resetup....boo...hiss. (naw, In reality I'll just use a backup file ) This means the only way to change only games using the default emulator to newer default emulator while also leaving custom game entries alone that are using a non-default emulator is to bulk edit. But this would rely on the user to know exactly which games to edit. If you have a lot of stuff customized, this makes such an approach not feasible, because no one is going to remember all of them. The only other idea I have off the top of my head to help with that is using custom fields. Which means you also need to remember to update those when you change them. You could make a custom field called "Emulator" or "Assigned Emulator" , or something like that. And then sort by that to see what you got and edit away accordingly. I'm starting to see why so many users have asked for being able to search and/or sort by emulator. That addition would take care of this situation as well!

tried a new experiment tonight with another test instance of Retroarch, but making it my default emulator for SNES. if you have no core assigned and no parameters in the extra command-line parameters field, or the game specific custom command-line parameters field, you can in fact include the core parameter, or any parameter at that, on the default command line parameters field. games launched and other features worked as expected like Startup and Shutdown screens. so, not a very practical way to do this, you would need to have a separate instance for every core since you can only declare one core in the default field. I kinda ran out of time when I testing the other day, I def should have tried this then as I was suspicious about right clicking onto just the emulator name rather than the core name was part of behavior I saw. that's on me for not being more thorough, but there's only so much time in a day lol. so I have good understanding now of how all this works and what I come out of it is I just want better communication to users about why the field acts like it's disabled for any normal situation of use. typical users will likely find it confusing or frustrating. though I realized this whole situation within like 5 mins of first using the program, i just kinda left it as a "it is what it is" situation without understanding why I had to use the extra command-line parameter field or couldn't make use of the default command-line parameter field. I wonder if other users did the same thing as me. at least now I know why and that just makes me more confident in using this program to it's full potential for my evolving use cases

go to a game that is using Retroarch right click on it and use the option to open Retroarch ("Open Retroarch...") now with this instance of Retroarch open, go to your core list post same pics from there. need to see EXACT same cores between what is being shown in Retroarch core menu and your Associated Platforms tab. ie if you have core A, B, and C in the Associated Platform tab, then we need to see what Retroarch says about core A, B, and C. make sure to have the Associated Platform image include the column about whether or not the core is missing

do you have more than one Retroarch installation? your Retroarch image shows for example you have downloaded nestopia_libreto but shows LB doesn't see it. also, your Retroarch image shows you did not download the Gamecube (Dolphin) core, yet LB shows it as installed (note there is no missing core file text in the field). makes me think you have multiple instances of Retroarch on your system. you should make sure everything is being directed to the proper instance and said instance has all the right cores installed and settings setup.

@DaveC1964 this is normal behavior. it will ask that for every system that has any entry (including additional versions), assigned to something different than the default emulator. this gives users the ability to change the default emulator for all entries that have the default emulator assigned, while still leaving further customized entries untouched. or if desired, change literally everything, even the customized stuff, to the default. for ex, I have several Mesen HD packs for NES games. Yet I use Retroarch nestopia core by default. if I go in and edit the Retroarch emulator, you don't even have to change anything, just click OK rather than the X or Cancel, it's going to ask those same questions but for Nintendo Entertainment System instead. This is because those games have Mesen as the default emulator rather than Retroarch. I have custom stuff for a handful of platforms, so I see this any and every time I edit Retroarch, even if you don't edit one of those customized platforms. LB auto populates a lot of fields when you type in "Retroarch" into the emulator name field (might not even have to type it in, just going into and out of that field once it's filled in may still do this auto populate thing IIRC). One of them would be listing out all of the various platforms in Associated Platforms and by default, selecting them as the default emulator. This process would explain why Dolphin was added as an Associated Platform, as well as why it gets default emulator checked. Seems you missed unchecking it at some point as you obviously removed the default check mark for many other platforms.

I was doing it through a supplemental emulator in my list used for testing so I needed to go through the right click context menu and click on the specific core to launch. In this case when I remove the core, that core will no longer show up in the right click context menu. So, I have a suspicion now with your feedback if I did that with the main (default) emulator it would behave as you mention here. I think since I'm not able to click on a core through the right click menu, I try and instead click on "Retroarch TEST" as I named the emulator, nothing happens because I'm not really clicking on a selection that triggers a game launch. Probably makes sense it works like that. No Startup Screens pop up because I'm not engaging with LB properly to start the launch processes. I bet if made it the default emulator rather than an auxiliary one, as in I can use the normal Play button to start the game, Startup Screens should still pop up even though we know the game will fail to properly launch.

Thanks both of you! Nah actually I was thinking pretty similar to this user who made a rather similar report. But thanks to all this testing and both of your feedback, now I understand how it all works! https://bitbucket.org/jasondavidcarr/launchbox/issues/5519/112-mame-default-command-lines-on-details The difference there with MAME is it seems you can remove everything from the entry in the Associated Platforms line and it will then allow the default command-line parameter field to work per the expected order of precedence. With this new info in mind I think this is intended behavior, but, maybe can call it an oversight on not disabling the default field that is always ignored. Retroarch seems to require the core to be selected in the Associated Platforms (if it's not defined at the game level custom command-line parameter field that is) which therefore means there will always be an entry there and further means the Default Command-Line Parameter field is always ignored. If you try to remove the core association in Associated Platforms Retroarch will not even launch. I have startup screens on and those don't even start, gives the impression LB doesn't try to launch the game in that situation. I filled out a "trivial bug" report in hopes it can be improved upon. https://bitbucket.org/jasondavidcarr/launchbox/issues/8568/retroarch-default-command-line-parameter

Hey @sundogak, thanks for chiming in here! Can you give an example of what would work in the default command line parameter field for Retroarch? If there ever was a candidate for a default, the fullscreen parameter would be just that. it is redundant to have to put it in every core's specific field in my opinion. I tried a bunch of variations of this. Parameter sequences do not matter. For ex, this works via command prompt - but doesn't if transposed into LB default command line parameter field retroarch --appendconfig "retroarch_Mega_Bezel.cfg" --set-shader "MAME_Mega_Bezel.slangp" -f "D:\ROMS\MAME .261 Non-Merged\MAME 0.261 ROMs (non-merged)\1941.zip" -L "mame_libretro.dll" The -f parameter also doesn't work in the default command line parameter field. (I'm sure why the devs designed to auto fill it in the extra field instead) Fullscreen is certainly not core specific, yet, this parameter, along with literally anything else, doesn't work in the default field. I think I'm just ranting a bit here, because if I am correct with my suspicions, LB has a field we can enter stuff into that seems to do literally nothing to impact things one way or the other. That can be confusing to users. This is why I ask for an example of how to use this field. If I am not "getting it", I need to understand how the field was meant to be utilized. If it does in fact do nothing for Retroarch, it should be able to detect when Retroarch is the emulator and grey out the default field and users should not be allowed to enter things here to prevent confusion. Or if that is not feasible, a note beneath the field saying "This field is ignored for Retroarch - instead use Extra Command-Line Parameter field in Associated Platforms".