Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
extends SceneTree
|
|
|
|
|
|
|
|
|
|
# Headless test: run with
|
|
|
|
|
# godot --headless -s res://tests/test_definitions_intact.gd
|
|
|
|
|
#
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# A guard against a failure mode that has now cost this project three times,
|
|
|
|
|
# and every time silently.
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
#
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# Opening the project in the Godot editor re-saves .tres files, and its writer
|
|
|
|
|
# DROPS properties it considers default-valued. An empty-looking
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
# PackedStringArray is the usual casualty: GasBurnerBuildingDefinition lost
|
|
|
|
|
# `capabilities` and `collected_outputs` once (which took the gas burner's
|
|
|
|
|
# whole conversion with it), and InterceptorVesselDefinition later lost
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# `capabilities`, `hull_points`, `build_time`, `icon` and `glow_color` - which
|
|
|
|
|
# cost the starting vessel its cargo hold, so nothing could be mined.
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
#
|
|
|
|
|
# Neither showed up as an error. The resource still loaded; it was just
|
|
|
|
|
# quietly less than it had been, and the failure surfaced somewhere else
|
|
|
|
|
# entirely - a full suite reporting ten unrelated tests broken.
|
|
|
|
|
#
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# The checks themselves have moved to core/CatalogCheck.gd, because #173 was
|
|
|
|
|
# the same damage a THIRD time and reached a shipped web build: a fleet that
|
|
|
|
|
# could not store any resources. A test only guards the tree at the moment
|
|
|
|
|
# somebody runs it, and an export is taken from the tree at whatever moment
|
|
|
|
|
# the editor last touched it. The same function now runs at startup in every
|
|
|
|
|
# build (GameState._ready) and here, so the two can never drift apart and a
|
|
|
|
|
# damaged build says so on its own.
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
#
|
|
|
|
|
# Covers:
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# A. the catalogue is whole - every vessel and building carries the things
|
|
|
|
|
# that make it what it is, and the paired facts agree
|
|
|
|
|
# B. the shipped build asks the same question, from the same code, so this
|
|
|
|
|
# test is not a promise the game does not keep
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
var stage: int = 0
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
func _initialize() -> void:
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
# --- A. nothing has been eaten ---------------------------------------
|
|
|
|
|
var faults: PackedStringArray = CatalogCheck.faults()
|
|
|
|
|
if not faults.is_empty():
|
|
|
|
|
for message in faults:
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
print(" - %s" % message)
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
print("TEST_DEFINITIONS_INTACT: FAIL (%d definition(s) came back incomplete)" \
|
|
|
|
|
% faults.size())
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
quit(1)
|
|
|
|
|
return
|
|
|
|
|
print("%d vessels and %d buildings, all intact" \
|
|
|
|
|
% [VesselDefinitions.all().size(), BuildingDefinitions.all().size()])
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
func _process(_delta: float) -> bool:
|
|
|
|
|
if stage != 0:
|
|
|
|
|
return false
|
|
|
|
|
stage = 1
|
|
|
|
|
|
|
|
|
|
# --- B. and the build itself checked, from the same code -------------
|
|
|
|
|
# The whole point of #173 is that the suite is not where this damage gets
|
|
|
|
|
# noticed. GameState runs the check on startup and keeps what it found, so
|
|
|
|
|
# a build with an eaten .tres reports it instead of quietly failing to
|
|
|
|
|
# mine - on the web, into the on-page error log.
|
|
|
|
|
var game_state: Node = root.get_node("GameState")
|
|
|
|
|
if not (game_state.catalog_faults is PackedStringArray):
|
|
|
|
|
return _fail("GameState does not record what the startup check found")
|
|
|
|
|
if not game_state.catalog_faults.is_empty():
|
|
|
|
|
return _fail("the running build reports %d catalog fault(s) this test did not" \
|
|
|
|
|
% game_state.catalog_faults.size())
|
|
|
|
|
var source: String = FileAccess.get_file_as_string("res://core/GameState.gd")
|
|
|
|
|
if "CATALOG_CHECK.faults()" not in source or "push_error" not in source:
|
|
|
|
|
return _fail("GameState no longer runs the catalog check at startup, so a damaged build would ship silently again")
|
|
|
|
|
print("the running build ran the same check on startup and found nothing")
|
|
|
|
|
|
Guard the definition catalog against silent .tres property loss
Opening the project in the Godot editor re-saves .tres files, and its writer
DROPS properties it considers default-valued. An empty-looking
PackedStringArray is the usual casualty, and it has now cost this project
twice - both times silently, and both times the damage surfaced somewhere
else entirely:
GasBurnerBuildingDefinition lost `capabilities` and `collected_outputs`,
which took the burner's whole conversion with it.
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.
Neither raised an error. The resource still loaded; it was just quietly less
than it had been.
test_definitions_intact asserts the SHAPE of the catalog rather than any one
value: every vessel has a name, stats, a hull and its components; a hold and
a "cargo" capability imply each other; every building has a description, a
price, hit points, its build-menu wiring and at least one capability; and a
converter keeps the fields its conversion needs. Whatever the editor eats
now fails here, next to the thing that was eaten.
Verified against both real incidents by reproducing them: deleting the
interceptor's capabilities line fails with "cargo_capacity 20.0 but
capabilities []", and deleting the burner's collected_outputs fails with
"converts but lists no collected outputs".
The first draft of that last check looked for the conversion fields on the
DEFINITION, where they are not - they live on its logistics sub-resource -
so it answered null and never fired. It passed while the burner sat there
broken, which is the same class of quiet as the bug it is guarding.
Also restores what the editor took from the gas burner this time round.
2026-08-29 14:38:51 +02:00
|
|
|
print("TEST_DEFINITIONS_INTACT: PASS")
|
|
|
|
|
quit(0)
|
#166-#173: plainer words, a point to shoot at, and a catalog that says when it is broken
Eight tickets. The last one is the interesting one.
#166 - PLAINER DIALOG. Every spoken line rewritten: the nine prologue lines and
all twenty quest brief/done pairs. Mostly splitting em-dash subclauses into
sentences and dropping the literary register ("hulls" -> "ships", "That is our
hands back" -> "That frees us for other work"). Same meaning, same voice.
#167 - NOTHING ANNOUNCED TWICE. Quests carry an `important` flag; seven of the
twenty have it, and they are the search for the World Ship. A quest handed out
with its goal ALREADY met is now credited in silence unless it is one of those
- no brief, no answer, both signals still fired and the index still moved, so
it appears ticked in the objectives panel. The chain used to stop the game to
set a task the player had already done, then stop it again to congratulate
them on it.
#168 - THE KEYBOARD CAN ANSWER A DIALOG. The rule the ticket asks for (still
arriving, show it all; already whole, move on) was already the rule for a
click since #149, but a key press reached the banner and did nothing - and
this game is played with WASD and a mouse. Touch, click and key now go through
one door. Modifiers alone and auto-repeat echoes are not presses.
#169 - A LOADING SCREEN. A press raises a cover, and the load happens after it
has been on screen for a frame, so the wait is something the player is
watching. Deliberately still a blocking load: load_threaded_request() comes
back FAILED for these scenes, reporting text-parse errors that load() does not
produce, because the global class names and preloads they reach each other
through are not resolvable off the loading thread. A progress bar is not worth
a menu that sometimes refuses to start the game, and the web build ships with
thread support off anyway. Further presses while loading are ignored - on the
web a button fires on PRESS, so an impatient double tap costs nothing to make
and used to build the world twice.
#170 - THE PICTURE BEFORE THE CAPTION. The prologue's first line was up before
the scene had finished arriving, so the game opened STOPPED (#128) over a
convoy nobody had seen yet. It flies for three seconds first.
#171 - THE CONTROLS FOLLOW WHAT IS BEING HELD. is_touchscreen_available() asks
whether a touch COULD arrive, and in a browser that is yes on any laptop whose
panel reports touch support - so the web build put thumb sticks over a screen
being played with a mouse, and switched mouse aiming off on the machine it
exists for. The reading is now the last input actually used, it lives in
GameState so the sticks and the guns cannot disagree, and it is two-way:
nothing can strand a tablet, because the gesture that needs the controls is
the gesture that brings them back. A touch suppresses mouse evidence for a
second, so the click Godot manufactures out of a tap is not mistaken for a
mouse.
#172 - AIM AT A PLACE. Every gun was handed the same direction, so a fleet
firing at something threw a sheet of parallel bolts past either side of it and
only the middle hull could hit - worse the wider the formation. Guns now take
a POINT and each hull works out its own heading to it, so the fleet's fire
converges. The mouse already had a place and was flattening it into a bearing;
a pushed stick names the point at the guns' reach along it, so touch loses
nothing. The assist (#89) still bends a shot onto an enemy, now per hull and
around that hull's own heading. The aim guide stops at the point and marks it.
#173 - AND THE ONE THAT EXPLAINS ITSELF. "In the web export version the fleet
can not store any resources" is not a web bug. It is the third time the Godot
editor's .tres writer has quietly dropped a property it thought was
default-valued: InterceptorVesselDefinition losing `capabilities` leaves
cargo_capacity at 20 and takes away the "cargo" claim that
fleet_cargo_capacity() actually gates on, so the hold is zero and nothing can
be mined or carried. That is the symptom, word for word.
test_definitions_intact caught it in the suite. What it could not do is catch
it in a BUILD - an export is taken from the working tree at whatever moment
the editor last touched it, which is exactly when the damage is done and
exactly where nobody is running tests. The checks move to core/CatalogCheck.gd
and now run at startup in every build as well as in the test, from the same
function. On the web push_error lands in the on-page log web_shell.html
mirrors, which is the only error a phone can read.
The tree is intact today, so a fresh export should restore the hold. The point
of the change is that the next time it is not, the build says so.
Full suite green at 154/154.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0139MmxRAJSUe1j77kftAWv3
2026-08-30 14:04:46 +02:00
|
|
|
return true
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _fail(message: String) -> bool:
|
|
|
|
|
print("TEST_DEFINITIONS_INTACT: FAIL (%s)" % message)
|
|
|
|
|
quit(1)
|
|
|
|
|
return true
|