31
Programming / Re: Upgrading to the nightly
« on: May 13, 2015, 05:03:56 am »
Here's a few ideas for implementing mod options without making it too complicated.
Mods could have an options.xml file (not required) that would look something like this:
This could later be expanded to allow for things like:
I would be in favor of the xml approach because it would be a lot easier for modders then YAML. But since OXC already uses so much YAML, another approach would be to incorporate the options into Metadata.yml. The descriptions would only be needed if there's no corresponding entries in a language file.
My final idea would be to allow options to be externalized from metadata.yml to options.rul or options.xml, and allow the exact same code as above, but also allow things like:
Keep in mind that with each of these suggestions modders are still able to have optional rulesets just like before using the grenade example. As a matter of making things easier for modders I personally would greatly prefer XML because it's not evil. XML does not sneak into a persons room at night to count and judge all your whitespace chars like some kind of anal-retentive nazi. XML also doesn't take sides in the bloody line-break war. XML hasn't chosen /n as its glorious standard and doesn't execute impure (/r or /n/r) line-breaks in the name of UNIX supremacy.
Mods could have an options.xml file (not required) that would look something like this:
Code: [Select]
/* Only one string */
<option "Include original grenade (don't replace)">Rulesets\KeepGrenade.rul</option>
/* or multi-language */
<option STR_KEEP_GRENADE>Rulesets\KeepGrenade.rul</option>
This could later be expanded to allow for things like:
Code: [Select]
<optiongroup "Hyperwave Decoder Options:">
<option "Hyperwave Decoder doesn't add any detection">NoDetect.rul</option>
<option "Hyperwave Decoder range is unlimited but only has 10% detection">InfiniteRange.rul</option>
<option "Same as Vanilla"></option>
</optiongroup>
I would be in favor of the xml approach because it would be a lot easier for modders then YAML. But since OXC already uses so much YAML, another approach would be to incorporate the options into Metadata.yml. The descriptions would only be needed if there's no corresponding entries in a language file.
Code: [Select]
Options:
- Name: STR_KEEP_GRENADE
Description: "Include original grenade (don't replace)"
Ruleset: KeepGrenade.rul
OptionGroups:
- Name: STR_HYPERWAVE_OPTIONS
Description: "Hyperwave Decoder Options:"
- Name: STR_NO_DETECT
Description: "Hyperwave Decoder doesn't add any detection"
Ruleset: NoDetect.rul
- Name: STR_INFINITE_RANGE
Description: "Hyperwave Decoder range is unlimited but only has 10% detection"
Ruleset: InfiniteRange.rul
- Name: VANILLA
Description: "Same as Vanilla"
Ruleset: []
My final idea would be to allow options to be externalized from metadata.yml to options.rul or options.xml, and allow the exact same code as above, but also allow things like:
Code: [Select]
facilities:
- type: STR_HYPER_WAVE_DECODER
hyper: STR_HYPER
radarRange: STR_RANGE
radarChance: STR_CHANCE
options:
- name: STR_HYPER
description: "Extra Hyperwave-info in radar screens:"
type: bool
default: true
- name: STR_RANGE
description: "Maximum Detection Range (1200 for whole globe):"
type: int
default: 12000
- name: STR_CHANCE
description: "Percent chance of detecting an undetected UFO each scan:"
type: int
range:
[0, 100]
default: 10
or with an options.xmlCode: [Select]
<rule>
facilities:
- type: STR_HYPER_WAVE_DECODER
hyper: <bool STR_HYPER>true</bool>
radarRange: <int STR_RANGE>1200</int>
radarChance: <int STR_CHANCE min=0 max=100>10</int>
</rule>
Keep in mind that with each of these suggestions modders are still able to have optional rulesets just like before using the grenade example. As a matter of making things easier for modders I personally would greatly prefer XML because it's not evil. XML does not sneak into a persons room at night to count and judge all your whitespace chars like some kind of anal-retentive nazi. XML also doesn't take sides in the bloody line-break war. XML hasn't chosen /n as its glorious standard and doesn't execute impure (/r or /n/r) line-breaks in the name of UNIX supremacy.