Modding collections (lists, maps).

[Yankes]

Can you remind me what is point of this discussion? If you want some details or quirks of some properties in rulest read wiki.
Even if we describe some mathematical model how it work, you will find multiple exceptions and inconsistencies that will make every thing pointless.

Simple rule is:
If you want edit some property, you do:

Code: [Select]

propertyX: Y
where `Y` is value describe in ufopedia wiki as valid value, any thing else is Undefined Behavior (yes, same UB like in C++).

[zee_ra]

Can you remind me what is point of this discussion? If you want some details or quirks of some properties in rulest read wiki.
Even if we describe some mathematical model how it work, you will find multiple exceptions and inconsistencies that will make every thing pointless.

Simple rule is:
If you want edit some property, you do:

Code: [Select]

propertyX: Y
where `Y` is value describe in ufopedia wiki as valid value, any thing else is Undefined Behavior (yes, same UB like in C++).

The point of this discussion is editing existing configuration structures.

I think, the Ruleset Reference doesn't mention the interpretations of all desired properties.

Now, when considering undefined behaviour, what this means in practice, is that there exists a default value for many of the parameters that need to be considered (and they're there in the first place to be considered somewhere), if only that value lies in the code.

A practical solution for the current situation would be to describe what explicit defaults would work for at least a relevant (determined by modding experience) subset of parameters.

[zee_ra]

The point of this discussion is editing existing configuration structures.

I think, the Ruleset Reference doesn't mention the interpretations of all desired properties.

Now, when considering undefined behaviour, what this means in practice, is that there exists a default value for many of the parameters that need to be considered (and they're there in the first place to be considered somewhere), if only that value lies in the code.

A practical solution for the current situation would be to describe what explicit defaults would work for at least a relevant (determined by modding experience) subset of parameters.

I could eventually list all parameters that need further documentation of this nature.

For the time being, I would like to inquire how to make costBuy into a no-op.  The one unclear point to me is what would be the behaviour if costBuy = 0 and requiresBuy is populated?  I assume, whence the requiresBuy is not populated and costBuy = 0, the behaviour would be that the item is un-purchaseable, and must be acquired as either a trophy or by means of being manufactured.

Should a separate thread in modding subform (which would you suggest?) be started?

[Yankes]

I could eventually list all parameters that need further documentation of this nature.

For the time being, I would like to inquire how to make costBuy into a no-op.  The one unclear point to me is what would be the behaviour if costBuy = 0 and requiresBuy is populated?  I assume, whence the requiresBuy is not populated and costBuy = 0, the behaviour would be that the item is un-purchaseable, and must be acquired as either a trophy or by means of being manufactured.

Should a separate thread in modding subform (which would you suggest?) be started?

I think that your current mental model of ruleset OXC is so different to how OXC work that become unmatchable for me to anything in OXC.
What could even mean "no-op"? Especially in case of `costBuy`, this is simple numerical value, noting more, nothing less. If value is zero then item will not be available to buy. If you add some `requiresBuy` then it only can add to "not available", this mean both condition need be meet to have given item available to buy.

[zee_ra]

I think that your current mental model of ruleset OXC is so different to how OXC work that become unmatchable for me to anything in OXC.
What could even mean "no-op"? Especially in case of `costBuy`, this is simple numerical value, noting more, nothing less. If value is zero then item will not be available to buy. If you add some `requiresBuy` then it only can add to "not available", this mean both condition need be meet to have given item available to buy.

I see.  This matches my understanding.  It's a classical config file approach, and it seems that most values always exist, with well-defined defaults in case they're absent in the configuration.

The "no-op" means essentially a zero value, where zero is whatever makes sense in the context.  The "no-op" means that a value does not convey any properties to the object upon which it is applied.  If I moved by zero meters, then I did not move at all.  I assume, the analogy is rather obvious.

[zee_ra]

It's not inheritance, it's an automated copy-paste.

I will update the ruleset reference this weekend to be more precise.

It seems that I still need to import an anchor into my mode's namespace in order to enable the propagation of values.

Could you please have a look at the technique suggested below and ascertain its validity.

Code: [Select]

# In order to reference the large rocket definition in my mod,
# I actually need to create an anchor that refers to a parent
# definition
items:
  - &STR_LARGE_ROCKET
    override: STR_LARGE_ROCKET
# nothing is done to this definition
# the override there is merely as a means of importing the definition
# [...]
#
# Now I could take advantage of the definition through refNode.
  - &STR_GAS_ROCKET
    type: STR_GAS_ROCKET
    refNode: *STR_LARGE_ROCKET
# I could define whatever fields need to be defined.
# All the values that were populated in the parent mod large rocket definition
# would be pre-populated in this definition already.
# [...]
#

I also wonder, whether it makes a difference whether I use update: or override in the example above.

[Meridian]

It seems that I still need to import an anchor into my mode's namespace in order to enable the propagation of values.

yes

Could you please have a look at the technique suggested below and ascertain its validity.

it's invalid

I also wonder, whether it makes a difference whether I use update: or override in the example above.

since the example is invalid, this question is also invalid

but purely technically, it makes a technical difference, we don't have any reason to add 2 keywords doing exactly the same thing

[zee_ra]

it's invalid

since the example is invalid, this question is also invalid

but purely technically, it makes a technical difference, we don't have any reason to add 2 keywords doing exactly the same thing

Could you please suggest a solution to my original task of reusing definition from the parent mod?  Would the stub code above be sufficient for illustration?

[Meridian]

Currently, there is no solution.

OXCE does not support inheritance.
Most we can do is various forms of smart copypaste, within the scope of one single rul file.

You can change the definition from a parent mod.
You cannot reuse a definition from a parent mod to define something new.

[zee_ra]

Currently, there is no solution.

OXCE does not support inheritance.
Most we can do is various forms of smart copypaste, within the scope of one single rul file.

You can change the definition from a parent mod.
You cannot reuse a definition from a parent mod to define something new.

I basically need to copy data from the parent mod.  The binding time is at the instantiation of the data.  Clearly, the copying semantics is satisfactory.

I hope the use of terminology that is homonymous with that adopted by c++ does not convey the wrong idea.

You mentioned smart copying.  How could this be achieved?

[zee_ra]

Currently, there is no solution.

OXCE does not support inheritance.
Most we can do is various forms of smart copypaste, within the scope of one single rul file.

You can change the definition from a parent mod.
You cannot reuse a definition from a parent mod to define something new.

Could I create a copy of the item already available in a mod?

Why is my original technique invalid?  What happens when those definitions are applied?

[Yankes]

because two separate things, yaml file and rules in engine, data can only flow from yaml file to engine not in opposite way.
OXCE only support "coping" in yaml file as some nodes are duplicated in multiple places.
This duplication do not alow in any way to duplicate any thing that is in engine as this is different layer.

[zee_ra]

because two separate things, yaml file and rules in engine, data can only flow from yaml file to engine not in opposite way.
OXCE only support "coping" in yaml file as some nodes are duplicated in multiple places.
This duplication do not alow in any way to duplicate any thing that is in engine as this is different layer.

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).

---

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.

[Yankes]

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.

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.

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.

[zee_ra]

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.

So, the algorithm is as follows:

1. Read config at current point.
2. Apply config data directly to a global object.
3. Advance cursor in (1).  If cursor points to the end, terminate.


Is that what is happening in the OXCE?