RFC: Modular system for mods

[agris]

This project reminds of the ubiquitous WeiDU mod tool for the Infinity Engine games (Baldur's Gate, etc). http://weidu.org/WeiDU/README-WeiDU.html#htoc1

I have a question: I know that higher priority mods overwrite lower priority ones if they have the same values, but how does it deal with two mods modifying Researches.AleniumExplosives? Mod A adds UnlockKnowledge("Researches.ExampleA") while Mod B adds UnlockKnowledge("Researches.ExampleB"). Would it add both of these or overwrite one of them?

I wonder if this could be solved by the mod author specifying that RFC should "extend" the attribute (either at the beginning or end), vs. replace. Some command that give finer control over how the patch data should interact with existing data. Or the ability to input specifically what strings are to be overwritten, doing a string compare and, if true, override the string.

[llunak]

Preview of what the mod system will be like in 0.26 . It's 0.25HF only with mod system changes/fixes.

[ATTACH]5012[/ATTACH]

If there's still something that cannot be modded using this version, I'd like to know.

Exceptions:

- .lua scripts

- ufocontents/

- AM_*.xml

(the last two I still intend to change for actual 0.26 release)

/*

How merging of XML spreadsheets works (for modding):

First row is header, it must match.

First column is identifier of each item (i.e. row).

For each row from a merged XML spreadsheet:

- if the item doesn't exist yet, it is appended

- if the item already existed

- if the item has all columns except for identifier empty, the item is removed (even if it previously existed)

- if the item has all columns non-empty, the item is replaced

- if the item has some columns empty, the item is updated - empty columns will keep previous values

- if a column has value prefixed with MODMERGEAPPEND: , it will cause the value to have the prefixed text appended

(this is meant e.g. for "When finished" column of researches.xml)

*/

/*

How merging of XML documents works (for modding):

- if an element has a special attribute MODMERGEATTRIBUTE, this attribute specifies the name of attribute

that will be used for matching, i.e. elements match if their names match and values

for the given attribute match (this is for merging e.g. <Weapon name="weapon"...> elements in weapons_gc.xml),

if the attribute does not exist, two elements match if their names match

- if an element has a special attribute MODMERGEATTRIBUTESET, when updating element's attributes while merging,

this is the new value for the attribute specified by MODMERGEATTRIBUTE (which cannot have a new value

specified the usual way, because that would prevent matching)

- if an element has a special attribute MODMERGE, this attribute specifies how the element will be merged

with a possibly already existing matching element

- if the value is "insert", if there is no matching element, insert the element, it is an error if a matching

element already exists

- if the value is "replace", the already existing matching element is replaced by this element (including

all its children), it is an error if there's no or more than one element to replace

- if the value is "replaceifexists", an already existing matching element is replaced by this element (including

all its children) if it exists, otherwise nothing happens, it is an error if there are more than one elements

to replace

- if the value is "insertreplace", use "insert" if there is no matching element, otherwise use "replace"

- if the value is "delete", the already existing matching element is deleted if it exists, it is an error

if there are more than one element to delete

- if the value is "deleteall", all already existing matching elements are deleted, if they exist

- if the value is "update", it is an error if there are no or more than one matching elements, otherwise

update possible attribute values and (direct) content, descent one level down and repeat for all children

- if the value is "updateifexists", it is an error if there is more than one matching element, otherwise

nothing happens if there is no matching element, otherwise update possible attribute values and (direct)

content, descent one level down and repeat for all children

- if the value is "updateall", use "update" for all matching elements

- if an element has no MODMERGE attribute

- if a matching element doesn't exist yet, it is appended in the right place including all its child elements

- if an element has no children elements

- if there's already exactly one matching element, update attribute values and content (this is mainly

for simpler modding of files like gameconfig.xml)

- if there are already more matching elements, that is an error

- (the no-element-yet case is handled above)

- if an element has children elements but no attributes besides the internal MODMERGE* attributes (in this case

an already existing element can match even if it has attributes, this allows for easy updating of config

elements that have attributes, such as in moraleconfig_gc.xml)

- if there's already exactly one matching element, descend one level down and repeat

for all children

- if there are already more matching elements, that is an error

- (the no-element-yet case is handled above)

- otherwise it is an error (the element has both children and attributes and there already exists

an element with the same name - in this case it's not easy to say if the element should be

merged (which would be suitable for settings) or added or replaced (either of which could be suitable

e.g. for <Weapon> elements in weapons_gc.xml)

*/

Xenonauts-modspre026.zip

Xenonauts-modspre026.zip