Author Topic: [DONE] Added more options how rulesets can be overridden  (Read 6850 times)

Offline Yankes

  • Commander
  • *****
  • Posts: 3323
    • View Profile
[DONE] Added more options how rulesets can be overridden
« on: March 09, 2023, 12:49:08 pm »
I pushed yesterday a couple of changes in OXCE 7.8.10:

  • Added `update:`, `override:` and `new:` to old list of `type:` (or `name:` for some) or `delete:` special properties in ruleset that define how handle rulesets,
    Supported rulesets can be check by `!info` tag on main node like (`ufos: !info`)
  • Fix some bugs/quirks in loading rulesets (mostly in case of `refNode:`)
  • Added `ignore:`, more info here: https://openxcom.org/forum/index.php?topic=10233.msg161899#msg161899
« Last Edit: September 22, 2024, 11:06:50 am by Meridian »

Offline Yankes

  • Commander
  • *****
  • Posts: 3323
    • View Profile
Re: Added more options how rulesets can be overridden
« Reply #1 on: March 25, 2023, 12:33:39 am »
I will make breaking change with my recent addition of `update:` and `override:`, I forget what sematic was of it in
scripts and new implemented was complete different for this two names compared to script version.
As some thoughts I see that script version was superior, because of this I revert this new rule behavior and make it work same as
did for scripts.
This mean:
  `override:` - throw a error when rule of given name is missing
  `update:` - only log waring in logs if old rule was missing and skip current rule

If old rule did exists both work same as `type:`. If someone manage to use old `override:` before this change,
he can easy recreate it by two rules `delete:` and `new:`.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
Re: [DONE] Added more options how rulesets can be overridden
« Reply #2 on: March 29, 2023, 10:18:45 am »
extracted into a separate thread

Offline 0xEBJC

  • Colonel
  • ****
  • Posts: 180
  • Y'all are awesome! Thankful for this community.
    • View Profile
    • My Projects
Re: Added more options how rulesets can be overridden
« Reply #3 on: December 18, 2023, 04:54:28 pm »
I will make breaking change with my recent addition of `update:` and `override:`, I forget what sematic was of it in
scripts and new implemented was complete different for this two names compared to script version.
As some thoughts I see that script version was superior, because of this I revert this new rule behavior and make it work same as
did for scripts.
This mean:
  `override:` - throw a error when rule of given name is missing
  `update:` - only log waring in logs if old rule was missing and skip current rule

If old rule did exists both work same as `type:`. If someone manage to use old `override:` before this change,
he can easy recreate it by two rules `delete:` and `new:`.


Yankes

Thanks this is great. 

I'm reviewing mod implementations from mature mods like X-Com Files and I am also looking at the documentation here to get a good understanding on how to implement myself:
"https://www.ufopaedia.org/index.php/Ruleset_Reference_Nightly_(OpenXcom)"



I have a three question about how these rules work

1.) Is 'type' deprecated? Going forward should I update all my mod .rul files to remove 'type' and change to 'new'?

2.) For 'override' and 'update' is my understanding correct that it will only 'update' or 'override' the specific values and 'inherit' all the other values?

for example
Code: [Select]
#base mod:
 items:
  - new: STR_SNUBNOSE_PISTOL
    size: 0.1
    costBuy: 900
    costSell: 400
    ...
    compatibleAmmo:
      - STR_SNUBNOSE_PISTOL_CLIP
    accuracyCloseQuarters: 145
    accuracySnap: 70
    accuracyAimed: 80
    ...

Then in a different mod modify the STR_SNUBNOSE_PISTOL like the following. Will the changed item's values keep all it's other properties from initial declaration?

Code: [Select]
items:
  - override: STR_SNUBNOSE_PISTOL
    accuracySnap: 70
    accuracyAimed: 85


3.) If there was an item / armor I wanted to override from another mod create a new &'address' I could *'point' to then make some change, would the following work appropriately?

Code: [Select]
armor:
  - override: STR_JUMP_ARMOR_UC
    builtInWeapons: &JetPackBBackPack
      - INV_NULL_1X3
      - INV_NULL_4X1
      - INV_JETPACK_B_3X3



  - override: STR_JUMP_ARMOR_INFERNAL_UC
    builtInWeapons: *JetPackBBackPack



  - update: STR_JUMP_ARMOR_INFERNAL_UC
    builtInWeapons: !add
      - INV_JETPACK_A_3X3


  - update: STR_JUMP_ARMOR_INFERNAL_UC
    builtInWeapons: !remove
      - INV_JETPACK_B_3X3



 #now `STR_JUMP_ARMOR_INFERNAL_UC` will have builtInWeapons equal to `[INV_NULL_1X3, INV_NULL_4X1, INV_JETPACK_A_3X3]`


« Last Edit: December 19, 2023, 02:20:08 am by 0xEBJC »

Offline 0xEBJC

  • Colonel
  • ****
  • Posts: 180
  • Y'all are awesome! Thankful for this community.
    • View Profile
    • My Projects
Re: [DONE] Added more options how rulesets can be overridden
« Reply #4 on: December 18, 2023, 05:12:37 pm »
Is there a function like 'override' and 'update' that could duplicate / 'inherit' another entry?

I have an armor defined with many lines of properties and I want a duplicate armor with only a minor change for another specific unit type, instead of manually having a copy of the entire armor definition, is there a way to 'inherit' the previous armor definition with minimal manual entry changes.

For example:
Code: [Select]
armor:
  - new: NEW_ARMOR_ONE
    ....
    ....
    many properties
    ....
    ....
    visibilityAtDark: 14
    ....
    ....
    ....
    builtInWeapons:
      - INV_JETPACK_A_3X3



Code: [Select]
  - new: NEW_ARMOR_TWO !inherit NEW_ARMOR_ONE
    builtInWeapons:
      - INV_JETPACK_B_3X3



Code: [Select]
  - new: NEW_ARMOR_THREE !inherit NEW_ARMOR_TWO
    visibilityAtDark: 18


Then Armor 2 would be a duplicate of Armor 1 with only the Jetpack B vs Jetpack A, and then Armor 3 would be a duplicate of Armor 2 so Armor 3 would have all the properties of Armor 1 and 2 with the updates to have Jetpack B and visibilityAtDark: 18


I am reviewing X-Com Files mod and Solarius Scorch, he has done a great job but there is so much manual duplication of items just for little changes to variations.  It make it's really hard to spot errors, make updates, and a lot of work to make a submod with minor tweaks.

If there isn't an 'inherit' function for entries, I would highly recommend it.  I think this would greatly help clean up .rul files and minimize redundancy.

Offline Yankes

  • Commander
  • *****
  • Posts: 3323
    • View Profile
Re: [DONE] Added more options how rulesets can be overridden
« Reply #5 on: December 18, 2023, 06:06:13 pm »
`override` and `update` work same way as `type`, only difference is when some previous loaded mod do not define given rule.

`update` if for updating optional ruleset, like when some sub mod is optional and you want integrate with it with your mod.
example would be adding script tags or new ammo to existing weapon, and one weapon from sub mod is not preset,
your mod should still load correctly (aside of some warnings).

`override` is for required ruleset, like form base mod and if it do not exists your mod make no sense any more,
like mod that improve specific weapon, it do not have sense if base mod remove given weapon.

`type` (and other similar)  will stay as is, to many mods use it to make it obsolete. But good taste would be make your intend
explicit in new mods by using `new`, `override` and `update`.


for new `inherit`, there is no clear way with properties should be copied and with not, there is already one case when you
copy specific research game should fail to load as one property should be globally unique.
not mention requirement for loots of new code to handle of copying rule objects.

beside in many cases you can workaround this problem using `refNode:` that allow textual coping of yaml node with your rules inside one file.

Offline 0xEBJC

  • Colonel
  • ****
  • Posts: 180
  • Y'all are awesome! Thankful for this community.
    • View Profile
    • My Projects
Re: [DONE] Added more options how rulesets can be overridden
« Reply #6 on: December 19, 2023, 04:07:32 am »
Thank you for all the clarifications, I'll dig through the mods and forms regarding examples for using the `refNode:`





I was trying to use the `!info`  from the wiki documentation, but not sure how to get that info back?

items: !info                # this tag can be used to check if a given ruleset supports the new features

I created a test mod entry and add `!info` to it, but wan't sure if I needed to look at some logs or something else?  The load screen didn't show me anything either.

I was trying to get the `!info` for an armor sub property `builtInWeapons:` as I tried the following:

Code: [Select]
armors:
  ...
  ...

  - override: STR_THE_THING_DOG_ARMOR
    builtInWeapons: *noInventoryExceptHands
  - update: STR_THE_THING_DOG_ARMOR
    builtInWeapons: !add
      - STR_DOGE_BARK
      - STR_DOGE_BITE

and got the following error on mod load for tagging builtInWeapons with `!add`  Error for `STR_THE_THING_DOG_ARMOR`: unsupported node tag `!add` at line...


Offline Yankes

  • Commander
  • *****
  • Posts: 3323
    • View Profile
Re: [DONE] Added more options how rulesets can be overridden
« Reply #7 on: December 19, 2023, 11:55:34 am »
`!info` dump data into logs, and remember not all places support it. If you do not see anything in logs then its mean is old property that do not support `!add` or any other tag that change how yaml node is handled.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 9047
    • View Profile
Re: [DONE] Added more options how rulesets can be overridden
« Reply #8 on: September 22, 2024, 11:04:55 am »
FYI, ruleset validator was updated today to support these attributes.
Newest version is 0.9.34
Please report if something broke or doesn't work.

Offline CrazedHarpooner

  • Captain
  • ***
  • Posts: 97
    • View Profile
Re: [DONE] Added more options how rulesets can be overridden
« Reply #9 on: September 22, 2024, 06:52:09 pm »
Ah nice, updated and hundreds of "property XXX is not allowed" vanished. No issues so far, but will keep an eye out to spot if anything's off.