That doesn't look bad at all. I was worried the second would conflict with the first and get itself deleted too
By the way, does it matter in which order they are listed? What if you did "delete: STR_ID" after "name: STR_ID"? Or is "delete" just removing the previous/older iteration (which would be found in the base ruleset) regardless?
Well, it looks worse than the other way
And as far as I can tell, things are executed in order from top to bottom, so if you did:
- name: STR_AQUA_PLASTICS
dependencies: []
- delete: STR_AQUA_PLASTICS
you would first redefine the dependency, but then remove the project altogether after. That's not a good place to be!
And if I did the above to replace old dependencies for new ones, would it still work? Like this:
- name: STR_AQUA_PLASTICS
dependencies: []
- STR_SONIC_PISTOL
Would that cancel out Deep-One Corpse and add in Sonic Pistol?
Or perhaps I should just stick to the good ol' "delete: STR_ID" method!
If you define new dependencies, they automatically replace the previous one. So if you want the sonic pistol to replace the corpse, all you need to do is:
- name: STR_AQUA_PLASTICS
dependencies:
- STR_SONIC_PISTOL
No need to delete anything. Since a new definition overwrites the old one, if you want both the Deep One and the Sonic Pistol, you need to do:
- name: STR_AQUA_PLASTICS
dependencies:
- STR_DEEP_ONE_CORPSE
- STR_SONIC_PISTOL
I do have totally different question now: when I change weapon stats, does that reflect in the corresponding UFOpedia entry or do I have to update the UFOpedia file separately? Like, if I change Dart Gun's meager power value of 16 to 24 or whatever, would UFOpaedia show this?
The UFOPaedia section of the game is very well done and goes to get all its own data. If you change stats (or pictures) of an already existing item, the UFOPaedia article will automatically load the new data. Nothing to else to do. The only exception is for things like weight, which are NOT displayed generally but some modders add it to the flavour text. If you do that and then change the weight, you need to update the flavour text yourself.
PS: One more question. Does 'unlock' override 'needItem'? Or do I still need to have said item before 'unlock' can come into effect? For example, Sonic Pistol could have Zrbite, Aqua Plastics and Gilman dependencies while research on Gilman Corpse can independently 'unlock' Sonic Pistol. But if Sonic Pistol has 'needItem', does Gilman Corpse research till 'unlock' it or do I have to have Sonic Pistol first?
What
unlock does is make it so that the
dependencies of a given research project count as being fulfilled, regardless of if they actually were. It does
not work if there is also a
requires that has not been satisfied yet. It also does not interact at all with needItem, so you will still need the item. So if you have:
- name: STR_ITEM_C
dependencies:
- STR_PROJECT_A
- STR_PROJECT_B
needItem: true
- name: STR_PROJECT_B
unlocks:
- STR_ITEM_C
Researching project B will make item C researchable even if you haven't completed project A, but you will still need to have item C in your storage, otherwise the project will not show up. All that
unlocks does is get rid of dependencies
if there is no require.
Good catch on the research. It does not seem to have been corrected. For reference, if you want to see the most up to date code without having to update, you can go to
the git repository and look there for the ruleset in bin/standard/xcom2.