better built in extraction

[briaguya-ai]

brainstorming UX for better built in extraction

rom in dir	otr matching rom in dir	other otr in dir	behavior
no	n/a	no	prompt for rom
no	n/a	yes (outdated)	prompt for rom
no	n/a	yes (up to date)	boot game
yes	none	no	auto-extract rom
yes	yes (outdated)	no	prompt? auto extract? not sure
yes	yes (up to date)	no	boot game
yes	none	yes (up to date)	auto-extract rom
yes	none	yes (outdated)	auto-extract rom(s), prompt for other?
yes	yes (outdated)	yes (up to date)	prompt? auto extract? not sure
yes	yes (outdated)	yes (outdated)	prompt? auto extract? not sure
yes	yes (up to date)	yes (up to date)	boot game
yes	yes (up to date)	yes (outdated)	prompt? auto extract? not sure

[Archez]

Maybe should consider game type too. Thinking about what happens if you have two different original roms in the dir. Which should be auto extracted? Maybe only auto extract if there is one per game type, otherwise prompt to ask?

[Malkierian]

Regarding the "yes (up to date)" condition for the OTRs, I've seen in logs a LOT that pretty much all OTRs generated are still unversioned. Has that been addressed in develop yet?

[Archez]

Regarding the "yes (up to date)" condition for the OTRs, I've seen in logs a LOT that pretty much all OTRs generated are still unversioned. Has that been addressed in develop yet?.

The "missing version" that you see in logs is unrelated to ship version. The existing version file in otrs is the CRC hash, so the otr can be identified as a supperted OTR file.

For Ship version tracking, we will need to store a new version file that contains the ship version in it (at time of generation).

What this means is detecting old OTR files would have to be introduced at the same time as we store the version. Any otr without this version file can be assumed as "old", and so the detection would have to be reserved for 8.0.0