Game detection for appropriate settings for patches etc.

[rygos]

In some cases it is good to know which game has just started.
For example, specific settings can be set which might be necessary for some specific patches. This way, the player would not have to guess which is the right approach for the game. This was done, for example, with the Amiga Emulator Frontend Lemonade (http://www.lemonamiga.com/lemonade/). He has recognized the game and set the appropriate settings for the emulator.

In tests, it turned out to be useful to hash the rpg_rt. * And map files, and to determine a "global" hash.
Thanks to Demetrius for this suggestion.

This would allow you to query an optional external or internal database and get the appropriate information.

Further thoughts: The player could display title images or description texts in the game selection screen if several games are in the player directory.

[Ghabry]

Now with #1860 in the queue we should decide about some database format for games.

I talked about this with @rygos before, the author of rmarchiv.tk. The website was perfect as a base for testing this because it has hundreds of machine readable RPG Maker 2000/2003 game archives.

We decided on using a hash function for this.
The fastest approach is probably hashing the LMT first because it is much smaller but I can't remember how many conflicts this had. Maybe ryg can find the statistics again :).
And when there is a LMT hash conflict also hash the LDB.
(hash function TBD, should be the fastest we can find, no security characteristics required, but should have small amount of collisions).

When looking at different emulation projects the file format is usually INI based:
https://github.com/project64/project64/blob/master/Config/Project64.rdb
https://github.com/dolphin-emu/dolphin/tree/master/Data/Sys/GameSettings (Dolphin uses the game ID as the filename, we could use the LMT hash)

As we need to ship some kind of database for existing games and to make accessing it fast (not too many files in one directory) the folder structure could be like e.g. the pip or firefox cache directory way:

The first two folders are the first two values of the hash and then the filename is the full hash, e.g. game has hash ab12351155136a1f16, the the path is a/b/ab12351155136a1f16.ini. (directory depth could be decided after hashing thousands of games, just two folders deep will result in many files in one folder, more than 10000 games are known).

Then the structure could be something like:

The [12abcdef] is for the case that it is in the global database, there could be also a easyrpg.ini provided in the game directory which contains [Game] instead of the hash.

[EasyRPG]
Version=1 <- File format version

[12abcdef]/[Game] <- hash of LDB (LMT is already in filename)
Name=game name
Engine=RPG2k1.05
Encoding=1252
LMT=abcdef12 <- redundant, already in filename
Authors=Author 1,Author 2,Author 3
Language=de,en
Date=2000-01-01
Description=a description of the game
Patches=PicPointer,AutoEnter
Status=Unplayable
ErrorMessage=This game uses a custom RPG\_RT and is not compatible with EasyRPG Player

This could be extended to allow save import, see the other issue ( #1860 ) for this.
Advantage: By doing it through the global database even older games could gain this feature.

[sorlok]

It seems that #1375 might be a good candidate for easyrpg.ini file metadata.

I expect that easyrpg.ini will be at least partly script-generated (since LMT/LDB checksums are tedious to do by hand), so the EXE could also be scanned at this point to populate HP/MP limits, etc.