Features and patches for 0 A.D.

This page tracks changes to the core that can enhance the modability or advance in the development of 0 A.D. in general. It excludes all balance/values tweakings as they are implemented with a global scheme and won't make any sense to try them one by one.

Once patches or suggestions are ready, a ticket will be opened for discussion with the team.

Build restrictions and territories

Allow multiple build restrictions

State: It works for me but with some bugs. The patch will probably be a starting point for a more complete patch.

This patch is used to allow a building to have multiple distance restrictions from other buildings.

Ticket 3592

The restriction is not bidirectional, it is still possible to build something in an incorrect place if it was there before building the one that make the place incorrect.

Territory level

State: Hacky feature to provide in an elegant way. Pre-implementation phase.

The contryside feature adds restrictions in a hacky way to be able to build city facilities only near a civil center. It would be much more elegant to have multiple territory levels, like CC casting level 2 (City), houses casting level 1 (village) and temples being buildable only on level 2 territory (inside the city).

Requires some thoughts, implementation suggestion and a kind of roadmap to make some clear patches.


Formation bonuses

State: Implemented in a simple way in experimental1 branch, allowing units to get some bonuses when in formations (like an armor bonus in closed line)

The formation feature will have it's own concept page before going somewhere seriously.

Formation orders

State: Expectations. Just not to forget.

Using formations sometime messes up with the order queue, making units not doing what they are expected to do (like trying to fight in formation after being ordered to dismiss and run berserk).

Requires more debugging.


Infinite farms

State: Expectations, just not to forget one day.

The decreasing productivity of farms is unflexible and cannot be applied on other resources (hardcoded to a limit of 5 or something like that).

There could be something to fix, or find an other solution for the everlasting farming issue (list of tickets on this topic required before suggesting anything).

Game engine

Extend a template from an other mod

State: thinking about side effects, constraints and a correct way to handle this.

Ticket 4076. The goal is to add a feature to edit only a little part of a template for a mod, instead of copying it entirely and keeping track of every little change from the original file.


  • You cannot change the parent, as it would require to rebuild entirely the original template. This means the mod cannot add a layer in inheritance.
  • The extension template cannot extend multiple templates.
  • Parent templates must be fully extended before children can inherit from them.
  • It could be possible for multiple mods to extends the same main template, extension is done from the main template to the latest mod in the enabled list.
  • A file with a given name can be loaded only once, priority is given to the last mod in list down to the public mod.

Note: the relative template values (like attack + 2, HP + 10) works with inheritance, not template overwriting.

The weird case of multi-extension

A template may be extended by multiple mods. For example a balance mod may change armor and attack values while a voice mod may change sounds. Both are completely viable without conflicts and should be included.

But what about a conflict, especially when a relative value is given? In case of a conflict, the first extension should be kept (mod with the highest priority) but the basic value is found in the lower priority (public reference).

If applying extensions from the lower priority to the highest, the latest value is kept but in case of relative value all values may be summed up (which may in most case not make any sense anyway). Conflicts may then, at first, be considered as nonsense and keep the relative addition as an hidden feature.


Add an attribute in root element to load the same file from a lower priority mod

Add an attribute to the root element like it is done for replace=“” or delete=“” to indicate to seek for the original file in a lower priority mod and extend it.

Files are loaded by priority, there is only one file with a given name which is loaded. This is true for all mod files and not only templates. Thus loading a file with the same name would require to parse it at loading time to check if the lower priority file should be loaded too instead of being discarded.

Add a suffix to a file to suggest extension

Add an .EXTENDS (or anything else) suffix to a file like for the .DELETED suffix for the loader to add multiple files. The parser would require to check for extensions before loading the actual template.

This allows only one .EXTENDS file, so multiple mods with an the same extension won't load everything, even if there are no conflicts in extension.

Add a new template file that references the original with only extensions inside

Add a new template file that includes either as its root element or an attribute extends=“original_template_name” to indicate that the content should be merged in the referenced template.

When loading the file, it edits the referenced template (that should already be parsed) to change only the values defined in the extension template. Multiple mods can extends the same original template, but that may lead to conflicts (priority is set at file level for overwriting files with the same name, not for file to file comparison).

  • How to handle priority for multiple mods or even multiple extensions in the same mod. It also requires for children templates that the parent is extended before inheriting (use a special template name to parse them first?). Adding priority to each value seems an overkill and is completely arbitrary to harmonize values between mods (and makes everything a big mess).
  • Because there are no way from a given template to say if an other file extends it, the parser will require to check for extension for each template before parsing it, which will lead to lower performance. An extension list file can gather them all in one place but looks inelegant and is prone to human errors.

There could be a lot of ways to identify a file as an extension for an other one.

  • Nothing: each file is parsed to check for extensions. This may be time consuming but eludes most of human errors.
  • Special name: like adding .EXTENDS on a file without other name requirement. So that all .EXTENDS can be parsed first to build a loading tree for the templates. There are no reason to add the mark to a modder point of view so it can easily lead to human errors.
Use an extension list file

This is a completely different approach. Instead of extending a given file, some components are defined to be included in regular templates.

An extension file list indicate which file should be applied which component. So a component may be used for multiple templates. Even if in most of the cases inheritance negates the need for duplication.

Each mod has this extension list so it is easy to know which templates are to be extended and in which order.

This is very flexible but may be used in some case like inheritance. This was discussed previously as potentially adding a big mess if not used correctly (for example it could be forbidden in public).

Using an external tool

The main reason for extensions is to keep track of the constant and rapid evolution of the main game, which will settle down once released.

We may consider that once that stable state is reached, the extension feature will have only a little importance and could even add unworthy complexity.

The use of an external program that would generate the full template from a referenced mod with some modification could do the trick as long as the referenced pattern is modified heavily. The game engine isn't touched at all so no bugs are included and there's still an easy way to make tweaks with some official or unofficial moder tools.

Files to check

  • ps/TemplateLoader.cpp → handles inheritance
  • ps/GameSetup/GameSetup.cpp → handle mounting mods in a virtual file system with priorities (see GetMods, MountMods)
  • lib/file/vfs/vfs.h → defines some flag used for file loading
  • lib/file/vfs/vfs_populate.cpp → actually handles the loading, with the .DELETED case

I do not guaranty all of the following things are correct.

Mounting is done in InitVfs, GetMods add the public mod automatically when required. Loading is done from the most precise (mod) to the most generic (public), so in reverse order than the mod list in Mods Selector.

TODO: check vfs mounting flags, priority as well as in game directory and user directory. VFS flags defined with doc in lib/file/vfs/vfs.h.

TODO: check the loading order with the .DELETED case (which cannot delete a file that is not already loaded…)

0adsv/merge.txt · Last modified: 2017/07/11 11:49 (external edit)
Recent changes RSS feed CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki