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

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #15 on: January 15, 2017, 06:32:42 pm »
I think we are both looking in the wrong function.

Take a look at: https://github.com/SupSuper/OpenXcom/blob/master/src/Savegame/SavedGame.cpp#L1080 and following.
The actual check for a requirements for a research is done once a research project finishes.
So the game knows it can make a topic available for research.
The STR_COMMANDER_PLUS and STR_LEADER_PLUS are indeed hardcoded, and you need those to reach the final research topic.
GetOneFree only for Alive Aliens.

And btw I never said anything about you being wrong, I just pointed out that there is a check. It only works together with the above mentioned function, otherwise it would indeed not make sense.

--- posts merged - Solarius Scorch

Also the example you mentioned, will of course not work because it is not correctly coded.
Using the hardcoded string will not work, you have to create extra unlocks.

See here:
Code: [Select]
  - name: STR_NEW_FIGHTER_TRANSPORTER
    cost: 1050
    points: 30
    listOrder: 102
    dependencies:
      - STR_UFO_CONSTRUCTION
      - STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_1
      - STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_2
  - name: STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_1
    listOrder: 103
    requires:
      - STR_UFO_CONSTRUCTION
    dependencies: &ALL_ALIVE_ENGINEERS
      - STR_FLOATER_ENGINEER
      - STR_SECTOID_ENGINEER
      - STR_SNAKEMAN_ENGINEER
      - STR_MUTON_ENGINEER
      - STR_WASPITE_ENGINEER
      - STR_GAZER_ENGINEER
      - STR_SECTOID_ELITE_ENGINEER
      - STR_MUTON_ELITE_ENGINEER
      - STR_MUTON_ELITE_GUARD_ENGINEER
  - name: STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_2
    listOrder: 104
    requires:
      - STR_UFO_CONSTRUCTION
    dependencies: &ALL_ALIVE_NAVIGATORS
      - STR_FLOATER_NAVIGATOR
      - STR_SECTOID_NAVIGATOR
      - STR_SNAKEMAN_NAVIGATOR
      - STR_MUTON_NAVIGATOR
      - STR_WASPITE_NAVIGATOR
      - STR_GAZER_NAVIGATOR
      - STR_SECTOID_ELITE_NAVIGATOR
      - STR_MUTON_ELITE_NAVIGATOR

This will also work if you replace the alive alien here with normal Items, as long as the respective research has the appropriate unlocks.
« Last Edit: January 15, 2017, 06:47:52 pm by Solarius Scorch »

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8616
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #16 on: January 15, 2017, 07:20:02 pm »
I think we are both looking in the wrong function.

You know, if you don't believe me, ask SupSuper or Warboy... I can't give you more proof than source code + example.

GetOneFree only for Alive Aliens.

GetOneFree fools you into false safety, because it allows you to repeat the research of a certain topic/unit finite-amount-of times. So, instead of 1 try, you will have let's say 7 tries.
Still, if you do all GetOneFree topics BEFORE you manage to fulfill the requirement... you will again be completely stuck.

And btw I never said anything about you being wrong, I just pointed out that there is a check. It only works together with the above mentioned function, otherwise it would indeed not make sense.

No, it still doesn't work... only gives you a few more attempts, as mentioned above.

Also, from other side, you can remove GetOneFree from Floater Leader... and it will still show up in your research... until you unlock Martian Solution.

Also the example you mentioned, will of course not work because it is not correctly coded.

It is coded the same way as the vanilla Martian Solution... I copy-pasted it from vanilla.
As far as I can say (99.99998% sure), it is coded correctly.

Using the hardcoded string will not work, you have to create extra unlocks.

I tried it and it worked.
Not saying it's a correct solution... it's not... it wouldn't work if I used it twice (in different topics).


See here:
Code: [Select]
...

This will also work if you replace the alive alien here with normal Items, as long as the respective research has the appropriate unlocks.

I will look at your code later (probably tomorrow) and share what I found.

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #17 on: January 15, 2017, 07:32:42 pm »
You know, if you don't believe me, ask SupSuper or Warboy... I can't give you more proof than source code + example.

The code is spread over a few functions and has even different checkorders for the same checks, to be brief its a mess.

GetOneFree fools you into false safety, because it allows you to repeat the research of a certain topic/unit finite-amount-of times. So, instead of 1 try, you will have let's say 7 tries.
Still, if you do all GetOneFree topics BEFORE you manage to fulfill the requirement... you will again be completely stuck.

No, it still doesn't work... only gives you a few more attempts, as mentioned above.
I see, so actually if you research all alien Leader or Commanders, before researching alien origins you are essentially fucked (or whatever topic comes before the STR_LEADER_PLUS holding topic). And at that point the hardcoded strings with special functions actually do save your ass.

Also, from other side, you can remove GetOneFree from Floater Leader... and it will still show up in your research... until you unlock Martian Solution.

It is coded the same way as the vanilla Martian Solution... I copy-pasted it from vanilla.
As far as I can say (99.99998% sure), it is coded correctly.

I tried it and it worked.
Not saying it's a correct solution... it's not... it wouldn't work if I used it twice (in different topics).

I will look at your code later (probably tomorrow) and share what I found.

Looking forward to your insights.

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8616
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #18 on: January 15, 2017, 11:46:26 pm »
Looking forward to your insights.

So, assuming your code is identical to what's in Hardmode v0.99.2d, I did a test with latest nightly (commit c05326a).

Steps:
1. New game
2. Save game
3. Edit saved game:
- removed alienMissions
- increased funds 10x
- added discoveries: mind shield, alien containment
- added 2 labs, 3 mind shields, 3 living quarters, 2 alien containments
- added 140 scientists
- added 6 floater engineers and 6 floater navigators
- added discoveries: almost all topics from floater engineer/navigator GetOneFree lists... except 2 from each... to save some testing time
- added discoveries: all 3 pre-requisites for UFO construction

Save is attached in this post... feel free to test yourself.

Note:
Let's assume your STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_1 and STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_2 topics only work with floaters engineers/navigators and not other races... for sake of simplicity. It doesn't change anything.

4. Load edited save
5. Research:
UFO construction -> Floater engineer -> Floater navigator -> New Fighter Transporter unlocked!

6. Reload again
7. Research:
- 2x Floater engineer -> cannot research more even though there are still 4 in prison
- 2x Floater navigator -> cannot research more even though there are still 4 in prison
- research UFO construction -> New Fighter Transporter in not unlocked (which is OK)...
...BUT you cannot research floater engineers or navigators anymore... thus you will never be able to unlock it... you're stuck!

Q.E.D.

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #19 on: January 16, 2017, 02:23:25 am »
Dear Meridian,

it was not my intention to offend you in any way. I just wanted to know why this behaviour can occur and why.
So thanks for the test case.

So, assuming your code is identical to what's in Hardmode v0.99.2d, I did a test with latest nightly (commit c05326a).

It is the same, this part of the research rules has not been changed since v0.84 or so.

Steps:
1. New game
2. Save game
3. Edit saved game:
- removed alienMissions
- increased funds 10x
- added discoveries: mind shield, alien containment
- added 2 labs, 3 mind shields, 3 living quarters, 2 alien containments
- added 140 scientists
- added 6 floater engineers and 6 floater navigators
- added discoveries: almost all topics from floater engineer/navigator GetOneFree lists... except 2 from each... to save some testing time
- added discoveries: all 3 pre-requisites for UFO construction

Save is attached in this post... feel free to test yourself.

Note:
Let's assume your STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_1 and STR_NEW_FIGHTER_TRANSPORTER_UNLOCK_2 topics only work with floaters engineers/navigators and not other races... for sake of simplicity. It doesn't change anything.

Indeed for showing the and testing it doesn't make a difference.
I would even assume that the code would behave the same way, if you would use all aliens Engineers/Navigators (in this case).
When you research all the Engineers and navigators before you met the requires you would also be stuck.

4. Load edited save
5. Research:
UFO construction -> Floater engineer -> Floater navigator -> New Fighter Transporter unlocked!

6. Reload again
7. Research:
- 2x Floater engineer -> cannot research more even though there are still 4 in prison
- 2x Floater navigator -> cannot research more even though there are still 4 in prison
- research UFO construction -> New Fighter Transporter in not unlocked (which is OK)...
...BUT you cannot research floater engineers or navigators anymore... thus you will never be able to unlock it... you're stuck!

Q.E.D.

Indeed you are stuck. I have had reports about this a while back but was not really identify the cause of the issue.
My assumption judging from the behaviour:
- Game only checks if the topic has getonefree, to make it available for make it appear again on the researchlist
- Game ignores unsatiesfied "unlocks", which only can happen if "require" is set
Or
-Game checks both and the check gets screwed up (logic error).

How could the research work:
1.)Get list with all available research topics from ruleset.(Mod->research)
2.)Get list of all discovered research topics from ruleset. (SaveGame->discovered)
3.)Check if "requires" list of available research topic has been satiesfied (compare with discovered), if true check for "depends" (no "requires"->check for "depends")
4.)Check if "depends" list of available research topic has been satiesfied (compare with discovered), if true display on Research List. (or no "depends"->display")
5.)Check if "getOneFree list of available research topic has been satiesfied (compare with discovered), if false display.
6.)Check if "unlocks" list of available research topic has been satiesfied (compare with discovered), if false display.

Question is were does our code screw up?
Thats just the logic.
« Last Edit: January 16, 2017, 10:45:20 pm by hellrazor »

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8616
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #20 on: January 16, 2017, 10:28:58 am »
it was not my intention to offend you in any way. I just wanted to know why this behaviour can occur and why.
So thanks for the test case.

No worries, maybe a bit more faith in me next time.

Btw. I have no intention or desire to change/fix this. I was just telling new people to avoid it.

Offline hellrazor

  • Commander
  • *****
  • Posts: 2011
  • Deep Ruleset Digger & Bughunter
    • View Profile
    • Github Account
Re: Dumb questions about modular Rulesets inheritance.
« Reply #21 on: January 16, 2017, 03:24:04 pm »
No worries, maybe a bit more faith in me next time.

Btw. I have no intention or desire to change/fix this. I was just telling new people to avoid it.

Maybe this could help:

Code: [Select]
/**
 * Check whether a ResearchProject can be researched.
 * @param r the RuleResearch to test.
 * @param unlocked the list of currently unlocked RuleResearch
 * @param mod the current Mod
 * @return true if the RuleResearch can be researched
 */
bool SavedGame::isResearchAvailable (RuleResearch * r, const std::vector<const RuleResearch *> & unlocked, const Mod * mod) const
{
if (r == 0)
{
return false;
}
std::vector<std::string> deps = r->getDependencies();
const std::vector<const RuleResearch *> & discovered(getDiscoveredResearch());
if (_debug || std::find(unlocked.begin(), unlocked.end(), r) != unlocked.end())
{
return true;
}
if (!r->getGetOneFree().empty())
{
for(std::vector<const RuleResearch *>::const_iterator isDiscovered = discovered.begin(); isDiscovered != discovered.end(); ++isDiscovered)
{
RuleResearch *researchDiscovered = mod->getResearch(*isDiscovered);
std::vector<std::string>::const_iterator unlockCheck = std::find(r->getUnlocked().begin(), r->getUnlocked().end(), researchDiscovered);

bool unlock ( unlockCheck != r->getUnlocked().end());

if (unlock)
{
std::vector<const RuleResearch*>::const_iterator found = std::find(discovered.begin(), discovered.end(), mod->getResearch(researchDiscovered));
if (found == discovered.end())
{
return true;
}
}
}
}
for (std::vector<std::string>::const_iterator iter = deps.begin(); iter != deps.end(); ++iter)
{
RuleResearch *research = mod->getResearch(*iter);
std::vector<const RuleResearch *>::const_iterator itDiscovered = std::find(discovered.begin(), discovered.end(), research);
if (itDiscovered == discovered.end())
{
return false;
}
}

return true;
}

Just testing.

EDIT: I am having some conversion errors here and can't get the loop running...
« Last Edit: January 16, 2017, 04:42:38 pm by hellrazor »

Offline Meridian

  • Global Moderator
  • Commander
  • *****
  • Posts: 8616
    • View Profile
Re: Dumb questions about modular Rulesets inheritance.
« Reply #22 on: June 27, 2017, 10:33:55 am »
No worries, maybe a bit more faith in me next time.

Btw. I have no intention or desire to change/fix this. I was just telling new people to avoid it.

So, it's fixed (in the latest nightly).
You can stop avoiding it people :)