Thoughts on diff-mods and INI files.

[Iluvalar]

Per is right !

Except we should design that GUI with multiple mod selection in head and try to keep the chain mod loader as it is (since Aubergine proved some mod are compatible).

[Rman Virgil]

.

...... get mod management under control first.

First thing that was tackled after Pumpkin Studios went defunct. First iteration was released for X-mas of '99.

Utility was called WZS. Served as "one source of truth" for almost 7 years for everyone in the community. It was wonderful.
.

[NoQ]

Right now i feel that the best format for diff-mods is something like that:

Code: Select all

/diffs/Ultimate Scavenger AI/stats/body.ini
/diffs/Fancy Balance Mod/stats/weapons.ini
/diffs/Fancy Balance Mod/stats/propulsion.ini

With these .ini files looking exactly as the base .ini files with the same path, just containing less data.

[Emdek]

BTW, anybody remembers idea of introducing mutators?
It simply doesn't make sense to create multiple combinations of existing mods to pick few small changes and duplicate code that could be done as mutator and used along "main mod".

[Shadow Wolf TJC]

I remember, though I originally thought that you were referring to the ability to provide special effects on the game using JavaScript functions. I'm still interested in seeing that happen though.

[Emdek]

Shadow Wolf TJC, that is also in their scope. All depends if and what would be available to change in that way.

[aubergine]

There is already a wide scope for JS mutation, especially as a bunch of stuff was un-hardocded recently by felipe and others. I've got a growing library of APIs that manage mutations of various forms - example: completely overriding functions/constants/globals, hooking in to before/after function calls (with ability to change params and return values), etc.

I'm not sure the mutators we originally discussed would be ideally suited to tweaking ini files - the direction NoQ is going in seems better suited to that.

[Emdek]

aubergine, the thing that we are for sure missing is UI to manage such things. Also it would be good to decide ASAP which ways to mod will be supported. I we would have "official" way to inject only small changes in that way then it would make sense to allow only one global mod at a time, since it wouldn't be needed to duplicate lots of small changes.
As far as I understand what NoQ wants to achieve here is to have alternative way to modify rules by these "global" mods, right?

[aubergine]

Let's clarify 'rules' first: I take the word 'rules' to mean everything about rules.js - player init, sit rep, vitory conditions.

What NoQ wants is a way to modify stats in ini files. Take Ultimate Scavenver AI mod for example. It defines a bunch of new propulsions/bodies/turrets. In order to do that it has to copy the entire existing stats for props/bodies/turrets, then make changes to the copy. The problem is then when the original stats get updated in future releases of WZ - the mod has no idea about that. All the mod really wants to do is add it's new stuff, and maybe tweak some existing stuff. But currently mods are forced to clone entire stats files, even if they only want to add or change one property.

By being able to have little "patches" that leave the existing stats intact but just tweak specific properties or add a few extra bits, there are several benefits:

* It's much easier to see what specifically the mod is doing - you don't have to wade through a massive pile of cloned stats to try and work out what the diffs are
* If the stats in WZ get updated in future releases, you don't need to update your mod (in most cases) because it's patch has surgical precision and doesn't affect any of the other stats
* When multiple mods are running (as I illustrated in an earlier post), they can co-exist more easily - there is far less chance of them conflicting because they are only providing surgical tweaks rather than entire clones of stats files

----

Also, in relation to Per's earlier comment, I don't think it's going to be any more difficult to debug conflicts using the patch approach. In fact, I think it's going to be easier than what we currently have. First, there are going to be fewer conflicts because patches are small and very specific. Secondly, if all the patches are in a /diffs folder it's very clear where to look for culprits, and because the diffs are significantly smaller it's also much easier to see exactly what they are doing.

Compare that to current situation: You can have multiple mods already that override stats, but because they are forced to clone entire stats file it's much more tedious to work out what's changed and what's conflicting.

Now let's fast forward a few years. Imagine that the only way to mod ini files is via patches. You could still do mass changes, but it would be rare (eg. only seen in mods such as NRS or Contingency), normally you'd just be adding a few bits or tweaking a couple of bits. And all those patches live in diffs folder. Now, in game set-up, you could list all the patches that will be applied to current game and give user option of disabling them (although that could break stuff if a script, for example, was expecting presence of a custom droid component, etc.).

[Emdek]

I don't like use of patch metaphor here, it should be manipulated by API with getters and setters (optionally with dedicated method to remove entries by given key). That is cleanest way to achieve that, but not easiest (for moders) I guess, for them probably it would be simpler to just supply file differences... So there would be need for small helper algorithm, preferably built in stats editor, which would allow to export such difference in form of API calls (to generate script that uses those setters and getters to insert changes). Less clean way would be to have additional call to load such diffs from data files but I'm not sure if such thing should be incorporated into game engine.

[aubergine]

Well, let's remove the words "diffs" and "patch" from our discussions - I think they're misleading in the context of what NoQ is proposing.

"Tweak" is probably a better word, as that more accurately explains what the files are doing. They are tweaking the existing stats - either adding a little bit of new stuff (eg. new weapon) or changing just very specific existing entries (eg. increasing ROF of an existing weapon).

Anyway, I assume NoQ is working on some C++ code to implement a prototype and it will probably be easier to discuss once there is code to look at (although I can never seem to get my head around C++ code for some reason).

[NoQ]

"modlets"?

We need to fix the terminology cause i need a name for the physfs folder, lol.

[Emdek]

Stats-mod? Personally I don't think that this needs custom name, it's simply kind of mod.
Any comment on my proposition? It covers how API for doing that should look like and how data should be generated...

[aubergine]

"modlets" is kinda cool

@Emdek: While they are starting out as stats mods, other things could be "modletted" in future (although I'm not sure what, as ini files cover just about everything I'd want to modlet).

[NoQ]

Well, essentially, the code i propose is now here: part 1 (trivial), part 2.

It'd be great if Emdek's idea gets implemented, but if it turns out to be too complicated or something like that, here's what seems to be a relatively simple way.