MD5 Database Manager with detailed information about a MD5 and Black-List function

[ghost]

It would be nice to have all the MD5's saved in one Database instead of the Game Pages and adding more informations to them. The Advantage of this would be to easily identify and manage MD5's for individual Game Page Entries and changing GameID's, Information and Rules instantly.

The information from the MD5 Database could be used to display what Game Versions are supported on each Game Page as it reads the info directly from the Database, forum Topics with MD5 lists will no longer be needed.

MD5 Database Manager Example:

MD5 in Database	GameID	Language	Version	Note	Current Rule	Change Rule	Remove MD5
D202156549F981F6DAFC759575DD6E67	242 🖋	ENG 🖋	1.0 🖋		👍	🔀	🗑
D202156549F981F6DAFC759575DD6E67	XXX 🖋	ENG 🖋	1.0 🖋	Bonus Set 🖋	👍	🔀	🗑
2FF43498FBB957FACF11C598DD8A6299	242 🖋	GER 🖋	1.0 🖋		👍	🔀	🗑
5223853D5EDC9856F2BF8A9F04D01D3A	242 🖋	SPA 🖋	1.0 🖋		👍	🔀	🗑
5BEC2D7ECF3117B479C69CADA8EBAFA4	242 🖋	JAP 🖋	1.0 🖋		👍	🔀	🗑
055EDA915DDB932C22AC61D6A2951759	242 🖋	JAP 🖋	1.0 🖋	Hack 🖋	👎	🔀	🗑
83C9FFC6BBA2A297BAE9EF4AFC3989A8	242 🖋	T+BRA 🖋	1.0 🖋		👍	🔀	🗑
D77120ECD774E391D3B974BFB1905246	242 🖋	T+BRA 🖋	1.0 🖋	NTSC Patched 🖋	👍	🔀	🗑

Game Page Example:

Supported MD5	Language	Version	Note
D202156549F981F6DAFC759575DD6E67	ENG	1.0
2FF43498FBB957FACF11C598DD8A6299	GER	1.0
5223853D5EDC9856F2BF8A9F04D01D3A	SPA	1.0
5BEC2D7ECF3117B479C69CADA8EBAFA4	JAP	1.0
83C9FFC6BBA2A297BAE9EF4AFC3989A8	T+BRA	1.0
D77120ECD774E391D3B974BFB1905246	T+BRA	1.0	NTSC Patched

As you see all the Dev-Specific options are hidden, this includes:

• GameID (not needed as every Game Page will only show MD5's for its GameID)
• Current Rule
• Change Rule
• Remove MD5

Also not visible will be all MD5's with the Not Allowed Rule like the Japan Hack Version in the example above. Also notice that the Bonus Set Entry isn't listed as it has a different GameID.

Following optional features could make the MD5 Database Manager more comfortable to use.

• Adding or Change a new MD5 in the Database manually
• Adding a new MD5 to the Database by choosing a File from your Local Folder (local MD5 hash calculation, no File upload)
• Scanning a File if its compatible with the Game Entry by choosing a File from Local Folder (local MD5 hash calculation, no File upload)
• Copy or Move all MD5's from a GameID to another GameID (mostly for Bonus Sets)
• Remove a MD5 in all GameID's
• Remove all MD5's from a GameID (like the current Unlink Game function)
• Show only White-Listed or Black-Listed MD5's

Marking MD5's as Compatible with a Set shouldn't be included in the Database as every Achievement is written differently and its more a job for the Ticket-Manager.

[Formedras]

I suggest also having the ROMs' GoodTools name in the entry; this would help players ID the correct files from fullsets. A GoodTools name would probably be shown in an individual game's hash tags page so as to help players with fullsets determine which ROMs are ok to use, without forcing them to make MD5 checks on each file in sequence.

[SyrianBallaS]

GoodTools can identify a rom with or without a header (which seems to confuse people). Nointro is straight headerless, even for nes roms. The only emu I know that can load headerless nes is nestopia. Goodtools is more flexible in that regard, yet nointro is more accurate.

[SyrianBallaS]

hash checks should still be required but I think we should eventually use something like salted hashes later, md5 isn't really hashing at all and has a high collision rate.

[luchaos]

This is being worked on. V2s hashes are seeded by the whole of the no-intro dataset, including not only MD5s but also SHA1 hashes (we could use those as well for less collisions), regional parent/clone relation, ROM file names and (no-intro's) validity status.
Whether no-intro/hashes of unknown source are linked to a game with an "active" flag (meaning the rom is good, known to work with the set) or not is still up to us - but we will have the data at hand.
Adding another source of valid hashes is just a matter of writing a dedicated importer for publicly available data, just like i did for no-intro.

[stt]

It'd be useful if the hash also had "title alias" field as some games are released under a different name in different regions.
Some people might be unaware of the other names and think the game is simply unsupported since the name they're familiar with doesn't appear in the lists. These aliases could then be included in the supported games pages with the main title: "Supported Title / a.k.a: Alternative Title (JPN)".

And, perhaps this was included in planning already but didn't see it mentioned above: IMO if player tries booting up a game known unsupported hash of a game that has some supported hash the RA client could show a message telling them the correct supported title/region etc of the game they're trying to play. This could of course be added later on once there's relevant amount of unsupported hashes.

[wimpyrbx]

I might be necroing this, but wanted to just add a tiny suggestion.

Adding a new MD5 to the Database by choosing a File from your Local Folder (local MD5 hash calculation, no File upload)
Not sure if this means adding the local MD5 Hash as "local file md5" in it's own field (before RAHasher).
If it does not read on:

Example in bold below:
MD5 in Database | File MD5 | GameID | Language | Version | Note | Current Rule | Change Rule | Remove MD5

File MD5 = if the local file MD5 checksum differs from the MD5 in Database. Example is where RAHasher might have one MD5 for a rom (V15+ checksums), while the local file has another checksum due to headers.

[Formedras]

I might be necroing this, but wanted to just add a tiny suggestion.

As far as Github Issues go, necroing isn't really a thing. Unlike a regular forum where topics lose relevance over time and fresh topics are generally desired, Issues remain relevant until dealt with (and marked as Closed), and duplication of Issues through new topics is generally a bad thing.

That said, if in the future you want to make a suggestion or point that's only tangentially related, a new Issue may be a good idea. (What you typed is pretty relevant, so a reply is better than a new Issue in this case.)

[wimpyrbx]

As far as Github Issues go, necroing isn't really a thing.
(What you typed is pretty relevant, so a reply is better than a new Issue in this case.)
True and thanks for the feedback!
I will create a new issue if I have anything more to suggest that is not related to this.

I bet the ones working on this get what I meant in the previous post, but I'll add this concrete example:
3. Mahjong (Japan) (Rev B) [T+Eng1.0_Psyklax][arabic numerals].nes
V14- RA Checksum: 1bfec0f52e58d5697dc12849ca86bc46 <- Linked "MD5 in Database" (from RAHasher)
V15+ RA Checksum: c74c09ddc190ec9d78d2d43e8492e14c <- Linked "MD5 in Database" (from RAHasher)
ROM Checksum: a6c0ad487c8fcfdc1175fc016e3e2aba <- Not Linked "File MD5" (from local file/filesystem)

In this case the two linked checksums in the database will not match the local file md5 which is what I am hoping could be added as a "File MD5" field to the database so that we preserve this checksum as well.

Value for the field I propose leaving NULL if the "file md5" == "md5 in database" and only have values in the field when the md5 values differs.

At least I believe there is a benefit of having this field if this ever gets revamped 👍

[redwizard42]

Hopping in here to state that after recent discussions about wanting [Patch Required] to shop up as a first-class citizen when presenting a game title if a game has a non-obvious patch required (ie: a patch to strip out a debug mode), that it'd be really useful to have this as an alternative to that idea, especially if a message could be presented upon loading a 'not allowed' hash: "This game requires a mandatory patch in order to support achievements." Possibly with further direction towards the linked hashes/RAPatchers/etc.