Author Topic: Dumb questions about modular Rulesets inheritance.  (Read 11679 times)

Offline wolfreal

  • Colonel
  • ****
  • Posts: 298
    • View Profile
Dumb questions about modular Rulesets inheritance.
« on: January 08, 2017, 11:47:37 am »
Hello.

I have what I think it could be a little dumb questions about the modular Ruleset mechanism. In particular, about research.

First: What is the difference between unlocks: and dependencies:. I understand one work upward in the dependence tree, and the other downward. but I´d like to have more details about each one.

Second:

Imagine the following Scenario. I have UFO1 Rulesets (Xcom1Ruleset), some large mod ruleset (Bm1Ruleset), and a little addon ruleset (laRuleset)

In this Scenario, "Bm1" make some important changes to the Xcom1 research tree (Like in hardmode expansion, FMP, etc), and "la" add a little item to the game. The load order is Xcom, Bm1 and la.

Let´s say "la" add a "ethereal cloak", and the idea is make it dependent of the personal armor and ethereal autopsy.

So, I have

Spoiler:
- name: STR_ETHEREAL_CLOAK
    cost: 3141592
    points: 271
    dependencies:
      - STR_PERSONAL_ARMOR
      - STR_ETHEREAL_AUTOPSY

 So, I want to unlock the research when the personal armor is investigated, so, I add this to the "la" ruleset

Spoiler:
- name: STR_PERSONAL_ARMOR
    unlocks:
      - STR_ETHEREAL_CLOAK


xcom1 and bm1 have an unlock item too, my question then is: when la ruleset is loaded, ¿this new unlocks override the other unlocks, or is added to the others?

I hope I made myself understand good enough. I have to said that I searched in the forum and the wiki and did not found anything that clear my doubts about this question. Thanks in advance.

Pd. Sorry for broken English.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8617
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #1 on: January 08, 2017, 12:12:02 pm »
The research-related ruleset unfortunately isn't very robust... dare I say even quite buggy.
It works 100% on vanilla ruleset, but if you try some combinations and/or some "creative usage"... it may work against common sense or just not work at all.
It's hard to describe "requires", "unlocks" and "dependencies" accurately, because of these shortcomings... but if you forget about those, the meaning is self-explanatory.

Good news is that this is the only remaining part of OpenXcom (that I am aware of) which is still considerably buggy.
Everything else is mature enough (as far as I can say).

As to your question:
my question then is: when la ruleset is loaded, ¿this new unlocks override the other unlocks, or is added to the others?

The "new unlocks" overrides the "old unlocks"... it is NOT added.

Offline Solarius Scorch

  • Global Moderator
  • Commander
  • *****
  • Posts: 11456
  • WE MUST DISSENT
    • View Profile
    • Nocturmal Productions modding studio website
Re: Dumb questions about modular Rulesets inheritance.
« Reply #2 on: January 08, 2017, 02:13:28 pm »
I don't understand the code like Meridian does, but I am an experienced modder and I recommend sticking to these rules:

1) In normal circumstances (where techs A, B and C are needed for tech D), always use "dependencies:" in the resulting tech:

Code: [Select]
  - name: STR_SECTOPOD_CONSTRUCTION
    cost: 600
    points: 50
    dependencies:
      - STR_SECTOPOD_CORPSE
      - STR_SECTOPOD_AUTOPSY
      - STR_ALIEN_ELECTRONICS

2) If you have several techs that all lead to one tech, but only one is necessary, use "unlocks:" in the prerequisite techs and "dependencies:" in the later tech:

Code: [Select]
  - name: STR_TANK_CORPSE
    unlocks:
      - STR_ADVANCED_AI

  - name: STR_BLACKOPS_SMARTGUN
    unlocks:
      - STR_ADVANCED_AI

  - name: STR_BLACKOPS_SMARTPISTOL
    unlocks:
      - STR_ADVANCED_AI

  - name: STR_BLACKOPS_SMARTRIFLE
    unlocks:
      - STR_ADVANCED_AI

  - name: STR_ADVANCED_AI
    dependencies:
      - STR_TANK_CORPSE
      - STR_BLACKOPS_SMARTGUN
      - STR_BLACKOPS_SMARTPISTOL
      - STR_BLACKOPS_SMARTRIFLE

In this situation, researching only one of the four required techs will allow you to research Advanced AI.

3) Never, ever use "requires:". It's buggy and unnecessary.

Offline wolfreal

  • Colonel
  • ****
  • Posts: 298
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #3 on: January 08, 2017, 06:03:49 pm »
Thanks Meridian. So, I have to suppose that the behavior with dependencies: and requires: is the same as with unlocks:, it override precedent rulesets.

Great guidelines Solarius. Will stick to it. Thanks.



Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8617
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #4 on: January 08, 2017, 06:12:43 pm »
Thanks Meridian. So, I have to suppose that the behavior with dependencies: and requires: is the same as with unlocks:, it override precedent rulesets.

Yes, that's a general rule... maybe there are a few exceptions, but I can't think of any right now.

Offline Nord

  • Commander
  • *****
  • Posts: 1637
  • The Gate is open.
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #5 on: January 10, 2017, 07:59:33 am »
So, if we have in vanilla:
Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER
How this will work? Do we need STR_ALIEN_ORIGINS and one of commanders?

Offline wolfreal

  • Colonel
  • ****
  • Posts: 298
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #6 on: January 10, 2017, 09:25:06 am »
So, if we have in vanilla:
Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER
How this will work? Do we need STR_ALIEN_ORIGINS and one of commanders?

If I understand well, you can get rid of the requires:, and just add STR_ALIEN_ORIGINS to dependencies.

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #7 on: January 10, 2017, 09:39:39 am »
If I understand well, you can get rid of the requires:, and just add STR_ALIEN_ORIGINS to dependencies.
Wrong. What you suggest will drasticallly change the main story line research.

Read here: https://openxcom.org/forum/index.php/topic,3312.msg38422.html#msg38422

Requires meaning this research topic is ready to be researched/unlocked after the requirement has been met (meaning research projects listed under requires have been researched)
Dependencies mean that the research project have to fullfilled to make this research topic appear.

Offline wolfreal

  • Colonel
  • ****
  • Posts: 298
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #8 on: January 10, 2017, 10:27:09 am »
Thanks Hellrazor.

So, to confirm that after reading the other forum post and this explanation, I´m not understanding, I will try to imagine the two scenarios.

Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    dependencies:
      - STR_ALIEN_ORIGINS
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER

Just have those four in any order and STR_LEADER_PLUS will pop up.

Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER

In this case, STR_LEADER_PLUS will only appears after you have STR_ALIEN_ORIGINS, and get the dependencies. If you got those aliens interrogations before, you have to get it again.

I hope this time I understand well. If not, I will take pencil and paper tomorrow. :P

 I have another question. There is a way to replace the logic with require: using unlock: in another tech?.

Edit: Corrected Hellrazor name :)

« Last Edit: January 10, 2017, 06:55:09 pm by ajnunezr »

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #9 on: January 10, 2017, 10:52:47 am »
Thanks HellRazor.

First its hellrazor not " HellRazor", but nevermind.

So, to confirm that after reading the other forum post and this explanation, I´m not understanding, I will try to imagine the two scenarios.

Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    dependencies:
      - STR_ALIEN_ORIGINS
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER

Just have those four in any order and STR_LEADER_PLUS will pop up.

Yes, it should work this way. But it would totally screw up the vanilla research.
In this STR_LEADER_PLUS is actually a topic which gets "unlocked" from the alive interrogations.
Meaning you do not need to have all 4 dependencies but only one of the alive interrogations.
Destroying the vanilla research tree.

Code: [Select]
  - name: STR_LEADER_PLUS
    cost: 0
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_LOBSTERMAN_COMMANDER
      - STR_LOBSTERMAN_NAVIGATOR
      - STR_GILLMAN_COMMANDER

In this case, STR_LEADER_PLUS will only appears after you have STR_ALIEN_ORIGINS, and get the dependencies. If you got those aliens interrogations before, you have to get it again.

Thats how it would work. But Remember the interrogations do have "unlocks" set.

I hope this time I understand well. If not, I will take pencil and paper tomorrow. :P

 I have another question. There is a way to replace the logic with require: using unlock: in another tech?.

Nope.
You wanna see some weird research code using these limitation, take a look here:
Code: [Select]
#BEGIN WIN THE GAME
#listOrder: 10-29
  - name: STR_THE_ALIEN_THREAT
    cost: 200
    points: 20
    listOrder: 10
  - name: STR_ALIEN_INVASION
    cost: 500
    points: 40
    dependencies:
      - STR_THE_ALIEN_THREAT
      - STR_ALIEN_DATA_SLATE
      - STR_ALIEN_INVASION_UNLOCK
    listOrder: 11
  - name: STR_ALIEN_INVASION_UNLOCK
    requires:
      - STR_THE_ALIEN_THREAT
    dependencies: &ALL_ALIVE_ALIENS
      - STR_FLOATER_SOLDIER
      - STR_FLOATER_NAVIGATOR
      - STR_FLOATER_MEDIC
      - STR_FLOATER_ENGINEER
      - STR_FLOATER_LEADER
      - STR_FLOATER_COMMANDER
      - STR_SECTOID_SOLDIER
      - STR_SECTOID_NAVIGATOR
      - STR_SECTOID_MEDIC
      - STR_SECTOID_ENGINEER
      - STR_SECTOID_LEADER
      - STR_SECTOID_COMMANDER
      - STR_SNAKEMAN_SOLDIER
      - STR_SNAKEMAN_NAVIGATOR
      - STR_SNAKEMAN_ENGINEER
      - STR_SNAKEMAN_LEADER
      - STR_SNAKEMAN_COMMANDER
      - STR_MUTON_SOLDIER
      - STR_MUTON_NAVIGATOR
      - STR_MUTON_ENGINEER
      - STR_WASPITE_SOLDIER
      - STR_WASPITE_NAVIGATOR
      - STR_WASPITE_MEDIC
      - STR_WASPITE_ENGINEER
      - STR_WASPITE_LEADER
      - STR_WASPITE_COMMANDER
      - STR_GAZER_SOLDIER
      - STR_GAZER_NAVIGATOR
      - STR_GAZER_MEDIC
      - STR_GAZER_ENGINEER
      - STR_GAZER_LEADER
      - STR_GAZER_COMMANDER
      - STR_SECTOID_ELITE_SOLDIER
      - STR_SECTOID_ELITE_NAVIGATOR
      - STR_SECTOID_ELITE_MEDIC
      - STR_SECTOID_ELITE_ENGINEER
      - STR_SECTOID_ELITE_LEADER
      - STR_SECTOID_ELITE_COMMANDER
      - STR_MUTON_ELITE_SOLDIER
      - STR_MUTON_ELITE_NAVIGATOR
      - STR_MUTON_ELITE_ENGINEER
      - STR_MUTON_ELITE_LEADER
      - STR_ETHEREAL_SOLDIER
      - STR_ETHEREAL_LEADER
      - STR_ETHEREAL_COMMANDER
      - STR_MUTON_ELITE_GUARD_SOLDIER
      - STR_MUTON_ELITE_GUARD_ENGINEER
      - STR_MUTON_ELITE_GUARD_LEADER
      - STR_SILACOID_TERRORIST
      - STR_REAPER_TERRORIST
      - STR_CYBERDISC_TERRORIST
      - STR_CHRYSSALID_TERRORIST
      - STR_SECTOPOD_TERRORIST
      - STR_CELATID_TERRORIST
      - STR_MUTON_BERSERKER_TERRORIST
      - STR_CYBERMITE_TERRORIST
      - STR_HOLODRONE_TERRORIST
      - STR_ARMORED_CYBERDISC
      - STR_ARMORED_SECTOPOD
      - STR_CHRYSSALID_SPITTER_TERRORIST
    listOrder: 12
  - delete: STR_ALIEN_ORIGINS
  - name: STR_ALIEN_ORIGINS
    cost: 1000
    points: 60
    dependencies:
      - STR_LEADER_PLUS
    listOrder: 13
  - delete: STR_LEADER_PLUS
  - name: STR_LEADER_PLUS
    requires:
      - STR_ALIEN_INVASION
    dependencies:
      - STR_FLOATER_LEADER
      - STR_FLOATER_COMMANDER
      - STR_SECTOID_LEADER
      - STR_SECTOID_COMMANDER
      - STR_SNAKEMAN_LEADER
      - STR_SNAKEMAN_COMMANDER
      - STR_WASPITE_LEADER
      - STR_WASPITE_COMMANDER
      - STR_GAZER_LEADER
      - STR_GAZER_COMMANDER
      - STR_SECTOID_ELITE_LEADER
      - STR_SECTOID_ELITE_COMMANDER
      - STR_MUTON_ELITE_LEADER
      - STR_ETHEREAL_LEADER
      - STR_ETHEREAL_COMMANDER
      - STR_MUTON_ELITE_GUARD_LEADER
    listOrder: 14
  - name: STR_THE_MARTIAN_SOLUTION
    cost: 2000
    points: 60
    dependencies:
      - STR_COMMANDER_PLUS
    listOrder: 15
  - name: STR_COMMANDER_PLUS
    unlocks:
      - STR_THE_MARTIAN_SOLUTION
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_FLOATER_COMMANDER
      - STR_SECTOID_COMMANDER
      - STR_SNAKEMAN_COMMANDER
      - STR_WASPITE_COMMANDER
      - STR_GAZER_COMMANDER
      - STR_SECTOID_ELITE_COMMANDER
      - STR_ETHEREAL_COMMANDER
    listOrder: 16
  - delete: STR_CYDONIA_OR_BUST
  - name: STR_CYDONIA_OR_BUST
    cost: 3000
    points: 100
    unlockFinalMission: true
    dependencies:
      - STR_CYDONIA_PLUS
    listOrder: 17
  - name: STR_CYDONIA_PLUS
    unlocks:
      - STR_CYDONIA_OR_BUST
    requires:
      - STR_THE_MARTIAN_SOLUTION
    dependencies:
      - STR_ETHEREAL_COMMANDER
    listOrder: 18
#END WIN THE GAME

These the research topics and here the interrogations of the Ethereals and their Commander:
Code: [Select]
#BEGIN ETHEREAL
#listOrder: 1600-1699
  - delete: STR_ETHEREAL_SOLDIER
  - delete: STR_ETHEREAL_LEADER
  - delete: STR_ETHEREAL_COMMANDER
  - name: STR_ETHEREAL
    listOrder: 1600
  - name: STR_ETHEREAL_SOLDIER
    cost: 288
    points: 50
    needItem: true
    destroyItem: true
    listOrder: 1601
    lookup: STR_ETHEREAL
    unlocks:
      - STR_ALIEN_LANGUAGE_UNLOCK
      - STR_ALIEN_INVASION_UNLOCK
      - STR_PSIONICS_UNLOCK
  - name: STR_ETHEREAL_LEADER
    cost: 288
    points: 50
    needItem: true
    destroyItem: true
    listOrder: 1605
    lookup: STR_ETHEREAL
    unlocks:
      - STR_ALIEN_LANGUAGE_UNLOCK
      - STR_ALIEN_INVASION_UNLOCK
      - STR_LEADER_PLUS
      - STR_PSIONICS_UNLOCK
  - name: STR_ETHEREAL_COMMANDER
    cost: 288
    points: 50
    needItem: true
    destroyItem: true
    listOrder: 1606
    lookup: STR_ETHEREAL
    unlocks:
      - STR_ALIEN_LANGUAGE_UNLOCK
      - STR_ALIEN_INVASION_UNLOCK
      - STR_LEADER_PLUS
      - STR_COMMANDER_PLUS
      - STR_PSIONICS_UNLOCK
      - STR_CYDONIA_PLUS
#END ETHEREAL

As you can from the code above, you need to research some topics first until you reach the unlock of STR_CYDONIA_PLUS.
This was made intentionally to force the game to only allow Ethereal Commanders to give you the Final Research Mission Topic.

Offline Nord

  • Commander
  • *****
  • Posts: 1637
  • The Gate is open.
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #10 on: January 10, 2017, 01:55:34 pm »
Well, if i understand properly, there is a way to not use "requires" by adding "virtual" research topics, opened by "unlock", so one of equal topics(like different commanders) will unlock virtual one, and final topic (like cydonia) will have virtual as one of dependencies?

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #11 on: January 10, 2017, 02:30:16 pm »
Well, if i understand properly, there is a way to not use "requires" by adding "virtual" research topics, opened by "unlock", so one of equal topics(like different commanders) will unlock virtual one, and final topic (like cydonia) will have virtual as one of dependencies?

The requires are still used to ensure that the topic in questions only becomes available after the other researches in the tree have been researched before.
It depends how you use it. "requires" allows you to restrict research access, meaning that all topics listed in "requires" have to be researched completely before the topic in question is even considered to be poped for research or unlocks or getOneFree.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8617
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #12 on: January 10, 2017, 02:46:09 pm »
The requires are still used to ensure that the topic in questions only becomes available after the other researches in the tree have been researched before.
It depends how you use it. "requires" allows you to restrict research access, meaning that all topics listed in "requires" have to be researched completely before the topic in question is even considered to be poped for research or unlocks or getOneFree.

It's still pointless discussing using "requires".

It works only for 2 specific topics:
- STR_LEADER_PLUS
- STR_COMMANDER_PLUS

If you try anything else, it won't work.

Proof: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedGame.cpp#L1181

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #13 on: January 15, 2017, 03:31:14 pm »
It's still pointless discussing using "requires".

It works only for 2 specific topics:
- STR_LEADER_PLUS
- STR_COMMANDER_PLUS

If you try anything else, it won't work.

Proof: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedGame.cpp#L1181

Proof: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedGame.cpp#L1214
Here is the general check.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8617
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #14 on: January 15, 2017, 05:59:02 pm »
Proof: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedGame.cpp#L1214
Here is the general check.

Do I really look like someone, who wouldn't notice that?
REALLY?

The check/mechanism is there, but it's broken!

Let's take Martian Solution from vanilla as example.
You need Alien Origins and a live leader (e.g. Floater Leader) to unlock it.
In the example below, I have replaced Alien Origins with Laser Weapons and Floater Leader with Motion Scanner; and STR_LEADER_PLUS with Medi-kit.

Now if I research:
1. Laser Weapons (=Alien Origins) first and then Motion Scanner (=Floater Leader)... Martian Solution is correctly unlocked
2. Motion Scanner (=Floater Leader) first and then Laser Weapons (=Alien Origins) ... Martian Solution is correctly not unlocked... BUT I have no possibility to research Motion Scanner (=Floater Leader) again... thus my game becomes broken without a possibility to continue!

Code: [Select]
research:
  - name: STR_LASER_WEAPONS # simulates STR_ALIEN_ORIGINS
    cost: 5
  - name: STR_MOTION_SCANNER # simulates a live leader, e.g. STR_FLOATER_LEADER
    cost: 5
    unlocks:
      - STR_MEDI_KIT # simulates STR_LEADER_PLUS
      - STR_LASER_WEAPONS # simulates STR_ALIEN_ORIGINS
  - name: STR_MEDI_KIT # simulates STR_LEADER_PLUS
    cost: 0
    requires:
      - STR_LASER_WEAPONS # simulates STR_ALIEN_ORIGINS
    dependencies:
      - STR_MOTION_SCANNER # simulates a live leader, e.g. STR_FLOATER_LEADER
      - STR_FLOATER_COMMANDER
      - STR_FLOATER_LEADER
  - name: STR_THE_MARTIAN_SOLUTION
    cost: 5
    dependencies:
      - STR_LASER_WEAPONS # simulates STR_ALIEN_ORIGINS
      - STR_MEDI_KIT # simulates STR_LEADER_PLUS

If I wanted to "fix" this ruleset (if it even can be called a fix), I would need to:
a/ make Motion Scanner a unit... LOL
b/ add STR_LEADER_PLUS (or STR_COMMANDER_PLUS) into the "unlocks" section of the Motion Scanner... only these 2 hardcoded topics would allow me to continue.

Now, I could use a real unit instead of a Motion Scanner in my research tree... so point a/ is not sooo bad.
But you can never workaround the 2 hardcoded topics from point b/.