"Core" ‒ Total Conversion & Mod Support
Moderator: Forum Moderators
"Core" ‒ Total Conversion & Mod Support
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.
"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.
- Pentarctagon
- Project Manager
- Posts: 5563
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Support for Total Conversions and mods
What does "replaces the entry point for loading the wml tree" mean?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Support for Total Conversions and mods
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.
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
- Project Manager
- Posts: 5563
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Support for Total Conversions and mods
Where are the file(s) for the three current core mods?fabi wrote: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.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Support for Total Conversions and mods
This looks like it could be cool, but I'm also not sure what you are saying...fabi wrote:Please feel free to ask more detailed specific questions.
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.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Support for Total Conversions and mods
https://github.com/wesnoth/wesnoth/blob ... /_main.cfgPentarctagon wrote:Where are the file(s) for the three current core mods?
- Pentarctagon
- Project Manager
- Posts: 5563
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Support for Total Conversions and mods
How is the coremod that forbids add-ons doing that? It has the same start path as the default coremod.fabi wrote:https://github.com/wesnoth/wesnoth/blob ... /_main.cfgPentarctagon wrote:Where are the file(s) for the three current core mods?
Also, is it possible to forbid/replace specific files? Or does any coremod have to fully replace the entire core of wesnoth?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Support for Total Conversions and mods
The "failsafe" core has a different id.Pentarctagon wrote:How is the coremod that forbids add-ons doing that? It has the same start path as the default coremod.
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.
The core can load any of the mainline cfg files.Also, is it possible to forbid/replace specific files? Or does any coremod have to fully replace the entire core of wesnoth?
The ai, lua files (overwriting action wml), terrain, units, macros, themes...Doofus wrote: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?
Re: Support for Total Conversions and mods
Right, well, that doesn't explain much. UMC can already make terrain, units, etc. and completely avoid using mainline instances.fabi wrote:The ai, lua files (overwriting action wml), terrain, units, macros, themes...Doofus wrote: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?
If you don't wish to explain this, that's certainly your right, but then what is the point of this thread?
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Support for Total Conversions and mods
Let me give you an example maybe that makes things more understandable.Doofus wrote: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?
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.
Re: Support for Total Conversions and mods
Let me point you to GameConfigWML.doofus-01 wrote: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?
Re: Support for Total Conversions and mods
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.
Thanks for the explanation.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: Support for Total Conversions and mods
Yes, you nailed it down to the point, regarding the total conversion use case.doofus-01 wrote: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.
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.
You are welcome.Thanks for the explanation.
- Pentarctagon
- Project Manager
- Posts: 5563
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: Support for Total Conversions and mods
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?
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: Support for Total Conversions and mods
Sorry for answering that late.Pentarctagon wrote:What do I put in the "path" key in order to load everything in default plus something else?
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.
What exactly do you mean by "coremod"?Also, how does an add-on specify it's a coremod?
A core that provides everything to be compatible with Wesnoth's add-ons?