Zombeaver

Well that was true prior to 2.8, and as far as I can tell 2.8 was only released very recently. There isn't a date on the download page and there's no blog post/changelog for 2.8 on the site and there's no mention of it in the development thread on the support.FS-UAE board. 2.6.2 was the latest stable up until like a week ago (maybe less) as far as I can tell. I'm not sure when UUID launch support was added but I think it was WHDLoad zip support that was the main thing that wasn't supported at the time.

I just tested and launching via UUID on 2.8 does not update the config_name field so no, using 2.8 doesn't fix the issue. The save state folder structure doesn't get updated when switching by UUID so your saves/save states get all mixed up/overwritten/lost when switching from game to game. @Eirulan I was testing out your launcher last night, by the way, and it worked perfectly!

Does it actually update the config_name field in the settings.ini though? They launched fine already with dev 2.7.15+ but that field didn't update when games were launched via UUID and that breaks saves/save states. I see 2.8 listed on the site but there's no changelog for anything passed 2.6.2.

Yeah I second moving away from WinKawaks. I used it many many years ago before there were myriad alternatives. Have you tried the FBA core of Retroarch? Beyond having better emulation accuracy, that gives you all the benefits that come with using Retroarch. I don't use ClrMamePro either.

Open your Launchbox -> Videos -> Playstation 2 folder and delete them. I have no idea why emumovies does this. Beyond the fact that it's likely to be outdated/false eventually, it just takes up hard drive space for no reason and doesn't help anything. I just open up the appropriate videos folder and then change the window view so I can see their thumbnails and then bulk delete any that have that exclamation icon in the thumbnail - they'll all look the same.

One other interesting thing I noticed is that it would seem that it's using the same BIOS as North America for the PAL games based on the documentation. I was looking for the file name that it wanted for the PAL BIOS but in their description for it mpr-17933.bin (the one that we're already using for North America) it says "Required for North America/US-region and Europe-region games". I guess this isn't so crazy given that PAL games already worked with Mednafen when region-patched to read as North America. http://mednafen.fobby.net/documentation/ss.html

Yeah I've actually checked it a couple times to see if they said anything Like I said, who knows when/if it'll ever actually be fixed on that end. It seems like a pretty glaring oversight honestly... My guess is launching via UUID is something that was implemented but is rarely used by the average user so it's not something that most people would probably even notice.

Hey, it doesn't have to be flashy so long as it does the job. I agree, I think this is really a fault in FS-UAE itself that Frode should address; but if you've overcome that shortcoming that's good enough for me (because who knows when/if it'll be fixed). Thanks for your hard work!

0.9.39.2 has been released. It adds in PAL support. http://forum.fobby.net/index.php?t=msg&th=1354&start=0&

Could be, yeah. If anything that's even more reason to get more people doing it though. The more people involved, the less workload each individual has. It is a time-consuming process, I won't lie. I spent a couple hours yesterday submitting and moderating and I got through less than I would have hoped for during that time.

Huh? I'm not sure what you mean. There's definitely some stuff that could use some adjustment but I'm not sure why that would have any impact on the need for moderators. Stuff usually takes a day or two to get fully accepted through the moderation queue currently. I moderate for the DB as well.

Awesome! Thanks @Eirulan, I'm looking forward to giving this a go tonight!

I had the same thought...initially. When you really consider the ramifications of that, however, you'll see that it would be a moderation nightmare. The first step in adding games to the DB is to verify that it's not currently there already, then you add in the release date, publisher/developer, description, etc. along with any images you have (preferably with the correct region for them) at which point your submission goes into a moderation queue and moderators approve or deny them. If literally anyone with LB could just click a button and suddenly their library entry was uploaded for moderation, with no examination/consideration of any other current or pending DB entries, it would be a complete disaster. We could really use more moderators as it is, let alone with 100 times the workload. You're eligible to moderate once a certain number of submissions are accepted. I think it's 50, which sounds like a lot but it's really not - completely filling out a new library entry with all fields and including front and back covers is something like 15 changes.

The "grumpy muscle" haha. I like it - sounds like a super villain. "What will our heroes do on the next exciting episode of Launchbox when they face their greatest opponent yet... THE GRUMPY MUSCLE. Stay tuned!" In all seriousness though, my comments aren't intended to be jerkish, you just have to understand that people from our community - people just like you - took the time and made the effort to make the contributions that you were downing. I don't respond well to that kind of thing Understood. No harm done. And like I said, I don't disagree that there's room for improvement - but that just comes from everyone here, not a mysterious team of gerbils behind the curtains. Your contributions will be greatly appreciated by everyone here! I've been making an effort to work on C64 and Atari ST myself as there's still quite a bit of stuff missing. C64 is kindof an impossible task since there's more than 10,000 games for that platform... but it's a righteous struggle!

The problem is the way that you're conveying that. You're coming on here saying "You really need...". You mean we really need? Because the DB relies on you just as much as it does some mysterious other entity in order to be brought up to par. We (theoretically) pulled the entirety of the GamesDB as a starting point for the Launchbox Games DB; how successful/complete that was during transition, I don't know - but that's where it came from in the beginning. From there, we rely on contribution and moderation by members here. It's all well and good to say that our images "look like dirt" but it doesn't really contribute anything to the cause of improving it. Don't get all defensive after coming on here and trashing the efforts of many other members and contributing nothing yourself. As far as hooking into the Gamefaqs API, I know that it's been suggested; more than once in fact. It hasn't happened as of yet and I'm not exactly expecting it to. Jason could possibly provide more specifics on why but presumably there's some complication there that we're not privy to. In any case, the current situation is such that, if you want to improve the DB, you need to make some submissions - if you can do that, it would be appreciated because everyone reaps the benefits.

Yes, I think it was stated some time ago that until there's a dedicated spot for the hacks that they should be rejected. It seems to me like there should either be a way to incorporate them into the existing game entries from which they're hacked or have an entire platform just for romhacks; either way I don't think romhacks should be submitted as their own DB entries in existing platforms - those should be for official releases only.

Huh? I'm not sure what the significance of this would be. Yeah I guess I could see that. Honestly, this is a bad way to go. There is no one-size-fits-all solution to .conf files - DOS covers a good 20 years of games so there's no way to just throw a configuration in and it'll work for all (or even the majority) of them. The default is designed to be a starting point not a catch-all. I highly highly encourage people to create individual .confs for every game. In some cases you might be able to just leave it with some default settings but in many cases you won't - not if you want them to run the way they should anyway; and honestly starting that process earlier rather than later will make it less painful in the long run. There will be cases where you can just create one and leave it with the default settings and it'll work okay, so you won't necessarily have to tweak anything for every single one but creating them allows you to A) tweak things for that game if necessary and B) keep yourself from accidentally breaking something you imported and tested previously but you've changed your default settings since then. If D-Fend has it's own built-in confs for stuff and you can make use of them, great (I haven't used D-Fend in years); though I'm fairly dubious about relying on such things. Hell, I don't even use GOG's .confs most of the time - sometimes they'll be using weird video or audio settings that really aren't ideal. Sometimes settings that might work well on one PC might not necessarily work well on another too. I'm just too OCD to leave things alone and hope for the best

Feel free to submit superior images to our DB if you have them. That's kinda the whole point. Where do you think they came from on the alternatives you mentioned - they just materialized out of the magical ether of the interwebs? No, somebody took the time to add them. The reason we moved away from external DBs for this stuff in the first place is because they were either unreliable as hell (GamesDB) or they constantly changed their site to make it almost impossible to hook into them on a consistent basis (Mobygames). Could the DB use some work? Heck yeah. But talking about it needing work rather than contributing to that end gets exactly nowhere.

No problem! Happy to help Wait what? Is this because you're using "start.bat" instead of Catacombs.exe? You have a number of different options outside of using start.bat. You could 1) probably just rename Catacombs.exe to CatacombsII.exe and it'd probably be fine (though success with this will vary depending on any other files having a dependency on that specific name, like in .ini files) 2) open up the start.bat in notepad and remove the part that contains the instructions 3) remove the game from the application path in LB and then just add it into the autoexec section of the dosbox.conf. For this you would just go to the DOSBox tab, and where it says to browse to/use a custom .conf file, press "create" then scroll down to the bottom until you see the section for [autoexec] and then add in the following: The autoexec section is only used if your application path in your LB library entry is blank.

How are the game files themselves (what you have listed in the application/rom path) named? The reason I ask is that it LB looks for a number of different possibilities for the purposes of matching media - the standard is by your library title (this is how it will name any media that you download via the LB DB or Emumovies) but it will also match based on the application/rom name. I remember having this particular issue when I was adding in media for two games - Blood and Captain Blood. Obviously the library titles are different for these, but it just so happened that they both launch via a file named BLOOD.BAT (or .exe, I can't remember) and as result it was cross-associating the media. I believe what I ended up doing was just renaming one of them. You may want to take a look at the below post where I provide some more detailed information on what LB looks for to auto-associate media.

Yeah, it definitely needs some love. Jason is aware of it. It's on the to-do list. Importing them is still possible, but it is a bit time consuming. I've got some instructions on the process here if you need them. Welcome to the forums!

Yep, not only are they separately configurable, but in my experience updating LB can sometimes turn Controller Automation off in one or both places post-update. I'm not sure why

I forget, is FBA different from most cores in that it wants the bios in the same folder as the roms? Most cores want bios files in the "system" folder. Based on this post over at Libretro it sounds like you've got it correct though (assuming it hasn't changed since then - that was from over a year ago). You could always copy it into your system folder just to be safe (and to test), it won't hurt anything.

What I would do is duplicate your Gambatte_Libretro.dll (or whatever it's called) and rename the duplicate to "Gamebatte_Libretro_Color.dll" (or whatever you want) and then update your Retroarch emulator entry in LB to direct your Game Boy Color platform to that .dll instead of the normal one - now the two can have their shaders set separately. Load up a Game Boy game and set your shader. Load up a Game Boy Color game and set your shader. Done. Normally I would just create an entirely separate "emulator" entry in LB for the purposes of dividing out certain options that I want to be able to quickly switch between (as mentioned in the post below) but so long as you have Game Boy and Game Boy Color divided into separate platforms, you wouldn't even need to do that - that method is what I use when I want to divide out the same platform for a number of different options.

You're missing the point of this - it's not just to create folders for importing - it's to hook into FS-UAE's built-in configs for a very large number of games so that individual configuration isn't necessary. It takes the UUID associated with each one from the Open Amiga Game Database and dumps it to a blank file named after the UUID, and when launched via LB with "no quotes" and "no file extension" checked it launches not only the appropriate game, but the appropriate pre-made config to go with it. This benefits not only ADF versions but WHDLoad as well, because while WHDLoad games will technically launch by simply directing a zip to FS-UAE, without the corresponding config they normally won't run ideally. The PRELOAD WHDLoad argument needs to be added on nearly every WHDLoad game in order to keep the screen from flickering like crazy when it's loading data, some games need the BUTTONWAIT argument to keep the game from blasting through images faster than it should because WHDLoad games load significantly faster than ADF, and some games have custom viewport settings that are necessary for the screen to be the appropriate size; simply throwing a WHDLoad zip at FS-UAE won't do this. With this tool, you're hooking into all the premade configs so that you don't have to do any of this by hand. Granted, there are some games that aren't in the OAGD (typically some of the more obscure stuff that you may or may not care about) so those will still need to be configured manually, but a significant number of games are already covered.