INI parser throws unhandled exception on unimplemented W3DModelDraw fields (breaks Shockwave mod compatibility)

[gpherai]

Summary

Loading a Shockwave 1.201 (+ Shockwave Chaos / Good Balance overlay) object INI file causes an unrecoverable crash during TheThingFactory INI loading. The parser throws an exception on encountering INI fields that appear to be unimplemented, instead of skipping the unknown field/value the way the original retail engine does.

Environment

• GeneralsX Flatpak (com.fbraz3.GeneralsXZH), build tag GeneralsX-Beta-19
• Fedora Linux 44, Wayland
• Mod: C&C: Shockwave v1.201 base install, with a Shockwave Chaos / "Good Balance" overlay applied on top (.gib archives renamed to .big so they get picked up by loadBigFilesFromDirectory, since the loader only globs *.big)

Steps to reproduce

1. Install vanilla Zero Hour data + Shockwave 1.201 into the flatpak's game-data directory (files land in the ZH root next to Generals.exe, same layout retail installers use)
2. Ensure the mod's .big/.gib archives are present with .big extension so StdBIGFileSystem::loadBigFilesFromDirectory(dir, "*.big", ...) mounts them
3. Launch flatpak run com.fbraz3.GeneralsXZH
4. Observe the log during TheThingFactory -> loadFileDirectory('Data\INI\Object')

Observed

[INI] load('Data\INI\Object\china\specialweapons\defences\hellstorm.ini') START
[INI] load - calling prepFile('Data\INI\Object\china\specialweapons\defences\hellstorm.ini') START
[INI] load - prepFile completed
[INI] ERROR in load('Data\INI\Object\china\specialweapons\defences\hellstorm.ini') - exception caught

The process terminates shortly after (no further log output, process no longer running).

Likely cause

HellStorm.ini's W3DModelDraw block uses fields that I could not find anywhere in the GeneralsMD source tree via grep -r:

• WeaponFireFXBone
• WeaponRecoilBone
• ProjectileBoneFeedbackEnabledSlots
• MAINTAIN_FRAME_ACROSS_STATES (as a Flags value)

These are original SAGE-engine fields already used by Shockwave back in 2016 (long before this port), so retail Zero Hour 1.04 clearly supports them. It looks like the INI field dispatch table for W3DModelDraw/draw-module parsing doesn't have entries for these yet, and encountering an unknown field currently throws instead of warning-and-skipping (which is what I'd expect the original engine's behavior to be).

Impact

Since these fields are common across many Shockwave (and by extension Shockwave Chaos) unit/building art definitions, this isn't isolated to one file — it looks like it will hit most of the mod's larger object definitions, making the mod effectively unplayable on this port in its current state.

Suggested fix direction

• Add the missing field parsers to the W3DModelDraw INI field table (GeneralsMD and Generals variants), matching retail 1.04 behavior
• Regardless of the above, consider making unknown-field parsing failures non-fatal (log + skip) rather than throwing, to match original engine tolerance and avoid single unsupported fields taking down the whole INI load

Happy to provide the extracted INI file or more log context if useful.

[gpherai]

Correction to my original root-cause claim

I dug further into this and need to walk back the "missing field" hypothesis from the original report. I had grepped only GeneralsMD/Code/GameEngine for the field names, which missed the actual implementation location. All four fields I flagged as unimplemented are in fact present and wired up correctly in Core/GameEngineDevice/Source/W3DDevice/GameClient/Drawable/Draw/W3DModelDraw.cpp:

• WeaponFireFXBone, WeaponRecoilBone — in W3DModelDrawModuleData::parseConditionState's field table
• ProjectileBoneFeedbackEnabledSlots — in W3DModelDrawModuleData::buildFieldParse's field table
• MAINTAIN_FRAME_ACROSS_STATES — defined in the ACBits enum and ACBitsNames table used by the Flags field

I also checked every module type referenced in the file (StructureBody, AIUpdateInterface, WeaponSetUpgrade, GenerateMinefieldBehavior, etc.) — all registered, all present.

I tried to isolate the exact failing line by building a minimal single-file BIG archive (containing only HellStorm.ini) layered on top of an otherwise-vanilla install, to bisect the file. That test itself hit an unrelated failure (ERROR: No files read from directory 'Data\INI\Default\Weather') that I believe is due to my own hand-rolled BIG packer not being fully spec-compliant (missing some field/alignment/checksum the real archive reader expects), not a second engine bug — so I can't treat that result as reliable and won't speculate further on it.

Net result: I can no longer point at a specific missing field or line as the cause. What's still solid and reproducible from the original report:

• Environment (GeneralsX-Beta-19, Flatpak, Fedora 44)
• The exact failure signature: [INI] ERROR in load('Data\INI\Object\china\specialweapons\defences\hellstorm.ini') - exception caught, process terminates shortly after
• The file is Shockwave 1.201's HellStorm.ini (a China/SpecialWeapons building), loaded via TheThingFactory → Data\INI\Object

Given I can't confirm the actual root cause, please treat the "suggested fix direction" in the original post as withdrawn. Happy to attach the actual HellStorm.ini file if that helps someone bisect it faster than I could from the outside — let me know.

[fbraz3]

To be honest I haven’t tested myself these mods. Could you provide the download link and install instructions? Thanks!

[gpherai]

Did a full fresh re-test of this today. Answering your question first, then the new findings.

Download / install (what you asked for)

• ShockWave 1.201: https://www.moddb.com/mods/cc-shockwave/downloads/shockwave-version-12
• Installer is a self-extracting Windows .exe wizard (no silent/CLI install option — confirmed by inspecting the archive format and the bundled Readme). Run it (Wine/Proton works fine) and point the install path at your Zero Hour data directory (for GeneralsX this is whatever CNC_GENERALS_ZH_PATH points to).
• After install, the mod's files land as !Shw*.gib (13 archives) in that directory. GeneralsX's loader only globs *.big, so on their own these .gib files are silently ignored — no error, no crash, game just boots normally without the mod. You have to copy/rename each !Shw*.gib to !Shw*.big for the loader to pick them up. That rename is also what makes the crash reproduce.

Re-tested from scratch — confirmed crash, but not always the same file

Did a completely clean install (fresh ShockWave 1.201 download, GeneralsX-Beta-19-era build) and reproduced the crash immediately after the .gib→.big rename. This time it wasn't HellStorm.ini that crashed first — it was:

Release Crash at Wed Sep 16 11:23:35 2026
; Reason Error parsing INI file 'Data\INI\Object\china\infantry\infantry\minigunnersquad.ini' (Line: 'Object Infa_ChinaInfantryMinigunnerSquadNexus ')

So this isn't isolated to HellStorm.ini — it hits the first china\infantry\... object file alphabetically, before the loader even reaches china\specialweapons\...\HellStorm.ini. Confirms this affects a broad set of the mod's object definitions, not one file.

Both crashes report the crash-handler's "current object being parsed" as literally the block's first line (Line: 'Object <name> '), which is the SAGE crash-reporter convention for "here's the last checkpoint we were in", not necessarily the exact failing field/line.

One thing both crashing files have in common: both use WeaponFireFXBone fairly early in their W3DModelDraw/ConditionState block. I know the earlier correction in this thread found that field implemented in W3DModelDraw.cpp — so I'm not re-asserting it as the cause, just flagging the pattern in case it's useful for narrowing things down.

I extracted both full INI files directly from the mod's !Shw_ini.big (BIG archive format, parsed directly) so you don't have to install anything to look at them:
https://gist.github.com/gpherai/779ed1054f356c3911a5b31a30ab99d7

Note on testing against 1.0.0

I tried to re-test this against the just-released 1.0.0 to see if it's still an issue on current stable, but hit a separate, more fundamental crash first — vanilla Zero Hour (no mods at all) fails to start on 1.0.0 in my environment. Filed that separately since it's unrelated to Shockwave: #305. Until that's sorted I can't get a clean 1.0.0 repro for this issue specifically — happy to re-test #297 against 1.0.0 once #305 is resolved.

Let me know if you want anything else from my end (raw crash logs, the full !Shw_ini.big archive, etc).

[arazmj]

Thanks for correcting the W3D diagnosis and sharing both INI files. You're right that those fields are already implemented.

I found two more concrete candidates: the very large SpawnReplaceDelay in MinigunnerSquad.ini and RecenterTime in HellStorm.ini. Both exceed the signed 64-bit intermediate our current Linux numeric parser uses. That makes them rejection points, although I haven't confirmed which field fails first in your full installation.

The error reporting is also getting in the way: outer handlers replace the useful nested error with the Object ... line you saw. I've opened #323 to keep the actual field/file/line details and print the numeric conversion reason. It doesn't change how those values are interpreted, so this is not a Shockwave compatibility fix yet.

Once the separate vanilla-startup problem in #305 is cleared, could you attach the startup log from a build that includes #323? That should help us identify the first real failure rather than guessing from the outer Object header.

[gpherai]

Re-tested against 1.0.1 (Flatpak com.fbraz3.GeneralsXZH, commit 65b7bd1a2243aaf0347887ab4787a74ec6e7ed9a8884bfb55b715d16d923ab31), same Shockwave 1.201 install + .gib→.big rename as before.

Confirms @arazmj's hypothesis exactly

With #323's improved diagnostics in place, the failure is now fully explicit — no more guessing from the outer Object ... header:

[INI] load('Data\INI\Object\china\infantry\infantry\minigunnersquad.ini') START
[INI] load - calling prepFile('Data\INI\Object\china\infantry\infantry\minigunnersquad.ini') START
[INI] load - prepFile completed
[INI] Cannot parse numeric token '9999999999999999999': out of range
[INI] ERROR in load('Data\INI\Object\china\infantry\infantry\minigunnersquad.ini') - exception caught

ReleaseCrashInfo.txt pinpoints it precisely:

Release Crash at Wed Sep 23 17:51:18 2026
; Reason [LINE: 220 - FILE: 'Data\INI\Object\china\infantry\infantry\minigunnersquad.ini'] Error reading field 'SpawnReplaceDelay'

Line 220 of the mod's MinigunnerSquad.ini (extracted directly from !Shw_ini.big):

SpawnReplaceDelay = 9999999999999999999 ; 5 Years

Root cause, traced in source

SpawnReplaceDelay is registered against INI::parseDurationUnsignedInt (GeneralsMD/Code/GameEngine/Include/GameLogic/Module/SpawnBehavior.h:85), which bottoms out in the generic INI::scanType<Type>() template in Core/GameEngine/Source/Common/INI/INI.cpp. For integral types it parses into an intermediate Int64 via std::from_chars:

std::conditional_t<std::is_integral_v<Type>, Int64, Type> result{};
const auto [ptr, ec] = std::from_chars(token.data(), token.data() + token.size(), result);

if (ec != std::errc{})
{
    // GeneralsX @bugfix Copilot 20/09/2026 Identify overflowing mod values without changing their interpretation.
    fprintf(stderr, "[INI] Cannot parse numeric token '%.*s': %s\n", ...);
    throw INI_INVALID_DATA;
}

9999999999999999999 (~1.0×10^19) exceeds INT64_MAX (~9.22×10^18), so from_chars returns result_out_of_range and the load throws — aborting the entire object file's parse instead of just that one field.

Your other flagged candidate, RecenterTime = 99999999999999999999999999999999 in HellStorm.ini, goes through the exact same path (TurretAI.cpp:266, also parseDurationUnsignedInt) and is even further out of range (~1×10^32). Same bug, same fix would cover both.

This looks like retail's original engine just did an unchecked atoi/sscanf-style conversion that silently wraps/truncates on overflow instead of erroring — harmless in practice here, since the mod author's intent with 9999999999999999999 ; 5 Years is just "effectively never happens," and any garbage-but-large wrapped value achieves the same in-game effect.

One behavior improvement worth noting

Unlike the 1.0.0 run in the original report, this no longer produces an uncaught-exception SIGABRT/coredump — the process now exits cleanly (exit code 1) after printing the diagnostic. So #323 did make this fail safer, just not survivable yet.

Suggested fix

In scanType<Type>(), on result_out_of_range for integral types, saturate to the field's max representable value (with a warning logged) instead of throwing — matching retail's tolerance for these "so large it doesn't matter" mod idioms, rather than hard-failing the whole object definition.

Happy to test a patched build against my full Shockwave 1.201 + Chaos/Good Balance overlay install if useful.

[fbraz3]

@gpherai could you please test if this build fixes the issue? thanks!
https://github.com/fbraz3/GeneralsX/actions/runs/36165240070

[gpherai]

Thank you for taking the time to work on these issues. I understand that it is not part of the original game.

Tested the fix build from this thread (Linux Flatpak, commit 9464033b701216f92f0561093fbc791c7156229c52d469e22a842cc1e82d9ba2, from the fix/issue-297-ini-overflow-saturation CI run) against a full Shockwave 1.201 install (all !Shw*.gib renamed to .big).

Confirmed fixed. No crash. Both previously-reported overflow fields now saturate correctly instead of throwing:

[INI] Numeric token '9999999999999999999' out of range, saturating to limit
[INI] Numeric token '99999999999999999999999999999999' out of range, saturating to limit

I played multiple full skirmish matches to completion with no crashes. I could also play as a Shockwave general myself (Armor, Salvage, Special Weapons General) against non-Shockwave AI opponents without any issues on my side — so that part of the compatibility is solid.

While testing this, I did run into a separate, unrelated bug — opened as #335 so it doesn't clutter this thread: the skirmish AI itself never builds anything when it's assigned one of Shockwave's new generals. Not asking you to fix that here, just linking it in case it's useful context since it came out of this same test pass.

Thanks again for the quick turnaround on this one!