I was chatting with Argh while he was doing his missions last night, and he wanted to make his mission-mutators as "mod packages that can be launched as mods, but don't appear in mod-lists".

Now, i dimly remembered that modtype = 0 is supposed to be used to make invisible mod packages... but apparently that's just utterly useless in 0.79. And modtype = 0 was also supposed to be for dependencies, but Argh says that's modtype = 2 is used for.

And, as a lark, he checked what happens if you use 3 - it's the same as 1.

So, can anybody explain WTF the modtype values are? Because the wiki is obviously totally freaking wrong.

http://spring.clan-sy.com/wiki/Mod_specification

As far as I know, the wiki is actually right, except that modtype=2 has never been implemented.



Looking at the code it seems Spring checks for modtype != 1 or modtype == 1, so effectively there's modtype == 1 (primary mod) and everything else (hidden; dependency of primary mod).

Modtype == 2 is definitely not for dependencies although it currently has the same behaviour as modtype == 0, which is for dependencies. Modtype ==2 is for mutators of which multiple are selectable at the same time. But it isn't implemented, neither in Spring, nor in the lobby server/client infrastructure.

ModType 0 doesn't work as advertised. Put stuff in that ModType, it gets treated like ModType 1.

ModType 2 is hidden, and will not load anything from springcontent.sdz, which results in a crash if not corrected.

This can be fixed, to allow the game to run. I built my first "stealthed mod" last night. Sent the results to Quantum. There may even be better ways, IDK.

Wrong, modtype=0 works fine.

Just check in springcontent.sdz / maphelper.sdz / any of the OTA content files / any of the SWIW dependencies. All of them have modtype=0 and none of them shows up in the mod list in a lobby, which is exactly as intended.

Modtype=1 is the only type considered "primary mod" and as such returned to lobbies. It's the only type which shows up in lobbies, which is exactly as intended. It's also the only type of mod to which springcontent.sdz is implicitly added as a dependency.

Modtype=2 is treated as modtype=0 because Spring only checks for modtype != 1 instead of raising an error because the modtype is is not 0 or 1, which are the only supported modtypes. (EDIT: added raising error for unsupported modtypes to my to do list.)

EDIT:

The relevant pieces of code, from ArchiveScanner.cpp.

This shows only for modtype=1 springcontent.sdz is implicitly added as a dependency of the mod.


This shows mods are only considered a primary mod and hence visible in the lobby iff modtype = 1.

I built a modtype 0 yesterday, and it showed up as a primary mod.

I did it with type 2, and it worked correctly.

Now I'm doing it again, with 0.79, deleted ArchiveCache, and it works as advertised. Go figure

The stuff about springcontent.sdz still applies, though.

Using .sdd's possibly?

In that case make sure to change the .sdd directory timestamp or removing ArchiveCache*.lua to ensure the modinfo (and hence modtype) is re-read.


Just add it explicitly as dependency...

Tried that, and it crashes. You can fix the problem easily enough, by including these files:

http://www.wolfegames.com/TA_Section/SP_TEST.zip

That seems to result in a fully-functional game.

What kind of crash?

That set of files doesn't make any sense to me; as in, I can not imagine which of those files is somehow needed before all the dependencies are mapped into the VFS... are you 100% sure you didn't misspell springcontent.sdz in the dependencies list, or forgot to update numdepends or forgot to trigger an ArchiveCache*.lua refresh?

Also please do not use ModType=2 unless you intend that multiple of those mods can be selected sometime at the same time, if the feature described in the wiki ever gets added to Spring and the lobby infrastructure. More specific, use only ModType=0 or ModType=1, cause these are the only meaningful and supported ModTypes.

EDIT: downloading stuffs to check if I can reproduce it.

I thought modtype 2 was mutator or something liek that.

Something uses that?

so let me rephrase, is that now the way things work as in it was always that way? Or is it the mutators are going away?

It has always been unimplemented.

wow.

You should see the original idea for ModType=2 as a sort of multi-mutators.

Like, you select a primary mod (one with ModType=1), and then you can pick an arbitrary amount of "secondary mods" / "multi-mutators", which each would have to depend on the primary mod, I suppose.

(Or some other not yet invented tag would have to be used to indicate the mod(s) with which these multi-mutators can be used.)



Argh, I tested your example and manually adding springcontent.sdz dependency works fine. I did this:

1. made a tmp.sdd,
2. unzipped your SP_TEST.zip in it,
3. removed everything except modinfo.tdf,
4. added springcontent.sdz as a dependency,
5. changed the name in modinfo.tdf to "testzor" to ensure it didn't conflict with other P.U.R.E. stuff,
6. fixed the dependencies to point to RC52 / RC53 files instead of RC6
7. started Spring from commandline with a startscript with Gametype="testzor TEST"

This worked fine, no errors.

From what I've seen from P.U.R.E. in this test (almost nothing) it looks quite good btw.

Mutators is a poorly-understood term in Spring. People say mutator and they mean "small mod that depends on a big mod". That's always worked, since fundamentally a "Spring mutator" is the same as any other mod.

The modtype = 2 was for UT-style mutators, where they're not mutually exclusive.

Interestingly enough, the feature was a pointless concept before Lua came on the scene.

Now that we have Lua, it's really worth considering implementing, since it would be nice to make stand-alone gadgets that include new gametypes that may depend on units that don't exist in the mod they're based on.

But it would require a great deal of work, since you'd have to handle lots of colliding things that there used to be only 1 of before.

mutator was a name from TAM days. Where we had mods and the mutators which were used for changing a few stats in a file allowing for alternate versions of TCs or MODS.

Oooh, damn, I tried to use TAM once back in the day. I completely forgot about that. Either way, the point stands: the mutators we make on Spring today aren't true Mutators, they're just really-small-mods-that-depend-on-something-you've-already-got.

True mutators are modtype = 2.

Either way, we're getting sidetracked. It seems like the whole "listing in Spring.exe" was a caching broblem on Argh's part, so really there are two modtypes -

modtype = 1, which is a normal game package in the menu
modtype != 1, which is hidden from the menu and doesn't include springcontent.sdz

My question: can Spring be told to play with mods of modtype = 0 directly, instead of modtype = 1? Argh says no, Tobi says yes. Whut? Something about Argh not being able to include Springcontent?

'Mutators' are now better done with modoptions.

A few of them, but many things aren't going to be in the core game release.