Newer updated signatures get games blocked until a new ScummVM is released

[lwcorp]

For example, when Heroine's Quest was updated seemingly the only change needed in ScummVM was the signature (#13590), which probably took minutes to apply.

But the signatures are not cloud based, meaning new versions of games are blocked in ScummVM until a new ScummVM version comes along (with the updated signatures) which can take months.

Again in the example of Heroine's Quest, yet another version was recently released and was this time updated in ScummVM without needing a bug report. But the new version won't work until a new ScummVM comes along.
If you try to run an existing listing, it states it's unsupported. If you try to add it from scratch, it states it seems to be an unknown game variant.
It does work in the daily build, of course.

Not sure what the solution should be, but it just feels a shame to break a game for months just because offline ScummVM isn't linked to to the up to date signature database.

[tag2015]

Implementing an online service to check the gamefiles checksums/integrity is in the works, but not ready yet.

But I don't understand what you mean with "new versions of games are blocked".
It is engine dependent, most engines don't allow adding undetected games, but others (like the AGS engine) let you add and start any unrecognized game.
If the entry in your gamelist doesn't work anymore you simply need to add it again, it'll be detected as an unknown AGS game but it will work normally. If you want to use your existing saves, rename the ags-fallback ID to heroinesquest.

[criezy]

There is already a mechanism in place to handle this case: fallback detection. It lets engine run unknown game variants. Not all engines can provide this, but as mentioned by tag2015 it is implemented for AGS games, and that allows unknown games or game variants to be detected as generic AGS games and played. That's why I am surprised by Heorine's Quest being explicitly mentioned in the description. Being an AGS game, the new version should be playable even before we had an explicit detection for it.

However the initial request remains true for some other engines that do not implement fallback detection.

And to clarify, the online services to check game files checkshums that is being worked on is not meant to fix this issue. As far as I know it is not designed to replace or even complement game detection, but to check that game files are not corrupted, or missing.

[tag2015]

Replying to criezy:

Being an AGS game, the new version should be playable even before we had an explicit detection for it.

I think the issue occurred like this

1. He added the Steam version of Heroine's quest when it was properly detected by version 2.7.0/1
2. The game updated on Steam
3. Now the entry in the gamelist doesn't work anymore because the old detection entry used "heroine's quest.exe" but the new version is "heroine's quest.ags"

But as explained before it's just a matter of re-adding the game to ScummVM

And to clarify, the online services to check game files checkshums that is being worked on is not meant to fix this issue. As far as I know it is not designed to replace or even complement game detection, but to check that game files are not corrupted, or missing.

I'm almost sure that among the integrity service discussion, there was a proposal to move the biggest detection tables (AGS, Director) to a similar service. But I don't know if it's feasible, if it was scrapped or put on indefinite hold

[criezy]

Replying to tag2015:

I think the issue occurred like this

1. He added the Steam version of Heroine's quest when it was properly detected by version 2.7.0/1
2. The game updated on Steam
3. Now the entry in the gamelist doesn't work anymore because the old detection entry used "heroine's quest.exe" but the new version is "heroine's quest.ags"

But as explained before it's just a matter of re-adding the game to ScummVM

That is a good remark. Maybe we could improve this situation so that the user does not have to re-add the game. I think this is caused by the generic AGS fallback detection having a different gameid.
At the same time this is probably an issue mostly specific to the AGS engine. Most games supported by ScummVM are old games that are no longer updated.

I'm almost sure that among the integrity service discussion, there was a proposal to move the biggest detection tables (AGS, Director) to a similar service. But I don't know if it's feasible, if it was scrapped or put on indefinite hold

There was a discussion about moving the detection entries to a separate data file (as we do for some engine data) to avoid bloating the source code and memory with big detection tables. Instead they would be loaded on demand. I don't remember any discussion about using a web service. But just having a dat file separate from the executable would indeed in theory allow updating detections without updating the executable itself (in the cases where the new variants do not also require updates to the engine).

[lwcorp]

Replying to tag2015:

But as explained before it's just a matter of re-adding the game to ScummVM

True enough, it indeed works if I try re-adding. But unless I manually rename the ID, what happens when you try to add another unknown AGS game (with the fallback ID always being the same)?

Moreover, the fallback entry's Game Options miss out Achievements and Statistics. And even if a way is found around it, it will probably lose the original ones.

[tag2015]

There was a discussion about moving the detection entries to a separate data file (as we do for some engine data) to avoid bloating the source code and memory with big detection tables. Instead they would be loaded on demand. I don't remember any discussion about using a web service. But just having a dat file separate from the executable would indeed in theory allow updating detections without updating the executable itself (in the cases where the new variants do not also require updates to the engine).

That must be it. I probably mixed the two

[tag2015]

Replying to lwcorp:

Replying to tag2015:

But as explained before it's just a matter of re-adding the game to ScummVM

True enough, it indeed works if I try re-adding. But unless I manually rename the ID, what happens when you try to add another unknown AGS game (with the fallback ID always being the same)?

Moreover, the fallback entry's Game Options miss out Achievements and Statistics. And even if a way is found around it, it will probably lose the original ones.

I agree with you that it's not ideal, but you have to take into consideration that the detection mechanism works in a similar way in all engines and it was not designed for games that are frequently updated, which instead is the case for AGS games.
As of now the alternatives are:

• Use the stable version and use the fallback detection and occasional hassles
• Use the daily dev build, for which the AGS detection tables are constantly updated