Not possible to make mod compatible with vanilla but incompatible with different versions of itself

[badosu]

Like autociv and fgod I patch `hasSameMods` and `sendRegisterGameStanzaImmediate` to make my mod able to work with vanilla (avoid having all matches in lobby without mod greyed out).

E.g.: https://github.com/badosu/badmod/blob/ac9b65a009305fe1cc46412abd7a1a60477fd1fd/gui/gamesetup/gamesetup~badmod.js#L16-L20
 

However, in preparation for 0.18 release I want to still be compatible with vanilla but incompatible with 0.17. However it seems that to be able to do that I would have to start sending the mod on the stanza (so `hasSameMods` can perform the check) which would make it incompatible with vanilla.

This is a sample code of how the check would be performed:

 

global["balancedMapsCompatibilityMatcher"] = new RegExp('^0\\.18(\\.|$)', 'i'); 
autociv_patchApplyN("hasSameMods", function (target, that, args)
{
	let mod = function([name, version]) {
      return !(/^balanced[-_]maps.*/i.test(name) && global["balancedMapsCompatibilityMatcher"].test(version));
    }
	return target.apply(that, args.map(mods => mods.filter(mod)));
})

But to have the mod comparison available I would have to send on the stanza, it's my assumption that if I send on the stanza then all ppl without mod wouldn't be able to join mod-hosted games, even if the map being hosted itself is vanilla.

Is my understanding that this is impossible correct or is there another way?

[badosu]

Ok, thanks @elexis for the suggestion. We can send the mod on stanza only when a balanced-map is being used, which works.

@nani It seems autociv redefinition of sendRegisterGameStanzaImmediate is always used regardless if my mod is loaded before or after, if the filename is alphabetically before or after the one used in autociv, etc. Any ideas why I can't patch over the autociv definition?

[badosu]

Ok, this is what I ended up with: https://github.com/badosu/badmod/commit/4923a551063de471bb58df9f5f07a09a22d136b5
 

I had to patch `init` like autociv does. Also, I have a custom compatibility checked because I want patch versions to be compatible with each other.

[Stan`]

Good job

[nani]

You code should work but I guess that this should have better official support from 0ad as the cases keep getting more complex

[Stan`]

I'd be interested in this for the languages pack as well. The question is how do we make it useful without allowing people to completely break the game.

[badosu]

42 minutes ago, nani said:

You code should work but I guess that this should have better official support from 0ad as the cases keep getting more complex

I mentioned on lobby, the ideal solution would be to specify mod compatibility constraints on `mod.json`. I guess something that can be worked on for a24.

[badosu]

An alternative would be to have categories of mods, e.g. spec mods (e.g. autociv, fgod) are never checked for compatibility, maps mods are checked only when the map is loaded (like we do here), etc... But these would be ad-hoc solutions, I think a compatibility constraint would be best. As to avoid abuse, it would be impossible and made easier but I guess it's better to have it explicit than some kind of security through obscurity (stanza and hasSameMods can be patched regardless).

As for maps, language-packs, etc a resource distribution mechanism would be a better delivery system than packaging them as mods, thought the mod specification could be reused possibly with a tagging mechanic (as described above) if a proper resource delivery system is too ambitious for a first step.

A proper resource delivery system would download the assets on the fly, like for example when you download a map when playing a typical fps, with all textures, templates, etc... That would imply in additional complexity to be sure maps are compatible with mods, possibly even chaining on mod delivery. But I guess mod constraint specification would be a huge step in the right direction at least.

Edited April 28, 2020 by badosu