JoeViking245

As you know, with all emulators, the Default Command-line Parameters get completely overridden when there are any Custom Command-line Parameters present in the Associated Platforms section, for that platform. In case of RetroArch, in the Associated Platforms section LaunchBox adds the [would-be required] field Core. Which in turn, automatically adds to the command-line parameter -L "core_name_from_the_core_field.dll". Most likely (guessing here), since the Association Platforms section is adding [something] the command line, the Default Command-Lines Parameters are ignored (overridden). Which will be the case with any platform using RetroArch. So you are correct. Though the developers had the foresight to add the Core field and auto-populate them with the most likely core (along with adding -f to the Extra Command-line Parameters) for our convenience, they neglected to disable the Default Command-line Parameters field in the Details section. But who would have discovered this other than a 'power user'? Sounds like a reasonable BitBucket item. Though not a bug, not sure it's actually a feature request either. But a 'something' none-the-less.

A quick search found some icons and some as clear logos.

No, that does not matter. Just be sure to grab the correct one.

LaunchBox won't do it for you, but here're a couple options like RocketLauncher and Reshade that can add the bezels to emulators. There's an easy to do it as well using the plugin below. But do read through all the instructions and especially the part about SuperModel under Emulator Settings (if you decide to go this route).

No. As long as the path to the ROM is the/path/to/the/ROM.ext (either relative or absolute). But that 2nd prompt should still show. Even if it then shows a 3rd one saying 'file cannot be found'. I did find that you can't remove a game from LB via a Playlist View (w/auto populated playlists). Let alone, remove the ROM. But that's not related to your situation.

With the "Allow Deleting ROMs..." box checked, you should, after clicking Yes in the 1st prompt ("Are you sure you wish to permanently delete..."), get the 2nd prompt to delete the ROM: Just verified it is working (13.11). (Here, at least.) I doubt that part of the code has been changed with recent updates. But can't say for certain. Not to be repetitive but do make sure the box is checked and try again. If it's still not appearing, at the top of this page click Help & Support then Report a Bug. Assuming everything else in LaunchBox is working as it should, I'm not sure reinstalling LaunchBox [over your existing install] will resolve it. But is always a possibility. Especially if the issue started with a recent LB update on your system.

What platform are you attempting to do this on and what are the ROM file types? (.zip, .cue, .chd....) Are you getting the prompt after 'Delete game from LaunchBox...' asking (something like) 'Do you wish to delete the ROM file also?'? It should also state the warning that 'this is permanent and cannot be undone'.

Nice! I'd be inclined to do it all with the TransValue adjustment and remove the Sleep timer altogether. (one less thing in the mix) To reduce the code a little more and still get the same result TransValue := 255 ;Fade Out While (TransValue >= 0) { WinSet, Transparent, %TransValue%, ahk_exe notepad.exe TransValue := TransValue - .25 } ;Fade In While (TransValue <= 255) { WinSet, Transparent, %TransValue%, ahk_exe notepad.exe TransValue := TransValue + .75 }

Maybe setup a timer (or a For loop with a sleep timer?) and then WinSet the Transparent Level of your black screen. Adjusting from 255 to 0 (fade in) or 0 to 255 (fade out) If you have or can get the GUID of your black screen window... DllCall("AnimateWindow","UInt",GUI_ID,"Int",1700,"UInt","0xa0000") ; Fade in DllCall("AnimateWindow","UInt",GUI_ID,"Int",1700,"UInt","0x90000") ; Fade out 1700 is the fade duration (larger number longer). GUI_ID is, well... you guessed it. The GUID of the window you want to fade. Edit: per Microsoft docs, "AnimateWindow function (winuser.h)" Re: the "fade duration" (as I called it) is: So looks to be a value of 0 to 200.

The error indicates something is up with your license file. Email support@unbrokensoftware.com and they can sort it out for you.

It looks to me like EpicFail's method (which I did not use) has you create an Emulator in LaunchBox and then associate that emulator to your ScummVM platform. So now (after you had done all the other steps to set up per the EpicFail method), if you edit a game and go to the Launching - Emulation section, the checkbox for Use an emulator to play this game is checked. Which is not using the "built-in ScummVM feature". (Red box, image above) To edit the game, select it and then press Ctrl+E. Since you have the games already in LaunchBox and assuming the EpicFail method didn't alter or delete any of the innate LaunchBox ScummVM files (only added new files), to [directly] use the built-in ScummVM feature you should be able to: Edit the game In the Launching - Emulation section, un-check the box Use an emulator to play this game Now, in the Launching - ScummVM section, check the box Use ScummVM to play this game Click Browse and navigate to the folder [that contains the game files] and select it Under What game is it?, click the dropdown arrow (upside down triangle) and select the game from the list. Click OK to save. That's how I set mine up. One thing (among others) EpicFail does is, with using his emulator method he's made it so the games are truly portable (copies the ini file from AppData and uses command line parameters to start the game(s)). Which unfortunately you can't do [easily] with the built-in feature. Back to your original post... (now that I know little more of how yours is setup)... Not knowing how the EpicFail plugin was built, you might be able to hide the batrunner window. Edit the emulator you created and check the box Attempt to hide console window. If that doesn't work, edit the emulator and in the Startup Screen section, check the box Hide all Windows that are not in Exclusive Fullscreen Mode. Again, not having followed the EpicFail project, a quick search says something about an option was added to eliminate the need for batrunner altogether.

..\LaunchBox\Images\Nintendo Game Boy Advance\Clear Logo\name_of_the_game.png (LaunchBox) Tools - Download - Update Metadata and Media

Interesting. Because even with a fresh LaunchBox install, I still don't have batrunner.exe in my /ThirdParty/ScummVM/ folder. I even searched all of ../LaunchBox/. for the file and couldn't find it. So not really sure why/how yours is set up that way and has [or even uses] that file. Weird. What version of LaunchBox are you using? Maybe older versions used a different ScummVM setup.?. To set it up, all I did was edit he game(s) and in the Launching - ScummVM section (image above), check the one box, Browse to the folder and then selected the corresponding game. Here's what's in my /ThirdParty/ScummVM/ folder: There's also ../AppData/Roaming/ScummVM/ which looks like:

Pong is built into MAME so you will not find a physical file in any ROM set after [somewhere around] revision 0.245. (no relation to the numbers in my name) But to Launch Pong, you still need to tell MAME what it is you want to launch. Hence LaunchBox adds a "path to the ROM". Then of course, LB only sends the file name (without extension) from that path. "pong" Just like for clones that don't have a physical file in a merged-set, LaunchBox gets Pong (and 4 other TTL games ) ... well... All MAME games/ROM names from your physical "mame.exe" file. Using the command "mame.exe -listxml", a list of all the games for that revision of MAME is generated. From there, LB crosses with the file /LaunchBox/Metadata/Mame.xml to get other data. Both files are relatively large in size and can take a while to go through. Here's an excerpt for Pong from the info generated via -listxml <machine name="pong" sourcefile="atari/pong.cpp"> <description>Pong (Rev E) [TTL]</description> <year>1972</year> <manufacturer>Atari</manufacturer> ..and from /Metadata/Mame.xml <MameFile> <FileName>pong</FileName> <Name>Pong</Name> <Status>good</Status> <Developer /> <Publisher>Atari</Publisher> <Year>1972</Year> It's not in the .dat file because they're only [primarily] used for comparing/verifying physical files via their hashes (CRC/SHA1). And that's how ('why') LaunchBox adds it (them). That's what I use. Originally because it's way more versatile, but now... because that's what I originally used. (something about "old habits"?) I do keep it updated monthly and then add/remove games from LB accordingly after perusing whatsnew.

@Barny1100 Retro808 has been trying to suggest to you, that you remove -waitvsync from your command-line parameters.

The results will be better because when scanning for removed ROMs, it looks at the rom path for the game, then looks in the folder to verify if that file actually exists. With now having the non-merged set, there is a physical [.zip] file for each game entry (for both parent and clone games). So the comparison is pretty straight forward. It's quite possible the 5 that were removed are TTL games that don't have physical ROMs as they are built directly into MAME. PONG is one of those. With the merged set, all the clones for a particular game are embedded into the parents ROM .zip file. Your games path to a clone game will point to a "file" that is named for the clone, as MAME sees it. For example Donkey Kong Jr. The parent game will point to dkongjr.zip and the clone will point to dkongjrj.zip. In this case, the clone file doesn't physically exist, so when scanning, that game gets removed. Conversely when launching a clone game, LB sends the filename only (minus extension) to MAME. It's MAMEs innate logic that looks for the required files (found inside the zip file(s)) via an order of precedence. First looking for dkongjrj.zip, then dkongjr.zip. The 1st physical file it finds, it then looks inside the zip for the required files. And then looking in the 2nd file in the case of a split set. The beauty of the MAME Full Set Import Wizard is that it will import all games, parents and clones alike, regardless of the set type you have (aka, physical files). LaunchBox doesn't know if you have a merged, non-merged or split set. Even if it did, to scan for removed ROMS it would need to know which files are required to be in each sets ROM zip-file, respectively. Then instead of just looking for the physical file, it would need to go through MAMEs logic (above) plus generate a list of the required files (found inside the zip(s)) and scan the contents of the zips. Just to verify if the game is a clone, the set-type you have, if the parent exists and has the required files for that clone. We just increased the time to Scan for Removed ROMs by at least a 100-fold. Doesn't make good sense to me. It makes better sense to just remove the games from LaunchBox rather than removing the physical ROMs and then scan. Also, removing the physical ROMs in the case of a merged or split set can have drastic results. If I have a merged set and only play the Japan version of DK Jr., I can't delete the US version of the ROM and still be able to play the other.

(when you edit a game...) Are you using the built-in ScummVM feature (red box) to run your games? Or did you set up an Emulator (red arrow) to run them (regardless if you point the emulator to the exe in 'Third Party' or elsewhere)?

Is BatRunner.exe something you added to make your games run? I don't seem to have that file in my setup. If it's not needed for your setup, try removing it from that folder or simply rename it to something like "OLDBatRunner.exe", then try starting a game again.

I believe neither Mesen nor Nestopia directly (or even indirectly?) support MAME ROMs. Cudos on getting some to launch. Though the content of the ROM data is [for-the-most-part] the same, how the data is stored is different. MAME Software List ROMs are just that... ROMs generated for the MAME emulator. MAME doesn't require an NES BIOS. Not sure about the other 2 emulators.