[Solved] Rosigma issue (armor naming)

[Leflair]

Hey Meridian, trying to get 40k+Rosigma to work with OXCE 7.6.0 but running into a few errors consistently that weren´t there with version pre 7.6.0:

Both relate to 2 armors held by the main mod (40k) and referenced by the submod (ROSIGMA). First error that popped up right away after updating (validation level 0):
Error processing 'STR_FLOATER_ARMOR1' in armors: Geo corpse item cannot be empty.
Error processing 'STR_FLOATER_ARMOR2' in armors: Geo corpse item cannot be empty.

Odd error, as Open X-Com (not extended) should default to corpseBattle if geo is not mentioned(?). ROSIGMA simply refers back to 40k main mod on this one, no corpses mentioned in the code. 40k does have corpseBattle assigned, like so:
  - type: FLOATER_ARMOR2
/.../
    corpseBattle:
      - STR_FLOATER_CORPSE

Now, copying that corpseBattle and putting it into the submod armor code instead gives this error (or changing to validation level 2):
[ERROR]   During linking rulesets of armors:
Error for 'STR_FLOATER_ARMOR1': Number of battle corpse items for 'corpseBattle' does not match the armor size.
Error for 'STR_FLOATER_ARMOR2': Number of battle corpse items for 'corpseBattle' does not match the armor size.
Doesn´t seem to solve anything.

Extended log with validation level 0:
 [ERROR]    Supressed Error for 'STR_FLOATER_ARMOR1': Number of battle corpse items for 'corpseBattle' does not match the armor size.
 [ERROR]    Supressed Error for 'STR_FLOATER_ARMOR2': Number of battle corpse items for 'corpseBattle' does not match the armor size.
 [ERROR]    During linking rulesets of armors:
Error processing 'STR_FLOATER_ARMOR1' in armors: Geo corpse item cannot be empty.
Error processing 'STR_FLOATER_ARMOR2' in armors: Geo corpse item cannot be empty.

Any ideas? This is all the openxcom error log gives me on these errors.

e: I´ve tried on 2 computers, checked that there´s no double-read issue with some mod.zip file leftover in the mod folder, wiped the previous mod folder etc.

This is a "During linking rulesets of armors", as it only happens with the submod (but didn´t previous to 7.6.0).

[Meridian]

can I use the mod portal versions of 40k and rosigma to test this or do I need a newer version?

Edit: probably not, the versions from the mod portal started without problems for me, I used `40k_032.zip` and `rosigma1.08f2.zip`
Can you share the version that fails please?

[Leflair]

Mod portal 40k should work, that one is not updated yet.

Here´s the latest build of rosigma that uses some 7.6.0 functions:
https://github.com/BeatAroundTheBuscher/ROSIGMA/archive/refs/heads/main.zip

That is, 40k 032 + this rosigma 1.09 version.

[Meridian]

Both relate to 2 armors held by the main mod (40k) and referenced by the submod (ROSIGMA). First error that popped up right away after updating (validation level 0):
Error processing 'STR_FLOATER_ARMOR1' in armors: Geo corpse item cannot be empty.
Error processing 'STR_FLOATER_ARMOR2' in armors: Geo corpse item cannot be empty.

Both of these armors exist only in ROSIGMA, they don't exist in 40k nor xcom1.

Did you maybe mean to use `FLOATER_ARMOR1` and `FLOATER_ARMOR2` instead?

--
And one unrelated issue... the zip file you provided has duplicate filename (with different cases), about a dozen of them, which cannot exist on Windows simultaneously (and cannot be handled by OXC/E either).
For example: `cas_gun.PNG` and `cas_gun.png`

[Leflair]

Ah, the STR_was from an attempted fix with R1d0 input, reveresed it (didn't make a difference).

Just overwrite the duplicates.

[Meridian]

Ah, the STR_was from an attempted fix with R1d0 input, reveresed it (didn't make a difference).

so, is it fixed now?
not 100% clear from the sentence whether r1d0's input didn't make a difference or if the reverse didn't make a difference

Just overwrite the duplicates.

I did, but they are not the same... so sometimes you get one and sometimes you get another one... can cause a lot of headaches and not reproducible bugs in the future.

[Leflair]

I don't know if there's a way to point out case sensitive "duplicates" in github, it's not exactly a useful feature.

I've reversed the STR_ stuff.

[Meridian]

I've reversed the STR_ stuff.

Did it help?
(Can I close the issue?)

[Leflair]

no it makes no difference to this issue.

[Meridian]

no it makes no difference to this issue.

I checked github:
you did not revert all of them, STR_ versions still exist in `scripts_ranged_dodge.rul`

[R1dO]

Both (my input and the reverse) did not change.

My input was on discord.
It was based on the errors/ruleset snip posted there and a download provided by leflair.
The snippets all showed "-type: FLOATER_ARMOR2", while the download had some references to "STR_FLOATER_ARMOR2", see below:

Code: [Select]

ROSIGMA-main/Ruleset/scripts/scripts_ranged_dodge.rul:  - type: STR_FLOATER_ARMOR0   
ROSIGMA-main/Ruleset/scripts/scripts_ranged_dodge.rul:  - type: STR_FLOATER_ARMOR1 
ROSIGMA-main/Ruleset/scripts/scripts_ranged_dodge.rul:  - type: STR_FLOATER_ARMOR2

Since i was not able to tell (at that time) which of the two was intended (STR_ on non STR_) i pointed out the difference in "-type:" definitions.
Leflair tried to change the armor one, that did not help. After that he undid those changes (i assume) which didn't help either.

Hope this makes thing a bit more clear to you.

Edit:
Those STR_ snippets in the scripts were there before the request for help. That is probably why those were not reverted yet (did not touch them today).

[Leflair]

The script one is reversed too.

Again, has nothing to do with the geo corpse issue.

[Meridian]

I reverted also the STR_ in `scripts_ranged_dodge.rul` and it starts correctly for me now.

[Leflair]

It does run!

Although no idea what fixed it. I only added the STR_ when R1d0 pointed out they were missing, and now removed them from those files.

I guess the new ranged script had the STR_ by default (because STR_FLOATER_ARMOR1 has STR_ in vanilla 40k, but FLOATER_ARMOR1 and 2 does not have STR_... so easy to mix up).

A completely unintended fix, but I'll take it.

[Meridian]

Glad to hear it helped.

I'll provide also the other duplicate filenames... in 1 hour or so.