Jason Carr

Very nice, Kris. I've fixed some of the MAME issues we had built-in to LaunchBox, because I felt like we still needed an overly simple solution. So this is what I have: I think we'll probably stick with this approach going forward, though we may choose to further integrate it at some point. For the LaunchBox importer I basically fixed all the gaps in the MAME metadata and added some likely important filtering options. At least users won't get files that aren't recognized anymore with the built-in MAME import. I also took the MAME metadata and cross-referenced it to the LaunchBox Games Database, and added any missing games. There are some duplicates that will need to be cleaned up but there should be metadata now in the database for pretty much the whole set. Finally, I used the Progretto flyers images database to populate front images for as many games as possible, so things are looking a lot better in that department. Does anyone know where to get more of those flyers?

AWESOME! So glad to hear and glad there's a solution. :D

Hmm, okay. See if you can get into the "set up USB game controllers" control panel applet. Should be able to get to it just by searching in the Start menu (typing to search). My thought is that lots of people who use emulation have virtualized controllers enabled on their system. How many controllers do you see showing up in the list?

Hi @Mermsky, in the release notes for 5.9 I mention that multiple controller support for AutoHotkey was causing crashes in a bunch of people's systems because Microsoft screwed up the DirectInput drivers through Windows Update. The temporary solution until Microsoft fixes it is for AutoHotkey to support only the first controller attached to the system. Otherwise it was crashing constantly on many peoples' systems and was causing all kinds of problems. So I'm guessing that what's happening is that you're using a controller that isn't the only attached controller on your system?

No, LaunchBox works that way for everything already. If a folder is outside of the LaunchBox folder the path looks like this: ..\..\Games\MAME\example.zip ..\ means to go up to the parent directory. That's how Windows does it. The only time you have to resort to an absolute path is if the file is on a different drive than your LaunchBox folder is. In that case, LaunchBox just uses the absolute path.

By the way, @BombChel534, what were you using as a controller back when you were having the issue? Anything?

320kbps does not apply to WAV; that's only compressed formats like MP3s. WAVs are much bigger because they're uncompressed, which makes them more performant to play back in Big Box. Ideally the sounds would be 44,100 kHz 16-bit stereo or mono WAV files, which is the typical WAV standard. However, I do expect that some other formats would work.

One thing I'm noticing that would be really nice to fix (though it might not be easy) is that the paths to the ROM files are absolute, which breaks portability. For example, the paths come over like this: D:\Dropbox\LaunchBox\Games\MAME\example.zip Instead, if you can manage to make the path relative like this, portability would be maintained: Games\MAME\example.zip Basically, the path should be relative to the LaunchBox folder. LaunchBox automatically turns these paths into the proper absolute paths at runtime to send over to the emulator. That way, users that sync their collections with Dropbox can still have a functional setup even if the folder path is changed. Another thing that might be nice to fix (though it's much less important) is that all the paths come over as all lowercase. Certainly doesn't matter much in Windows but it bugs me a little. ;) Thank you @Antropus!

Thank you for those updates, @Antropus. I'll play with it more tonight. :)

Lol, you're such a joker Mr. Clive Barker. I just put out a new beta with updates for both the French and Spanish translations. Once we get the translations finalized I'll go ahead and put out an official 5.10 release.

Oh, also I noticed that some of the links are in the wrong spot in various dialogs due to the translations. Let me know if you guys notice that anywhere and I'll fix it before the next release. :)

Thank you @CliveBarker and @Wattoo, just put out a new beta with the updated language files. Can you guys translate these release notes? Once we're happy with the translations I'll go ahead and put out a new version. New optional VLC video playback engine 7-zip, RAR, and Zip archive support for ROMs XInput support for controllers My Collection syncing to the cloud Thanks!

No worries @DR9. If VLC is causing you errors you can always switch to the Windows Media Player video playback engine. Switch it out in the settings and see if that fixes it for you. :)

If any other developers want to hook into the LaunchBox Games Database let me know and I'll work with them to get a solution going.

I think he means something completely different guys. He's asking if he can hook Emulation Station up to the LaunchBox Games Database. I have this planned but unfortunately I haven't built the services for it yet. Then after I do, the various other frontends will need to implement something to support it, so unfortunately it's only LaunchBox for now but this is coming in the near future.

Hi @DR9, I'm wondering if it might be the video playback engine. Do you have any videos in your collection? Try going into the Options menu, then General, and changing the Video Playback Engine on the bottom.

I think I might have seen that early on in development of XInput. I ended up just calling it a fluke because it went away pretty quick and I couldn't make it happen again. I guess I better dive back into that; thanks for the report.

Ah, thanks guys. @CliveBarker, unfortunately the Spanish translation came in just after the 5.9 release. We can push out 5.10 after we get all the translations in. I'll have a new beta out later today. :)

Oh! I think I see what you mean now, @Antropus. In fact LaunchBox will pick up images either based on the game's title or on the ROM file name. So indeed, if you use the ROM file name they should show up without issue in LaunchBox, so the colon thing shouldn't be an issue at all. :) Excited to see that new interface!!!

Alright, maybe I'm confused here. I just ran a test: 1. Opened 1000 Miglia: Great 1000 Miles Rally for editing. 2. Added an image for the front box art by dragging it over. 3. Pressed OK to save the game. 4. The image shows up in the folder properly as 1000 Miglia_ Great 1000 Miles Rally.jpg. 5. Closed and restarted LaunchBox. 6. Image is shown properly. 7. I ran Refresh All Images from the Tools menu. 8. Image is still shown properly. So I'm not seeing any problems there. Am I misunderstanding the issue @Antropus?

Yeah, we've pretty well isolated file names from titles (I have a method that scrubs titles for acceptable file names). It sounds like I'm just I have a glitch I need to fix for the images. So going forward I don't think it will be an issue once I fix the bug.

Ah, thank you Clive, good catch. I just updated the language files to contain those three. Thanks!

Antropus said That was deliberated at some point. What happened is that I noticed that when you drag and drop a missing artwork into the game info window, it names the artwork after the description of the game, instead of the name of the rom. When that happens, if you have ":" in the name, windows simply cannot name the file using it, so ":" becomes "_" and when I re-open Launchbox, the artwork cannot be found for that reason. I think you could help with this one, renaming the artwork using the rom name instead. That would avoid this kind of problem :) Ah, I didn't know that was an issue! I'll look into it and get it fixed. Then hopefully we can go back to the colons. Thanks! :)

Antropus said I totally agree. It looks a little awkward. It's hard to trust the info provided by the support files though. For example, you will find games containing "Arika/Capcom" and some other games containing "Capcom/Arika". If we define a logic that Capcom is always the Publisher (which is probably true), than the other company mentioned, when found, will have to be the developer. That's a little tricky, because if the support files (including Mame's own xml file) ALWAYS considered the first to be the publisher and the second to be the developer, than things would be easy, but as in the example above, the support files have clear discrepancies and sometimes one might come first and other times it will come second. Quite annoying :) BUT for now, what we can be completely sure is that if no "/" is found, we should assume (I believe correctly) that Publisher and Developer are exactly the same. I can add this to the code pretty easily. Now, I can still split the two every time a "/" is found, but we will need to decide which one will be considered the developer and which one will be considered the publisher. Apparently, most of the time the Publisher comes first, but as I pointed out above, inconsistencies will happen, not because of some flaw in the way I'm capturing the variables, but simply because of inconsistencies in the official support files. Lets decide and I can add it! Another way would be to have a database of publishers only (as an additional support file), so I could compare to that and assume that anything not in the list is assumed to be a developer, but I doubt that would be consistent either :) Now for the Genres, this is much easier as it is pretty consistent. I can simply split that and consider the genre to be what's before the "/" and add the additional info after the "/" as an extra field, so people can still use it to filter stuff if they want to. Ah, sure; I think it would be a big improvement to split them all up, even if we can't get the developer and publisher necessarily into the right fields 100% of the time. The primary issue for me is that filtering gets ugly when they're all combined together.

Hi Magnus, no news on that; I'll update the ticket when I get to it. Just put out the 5.9 official. So we'll see what hits the fan and gets strewn across the room. ;)