Problem with modding the starting base inventory

[clownagent]

I tried to add some items to the starting base with a second ruleset. It seems that the game loses all other information on the starting base including facilities and staff. So to circumvent this one has to copy the whole "starting base" entry from the original ruelset to the second ruleset to circumvent this.

This problem seems to be very similar to the "missing bullet sprite" issue which was fixed in the latest build.

[moriarty]

apparently the behavior of existing strings when adding new ones or trying to modify them is somewhat unpredictable, or at least more complicated than we like to think.

at first I was under the (apparently false) impression that if you define anything new about an item (research, object, manufacture, whatever), everything from before is dropped and only the new values are used.

other people thought that they could add stuff, but the previously existing properties stay unchanged - apparently that's not the case either.

apparently, it is possible to erase string contents by defining "STR_XYZ: {}" as an empty string... but even this has been reported to fail sometimes, if I remember correctly.

is there anybody here with a more complete understanding of how this stuff works?

[Shadow]

Unfortunately, in my experience, it's as haphazard as you describe, moriarty. Sometimes only including new values to the modded ruleset works, and sometimes you need to copy over the whole type, including the stuff you didn't touch.

In a few cases of my own, I had modded:

1) ...the Psi-Amp to use 60% TUs instead of 25 fixed TUs (changing flatRate to false in the process). The result was soldiers somehow never having enough TUs to use the item. SupSuper tested it recently and it seemed to work correctly, so it might've been fixed. I preferred to stick to a flatRate of 40 TUs.
2) ...the power of the Hovertank/Plasma's plasma cannon, and added an auto-shot to the Heavy Laser. In both instances, the bullet sprite disappeared. That was fixed in a very recent build. Oddly enough, I had tweaked the damage of the Hovertank/Launcher's Fusion Bomb, and the projectile never vanished.
3) ...the minimum psiStrength and psiSkill for X-COM soldiers (for less sacking micromanagement and easy screening, respectively). Having left all the other stats untouched, they generated in wild amounts, positive and negative, in the hundreds or thousands. I solved the issue copying over the whole soldier generation block, with all the minimums, maximums and caps, just in case.

[SupSuper]

To clarify these issues, the "modular rulesets" feature isn't something that just "works" out of the box. We can't just make values "optional", we have to explicitly check that a value only replaces another if it's specified so everything works fine and the rulesets are combined properly. In some cases, there will be programming limitations that prevent this from being as seamless as possible, and the behavior will seem odd.

For example, having a number or a string replace another is simple, but stuff like lists, stats and more work as a whole, so specifying one will entirely replace the other, and anything unspecified will become void.

I understand your frustration, this is kind of a programmer mindset, and we try to iron these out as they're reported, but it's not as simple as just "make it modular".

[clownagent]

1) ...the Psi-Amp to use 60% TUs instead of 25 fixed TUs (changing flatRate to false in the process). The result was soldiers somehow never having enough TUs to use the item. SupSuper tested it recently and it seemed to work correctly, so it might've been fixed. I preferred to stick to a flatRate of 40 TUs.

I could reproduce this problem. When you set "flatRate: false" the following happens in the battlescape:
- When you click the Psiamp you get the typical menu with "Mindcontrol" or "Panic Unit". In this menu the TU-cost appears to be correctly calculated with the  "flatRate: false" flag.
- However, when you actually perform the action on an alien, your soldier loses TU as if it was set to "flatRate: true".
- So when you set TU-cost to 60 and flatRate:false, the actual TU-cost for your men was always 60 TU, which was probably too much for them.

This happens also if you change directly the original ruleset. So this is not a problem due to "second ruleset loading".