[Feature] Version Descriptions

[eulogy37]

Is your feature request related to a problem? Please describe.
So many versions of roms (especially Arcade), all with slightly different content. Determining which is which requires a CTRL-F search of the relevant DAT file.

Describe the solution you'd like
Include somewhere on the UI the description tag and possibly comment and manufacturer tags from the related DAT file...either for the selected rom in the Info section, or out to the right in the Switch Versions drop down menu. (example: sf2thndr2 would read "Street Fighter II: The World Warrior (Thunder Edition, bootleg, set 2) - Bootleg - bootleg"

Describe alternatives you've considered
Manual lookup in FBNeo.DAT is the only alternative I've found and it's tedious.

Additional context
Users would not need to memorize that sf2mdt is a bootleg of SF2CE called Magic Delta Turbo.

[gantoine]

how do you propose we do this? romm doesn't use DAT files internally.

[eulogy37]

You make a good point. It looks like hasheous returns a Name in the Signature Mapping section, but that may be of limited use since most of the bootlegs and hacks won't have unique names. Some do, though (https://hasheous.org/index.html?page=dataobjectdetail&type=game&id=281376) .

Seems tenuous. Probably the only reliable way to do it is what you said - use DAT files internally. I'm not sure how or if this could be achieved outside the Arcade arena, but for Arcade, EmulatorJS only currently supports a few Arcade cores, and 4 out of 5 of them are static, I believe...their DAT files are not getting any updates or changes. Also, all of them follow the same format, so the same python script could load all 5 into a sql table - loading 4 automatically and an optional FBNeo import via user-supplied file. Looking up using a filename and sql query is easy at that point.

I realize, however, that DAT files have always been an option for you all, and that you specifically chose not to go that direction. "Hey scrap all this stuff you've done and do it my way" is not the message I'm trying to send...also, I think this is a big lift for a small benefit - unless there are a half dozen other issues/features these DAT files would accomplish, it's maybe not worth the time.

I do think you're right that the only reliable way to do it is through DAT files - I mean if you get bored, you could see what kind of results come out of the hasheous "names" but I don't think it'll work even half the time.

[gantoine]

"Hey scrap all this stuff you've done and do it my way" is not the message I'm trying to send

I appreciate that 🫶

I think this is a big lift for a small benefit

It is, but maybe @michael-j-green has some thoughts on this being integrated into hasheous somehow?

[michael-j-green]

I do pull in the FBNeo DATs into Hasheous. Any extra fields should be stored under the attributes attribute:

As for the naming of the ROM (using the example "Street Fighter II: The World Warrior (Thunder Edition, bootleg, set 2) - Bootleg - bootleg") is included in the game attribute:

I think what we have here is possible an over-abundance of data, it can make it hard to choose which to use.

ROMM might need to implement an order of preference for which DAT source to use (example: for the arcade platform, use FBNEO, then MAME, then TOSEC), using the first match wins rule. It can then use that data to name the ROM appropriately.

As for displaying in ROMM, I can't really speak to that. But in Gaseous I have the game that the ROM is mapped to (which is the IGDB data), and then I list all ROMs that are mapped to that IGDB game id.

For example, with Super Mario Bros I'll have a screen that shows SMB metadata, logos, artwork, etc, and then list the official SMB releases, revisions, and hacks.

Unfortunately, the DATs (from any provider) don't have a standardised flag that says IsHack=1 to make it easy to parse out, and sadly the naming of the files is inconsistent to reliably extract that information.

[eulogy37]

What a twist! Looks like you don't need to ingest DATs because Hasheous is already doing it for you!

And it turns out I was way off in my "half the time" estimate. It's retrievable 100% of the time via Hasheous - the limiting factor seems to be whether the DAT-makers include the information...which is the same limitation we have when searching manually so that's perfect.

Unfortunately, the DATs (from any provider) don't have a standardised flag that says IsHack=1 to make it easy to parse out, and sadly the naming of the files is inconsistent to reliably extract that information.

The most reliable element I've seen for hack/bootleg in the DAT files are Game Name and Game Developer (publisher in the above). So if you decide to pursue this feature, that's the target I think. How you want to display it is another matter...you've made great choices so far as evident with the cleanliness of the interface so I'm hesitant to even make suggestions. But that's what this forum is for, I suppose...you could have the title/publisher out to the right in the "switch version" dropdown or you could add it to the Info section (Size, SHA-1, MD5, CRC, Title, Publisher) since that's already displayed at a per-file level.

[michael-j-green]

I could certainly add an extra attribute that tries to detect the content type (hack, bootleg, etc).

Just need a good list of types that are available across all data sources - that way as we work out methods to detect the type we can apply it to each source. Also need to decide how this attribute would be presented in the API level - is it a number of boolean types (ishack, or isbootleg) but that's quite limiting and doesn't scale well. I'm thinking it should be more of an array of types. That way we can add more as they're discovered.

Once we've got that it's over to ROMM to determine how to utilise the data in the app.

[eulogy37]

Please don't let me stand in the way of you making any improvements you want to make, but in my mind there's a spectrum of information availability ranging from completely invisible to categorically ironclad. IsHack and IsBootleg is much further along that spectrum than I'm asking for. :) One notch above invisible is good enough for me (and maybe others).

Behold my horrible mockup:

An adjustment like the above seems fairly low-effort to me (I'm a novice at python & js so I could be wrong), but IMO would go a long way in the interim while you work on a solution that's more toward the "categorically ironclad" side of the spectrum.

[michael-j-green]

I can’t speak for @gantoine on the difficulty of adding that, but I do want to call out an issue with that sort of solution: search.

If you wanted to search for all of the hacked ROM’s in your library, you couldn’t guarantee that you’d get them all, since the data isn’t normalised across all of the DATs.

And it’s far more difficult if the devs wanted to display icons next to the ROMs to display that this is a hack, or this is a bootleg.

@gantoine is there call for a hack or bootleg or other type of flag? If so, let’s create an issue on Hasheous and link it to this one. There we can discuss implementation and normalisation rules to ensure we get a good cross section of data from the DAT’s.

[gantoine]

is there call for a hack or bootleg or other type of flag

maybe? it's not something i'd ever use or need, @Moonraka or @danblu3 might have thoughts?