"Core" ‒ Total Conversion & Mod Support

[fabi]

Following the advice in an old feature request #8832 [Gna.org] from Zookeeper support for
"add-ons which need to acquire the full control over the wml tree" entered Wesnoth.

I called the add-on type "core".
A core just replaces the entry point for loading the wml tree.

This way everything WML (or lua) controllable (with exception of the gui2 wml config files) can be customized.

To avoid configuration breakage a core only loads add-ons which are specified to work with the core in question.

Here is a screenshot of the "Load Core" dialog.
It shows a user switching from the currently loaded "Combat Shore" core to Wesnoth's default content.

The core selection dialog

[Pentarctagon]

What does "replaces the entry point for loading the wml tree" mean?

[fabi]

Hmmmm,

That is not easy to say.

If you start earlier (< 1.13) Wesnoth versions they use the data/_main.cfg as the start of all the mainline wml loading.
Since a few days (1.13+) the "core"-type add-on is able to define a different start point for loading the basic data, one that can live in the user's add-on folder.

Thus it is now possible to use the Wesnoth engine and deliver a completely different game (our engine is very versatile) over the add-on server.

Please feel free to ask more detailed specific questions.

[Pentarctagon]

Hmmmm,

That is not easy to say.

If you start earlier (< 1.13) Wesnoth versions they use the data/_main.cfg as the start of all the mainline wml loading.
Since a few days (1.13+) the "core"-type add-on is able to define a different start point for loading the basic data, one that can live in the user's add-on folder.

Thus it is now possible to use the Wesnoth engine and deliver a completely different game (our engine is very versatile) over the add-on server.

Please feel free to ask more detailed specific questions.

Where are the file(s) for the three current core mods?

[doofus-01]

Please feel free to ask more detailed specific questions.

This looks like it could be cool, but I'm also not sure what you are saying...

This is like a super-Theme, that will let UMC overwrite the title-screen image, the help files (<-would be real nice BTW, if that could be done dynamically), and ... what else?

The terrrain-graphics and animation engines (if they aren't the same thing, what do I know) are indeed much more powerful than is taken advantage of. The image data is probably more of a problem though.

[fabi]

Where are the file(s) for the three current core mods?

https://github.com/wesnoth/wesnoth/blob ... /_main.cfg

[Pentarctagon]

Where are the file(s) for the three current core mods?

https://github.com/wesnoth/wesnoth/blob ... /_main.cfg

How is the coremod that forbids add-ons doing that? It has the same start path as the default coremod.

Also, is it possible to forbid/replace specific files? Or does any coremod have to fully replace the entire core of wesnoth?

[fabi]

How is the coremod that forbids add-ons doing that? It has the same start path as the default coremod.

The "failsafe" core has a different id.
Every addon specifies a core it is designed to run with.
Only those matching the current active core are loaded.

This is a very simple solution.
I am thinking about a more versatile one which should allow to specify compatible cores which replace for example the default Wesnoth one but work with the replaced core's add-ons.

Also, is it possible to forbid/replace specific files? Or does any coremod have to fully replace the entire core of wesnoth?

The core can load any of the mainline cfg files.

This is like a super-Theme, that will let UMC overwrite the title-screen image, the help files (<-would be real nice BTW, if that could be done dynamically), and ... what else?

The ai, lua files (overwriting action wml), terrain, units, macros, themes...

[doofus-01]

This is like a super-Theme, that will let UMC overwrite the title-screen image, the help files (<-would be real nice BTW, if that could be done dynamically), and ... what else?

The ai, lua files (overwriting action wml), terrain, units, macros, themes...

Right, well, that doesn't explain much. UMC can already make terrain, units, etc. and completely avoid using mainline instances.

If you don't wish to explain this, that's certainly your right, but then what is the point of this thread?

[fabi]

Right, well, that doesn't explain much. UMC can already make terrain, units, etc. and completely avoid using mainline instances.

If you don't wish to explain this, that's certainly your right, but then what is the point of this thread?

Let me give you an example maybe that makes things more understandable.

Everything CombatShore provides could easily be implemented as conventional add-ons.
Well, with some exceptions but those are mostly minor issues, no deal breaker discovered so far.

But is a solution relying on non core add-ons very user and (maybe more important) developer friendly?
CS uses a different set of base terrains (deep water, water, shallow water, very shallow water, mountains, high mountains, morass, road, railway, runway...).
A UMC Designer creating a map in the editor would need to avoid the Wesnoth terrains and only use new ones instead.
This can be done by creating more editor groups but the result is a pretty crowded terrain group menu for the editor's palette while the "all" section is
pretty much useless.
The same is true for the units.

If you start the editor with the CS core loaded, there are only terrains available which are working in the CS context.
All former Wesnoth units are missing, which is a fine thing in my opinion, the elves and orcs don't really fit between the tanks and planes of CS.
This will also be true regarding the placeable [icon]s, the music tracks, maybe the TODs and more I don't think about yet.

The player will only see descriptions of CS units and terrains in the help browser, which includes also the corresponding races, factions, traits, abilities and weapon specials.

A UMC Designer can't accidentally use a Wesnoth macro (or action wml tag) which might not work properly in the CS environment.

I should also mention that it allows me to overwrite core macros and action wml tags without harming the rest of Wesnoth.

This example only covers the "total conversion" use case but I hope it was detailed enough to communicate the idea.

[AI]

Right, well, that doesn't explain much. UMC can already make terrain, units, etc. and completely avoid using mainline instances.

If you don't wish to explain this, that's certainly your right, but then what is the point of this thread?

Let me point you to GameConfigWML.

[doofus-01]

OK, fabi, I think I see where you're coming from now. The "core concept" isn't really focused on expanding capabilities directly (though there are a couple of cases where it does), it's more about clearing out standard mainline stuff for the cases where it would be useless clutter, and to provide a more convenient access to some existing capabilities.

Thanks for the explanation.

[fabi]

OK, fabi, I think I see where you're coming from now. The "core concept" isn't really focused on expanding capabilities directly (though there are a couple of cases where it does), it's more about clearing out standard mainline stuff for the cases where it would be useless clutter, and to provide a more convenient access to some existing capabilities.

Yes, you nailed it down to the point, regarding the total conversion use case.

Another use case is a mod that wants to allow SP campaigns to be played with altered gameplay without the need to modify each of them separately.
This is also already possible to some degree but lacks a proper way to turn the thing on and off without deinstalling/reinstalling the modding add-on.

Thanks for the explanation.

You are welcome.

[Pentarctagon]

What do I put in the "path" key in order to load everything in default plus something else? Also, how does an add-on specify it's a coremod?

[fabi]

What do I put in the "path" key in order to load everything in default plus something else?

Sorry for answering that late.

You use the file-path to your toplevel file (mostly called "_main.cfg") in the same syntax like it is used for wml inclusions.
Then, in your file you use the inclusion syntax and include just the Wesnoth core's data/_main.cfg.
After that inclusion you include your own stuff.

Also, how does an add-on specify it's a coremod?

What exactly do you mean by "coremod"?
A core that provides everything to be compatible with Wesnoth's add-ons?