Thoughts on diff-mods and INI files.

[Emdek]

aubergine, things which they are changing are kind of scope for mutators.
NoQ, those are two approaches to get to one target, but as far as I can observe WZ is going away from loading raw data files and going for scripting.
The thing that I would change is only to not load and parse these files but load scripts and execute them, using example from IRC:

Code: Select all

setStats(STATS_BODIES, 'Body1REC/buildPower', 1000);

Instead of parsing:

Code: Select all

[Body1REC]
buildPower = 1000

All other aspects of your change are fine for me.
Keep in mind that this is only example call, with example syntax and example name.

[aubergine]

That's a heck of a lot more typing to do. For stats WZ is headed to .ini format (as far as I can tell), so it makes sense to use a similar format to mod ini files, rather than suddenly jump in to scripting (which seems like complete overkill).

Specifically, I like the ini modlets because they are the same format as the thing that's being modded. It's very clear to see what change is being made, as it's all in the same format. I can't see any benefit of switching to scripting, and if we did then surely all inis should be replaced with scripts, and as a scripter even I think that's a bad idea.

[Emdek]

aubergine, this is why I've said that those should be exported by stats editor, not written by hand.
Anyway, as I mentioned earlier, in less clean case we could have such API and support for overriding using raw files.
Also stats are in form of INI now, but was it finally decided what will be final format for them?

[aubergine]

So, just as you are mad Qt evangelist, I'm a mad JS evangelist. I think everything should be done in JS and JSON, and anything else is just plain ugly...

But I have to say I adore the .ini format. I used to hate it on Windows, but in WZ it makes the stats very clean and easy to read.

The ini files are like a menu provided by a proud restaurant owner to customers.

"Oh, I'll have a Viper with VTOL propulsion and a side order of HEAP bombs please" ... "Certainly Sir, would you like Damage upgrades with that?"

There's more than just the tech aspect to it. There's the aesthetic and usability aspect. The ini format, compared to anything else, is very clean and easy for anyone to read. To me it just seems to be a great way to store information about stats, the form matches the function. The ini file isn't about code, it's about simplistic presentation of data.

I would like to see the ini's exposed to JS environment as objects (or functions to let us read ini files so we can make our own objects would be even nicer). And it would be nice to be able to make little modlets using script as well. But for deploying modlets in an addon, I really think .ini is a very nice format.

[Per]

Now that I've had some time to think about it, I must say I really like the ini diff idea. Not because it makes multiple mods easier, but because it makes it harder for mods generally to break when things change. The override entire files design is quite brittle to changes in the base game, while mods using ini diffs would be far more resilient to changes to the underlying base data.

[Goth Zagog-Thou]

I agree with the above. This will make it FAR easier to write a campaign for, and editing stats (currently I do this manually) would be FAR less of a headache.

This in conjunction with "chain-loading" (being able to specify a mod loading order) along with custom search paths would really make my life easier.

[aubergine]

Here's another thing we could do...

Imagine if there was an ini that described all the texpages (textures) used in the game. Example:

Code: Select all

[arizona-sky]
file = texpages/page-25-sky-arizona.png
type = SKY
keywords = arizona, sky, orange, red, clouds, skybox, desert
description = A sky suitable for use in desert locations such as Arizona, USA
...etc...

And then there could be an ini for each of the key texture sets (arizona, urban, rockies, volcanic, etc).

Modlets could be used to easily add or change textures on a very granular basis = ability to have unlimited numbers of textures, and unlimited texture sets.

And, with each texture now having a bunch of descriptive metadata, if we moved the map editor in to WZ, you could for example use chat interface to do a search/filter on textures, with the resulting matches being shown in the texture palette. JS API would obviously need the ability to interact with ini files (or at least the data objects they generate within C++ code).

[NoQ]

Now that I've had some time to think about it, I must say I really like the ini diff idea. Not because it makes multiple mods easier, but because it makes it harder for mods generally to break when things change. The override entire files design is quite brittle to changes in the base game, while mods using ini diffs would be far more resilient to changes to the underlying base data.

Now that I've had some time to think about it, I must say I really like the Emdek's idea of doing the same thing shorter and more flexibly (: But i have no idea how to implement that (until we're exposing all stats to scripts in an rw mode ... don't know if it's difficult or easy).

[Originway]

Now that I've had some time to think about it, I must say I really like the ini diff idea. Not because it makes multiple mods easier, but because it makes it harder for mods generally to break when things change. The override entire files design is quite brittle to changes in the base game, while mods using ini diffs would be far more resilient to changes to the underlying base data.

just how would we use this?

[aubergine]

Now that I've had some time to think about it, I must say I really like the Emdek's idea of doing the same thing shorter and more flexibly (: But i have no idea how to implement that (until we're exposing all stats to scripts in an rw mode ... don't know if it's difficult or easy).

I prefer the .ini format for modlets, at least then you can see just by looking at filenames what sort of stuff is being modletted, and when you open the files their contents will be widely understood (and documented once I get round to it).

If we start using scripting for modlets, it's going to make everything more opaque. When it comes to modding, transparency/clarity is important IMHO.

[Emdek]

aubergine, and with constants (which should be also cheaper for environment, since they are simple numbers) you can also quickly see which groups are changed.
transparency/clarity is important but consistency, flexibility and performance also.
Also I've mentioned possibility to have both solutions (with simple INI overriding you cannot achieve dynamic values at all) and fact that JS could be generated by stats editor from those INI files (it is possible to turn them back into INI but loosing expressions for values, unless those would be implemented in parser...).

[aubergine]

Expressions are cool, but often too rarely used. CSS has certain expressions that can be used, but they are hardly ever used and for the amount of complexity they add it just doesn't seem worth it.

IMHO when you start needing to add expressions to moddable condig, you either need to be doing it 100% in script (ie. ditch config completely) or it's an indication of a design flaw in the nature of the config files.

[Emdek]

aubergine, about which expressions in CSS you are talking? IE proprietary mess or that new specification not yet supported outside (AFAIK) WebKit?
Expressions are usable if we want modify existing values instead simply overwriting them, basically they would be enabled to cooperate with chain loading multiple mods (in specified order) etc. Perfect use scope for mutators, modify instead of replacing.

[aubergine]

I've tried both formats, and IMHO while they can be useful they are a lot of extra work for little gain in most cases. With HTML, you it's better to use JS if you want to do expressions and keep the CSS clean.

I think something similar should be done with WZ. Keep the ini file stuff simple and basic, it will suffice for most needs. But also have something in the JS API for power-modders who might want to go the extra mile. I think most modlets will still be done via ini files because it will be much simpler and cleaner way to do it. Then there might be some special js modlet (eg. our mutator discussions) that could be applied for fringe cases the ini can't handle. In fact, we could have .js of same name as ini. So say you want to do a modlet for body.ini, you'd do most of it with a body.ini in the modlets/ folder. But there might be some very specific thing, and you'd also put a body.js in that folder to do those more tricky bits?

The main place where JS modlets would be useful that I am currently aware of is in scenarios where there are numbered sections, like in my proposed <campaign>.ini format. You'd want your modlet to ensure it adds a new section, even if there are other modlets also adding new sections (you couldn't have the modlets all assuming that they are the only modlet). I imagine the js modlet would need access to the original files (eg. <campaign>.ini) to read values from them, then access to the .ini modlet it's associated with so it can update it before it gets applied? Not sure, sounds crufty. How would you see it working?

[Emdek]

I think something similar should be done with WZ. Keep the ini file stuff simple and basic, it will suffice for most needs. But also have something in the JS API for power-modders who might want to go the extra mile.

I'm fine with that approach, I've described it at least once already.
But I'm against body.js etc., those should be defined in single file (but maybe letting modder to specify them in additional files included from main one), and only single file should be required by engine.

I imagine the js modlet would need access to the original files (eg. <campaign>.ini) to read values from them, then access to the .ini modlet it's associated with so it can update it before it gets applied? Not sure, sounds crufty. How would you see it working?

In case of campaigns I would disallow modifying sections of campaign.ini by scripts, those should be only data for JS, read only data, which could be used only to fuel JS based logic, nothing more. For other use cases global and session storage would be more suitable.
Also currently we don't have any mods for campaigns leveraging JS, we don't even have campaign ported to JS. It's too early to made decisions, but of course we can discuss it.