Changing the item used by research's needItem: & destroyItem: variables?

[The Martian]

The UFOPaedia Ruleset Reference lists needItem: as accepting True & False as input and only checking if there is an item in your base inventory with the same name as the research project.

Is it possible to specify which item needItem: checks for?

Using the item's name as the research projects name isn't viable as a project with that name already exists.


Additionally if it is possible to alter which item needItem: checks, is it also possible to change the item removed by the destroyItem: variable?

[ohartenstein23]

The item required when needItem is true is the item that bears the same name as the research project.  For example, the research project for the heavy plasma item is called STR_HEAVY_PLASMA in the ruleset, the same as the weapon.  You can change the name of the research project separately from the item name I believe by giving it a name:.  The destroyItem will be whatever the item required was.

[The Reaver of Darkness]

You can string together multiple projects with different names. An example included in the base ruleset is STR_PLASMA_CANNON_DEP_1 and STR_PLASMA_CANNON_DEP_2 linked with STR_PLASMA_CANNON. You could make an item called STR_PLASMA_CANNON_DEP_1 and have the corresponding research project require that item, but when completed it unlocks STR_PLASMA_CANNON. This means you don't need a STR_PLASMA_CANNON, but rather something else, to research it.


Here's another example you could make yourself:

Code: [Select]

items:
  - type: STR_ALIEN_CLOCKWORK_DEVICE
    size: 0.1
    costSell: 25000
  - type: STR_ALIEN_ENIGMATIC_DEVICE
    requires:
      - STR_ALIEN_TECHNOLOGY
    size: 0.4
    costSell: 187500
research:
  - name: STR_ALIEN_TECHNOLOGY
    cost: 500
    points: 50
    dependencies:
      - STR_ALIEN_CLOCKWORK_DEVICE
  - name: STR_ALIEN_CLOCKWORK_DEVICE
    needItem: true
    unlocks:
      - STR_ALIEN_TECHNOLOGY
So in this example (if I have written it correctly), the Enigmatic Device cannot be used until you have gained an understanding of the technology these aliens use by studying other things they made, first. If you get a Clockwork Device, it will unlock your Alien Technology research project. Once you have completed Alien Technology, you can use the Enigmatic Device.

If it's still confusing to you, tell me what scenario you're trying to create, and I'll explain how to code it in.

[The Martian]

You can change the name of the research project separately from the item name I believe by giving it a name:.  The destroyItem will be whatever the item required was.

I'm not sure if I'm understanding you correctly, do you mean it is possible to use the name: variable twice with the second one overriding the first research project name?

Thus the second name would be the displayed name and differentiate the project when other objects reference it, where as the first name would still be feeding destroyItem: and needItem: the name of the item consumed/required in your inventory?


Example of using name: twice inside the same research project:

Code: [Select]

research:
  - name: STR_ITEM_A
    name: STR_ITEM_A_OVERRIDE_NAME
    needItem: true
    destroyItem: true
  - name: STR_ITEM_B

If it's still confusing to you, tell me what scenario you're trying to create, and I'll explain how to code it in.

What I'm trying to do is create a research project that researches an already researched item a second time after additional technological knowledge has been gained elsewhere.

Research Tech Item A -> Research Tech B -> Research Tech Item A (Again) -> Grants Tech C.

In order to do this what I'm hoping is that code similar to this example is possible:

Code: [Select]

items:
  - type: STR_ITEM_A
  - type: STR_ITEM_B

research:
  - name: STR_ITEM_A
    lookup: STR_ITEM_A_UFOPEDIA
    needItem: true
    destroyItem: true
  - name: STR_ITEM_B
    lookup: STR_ITEM_B_UFOPEDIA
  - name: STR_ITEM_A2
    lookup: STR_ITEM_A_UFOPEDIA
    requires:
      - STR_ITEM_A
      - STR_ITEM_B
    destroyItem:
      - STR_ITEM_A
    needItem:
      - STR_ITEM_A

Basically I'm hoping that it is possible to perhaps pass needItem: and destroyItem: a list of the item(s) to be used instead of a True/False condition.

I've tried creating a test mod using the pseudocode I wrote above but as expected it does not function, the syntax doesn't appear to be correct.

In the test mod after researching Item A, Item B becomes unable to be researched.

Oddly if Item B is researched A becomes unable to be researched.

And if both projects are assigned scientists so that they are being researched at the same time and unlock... The 2nd research project for item A does not appear.



I'll attach the faulty test mod I constructed in a *.zip.

(To make ingame testing easier a manufacturing project is also included in the test mod that generates the required research items.)

[ohartenstein23]

I'm not sure if I'm understanding you correctly, do you mean it is possible to use the name: variable twice with the second one overriding the first research project name?

Thus the second name would be the displayed name and differentiate the project when other objects reference it, where as the first name would still be feeding destroyItem: and needItem: the name of the item consumed/required in your inventory?


Example of using name: twice inside the same research project:[/glow]

Code: [Select]

research:
  - name: STR_ITEM_A
    name: STR_ITEM_A_OVERRIDE_NAME
    needItem: true
    destroyItem: true
  - name: STR_ITEM_B

Sorry, I was mixing up name: with lookup: - the lookup definition allows you to make the displayed name of the research project and the ufopedia article unlocked by it different from the actual name: definition.  Adding a second 'name:' will either be ignored or replace the first one.  So the example would be:

Code: [Select]

research:
  - name: STR_ITEM_A
    lookup: STR_ITEM_A_OVERRIDE_NAME
    needItem: true
    destroyItem: true

This project would need and consume one STR_ITEM_A, but the project would be called STR_ITEM_A_OVERRIDE_NAME in the research screen.

What I'm trying to do is create a research project that researches an already researched item a second time after additional technological knowledge has been gained elsewhere.

Research Tech Item A -> Research Tech B -> Research Tech Item A (Again) -> Grants Tech C.

This might be possible using the requires: tag - in the original game, researching an Alien Leader before any other alien unlocks Alien Origins, then researching an Alien Leader again unlocks The Martian Solution.  However, using the requires: tag for things other than this specific sequence might be difficult, as there are some hardcoded bits specifically for these research projects.  What you might do instead is use a manufacturing project unlocked by your Research Tech B to turn Item A into something else that when researched unlocks Tech C.  So the sequence could be:

Research Tech Item A -> Research Tech B -> Manufacture Item B from Item A -> Research Tech Item B -> Grants Tech C.

[The Martian]

Code: [Select]

  - name: STR_LEADER_PLUS
    requires:
      - STR_ALIEN_ORIGINS
    dependencies:
      - STR_SECTOID_COMMANDER
      - STR_SECTOID_LEADER
      - STR_SNAKEMAN_COMMANDER
      - STR_SNAKEMAN_LEADER
      - STR_ETHEREAL_COMMANDER
      - STR_ETHEREAL_LEADER
      - STR_FLOATER_COMMANDER
      - STR_FLOATER_LEADER

Code: [Select]

  - name: STR_COMMANDER_PLUS
    unlocks:
      - STR_CYDONIA_OR_BUST
    requires:
      - STR_THE_MARTIAN_SOLUTION
    dependencies:
      - STR_SECTOID_COMMANDER
      - STR_SNAKEMAN_COMMANDER
      - STR_ETHEREAL_COMMANDER
      - STR_FLOATER_COMMANDER

Code: [Select]

  - name: STR_SNAKEMAN_COMMANDER
    cost: 192
    points: 50
    lookup: STR_SNAKEMAN
    needItem: true
    destroyItem: true
    unlocks:
      - STR_LEADER_PLUS
      - STR_COMMANDER_PLUS
      - STR_ALIEN_ORIGINS


I think I see what you're saying.

The requires: variable prevents the unlock of the research project unless prerequisite research items have already been researched.

So even though, for example, a Snakeman Commander allows the unlock of STR_ALIEN_ORIGINS, STR_LEADER_PLUS and STR_COMMANDER_PLUS it only unlocks them one at a time due to requires: and consumes the STR_SNAKEMAN_COMMANDER item each time forcing the player to acquire it again in the field before they can research the next entry in the sequence.

I'll try this immediately and post the result. ^_^


(EDIT)

I just finished coding a test mod using the above method and it is displaying some of the expected behaviors, but not all of them.

Researching STR_ITEM_A can now be done several times before it stops appearing in the research menu.

In theory this is unlocking research projects STR_RESEARCH_A then STR_RESEARCH_B followed by STR_RESEARCH_C.

However oddly STR_RESEARCH_A, STR_RESEARCH_B and STR_RESEARCH_C are not themselves appearing in the research menu after being unlocked.

Here's the code I changed in the research: variables:

Code: [Select]

research:
# Research Item A
  - name: STR_TEST_A
    needItem: true
    destroyItem: true
    unlocks:
      - STR_RESEARCH_A
      - STR_RESEARCH_B
      - STR_RESEARCH_C
# Research Unlocks A-C
  - name: STR_RESEARCH_A
    dependencies:
      - STR_TEST_A
  - name: STR_RESEARCH_B
    requires:
      - STR_RESEARCH_A
  - name: STR_RESEARCH_C
    requires:
      - STR_RESEARCH_B

I'll attach the new test mod with the updated code in it to this post as a *.zip.

[ohartenstein23]

The unlocks: tag only works if the research that is doing the unlocking (STR_TEST_A) is included in the dependencies: tag on the research project that is being unlocked.  So you need to add the dependency on the Item A research topic to projects B and C.  Also, the definitions of the projects is incomplete; they don't have the amount of time it takes to research.  As such, all of them cost 0 scientist-days to research and are probably automatically researched when the unlock happens - you can check this by saving after researching Item A and seeing what research topics are unlocked in the save file.

[The Martian]

I've altered the code to include cost: values and dependencies: however now I'm getting an error when OpenXcom tries to load the mod:

Code: [Select]

Error: failed to load 'Test Mod' mod disabled for next startup.
Research topic STR_RESEARCH_B has requirements, but the cost is not zero. Sorry, this is not allowed!
Make sure you installed OpenXcom correctly
Check wiki documentation for more details

Here is the changed research: code:

Code: [Select]

research:
# Research Item A
  - name: STR_TEST_A
    cost: 10
    points: 10
    needItem: true
    destroyItem: true
    unlocks:
      - STR_RESEARCH_A
      - STR_RESEARCH_B
      - STR_RESEARCH_C
# Research Unlocks A-C
  - name: STR_RESEARCH_A
    cost: 10
    points: 10
    lookup: STR_RESEARCH_A
    dependencies:
      - STR_TEST_A
  - name: STR_RESEARCH_B
    cost: 10
    points: 10
    lookup: STR_RESEARCH_B
    requires:
      - STR_RESEARCH_A
    dependencies:
      - STR_TEST_A
  - name: STR_RESEARCH_C
    cost: 10
    points: 10
    lookup: STR_RESEARCH_C
    requires:
      - STR_RESEARCH_B
    dependencies:
      - STR_TEST_A

I'll attach the latest version of the test mod to this post as a *.zip.


(EDIT)

Removing cost: from the research projects for STR_RESEARCH_B and STR_RESEARCH_C has prevent the error on startup, I'm unsure how their project length is determined without that variable though.

The research for item STR_TEST_A now unlocks STR_RESEARCH_A as expected, however STR_RESEARCH_B & STR_RESEARCH_C do not become available for research after STR_RESEARCH_A's research is completed.

Also STR_TEST_A is remaining an available option to be researched additional times even while the higher sequenced STR_RESEARCH_B and STR_RESEARCH_C do not have their requirements met.

I'll attach the newest version of the test mod (V4) to this edited post

[ohartenstein23]

Ah, I forgot that's how it was done for those researches - STR_LEADER_PLUS and STR_COMMANDER_PLUS are 'dummy' research projects that are automatically unlocked by researching any leader or commander respectively after the requisite projects are finished.  If you want Research B to depend on Item A, you don't need to have it 'require' Item A, it just needs to 'depend' on Item A.  You should also remove the cost from Research C then, as it will be automatically unlocked after Research B is finished and Item A is researched again.  Another issue might be that you can only research Item A once in its current form.  To be able to research an item multiple times, it needs to have a getOneFree list.  Then Item A can be researched as many times as their are projects in the getOneFree list - this still has the issue that if you research it that many times before Research B, you might never unlock Research C.

Edit:
Okay, I've got something that works for you:

Code: [Select]

research:
# Research Item A
  - name: STR_TEST_A
    cost: 10
    points: 10
    needItem: true
    destroyItem: true
    unlocks:
      - STR_RESEARCH_A
      - STR_RESEARCH_C
# Research Unlocks A, and C but only after B is researched.
  - name: STR_RESEARCH_A # This is researched immediately after Item A is finished, technically unnecessary
    points: 10
    lookup: STR_RESEARCH_A
    dependencies:
      - STR_TEST_A
  - name: STR_RESEARCH_B # This can be researched immediately after Item A is finished, and is necessary to get Research C
    cost: 10
    points: 10
    lookup: STR_RESEARCH_B
    dependencies:
      - STR_RESEARCH_A
  - name: STR_RESEARCH_C # This is automatically researched after Item A is researched after Research B is done.
    points: 10
    lookup: STR_RESEARCH_C
    requires:
      - STR_RESEARCH_B
    dependencies:
      - STR_TEST_A
The getOneFree list bit I talked about above is not necessary when using requires:, apparently any item that's necessary for a requires: research project can be continued to be researched so the issue I mentioned above doesn't occur.  Next, Research B doesn't need to be unlocked by Item A or Research A, just having only one of them in the depends: list lets it be researched.  Giving it 0 cost and being unlocked means it will be automatically researched when the unlocking project is finished.  The above code ends up having the following sequence:

Research Item A -> Research Project B -> Research Item A -> Research Project C is unlocked and the article is available in the Ufopedia, but is not shown when the second Item A research is finished.

You could make this even simpler in ruleset by making Research Project B depend directly on Item A, the 'dummy' research project A would mostly be useful for having a separate Ufopedia page from Item A.

By the way, you should change the type_id: of the ufopedia articles - the current version is for craft only, and the game crashes when looking for the craft called STR_RESEARCH_B, because that's not a craft.  You could use type_id: 8 for a text-only article.

[The Martian]

Thank you, your code functions exactly as you described.


I have two additional questions:
(1)
Is there any way to make STR_RESEARCH_C display it's research report when it is automatically researched by researching STR_TEST_A for the second time?

I'm worried the player may not be aware they'd gained access to the new technology.
(If not this problem can be mitigated by notes in other UFOpedia entries explaining this research entry's special requirements and operation.)


(2)
The only negative of this method is that STR_TEST_A remains in the research option menu even when it will not advance to STR_RESEARCH_C, thus consuming a STR_TEST_A item each time with little benefit and no direct way for the player to know if it will pay off to research it again.

Is there a way to hide STR_TEST_A while it does not have the ability to unlock additional research?

By the way, you should change the type_id: of the ufopedia articles - the current version is for craft only, and the game crashes when looking for the craft called STR_RESEARCH_B, because that's not a craft.  You could use type_id: 8 for a text-only article.

Thank you for pointing that out, I'll keep the type_id: craft specialized behavior in mind when constructing future UFOpedia entries.

The craft UFOpedia being limited to crafts: makes sense as it must be how the game is referencing which aircraft's stats it displays when their text is shown with the rect_stats: variable.

[ohartenstein23]

If you treat Research C as a 'dummy' project and have it unlock another project instead (just like STR_LEADER_PLUS and STR_COMMANDER_PLUS), then the game should pop up a window saying the player can now research whatever that unlocked topic was, as long as it doesn't have 0 cost.

There is no way to hide the test Item A research - this is part of the reason why my original suggestion was to simply use a manufacturing project that turns that item into another one that can be researched separately, avoiding the whole requires: tag. So the sequence would be:

Research Item A -> Research B to unlock manufacturing -> manufacture Item B from Item A -> Research Item B -> Research C

[The Martian]

I tried the manufacturing method you suggested and it is definitely easier to use and setup.

For now I'll keep experimenting with your "research the same item twice" code example but in the end I'll probably switch to using the manufacturing method since it is the more straightforward solution.

Thank you both for the help. ^_^


(For anyone that wants an easy download of the examples of both methods: I've attached *.zip files of them to this post.)

[greg77]

reading thorugh the above, i would like to ask for any advice, too.
i'm not inexperienced, have put together a mod or two, but have always had difficulties with understanding unlocks:/requires:/dependencies:/etc.
i would like to modify the vanilla xcom in the following way:

as to my understanding,
- if the getOneFree: list is depleted, the live alien of the matching rank (engineer, medic, navigator) ceases to be available for further research. this is as expected.
- when completing a research of any live alien, Origins becomes available. this is "required:" by Leader Plus.
- Origins is to be completed.
- any leader/commander has to be researched as Leader Plus "depends:" on it. since it has "cost: 0", Leader Plus is also completed on completion.
- Martian Solution is next, that "depends:" on Origins and Leader Plus.
- upon finishing Martian, any commander has to be researched as Commander Plus "depends:" on it. as with Leader Plus, "cost: 0".
- Cydonia is next.

my expectation is,
no more live leader or commander the player acquires should be available for research, provided their race is discovered previously, since it can yield no more new information. for example, if one captures and interrogates a sectoid soldier, a sectoid leader, a sectoid commander (origins, martian, cydonia in between), then for example a snakeman soldier, the next snakeman commander should be unavailable for research.

my observation is,
yet they show up on the research list indefinitely.
same goes for any soldier, leader or commander captured.

i would like to fix this. please help if concerned/interested/agreed.
thank you in advance.

[Meridian]

Your expectation is correct and that is exactly how I implemented it in June 2017.

If your observation is different, please provide a save to investigate.
If you're using any mods, please provide links or download for the mod(s) too.

[greg77]

thank you for your prompt response. i'm not in a hurry.
i'm still unsure if you understood my problem correctly. maybe i did not express myself properly. sorry, english is not my primary language.

i had a few 'official' mods turned on, namely aliens pick up, limit craft item, unlimited waypoints, tftd damage model. none of which should interfere with research; nevertheless, i disabled them and started another test run with "1.0 git 2021-12-20".

i did the following:
- built the first base
- saved the game as '05.sav'
- made a copy of the file as '06.sav'
- edited '06.sav' to include a bunch of different live aliens and 100 scientists instead of 10. marked all modifications with eol  #comments
- loaded the modified save
- built some facilities, saved it as '07.sav'
- began the research process in the following order:
  - snakeman soldier. received snakeman. unlocked corpse, origins. snakeman soldier removed from available projects. as expected so far.
  - origins.
  - sectoid leader. received sectoid. unlocked corpse, martian. sectoid leader removed. as expected.
  - martian.
  - sectoid commander. unlocked cydonia, psi lab. sectoid commander removed. as expected.
all finished research projects are included in this order under 'discovered:' in the last '08.sav'. as expected.

at this point, snakeman commander should not be available, because its interrogation would not yield any more ufopaedia entries, not even the snakeman corpse. but it is still available as a new research project. i even finished cydonia before saving '08.sav'. see all attached.
i would say that none of the soldier, leader or commander ranks from the sectoid and snakeman race should be available for research at this point.

i don't say that the game mechanics are flawed. technically, because of the fact that the research on snakeman commander itself was not completed, it is not included in the 'discovered:' list, therefore it is available as a new project. i merely say that i would like to make my own mod that changes this behaviour to match my expectations. i'm somewhat suspicious about my find; i feel that either i'm doing something wrong or my expectations are too high. the vanilla research.rul would be complicated [beyond comprehension for people like me] if this mechanism was fixed/changed the way i expect it to work, that's why i'm trying to achieve it with a mod.