mGalaxy forum

The ideal solution might be to check ROM name against a database, if it isn't there then fallback to displaying the file name for that ROM.

Duckeenie IMO has got it right.

A database (something editable, like a .txt or .xml) could be generated using the filenames as they are now (and the MAME rom descriptions). Once it's generated, you can leave it alone or you can get editing. That way, surely everyone's happy and the idea of keeping the rom names up-to-date is placed on the user and not the developer.

What would be needed then, of course, is a way to re-scan the folders to re-create the database(s) for the systems.

I can see two ways of getting this to work:

1. There's one database file (or several for each system). It's generated by mGalaxy according to user demand. If you make amendments in it then mGalaxy will automatically show the changes. If you re-scanned your roms (essentially creating new databases) then you would either have a way to determine what's been changed and leave it alone (a flag in the XML perhaps?) or the re-scan will simply overwrite what was already there.

2. There's one "custom" file (or again several for each system). It's created by the user. mGalaxy uses it's own methods for determining how to name the files, as it does now. If it finds a custom file it checks this against the filenames it has and does a simple substitution.

I think the upshot is that the developer doesn't have to do much, other than provide the tools for the user - they can then amend or leave it as it currently works.

To be completely honest, I'm not that bothered either way. I thought if it is something that users want, then it doesn't have to be a painful job to implement. I'm just happy after trying lots of different frontends to find one that's simple, works and is pretty to look at!! So congrats to the author for doing an amazing job! GameEx, Hyperspin, Mala and all the others have their place - but for me this is the best frontend I've had the fortune to stumble across so far! =)

I'm not (at all) against the idea of a database for each system...my main concern is: based on which romset!!??
Gamebase, No-Intro, GoodRoms,... there are a few romsets available, each with different naming convention.
As one can't impose a specific one, that would involve maintaining a database for each romset in each system!?

I'm OK to write a little utility that would make a database out of a folder (or another existing XML?)

All your ideas and suggestions are welcome!!

Well - personally speaking - I don't think it needs a naming convention, other than the one that mGalaxy already uses (based on the filename). It's the ability for the user to change what's displayed I think is the request from a few people on here - and it would be a handy feature IMO.

Well I'm afraid to not understand!? What's the benefit of a database if it simply lists the rom name without (for instance) allowing you to have the 'correct' (by opposition to the rom name) name displayed or a 'genre' attributed?
What would you gain? Apart from removing games from the list (but you simply could remove them from the folder) I can't see!

I've noticed Stefan also mentioned the same idea in another thread. Maybe this conversation would be more suited there.

In simple terms:

• mGalaxy creates the file.
• If you leave it alone, everything stays the same - you gain nothing - as you pointed out.
• If you amend it manually in notepad or whatever, those custom rom names show up in the list, instead of the rom's filename. The filename basically gets associated with a custom name.

As an example, the file could be laid out as follows, auto-generated when required by the user:
The GUI then displays the <CustomText /> from the file in the listing, instead of the <FileName />

If a user amends the file manually, replacing srally2.zip with Sega Rally Championship 2 then that's what will show up in the GUI, instead of srally2.zip.

I'm struggling to find a simpler way to put it!! 

Like I said before, it's not a huge problem for me either way - I just noticed people enquiring about it on here so thought I'd offer some ideas.

OK...we are talking of the same thing!...and indeed you would like to have the "real name" displayed instead of the "rom name" ;-)
The only difference between me and you is that you see it from a single user view (each one does as he wants)...when I see the benefit to share all that work among all users...But it requests (that's true) to maintain as many databases that there are romsets available!

The idea:
One user, with a full Commodore 64 romset coming from Gamebase (roms are really bad named!) decide to work on it and begin to associate a "real name" to the rom name...Wouldn't it be interesting to make all this work available to other users that perhaps don't have the technical abilities to do so?

I understand what you're saying - and you're right it would be amazing for everyone to be able to rename the roms to something a little better automatically. This as you've pointed out would be a complete headache though! 

And yes I'm thinking from a single user point of view for simplicity's sake. Maybe people could share their databases on the forums if they've gone to the trouble of creating custom names?

Just an idea anyway! 

I've think to it...and it's OK, I will implement the scan for a database for each systems.
The presence of this database won't be mandatory (to keep simplicity for 'common' users) but if there's one present mGalaxy will use it.

The argument that finished to convince me is the possibility to have the "real name", of course, but eventually the 'cloneOf' info, the 'genre' of a game and the 'players' info (based on the same scheme that nPlayers (1player, 2players, 2players simultaneously,...)
That would bring the same functionalities (for people taking time to populate their database) than those used for mame.

The database will so be structured that way:
...and will be part of the next release: v4.2 that I hold until this addition is completed.

It's a nice feature and will be welcome for users that want to customise a little more. Thank you and good thinking with the extra functionality