Jason Carr

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. ;)

Drybonz said Hey Jason, the source field, on mine at least, is the source file for the rom... or the "family" that the rom is in... for instance the NeoGeo games are neogeo_noslot.cpp. This is the same info that shows in MAMEUI's source field. This would be useful for sorting... for instance if you wanted to look at the neogeo games... arrange by source. Ah, okay. Good to know; thanks @Drybonz. :)

Okay, thanks, keep me updated. It would be best to test with the 5.8 official first since it's been proven to work fine by the community for a while. The only thing I can think of other than what I mentioned above is some sort of weird driver conflict, but that would be odd considering the NTDLL error.

Hehehehe, I hear that. Pretty much all of LaunchBox comes purely from obsession. I do have some suggestions after playing around a bit more, @Antropus. It's all up for discussion of course: - I noticed that developers, publishers, and genres aren't split up (they come over as "Taito/Midway" for example). It would be awesome if the importer could separate these and put them in LaunchBox as separate since LaunchBox supports multiple items for these. - What is going into the Source field? It's a different use of that field than what it was intended for, though that might not be a bad thing if it's useful. I just don't know how it would be used. Either way, this isn't a big deal because it's simple to clear out. - Game titles often come over with a dash in them, such as "1943 - The Battle of Midway". It would be great if we could rename these games to proper titles with colons like this: "1943: The Battle of Midway". That should be as easy as doing a search and replace on " - " to ": ". That's all I've got for tonight, just after importing my personal collection. It's a great tool; thanks again. :)

I assume you've tried both 5.8 and the latest beta?