pogowolf

and I'll be on it as soon as I gain access to my media system again.

Ok.. let's see if I can't write convey the 'issue' I'm trying to solve. Not trying to be a donkey here, nor ruffle any feathers. I'm writing things because it helps me think. Issue: Keeping the meta data downloaded from 'somewhere' (in this case TheGamesDB.net) associated with the game itself. #1 - They way it's done currently is that all the meta data is downloaded and saved in one XML file. (mine is currently 78 meg) which is parsed on the fly for information, possibly partial saved on update, and re-read into LB after each edit. Pros: 1) Keeps the system 'clean' and it easy to access data 2) Keeps the data in once place, making the whole of LB more portable. Con: This process slows as the size of the XML file grows. Which effects the loading of LB to taking 30+ seconds per edit of a game and at 78 meg.. it's on longer portable anyway. Thoughts: Is portability really needed? yes, the INSTALL is.. but once you adding a few games, the idea of throwing everything to a USB drive and taking it to a friends becomes harder and somewhat impossible. so the question is: What is the why/reason for the need for the portability of the data? #2 - Use a seperate XML file to hold all the meta data Pros: 1) Would be easy(ish) to implement.. perhaps by GamesDb ID (so 8428.xml) which is Postal 3 2) Easy to update specific games (or re-update from the Gamesdb.net) 3) Possible to embed images into the games XML file. 4) Could be used for ISOs, DosBox Games, etc. Cons: 1) easy to de-associate game data from game image. Some sort of clean up system would be needed to sync the XML/image files no longer needed. 2) possible slow down on load due to loading multiple files at once (though, this could be threaded) 3) Makes Search and Filters much harder to implement and would slow the system down having 32k of files to search though in order to produce a search/filter list of games #3 - Embed the meta data of the game WITH with Game itself. Pretty much the same Pros and Cons as above.. except that the association of the meta data and game won't be lost and it would be easier to share this format than to share an image and force the user to download the meta data again. #4 - Hybrid of #2 I think this may be the best way to handle this issue. the PRIMARY meta data (Name, Release Date, Genre, Publisher, rating, etc) would be read from flat XML file as the game is being imported (and the XML file being created).. THis way all searchs and filters are fired agaist the database. If a user wants the additional information about the game.. then the XML file is read into the form. PROS: #1 - Fast access to any of the games, fast search, and filters. #2 - Opens the ability to create a virtual data grid so that a 78+ meg XML file isn't trying to be loaded all at once. #3 - Splits the data needed to RUN a game VS neat 'extras' that some users may not even care about. CONS: #1 - pretty much a total re-write of how the import system works, how the games are displayed, and how the import process works. #2 - Still pretty easy to de-associate the meta data from the game image. So the a tool would still be needed to clean up the XML files.. but now also the database as well. Also a tool to 'compress' the database would be a good idea to keep the database file size down. however if the import is split off.. you can speed up the import process by only downloading the primary meta data and download the 'extra' data later.. in the background.

Vinicius256 said Hey Jason, I made a mock-up based on the OpenEmu style with the ''Charms bar'' idea from bd with a kinda ''Modern'' look, tell me what you guys think: personally I like the first one better than anything.. however, even having the list of consoles.. you could have 30+ consoles.. listing like this (for large collections) I don't believe will work in the long run. my thoughts would be to have a fly out (kinda like the current filters) but filter the list of games by genre and/or keyword.. from my experance people don't tend to think "I'm going to play a PS2 game".. then think.. "I want a racing game".. or "I'm going to play mario" .. *shrug* but then I like to look though my list sometimes.. But that's why I like the current LB interface. it'll list everything.

SentaiBrad said Jason Carr said Ah, sure, that would make sense. Though I think I'd rather use a metadata file per previous discussion. Bd, you'll notice that the new export process does automatically arrange all the games for the zip file, so I'm not really far off from an option to "consolidate game files". At this point I didn't add the metadata files, but that wouldn't be too hard. Just didn't yet see that compelling of a reason to do it at this point. Could also move the images into the game folder, which would make it an isolated set. Think that's worth doing? I personally think there is such a thing as over organizing. I'm not saying dump it all in a folder and go, but should it be complicated? I think an images folder and an XML file are fine enough. If you wanted to maybe split it all up by system? Though, I don't keep any of my games in the games folder, I just use LB as is in a folder and its points to everywhere else, so honestly I don't care how the data is stored. I just want to make sure there is no chance of it breaking, which the way it is now is hard to break unless you start deleting files. it's easy to break. Just move the files. best case for something like that would be one XML per game. though really, the XML could be used just for additional information.. the standard meta data shold be in a database. and Using external images, xml, data, what have you does allow for leaving 'poop' all over the drive so you would need to add a clean up util to make verify the information. this way everything is self contained. Not saying it's the best option.. only an option.

Jason Carr said Great discussion guys. Pogowolf, I'd love to be able to define a standard to include metadata and images, etc., inside of a ROM file, but unfortunately there's no way to do it without breaking support for all of the emulators. The only way to do it would be to get all of the emulator developers on board, which would of course be impossible. Once you change the structure of a file at all, for the most part it will no longer work with existing software. We will be looking into which emulators to include soon; I'll definitely take a look at the ones you've mentioned. Like Bd00 stated.. not if it's local for FB. for 'standard' roms this wouldn't be too much of an issue.. but I do see problems with DosBox, Scrumm, MAME, etc. WORSE case for like a 2600.. you just allow the user to export the rom image from the CART file... which would take care of issue of other emulators not using the CART format.. until they jump on board. another option.. would be to keep a metabase of the hash for each rom image. (like what the GoodTools do) and link the hash with the game.. this way you don't need to even worry about the game itself. still thinking about that idea to figure out if it's good or not.. LOL

Observations, Thoughts, Comments, and Ideas: Version: Launchbox - 3.3 - Beta 1 General: 1) Need a test script to explain what we should see. If we don't know there should be a list of Platforms when you import your first game, how would we know it's an error? 2) Need pages with screen shots as walkthroughs along with the how to.. movies. I know, personally, I hate "how to" videos because I need to wade though the movie to get to the information I want unstead of being able to skim a page of text/screen shots. ?? 3) Perhaps the background could/should be set to a launchbox screen by default.. with options to change it.. little more 'advertising' instead of setting it to the current windows background. Welcome form: 1) Don't show welcome again - This is grey'd out. 2) Add the version somewhere on the form.. perhaps either in the title (Welcome - Version 3.3 - Beta) or in a smaller font under the 'intro to..' movie ?? 3) Don't like how, on start up, the welcome form is model but the parent form opens full screen. 4) the help spread the word.. might want to add support for Twitter and Tumblr as well. 5) Remove the 'minimize' button from this form. it's not needed and really could lead to confusion since it's a model form.. Same with the maximize button. Main Menu: 1) File - EXIT - kinda seems pointless... I understand why it's there.. but still. *laugh* 2) Game - Configure - Doesn't highlight for ROM or SCRUMM? what's this? 3) Game - view image -- better description as 'view Images'? 4) Game - save image as -- better placement of this feature under the view image form? 5) Game - flip box -- perhaps better description as choose default image? 6) VIEW - Button Bar - Turning this on and off moves the background image up and down. 7) tool - Install DOS/Import Games - combine the installers into one wizard? 1) Import allows you to change the platform from the ADD emu VS ADD game. 2) Platform should be saved after input to be used in other drop downs. 8) tool - Export Selected Games - 1) You can export nothing, this should be tested for. 8) tool - Clean Up Images - Could be a setting.. clean on launch? Game Edit form: =========================================== 1) Does the edit game auto-update theGamesdb.net? you have the option to add a game to the DB if there's a game it doesn't know.. what about game updates? (like adding the ESRB rating) 2) What does 'status' mean? there seems to only be one option. this could be used to download the game information in the background.. 3) Source? what's source? 4) Download images from the TheGamesDB should look to the configuration to know what to download.. instead of downloading everything by deafult. (like I don't really need the fan art..and would like to be a global setting) 5) Add ability to find and download the games manual?

bd00 said Vinicius256 said So I tested again today, redownloaded the beta, added a few N64 games and 1 PC game, same result, the .zip file contains everything needed, minus the .exe, I use Windows 7, could it be related to the problem? Better wait to some more input from the other testers before we jump to any conclusions though =P Same here, no exe. Everything else seems to work fine though. Same here. Just the XML file, a readme, and images for PC games (steam.. so I wasn't expecting anything else)

Got an error: Steps: 1) Clicked the filter button on the main form. 2) Selected the filter for platform.. and got the error above. have not been able to replicate it. :/ OK.. yes I have. If you have a filter (Developer) set up and then import more games (roms in this case) you get this error after the import is complete. here's another screen shot of the error:

SentaiBrad said Most of the portability you are talking about already exists though, its just not in a container or on OneDrive etc. You can already do all of that as is. The XML is holding the data of each rom like Publisher and its path on your system etc, and the images folder holds the images. The game is assigned an ID based on Hardware and setup, its given an entry in the XML then everything is assigned to that. Where as if it was based on names, that could be easily broken. It is the same result if its a container. If its based on ID we already have that system setup and if its based on name that can be easily broken and cause some headaches. The point of the program is to hopefully be stupid simple. If the power users like us want to mess around with it we can and if the general end user wants to just plug-in the roms and go they're also covered. Also, MESS is literally a mess. I tried it several times and did not like it at all. MAME barely gets there with a Frontend. The MESS cores are also not up to par from what I remember. A lot of emulators still being updated are generally better. Also, if we include emulators that have multiple systems tied to it, if someone wants to use another emulator I could see it being a hard time trying to change over the small portions, but with the UI rewite that would hopefully be a thing of the past. It only comes down to the right start up commands. I just personally don't like them. Yes, but you still need to download the information.. if there was a standard format, all of that would go away and you wouldn't need to rapid-fire a request the GamesDB.com for the data if you change where your roms are stored, kinda thing nor would you need worry about a name change or ID change breaking anything. All the metadata is right there. the only thing to worry about would be connecting to a database every so often to update meta data. I totally agree that a front end should be just simple stupid. Most people do want to just open, pick a game, and play it. that's why my thoughts are around how to manage the information and data.. LB's front end is pretty darn good, which is why I'm here. hehe However, there are some things that could be modified to make that process even simpler. My current biggest issue is the image cache and even perhaps the whole XML file. I need to look at the output to really see what's going on.. but from what you are talking about, it sounds like LB pretty much much dumps all the meta data into one XML file and processes from there. For small collections this is fine, for large.. a DB is needed. The few times I've used MESS I didn't like it either, however, I know it's been unified and there have been more updates. though, yes, at last check MESS isn't up to par with a lot of other emulators, at least it's a starting point for making LB "stupid simple" MAME works pretty well if you know how to set it up.. which is a total PITA with out a front end.. but programmatically creating INI file that has all the information needed and point it to the mame.exe is nothing. However, ROM management isn't (and I don't think ever will be) simple. Hince the need for standards and the thought to separate the management from the launcher.

Sure! I'm 'PogoWolf'

SentaiBrad said The only problem I see with changing file extensions is then Emulators issues. The fact still stands, we rely on other programs. Adding in layers of anything could have untold issues. It will also make the amount of user data a person has get to be out of hand and you are being forced to use LB so that the container is of any use. Also, after my last scan of TheGamesDB and going through a lot of my games manually, I don't have to do that again. When a new version comes out I just replace the exe and it automatically grabs all the data. If I need to change directories I put the new exe in the new directory, run LB, then place my old XML and Images folder in to the new structure. As long as the XML file corresponds correctly to the right images folder it will be all fine. That is because each game is generated a code based on hardware. Naming conventions can vary from person to person, so if each image set was tied to a specific name, once you edit that name it should break the link. Whereas its a generated code for each entry in the program so any value can change but you can't change the code it was assigned already. We also talked about playing around with an official list of Emulators. We would love to distribute emulators with LB for consoles with it already pre-setup so all you have to do is plug in the roms. Only problem is I can already imagine most Licenses and EULAs will prevent this from happening. The next step would to still pre configure all of the emulators, but each person has to plug in their own roms and the emulators, which we can link to from inside LB. I don't really see it as a problem. Perhaps just a bit of PITA to set up.. LOL First, forget the extension. Look at the header of the file during import to verify the format. This way you KNOW it's a .nes vs a .fds ROM, etc. though, I'm not sure there really needs to be multiple formats.. so perhaps converting .fds to .nes would make things easier in the long run... the data a person needs to see really depends on the person and their filter preferences. We're as I like the auto-detect of the games from the gamesdb.com some of the information is lacking. Like there is a difference between UT3 and UT3:Black Editon, but Gamesdb.com doesn't make that distention. as for the container, true.. but then again, it's one of those things that as soon as other developers see that all the meta data for a game is located with that game.. it could make programming a lot easier. even better if an API was provided for the format to allow for auto updates of the information, etc. and would make changing aa folder structure (I personally, don't want my games under the LB folder, I want them in their own place. like E:/Games/Roms/Nintendo/Nes having a container that already has all your game information makes it as easy as coping a file. It would also remove the problem of the naming convention... the CART format would set it. Yes, having a built in set of EMU's would be pretty sweet. Though I believe you can embed MAME, MESS, and LibRetro.. which would take care 90% of the emulators, and since DosBox and ScrummVM are already there.. LB would be a fully featured launcher. at that point you could tack in like the VLC to add support for movies. Though, even if, the EULA for the software doesn't allow it to be embedded.. then support it anyway in the backend and provide a link to download it from the website. No reason why the download/install process couldn't be automated and it works around the whole embedding of the players. What I see as a need would be to separate the media manager from the launcher.. perhaps even separate out the configuration. If the media player software (EMus, VLC, etc) had there own configuration in let's say an XML file, that XML file could be placed on Google Drive, OneDrive, Dropbox.. what ever... updates to the configuration then wouldn't require a new build of LB.

Good to see nice topics of conversation happening here! though there's a lot of information to read before knowing if you're just reposting something.. anyway... my thoughts about the library is that perhaps the problem is being looked at from the wrong angle. Instead of looking at it like 'what media can this Util play", look at it from the angle of "ok, this is the media, what can play it" stance. I know, for me, I could care less WHICH emulator plays what.. as long as it can play it quickly and within a tolerance for bugs. Since such a library would pretty much be a database of meta data with a pointer to the media. So NES games would be associated with the EMU's that play them.. perhaps with a crowd sourcing widget to know if X emu is horrible for this game, but Y is perfect. this would also separate the Media Players (media.. roms.. pics.. isos.. music.. movies.. what ever) from the media itself.. what I really think is needed is a new ROM file format, I purpose calling it the .CART format. A container file that contains not only the image but also its meta data. Then, you'd only need to hit the GamesDB.com ONCE for the meta data and now that game has all the information association with with.. like Name, console, release date, etc.. the meta data could then be extracted and dumped into the database making importing a HECK of a lot faster.. and I've not had my coffee or mt. dew this morning, so if non of this makes any sense.. I'm going to blame it on the lack of caffeine.

Good morning! Is there a list of features, bugs, and ideas to read? figured something like that would be easier to walk through than trying to read 9 pages of thread and missing something.

Jason Carr said One more thing, pogowolf, did I read that you have a technical/development background of sorts? Care to join the beta testing community (if you haven't already)? My background is in business app developement (vb.NET) and Quality assurance testing, and I would love to! how does one go about joining?

bd00 said pogowolf said bd00 said This is what I am doing. I have pretty much automated the process too. I just need to create a script that will pull the games from a specific platform out of the xml of the main instance and copy it into the platform instance [SNIP] I would be very interested in this setup! You can download the script and files here: https://www.launchbox-app.com/forum/features/automated-platforms-split-script Thank you! I'll check it out!