Yaribz
Allow plugins to handle `getMapHash`
Maybe I just don't see at the moment how to achieve that, but it would be nice if it was possible for plugins to be able to handle those queries and respond with value.
The dumbest plugin implementation could just reply with 1 which is accepted by engine and then hash validation just isn't performed.
Moreover, it's not clear to me why only "choose in game" is available in this mode? It should be also possible to have fixed or random, it's just that spads can't perform validation before the start of the game.
Maybe I just don't see at the moment how to achieve that, but it would be nice if it was possible for plugins to be able to handle those queries and respond with value.
The dumbest plugin implementation could just reply with
1which is accepted by engine and then hash validation just isn't performed.
That's not really possible to implement it this way currently because SPADS uses caches for the maps matching the current configured map list: one cache for the maps available locally, and another one for the "ghost maps" whose hash is known for the current engine major version. So basically there can't be requests for maps whose hash isn't already known...
However, there exist two ways to make SPADS learn new map hashes in addition to the normal methods of the ghost map functionality (autoLearnMaps / !learnMaps):
1 ) If the instance is currently running, a plugin can be used to call the saveMapHash(mapName,engineMajorVersion,mapHash) method on the SpadsConf object (gettable with the getSpadsConfFull() accessor of the plugin API). This makes SPADS learn the hash of a (new) "ghost map" for a (new) engine version. Such learned map hashes are private (local to each SPADS instance) but persistent (survive instance restart).
2 ) If the instance is not running, one can simply (over)write the file containing the persistent data for the SPADS "ghost maps" functionality: mapHashes.dat (located in SPADS instance directory).
The syntax of this file is pretty basic. First, one header line prefixed with #? containing the structure of the data:
#?springMajorVersion:mapName|mapHash
This line just means the structure of the following lines is <majorEngineVersion> : <mapName> | <mapHash>
Then, the next lines contain the actual data. For example:
103:1944_BocageSkirmish|-208875504
This file is overwritten by SPADS when it's running, so it can only be written when the corresponding instance is not running.
If you need a more flexible solution I might be able to extend the current plugin API, I will need to think a bit about it.
Moreover, it's not clear to me why only "choose in game" is available in this mode? It should be also possible to have fixed or random, it's just that spads can't perform validation before the start of the game.
By "this mode" I guess you are referring to SPADS "ghost maps" functionality (for map archives not available locally) ?
I didn't check if this was fixed in Recoil, but that used to be an engine limitation (see my previous answers in Discord here and there)
If the instance is currently running, a plugin can be used to call the saveMapHash(mapName,engineMajorVersion,mapHash)
Okey, so we could have a plugin that just on the start calls it for all maps in map list in sequence, and in case map list changes.
I didn't check if this was fixed in Recoil, but that used to be an engine limitation (see my previous answers in Discord here and there)
I totally forgot about this one, this will break ffa, so needs to be fixed before anything else in this feature request will be useful.
Okey, so we could have a plugin that just on the start calls it for all maps in map list in sequence, and in case map list changes.
Actually there is no need to take the current map list into account in the plugin code. The plugin should just perform the saveMapHash calls for all "ghost" maps that SPADS core should be aware of. Then SPADS core takes care of applying the map lists filters dynamically when needed to take the currently enabled subset of these maps.
However, ideally these saveMapHash calls should only be performed the first time an instance is started with a given engine version (or when new "ghost" maps are added). Performing these calls at every SPADS startup is suboptimal, but that's a minor inconvenience and it makes the plugin code much simpler I guess.