View Issue Details

IDProjectCategoryLast Update
0022433AI War 2[All Projects] Bug - OtherDec 27, 2019 10:38 pm
ReporterNRSirLimboAssigned Tox4000Bughunter 
Severityminor 
Status resolvedResolutionfixed 
Product Version1.025 Hotfix 
Fixed in VersionBETA 1.1 So Much Stuff We Can't Even, But More Is Still Coming 
Summary0022433: Flag is_partial_record="true" seemingly does not apply to all properties
DescriptionWith modding stuff I'm never entirely sure if it's me who is doing something wrong or if it's a bug, but I think in this case it is:

As far as I understand the is_partial_record="true" flag should allow to overwrite everything without further input, other than the name (to identify the entity) and whatever properties need to be overwritten. However, If the game is loaded up with for example this:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <entity name="VWing"
            armor_mm="150"
            is_partial_record="true"
    >
    </entity>
</root>

The game complains about requiring more tags.
So I added, copying over this from the default VWing:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <entity name="VWing"
            armor_mm="150"
            is_partial_record="true"
            ship_or_structure_explosion_sfx="ShipSmall_Explosion"
            ship_or_structure_explosion_if_on_other_planet_sfx="ShipLostOnOtherPlanet_Explosion"
    >
    </entity>
</root>

This time everything compiles, but there's a bug yet: The name inside the fleet management screen isn't displayed.
This seemingly can only be fixed by re-adding the name of the unit:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <entity name="VWing"
            armor_mm="150"
            is_partial_record="true"
            ship_or_structure_explosion_sfx="ShipSmall_Explosion"
            ship_or_structure_explosion_if_on_other_planet_sfx="ShipLostOnOtherPlanet_Explosion"
            display_name="V-Wing"
    >
    </entity>
</root>

After this, everything looks in order. But as far as I understand the modding system, it should be possible to have the same result with the very first 3 tags. If it's a bug, I think it's worth fixing for future modding support. If I'm doing something wrong or have a wrong idea about the system, please tell me.
TagsNo tags attached.

Relationships

related to 0021849 resolvedx4000Bughunter XML editing existing units issue 
related to 0022136 resolvedx4000Bughunter Modloader isn't overriding existing entries with is_partial 

Activities

NRSirLimbo

Dec 26, 2019 11:59 am

reporter  

20191226175511_1.jpg (197,680 bytes)
20191226175511_1.jpg (197,680 bytes)
20191226175719_1.jpg (369,876 bytes)

ArnaudB

Dec 26, 2019 1:23 pm

reporter   ~0055164

It IS bugged as I have had the same problem.

On the same vein, mods that aren't in the loading order still load improperly. Specifically, for ships or structures that already exist the data seems to merge, regardless of the presence of partial_record expression in the code.

You can end up with weapons that have the same multipliers twice for instance. Sometimes that'll have no impact but sometimes that will also lead to oddities where you can vanilla plus modded multipliers. For weapons, damage can be multiplied in some weird fashion. I have had Spire Frigate with Beam dealing over 500,000 damage at mark V despite the "Max damage for beam" being capped much lower. More recently we had a likely odd case where Golems didn't gain health and shields per mark.

On a more minor note, when adding modded tech, the tech menu won't properly sort. Back when we didn't have turret tech I added mine and it was always at the bottom despite my attempts to make it appear under the Hulls tech and above defenses/command-station techs. This behavior hasn't changed in since then.

That's my report on modding issue.

x4000Bughunter

Dec 27, 2019 2:50 pm

administrator   ~0055183

Last edited: Dec 27, 2019 2:57 pm

View 2 revisions

Thank you! The specific mod that you have outlined here now works fine for the v-wing, and I've tested that. There are still some other cases in other reports that probably need fixing, and I'm about to look into those. Here's what I've fixed so far:

* Several different things were not staying properly on ships when using an is_partial_record="true" to mod them:
** exp_to_grant_on_death
** watch_planets_at_X_hops
** tags (ow this would cause many problems)
** capturable_seed_weight (again very problematic)
** capturable_max_per_galaxy
** capturable_can_seed_at_all

* Fixed a couple of things that would complain they could not be found properly on ships when using an is_partial_record="true" to mod them (but in reality these were carrying over fine from the base version being modded):
** ship_or_structure_explosion_sfx
** ship_or_structure_explosion_if_on_other_planet_sfx

Specifically, this now works:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <entity name="VWing"
            armor_mm="150"
            is_partial_record="true"
    >
  </entity>
</root>

x4000Bughunter

Dec 27, 2019 3:25 pm

administrator   ~0055185

Thanks!

* If outgoing_damage_modifier or incoming_damage_modifier entries are duplicated in the list of rows for a system or entity (respectively), whether that be through mods or just in the original definition, it now only uses the last-to-apply version. This last-to-apply one is always going to be a mod version if there is a mod version.
** This makes it so that you can't have two different modifiers on the same weapon that both are based off of the hull health of a ship, for example, but I don't think we're doing that anywhere and it would be messy in the UI if we were, anyway.
** This then fixes the issue with various weapon bonuses and the like duplicating themselves when you are using an is_partial_record entry to mod a weapon.
** It's worth noting at this point that xml modding is inherently slightly fraught in terms of minor bugs or oversights like this which can have major repercussions. Please just let us know on a case by case basis what you find, ideally with the xml you're using and a savegame that shows the wrong behavior, and we can likely fix it up pretty fast.

So now this works:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <entity name="FusionBomber"
            armor_mm="150"
            is_partial_record="true"
    >
    <system name="FusionBomb">
      <outgoing_damage_modifier based_on="CurrentPersonalShieldPercentage" applies_to="HullOnly" comparison_type="AtLeast" compared_to="80" multiplier="2" />
    </system>
  </entity>
</root>

x4000Bughunter

Dec 27, 2019 3:39 pm

administrator   ~0055187

As to the tech sorting issue, that's very peculiar. I looked into possible reasons for that, and the code looks good. I revised that a lot earlier this month I think it was, so maybe it was fixed since then? If not, the xml to recreate the problem would be awesome.

x4000Bughunter

Dec 27, 2019 3:42 pm

administrator   ~0055188

Oh, and last note on this topic -- golems not gaining health or whatever per mark is a VERY central sort of bug which means there was an issue during processing, I think. I don't think that's a real bug, but rather a sign that there was another bug that happened earlier and then the later per-mark calculations were not run. I'd need a repro case for that either, so I could fix whatever the root bug is, and then the health and shields incrementing should sort itself out.

Thanks again for all the reports! Please feel free to make new ones for anything new that's coming up (or following on from these comments).

NRSirLimbo

Dec 27, 2019 5:21 pm

reporter   ~0055196

I'm starting to get into modding the game, at least on an XML level, so if I come across anything else I know where to put it, thanks!

x4000Bughunter

Dec 27, 2019 10:38 pm

administrator   ~0055199

Thanks very much! I was going to get this release out today, but then Puffin and I got into some craziness with AI reinforcement budgets and that's dragging into tomorrow.

Issue History

Date Modified Username Field Change
Dec 26, 2019 11:59 am NRSirLimbo New Issue
Dec 26, 2019 11:59 am NRSirLimbo File Added: 20191226175511_1.jpg
Dec 26, 2019 11:59 am NRSirLimbo File Added: 20191226175719_1.jpg
Dec 26, 2019 1:23 pm ArnaudB Note Added: 0055164
Dec 27, 2019 2:50 pm x4000Bughunter Assigned To => x4000Bughunter
Dec 27, 2019 2:50 pm x4000Bughunter Status new => resolved
Dec 27, 2019 2:50 pm x4000Bughunter Resolution open => fixed
Dec 27, 2019 2:50 pm x4000Bughunter Fixed in Version => BETA 1.1 So Much Stuff We Can't Even, But More Is Still Coming
Dec 27, 2019 2:50 pm x4000Bughunter Note Added: 0055183
Dec 27, 2019 2:52 pm x4000Bughunter Relationship added related to 0021849
Dec 27, 2019 2:52 pm x4000Bughunter Relationship added related to 0022136
Dec 27, 2019 2:57 pm x4000Bughunter Note Edited: 0055183 View Revisions
Dec 27, 2019 3:25 pm x4000Bughunter Note Added: 0055185
Dec 27, 2019 3:39 pm x4000Bughunter Note Added: 0055187
Dec 27, 2019 3:42 pm x4000Bughunter Note Added: 0055188
Dec 27, 2019 5:21 pm NRSirLimbo Note Added: 0055196
Dec 27, 2019 10:38 pm x4000Bughunter Note Added: 0055199