1
OXCE Support / Re: Modding collections (lists, maps).
« Last post by Yankes on March 31, 2023, 08:07:36 pm »Well, let's for the sake of discussion assume that a solution at the YAML level is not being considered. In YAML, it's possible to parse multiple data buffers and to merge them. The tooling for that is not a part of a YAML specifications.
If we treat the config as just data, then we in the end have a set of definitions that are processed in the second step. The merging occurs in that step, whence definitions from sub-mods are applied. At this step, all config data is already parsed, and we have available to us a set of unmerged configuration definitions. The definitions then need to be applied in descending order to the main configuration. The definitions thus may refer to whatever was previously defined. The way this reference is achieved is not through the YAML constructs, but through the reference (e.g. a field, without any special meaning in YAML, called "inheritFrom", which contains an id of the parent definition).
Do we discuss OXCE or some theoretical data processing? I here to answer question for former not latter.
If you want simplified model how OXCE work I can provide it:
We start with yaml file:
Code: [Select]
fooA: "X"
fooB: "Z"
fooC: 123
And you have struct in code:Code: [Select]
strict Data
{
std::string fooA;
std::string fooB;
int fooC;
};
Then loading is function that is called for each loaded yaml file:Code: [Select]
void load(Data& d, const YamlFile& f)
{
if (f["fooA"]) d.fooA = f["fooA"].as<std::string>();
if (f["fooB"]) d.fooB = f["fooB"].as<std::string>();
if (f["fooC"]) d.fooC = f["fooC"].as<int>();
}
And there is nearly noting aside from that. With this you can understand most of OXC or OXCE loading of rulesets.
Again, if you want have copy of some item from master mod you need manually copy it yourself. I do not plan add any functionality that would allow copy existing rule objects under different name.
Please allow me to note that the specific problem that I'm trying to solve is a very practical one, and it is about extending master mods, and actually any other mods, in a way that eliminates the bulk of the maintenance burden. I'm working out a solution within the current implementation constraints.
Anywhere a copy-pasting at the level of writing mod files is involved, we get a source of bugs and maintenance burdens.