Thoughts on diff-mods and INI files.

[NoQ]

A "diff-mod" is a word i turned out to use for an idea of letting wz mod files contain only differences between files rather than whole files, in a way similar to what GNU diff and patch utilities do. I'm not sure mentioning them was a good idea though; it's hardly possible to run them over physfs.

What sounds easier is describing/implementing a diff-mod as a file that contains "file,section,parameter,value" lines, something like that:

Code: Select all

stats/weapons.ini,MG1Mk1,damage,11
stats/body.ini,Body4ABT,name,"Fix"

This takes care of ini files only; diff-mods that affect javascript will probably require a full-featured GNU patch anyway; i'm not considering .txt/.csv files since we are migrating away from them. We can also assume that parameters, sections or even files (the latter being unnecessary) are added when not found (so that a diff-mod allowed adding new components to the game).

The mod itself will probably look like a .wz file containing a file to be put into a special directory for diff-mods, eg. /diffs/mg_mod.patch. This way a diff-mod could also include complete files in other folders (eg. both modify weapons.ini and provide a new model for a certain weapon as a whole file, and a texture for it), becoming mod-diff-mod.

Well, now i'd like to wonder how easy it is to code something like that. Anybody? (:

[aubergine]

Like it, although readability could get troublesome if there are lots of entries in the file.

What if it used a sort of ini format to the file, "patch.ini", eg:

Code: Select all

[stats/weapons.ini]
MG1Mk1.damage = 11

[stats/body.ini]
Body4ABT.name = "Fix"

The section names define the ini file to mod, the properties are in targetSection.property format, where targetSection is the section that contains the property in the ini that you're modding.

If .ini files have unique names, maybe we wouldn't even need to specify their path? And we probably don't need an extension (although some ini's don't use .ini extension, for example AI files).

Code: Select all

[weapons]
MG1Mk1.damage = 11

[body]
Body4ABT.name = "Fix"

[aubergine]

Oh, and can I also put in a vote to make the ini files names either all singular or all plural. Eg. weapons and bodies, or weapon and body, not weapons and body

[NoQ]

Good point, this way is shorter and probably easier to implement. Still makes me wonder if it's possible to create a weapon called "MG1Mk1.damage" and run into problems.

Another idea is to use something xml-like, but this is ugly.

Code: Select all

<file path="/stats/weapons.ini">
    <section name="MG1Mk1">
        <parameter name="damage">
             11
        </parameter>
    </section>
</file>

[aubergine]

As long as we don't allow dots in property names of normal inis, there shouldn't ever be a weapon called "MG1Mk1.damage".

XML is technically the most suitable way to do it, but yes, it's ugly and also difficult for creating by hand - too easy to forget to close a tag or get nesting mixed up.

As for implementation, I'm not entirely sure how it would work. I would assume that each of the standard ini files gets converted in to some sort of C++ object list. If that's the case, then it's a relatively straightforward task (for a C++ programmer) to parse the various patch.ini files (or all ini files in a patches/ folder might be better - then their names can be more descriptive) and alter the various object lists that the original inis created.

EDIT: I guess these patch mods would also make balance tuning a lot easier to deal with - people could make their little patch and share it for others to test and give feedback on, and it would be very obvious what is being patched.

[aubergine]

Oh, if we did go the XML route for some reason (you could apply a DTD to them = validation), I would suggest making the syntax more semantic:

Code: Select all

<patch file="/stats/weapons.ini">
    <modify section="MG1Mk1">
        <damage">11</damage>
    </modify>
</patch>

EDIT: But I still think the ini approach is a lot nicer to work with for modders, many of whom might not be overly technical.

[Iluvalar]

You look too away forward NoQ ! Right now we can only load ONE mod with ONE map. We should talk about how mods should merge together only when we will be able to actually load more than one pack.

[aubergine]

That's not true. When I start a game, the ArtRev mod gets loaded and makes stuff look nice. The Ultimate Scav AI mod gets loaded to massively enhance scavenger faction. Nullbot gets loaded to massively enhance the AI. A skybox mod gets loaded to add a custom sky. The Enhanced SitRep mod gets loaded to add more comprehensive in-game sit rep. So lots of mods can be running in a single game, not just the stuff in the map.

There could be any number of mods running, with multiple mods wanting to define or modify weapons, bodies, research, etc.

Currently there can be only one body.ini (or body.txt in 3.1 and earlier) and whichever mod overrides it last wins and everything else is excluded.

What NoQ is proposing is a solution to that specific problem - a way for multiple mods to change bits of an ini file rather than being forced to change the whole file.

Take Ultimate Scav AI mod as an example. It defines a bunch of new bodies, propulsions, weapons, techs and other stuff. But to do that it has to override all the standard stats that come with the game. It can't just add the new bits, or tweak existing bits, it has to replace the whole lot and then be kept up to date with any changes that are made in the vanilla stats.

[NoQ]

What we seem to need is to extend the constructor of WzConfig class in /lib/framework/wzconfig.h, which is fairly simple and a child of QSettings, to pick up diffs and apply them to itself before returning.

Sounds easy.

[NoQ]

Yeah, if only somebody explained me how this "wz::" magic works

[Per]

There could be any number of mods running, with multiple mods wanting to define or modify weapons, bodies, research, etc.

No. Please, no.

This is not the way we should be going. While this is every power user's dream, it will not make Warzone a better game for the remaining 99.9% of players out there. Quite to the contrary, there are many ways in which it will make it a worse game. The developer will spend far more time debugging the insanely complex problems that arise from such possibilities (see only the current mod loading code, horrible enough as it is). The power user will argue less how the game should be changed for everyone's benefit, and instead just change it on his own computer. The game's design will be turned toward ease for the power user, instead of ease for the ordinary user.

A case in point, the current mod loading is tuned for power users, but is near incomprehensible for ordinary users ('what is a command line parameter?' or 'why does my game stop working after i put a mod in autoload?'). Every hour that was spent trying to fix autoload, should have been spent adding a GUI to load a single mod in the skirmish dialog instead. Far less flexible, but far more useful to the overwhelming majority of players. Every hour that was spent adding support for both 'mp' mods and 'sp' mods and combined sp/mp mods should have been spent adding a dynamic menu to load alternative campaigns. Campaign mods that modify existing campaigns are as close to useless as you can get - the number of people who will actually play them is vanishingly small compared to our userbase (or just by any measurement).

We do not need support for multiple simultaneous mods. Having this support in the first place was a mistake. If there really are two mods that people desperately want to play with at the same time, some enterprising soul out there will combine them into one mod. Streamlining and improving the way a single mod can be loaded will be far more beneficial to the whole modding community in the long run, as it will get more users playing mods, and more players means eventually more people involved in making mods, and more fun for all.

</rant>

[NoQ]

We do not need support for multiple simultaneous mods.

The problem of mod compatibility across game versions is still present. This is, actually, one of the major frustration for mod makers: the impossibility of making a mod that will outlive your presence in the community.

Yeah, if only somebody explained me how this "wz::" magic works

Ah, i see, described in /lib/framework/wzfs.h.

QSettings

And when i setValue(), it modifies the ini file

[Rman Virgil]

The problem of mod compatibility across game versions is still present. This is, actually, one of the major frustration for mod makers: the impossibility of making a mod that will outlive your presence in the community.

Major...and for sometime. Should at least, alas, be aknowledged as a first step in seeking a better state going foward. And this is not to cast aspersions. Not in the least. It's also the way to build on past works, exploreing new territory, instead of duplicating work, which happens with some frequency. It has also discouraged a significant body of prelib work from being brought into present, only some of which has been duplicated.
.

[NoQ]

Talk a bit more to myself ...

QSettings

And when i setValue(), it modifies the ini file

And there's a magic QSettings::registerFormat() thing that seems to allow disabling writing.

[aubergine]

@Per: You're talking about making life easier for end-users, but I get the distinct impression the real motivation is to make life easier for yourself. Which is good, I'd do the same and I'm sure everyone else would too in your position. Please correct me if I'm wrong.

I'm not in your shoes but I imagine that if I was I'd see a constant stream of bug reports, many of which turn out to be mod related. It's difficult to improve an app when you're constantly swamped with bug reports, and very frustrating when lots of those bugs turn out to be mod-related.

For 7 years I was CEO of a small company that made mods (or plugins as we called them) for an enterprise wiki app, specifically Atlassian's Confluence wiki. Confluence was insanely moddable, you could change just about anything and add completely new features to it through mods.

As one of the first companies to make mods for Confluence, we ran in to all sorts of issues. In the early days end-users had some massive gripes about mods:

1. Where to find them
2. How to determine which version of the mod, if any, works on my version of the app
3. How to install or upgrade them
4. Where to go for help if the mod breaks

So, we made a plugin (mod) manager. Each mod was given some metadata that defined a bunch of useful stuff, such as:

* Title, Description
* Author username
* Homepage URL
* Support URL
* Screenshots
* What version(s) of the app it was known to work on

Each new release of a mod had it's own set of metadata. End-users could then:

* See a list of which mods were compatible with their version of the app
* See when an installed mod had updates available and one-click install it -- great for rolling out bugfixes!

The usage of mods skyrocketed. With a "single source of truth" for mods, users could quickly find what they were looking for, and knowing it was tested on their version of the app install with a single click.

Over time the mod manager evolved to make life easier and easier for end-users. At first, mod developers grumbled a bit because they had to do a little more work to release a mod (eg. defining the metadata). But as time went on, user interfaces were added to streamline the release process and developers also saw the benefit of being able to centrally notify their end users about bug fixes and other updates for their mods.

Atlassian built in a "safe mode" which would disable most mods, and mandated its use before handing any support requests. Users experiencing problems would enter safe mode and see if the problem went away - if it didn't, everyone could be pretty certain that it was an app-level issue. However, if the problems did go away, everyone could be pretty certain that it was a mod-level issue (though taking in to consideration that the mod might have exposed a latent bug in the app).

There's over 500 plugins for Confluence now. And you'll note that the most downloaded mod, now maintained by Atlassian themselves, is the "Universal Plugin Manager" -- the present-day manifestation of the mod that my company wrote 7 years ago.

What I'm trying to say is: Nerfing mods isn't going to solve any problems. If you want to make life easier for end users, and app/mod developers, get mod management under control first.

If users had an easy way to browse mods and get more information about mods, it would be a good start. At least then there's a "single source of truth" for mods.

The next stage would be to build a mod manager in to the game, so users could (un)install/upgrade/enable/disable mods from within the game itself.

These aren't silver bullets to the problems faced by end-users, app developers or mod developers. But they are still massive improvements and pave the way to tackling many other issues.