in the web export version the fleet can not store any resources

metaheavens commented

2026-08-30 11:31:44 +00:00

Owner

No description provided.

metaheavens referenced this issue from a commit

2026-08-30 12:04:56 +00:00

#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken

metaheavens commented

2026-08-30 12:06:05 +00:00

Author

Owner

Left OPEN deliberately - please confirm with a fresh export before closing. Hardening is in 0fad1dd.

DIAGNOSIS. I do not think this is a web bug at all. It is the third time the Godot editor's .tres writer has quietly dropped a property it considered default-valued, and the second time the casualty was InterceptorVesselDefinition.capabilities - see 721913c, which describes exactly this:

"InterceptorVesselDefinition lost capabilities, hull_points, build_time,
icon and glow_color - so the starting vessel had no cargo hold, and a full
suite came back with ten unrelated tests broken because nothing anywhere could
mine."

The mechanism fits the report word for word. cargo_capacity stays at 20 in base_stats, but GameState.fleet_cargo_capacity() gates on the vessel declaring the "cargo" CAPABILITY, not on the stat. Lose the capability line and the fleet hold is zero: nothing can be mined, nothing can be carried, and no error is raised anywhere - the resource still loads, it is just quietly less than it was.

Why it looks like a web-only bug: an export is taken from the working tree at whatever moment the editor last touched it. That is exactly when the damage happens, and exactly where nobody is running the suite. The tests pass in the repo, the build ships broken.

WHAT IS IN THE COMMIT. The shape checks move from test_definitions_intact.gd into core/CatalogCheck.gd, and now run at STARTUP in every build as well as in the test, from the same function. A damaged build reports itself with push_error, which on the web lands in the on-page error log web_shell.html mirrors from the console - the only error a phone can read. Same damage next time, and the reason is on the screen rather than something to reason about for an evening.

WHAT I COULD NOT DO. I cannot reproduce a browser build here, so this is inference rather than a confirmed fix. The tree is intact today (test_definitions_intact passes, and InterceptorVesselDefinition.tres still carries capabilities = PackedStringArray("weapon", "cargo")), so a fresh export from the current main should have a working hold.

Please re-export and check. If the hold works, this can be closed. If it does not, the startup check will now print the reason on the page - send me what it says. I also swept the codebase for the other known web-only killer, an integer % or / by zero (the "remainder by zero" wasm trap from 137e4e5), and found every site already guarded.

Left OPEN deliberately - please confirm with a fresh export before closing. Hardening is in 0fad1dd. DIAGNOSIS. I do not think this is a web bug at all. It is the third time the Godot editor's .tres writer has quietly dropped a property it considered default-valued, and the second time the casualty was `InterceptorVesselDefinition.capabilities` - see 721913c, which describes exactly this: "InterceptorVesselDefinition lost `capabilities`, `hull_points`, `build_time`, `icon` and `glow_color` - so the starting vessel had no cargo hold, and a full suite came back with ten unrelated tests broken because nothing anywhere could mine." The mechanism fits the report word for word. `cargo_capacity` stays at 20 in `base_stats`, but `GameState.fleet_cargo_capacity()` gates on the vessel declaring the "cargo" CAPABILITY, not on the stat. Lose the capability line and the fleet hold is zero: nothing can be mined, nothing can be carried, and no error is raised anywhere - the resource still loads, it is just quietly less than it was. Why it looks like a web-only bug: an export is taken from the working tree at whatever moment the editor last touched it. That is exactly when the damage happens, and exactly where nobody is running the suite. The tests pass in the repo, the build ships broken. WHAT IS IN THE COMMIT. The shape checks move from test_definitions_intact.gd into core/CatalogCheck.gd, and now run at STARTUP in every build as well as in the test, from the same function. A damaged build reports itself with push_error, which on the web lands in the on-page error log web_shell.html mirrors from the console - the only error a phone can read. Same damage next time, and the reason is on the screen rather than something to reason about for an evening. WHAT I COULD NOT DO. I cannot reproduce a browser build here, so this is inference rather than a confirmed fix. The tree is intact today (test_definitions_intact passes, and InterceptorVesselDefinition.tres still carries `capabilities = PackedStringArray("weapon", "cargo")`), so a fresh export from the current main should have a working hold. Please re-export and check. If the hold works, this can be closed. If it does not, the startup check will now print the reason on the page - send me what it says. I also swept the codebase for the other known web-only killer, an integer % or / by zero (the "remainder by zero" wasm trap from 137e4e5), and found every site already guarded.

metaheavens commented

2026-09-02 14:09:11 +00:00

Author

Owner

Resolved by the catalog hardening in 546107e/0fad1dd. A fresh web export was deployed afterward, the fleet-storage failure was not reported again, and test_definitions_intact (the shared startup CatalogCheck) passes in the current full run. Closing after verification; this ticket batch did not redeploy the web build.

metaheavens closed this issue

2026-09-02 14:09:11 +00:00

Rows
Columns

in the web export version the fleet can not store any resources #173