Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
extends SceneTree
|
|
|
|
|
|
|
|
|
|
# Headless test: run with
|
|
|
|
|
# godot --headless -s res://tests/test_menu_polish.gd
|
|
|
|
|
# Forgejo #111, #112, #119 and #120 - four panels that were hard to read,
|
|
|
|
|
# each for its own reason. Grouped because they are all "what does this
|
|
|
|
|
# panel actually show", and because each alone is a handful of assertions.
|
|
|
|
|
#
|
|
|
|
|
# Covers:
|
|
|
|
|
# A. #111 - the craft menu names no resources: prices are glyphs, and
|
|
|
|
|
# every vessel gets a caption that does not overlap its neighbour
|
|
|
|
|
# B. #111 - and a price strip really carries the vessel's cost
|
#145, #144, #143: a quest that could not be finished, and two boxes that overhung
#145 - the extractor quest could never be completed. Extractors are placed
onto a planet from space and live in GameState.extractors, with their own
position, stock and id; they are not in `buildings`. So the goal asked
has_building_of_type("extractor"), which is false however many the player
builds. Not the death the reporter guessed at - the quest was simply asking
a question that had no yes.
structure_exists() is the question anything wanting "does the player have
one of these" should ask, and the quest model asks it now. The regression
test builds every structure quest's target THE WAY THE GAME BUILDS IT and
watches the goal flip, rather than knowing which array each one lands in -
the knowing is what got this wrong in the first place.
#144 - the build menu's status line is anchored to the top of the panel and
its grid to the panel's centre, so the gap between the two is half the panel
height. It was a written-down constant, correct only at 1280 tall; at 1080
the grid started four pixels ABOVE the status line and drew through it.
Nothing about that geometry is written against a screen size any more. The
band is measured from the header that is actually there, the pitch closes up
to fit it (never below a row's own height, which is what makes overlap
impossible rather than unlikely), and the column count rises until the rows
fit - so a short window gets a wide grid instead of one running off the
bottom. Ten structures now lay out as 5 columns at 900px tall, 4 at 1080, 3
at 1280 and 2 at 1600, clearing the header at every one, which is what the
test walks.
#143 - a hangar caption is "Gas Bomber\n2 available": two lines before
autowrap and three after it in a narrow column, at a size fixed in the
scene. Labels do not clip by default, so the third line was drawn over the
icon of the row below. The size is fitted to the box the layout works out,
and the box clips - the first keeps it legible, the second keeps it correct
however the vessel names grow.
Its box also overhung by exactly HANGAR_LABEL_GAP: the layout subtracted one
gap where it needed two, above the caption and below it. Two pixels, but two
pixels inside the next row's icon.
2026-08-29 12:51:09 +02:00
|
|
|
# D. #143 - a hangar caption fits the box it was given and cannot draw
|
|
|
|
|
# outside it, so it never lands on the icon of the row below
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
# E. #147 - a price with several resources goes one per line and stays
|
|
|
|
|
# inside its own box, close to the button it is about
|
|
|
|
|
# F. #147 - and no craft entry overlaps another
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
# C. #120 - the hangar's captions have room for two lines, and there is a
|
|
|
|
|
# rule between what is parked and what is flying
|
|
|
|
|
# D. #112 - every skill node has a mark, and a node that unlocks a
|
|
|
|
|
# building uses that building's own icon
|
|
|
|
|
# E. #119 - the command centre draws the vessels actually in the fleet,
|
|
|
|
|
# not one placeholder repeated
|
|
|
|
|
|
|
|
|
|
var game_state: Node
|
|
|
|
|
var scene: Node
|
|
|
|
|
var controller: Node
|
|
|
|
|
var stage: int = 0
|
|
|
|
|
var elapsed: float = 0.0
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _initialize() -> void:
|
|
|
|
|
# GameState is an autoload: a bare GameState.<instance member> does not
|
|
|
|
|
# compile in a SceneTree script, so the node is fetched by name instead.
|
|
|
|
|
game_state = root.get_node("GameState")
|
|
|
|
|
game_state.buildings.clear()
|
|
|
|
|
game_state.extractors.clear()
|
|
|
|
|
game_state.reset_progression()
|
|
|
|
|
game_state.reset_waves()
|
|
|
|
|
game_state.reset_formation()
|
|
|
|
|
game_state.intro_active = false
|
|
|
|
|
game_state.rocks = 5000
|
2026-09-05 17:09:27 +02:00
|
|
|
# #219: fleet capacity is built now - one berth free, one per Fleet
|
|
|
|
|
# Office. This test flies more than one vessel, so it needs the offices
|
|
|
|
|
# standing before the fleet spawns into them.
|
|
|
|
|
load("res://tests/_berths.gd").grant(root.get_node("GameState"), 6)
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
scene = load("res://world/Main.tscn").instantiate()
|
|
|
|
|
root.add_child(scene)
|
|
|
|
|
current_scene = scene
|
|
|
|
|
controller = scene.get_node("BuildController")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _fail(message: String) -> bool:
|
|
|
|
|
print("TEST_MENU_POLISH: FAIL (%s)" % message)
|
|
|
|
|
quit(1)
|
|
|
|
|
return true
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
func _process(delta: float) -> bool:
|
|
|
|
|
elapsed += delta
|
|
|
|
|
match stage:
|
|
|
|
|
0:
|
|
|
|
|
if elapsed < 0.4:
|
|
|
|
|
return false
|
|
|
|
|
scene.get_node("AsteroidField").set_process(false)
|
|
|
|
|
scene.get_node("EnemySpawner").set_process(false)
|
|
|
|
|
|
|
|
|
|
# --- A. the craft menu spells no resource out -------------
|
|
|
|
|
controller.craft_building_id = 1
|
|
|
|
|
controller._refresh_craft_status()
|
|
|
|
|
# The caption is the vessel's NAME and nothing else. Checked as an
|
|
|
|
|
# exact match rather than by hunting for resource words in it: a
|
|
|
|
|
# Gas Bomber is named after a resource and always will be, and
|
|
|
|
|
# what #111 removed was the PRICE spelled out underneath.
|
|
|
|
|
var fleet_defs: Array = VesselDefinitions.fleet()
|
2026-08-31 02:18:08 +02:00
|
|
|
for i in range(mini(controller.craft_menu.vessel_labels.size(), fleet_defs.size())):
|
|
|
|
|
var caption: String = String(controller.craft_menu.vessel_labels[i].text)
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
var expected: String = String(fleet_defs[i].display_name)
|
|
|
|
|
if caption != expected:
|
|
|
|
|
return _fail("a craft caption reads \"%s\", expected just \"%s\"" \
|
|
|
|
|
% [caption, expected])
|
|
|
|
|
# Captions must not sit on top of one another, which is what
|
|
|
|
|
# made the old single row unreadable.
|
2026-08-31 02:18:08 +02:00
|
|
|
for i in range(controller.craft_menu.vessel_labels.size()):
|
|
|
|
|
for j in range(i + 1, controller.craft_menu.vessel_labels.size()):
|
|
|
|
|
var a: Control = controller.craft_menu.vessel_labels[i]
|
|
|
|
|
var b: Control = controller.craft_menu.vessel_labels[j]
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
if Rect2(a.position, a.size).intersects(Rect2(b.position, b.size)):
|
|
|
|
|
return _fail("craft captions %d and %d overlap" % [i, j])
|
|
|
|
|
print("craft captions: %d, one line each, none overlapping" \
|
2026-08-31 02:18:08 +02:00
|
|
|
% controller.craft_menu.vessel_labels.size())
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
|
|
|
|
|
# --- B. and the price is really there ---------------------
|
2026-08-31 02:18:08 +02:00
|
|
|
if controller.craft_menu.price_tags.size() != controller.craft_menu.vessel_buttons.size():
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
return _fail("%d price strips for %d vessels" \
|
2026-08-31 02:18:08 +02:00
|
|
|
% [controller.craft_menu.price_tags.size(),
|
|
|
|
|
controller.craft_menu.vessel_buttons.size()])
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
var priced: int = 0
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
var stacked: int = 0
|
2026-08-31 02:18:08 +02:00
|
|
|
for i in range(controller.craft_menu.price_tags.size()):
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
var definition: Resource = VesselDefinitions.fleet()[i]
|
|
|
|
|
var costs: Dictionary = game_state.product_costs(definition.definition_id)
|
2026-08-31 02:18:08 +02:00
|
|
|
var strip: Control = controller.craft_menu.price_tags[i]
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
if costs.is_empty():
|
|
|
|
|
continue
|
|
|
|
|
if strip.is_free():
|
|
|
|
|
return _fail("%s costs %s and its strip is empty" \
|
|
|
|
|
% [definition.definition_id, str(costs)])
|
|
|
|
|
priced += 1
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
# --- E. #147 - a price stays inside its own box ----------
|
|
|
|
|
# A two-resource price used to be laid out across a strip
|
|
|
|
|
# narrower than it needed, so it ran off the end and into the
|
|
|
|
|
# vessel beside it.
|
|
|
|
|
if costs.size() > 1 and not strip.is_stacked():
|
|
|
|
|
return _fail("%s is priced in %d resources on one line - they will not fit %.0fpx" \
|
|
|
|
|
% [definition.definition_id, costs.size(), strip.size.x])
|
|
|
|
|
if costs.size() > 1:
|
|
|
|
|
stacked += 1
|
|
|
|
|
if strip.wanted_height() > strip.size.y + 0.5:
|
|
|
|
|
return _fail("%s's price needs %.0fpx and its box is %.0f" \
|
|
|
|
|
% [definition.definition_id, strip.wanted_height(), strip.size.y])
|
|
|
|
|
for child in strip.get_children():
|
|
|
|
|
var box: Rect2 = Rect2((child as Control).position, (child as Control).size)
|
|
|
|
|
if box.position.x < -0.5 or box.end.x > strip.size.x + 0.5:
|
|
|
|
|
return _fail("%s's price runs from %.0f to %.0f in a %.0fpx strip" \
|
|
|
|
|
% [definition.definition_id, box.position.x, box.end.x, strip.size.x])
|
|
|
|
|
# ...and the price sits with the button it is about, not
|
|
|
|
|
# adrift below the caption.
|
2026-08-31 02:18:08 +02:00
|
|
|
var button: Control = controller.craft_menu.vessel_buttons[i]
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
var gap: float = strip.position.y - (button.position.y + button.size.y)
|
|
|
|
|
if gap > 80.0:
|
|
|
|
|
return _fail("%s's price sits %.0fpx below its button" \
|
|
|
|
|
% [definition.definition_id, gap])
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
if priced == 0:
|
|
|
|
|
return _fail("no vessel showed a price at all")
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
if stacked == 0:
|
|
|
|
|
return _fail("no vessel costs more than one resource - E proves nothing")
|
|
|
|
|
print("%d vessels show their price as glyphs, %d of them stacked one per line" \
|
|
|
|
|
% [priced, stacked])
|
|
|
|
|
|
|
|
|
|
# --- F. #147 - and the rows do not run into each other -------
|
2026-08-31 02:18:08 +02:00
|
|
|
for i in range(controller.craft_menu.vessel_buttons.size()):
|
|
|
|
|
for j in range(i + 1, controller.craft_menu.vessel_buttons.size()):
|
|
|
|
|
for part in [controller.craft_menu.vessel_buttons,
|
|
|
|
|
controller.craft_menu.vessel_labels, controller.craft_menu.price_tags]:
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
if i >= part.size() or j >= part.size():
|
|
|
|
|
continue
|
|
|
|
|
var a: Control = part[i]
|
|
|
|
|
var b: Control = part[j]
|
|
|
|
|
if Rect2(a.position, a.size).intersects(Rect2(b.position, b.size)):
|
|
|
|
|
return _fail("craft entries %d and %d overlap" % [i, j])
|
|
|
|
|
# A price must not reach the button of the row below it.
|
2026-08-31 02:18:08 +02:00
|
|
|
var mine: Control = controller.craft_menu.price_tags[i]
|
|
|
|
|
for k in range(controller.craft_menu.vessel_buttons.size()):
|
|
|
|
|
var other: Control = controller.craft_menu.vessel_buttons[k]
|
#147: one resource per line, and the price back under its button
Both halves of the report had the same cause: a craft cell laid out with
more slack than its row pitch had room for.
The caption box was 62px for a one-line vessel name, which pushed the price
70px clear of the button it belonged to - "far from the button they are
about". And the price was given 184px of width in a 190px column, so a
two-resource price ran out of its own box and into its neighbour's.
Prices now put each resource on its own line. Not only where they would
otherwise overflow, which was my first attempt: two resources came to 174px
in a 184px box, so it fitted - until the player was holding three figures
rather than one, and then it did not. A layout that is correct until you get
rich is not correct, and the ticket asked for the line break outright.
The caption is one line tall now with the price directly under it, and rows
are placed off a MEASURED band rather than a written-down pair of tops - the
same fix #144 needed for the build menu, and now the same code. A
centre-anchored grid under a top-anchored header has a gap between them that
is half the panel height, so it can never be a constant.
The test pins what the ticket describes rather than the numbers behind it: a
multi-resource price is stacked, its content stays inside its own box, it
sits within 80px of its button, and no craft entry overlaps another - the
price of one row into the button of the next included, which the old
geometry did by 14px whatever was priced.
2026-08-29 13:05:46 +02:00
|
|
|
if other.position.y > mine.position.y \
|
|
|
|
|
and Rect2(mine.position, mine.size).intersects(
|
|
|
|
|
Rect2(other.position, other.size)):
|
|
|
|
|
return _fail("the price under vessel %d runs into vessel %d's button" % [i, k])
|
|
|
|
|
print("craft grid: nothing overlapping, prices under their own buttons")
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
|
|
|
|
|
# --- C. the hangar ---------------------------------------
|
|
|
|
|
controller._layout_hangar()
|
2026-08-31 02:18:08 +02:00
|
|
|
if controller.hangar_menu.divider_y <= 0.0:
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
return _fail("the hangar laid out with no divider between its halves")
|
|
|
|
|
var available_bottom: float = 0.0
|
|
|
|
|
var fleet_top: float = 1.0e9
|
2026-08-31 02:18:08 +02:00
|
|
|
for label in controller.hangar_menu.available_labels:
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
available_bottom = maxf(available_bottom, label.position.y + label.size.y)
|
2026-08-31 02:18:08 +02:00
|
|
|
for slot in controller.hangar_menu.fleet_slots:
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
fleet_top = minf(fleet_top, slot.position.y)
|
2026-08-31 02:18:08 +02:00
|
|
|
if not (controller.hangar_menu.divider_y > available_bottom - 40.0
|
|
|
|
|
and controller.hangar_menu.divider_y < fleet_top):
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
return _fail("the divider at %.0f is not between the two grids (%.0f / %.0f)" \
|
2026-08-31 02:18:08 +02:00
|
|
|
% [controller.hangar_menu.divider_y, available_bottom, fleet_top])
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
# Two lines of caption. The font is 24-ish, so anything under
|
|
|
|
|
# about 44 cannot show a second line at all.
|
2026-08-31 02:18:08 +02:00
|
|
|
var caption_height: float = controller.hangar_menu.available_labels[0].size.y
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
if caption_height < 44.0:
|
|
|
|
|
return _fail("hangar captions are %.0fpx tall - a two-word name is clipped" \
|
|
|
|
|
% caption_height)
|
|
|
|
|
print("hangar: %.0fpx captions, divider at %.0f between %.0f and %.0f" \
|
2026-08-31 02:18:08 +02:00
|
|
|
% [caption_height, controller.hangar_menu.divider_y, available_bottom, fleet_top])
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
|
#145, #144, #143: a quest that could not be finished, and two boxes that overhung
#145 - the extractor quest could never be completed. Extractors are placed
onto a planet from space and live in GameState.extractors, with their own
position, stock and id; they are not in `buildings`. So the goal asked
has_building_of_type("extractor"), which is false however many the player
builds. Not the death the reporter guessed at - the quest was simply asking
a question that had no yes.
structure_exists() is the question anything wanting "does the player have
one of these" should ask, and the quest model asks it now. The regression
test builds every structure quest's target THE WAY THE GAME BUILDS IT and
watches the goal flip, rather than knowing which array each one lands in -
the knowing is what got this wrong in the first place.
#144 - the build menu's status line is anchored to the top of the panel and
its grid to the panel's centre, so the gap between the two is half the panel
height. It was a written-down constant, correct only at 1280 tall; at 1080
the grid started four pixels ABOVE the status line and drew through it.
Nothing about that geometry is written against a screen size any more. The
band is measured from the header that is actually there, the pitch closes up
to fit it (never below a row's own height, which is what makes overlap
impossible rather than unlikely), and the column count rises until the rows
fit - so a short window gets a wide grid instead of one running off the
bottom. Ten structures now lay out as 5 columns at 900px tall, 4 at 1080, 3
at 1280 and 2 at 1600, clearing the header at every one, which is what the
test walks.
#143 - a hangar caption is "Gas Bomber\n2 available": two lines before
autowrap and three after it in a narrow column, at a size fixed in the
scene. Labels do not clip by default, so the third line was drawn over the
icon of the row below. The size is fitted to the box the layout works out,
and the box clips - the first keeps it legible, the second keeps it correct
however the vessel names grow.
Its box also overhung by exactly HANGAR_LABEL_GAP: the layout subtracted one
gap where it needed two, above the caption and below it. Two pixels, but two
pixels inside the next row's icon.
2026-08-29 12:51:09 +02:00
|
|
|
# --- D. #143 - and the caption stays in its box --------------
|
|
|
|
|
# The caption is two lines before autowrap and three after it in
|
|
|
|
|
# a narrow column, at a size fixed in the scene - so the third
|
|
|
|
|
# line was drawn over the icon of the row below. It is fitted to
|
|
|
|
|
# the box now, and the box clips, so nothing can reach the next
|
|
|
|
|
# row however the vessel names grow.
|
|
|
|
|
controller._refresh_hangar()
|
2026-08-31 02:18:08 +02:00
|
|
|
for pair in [[controller.hangar_menu.available_labels, controller.hangar_menu.available_slots],
|
|
|
|
|
[controller.hangar_menu.fleet_labels, controller.hangar_menu.fleet_slots]]:
|
#145, #144, #143: a quest that could not be finished, and two boxes that overhung
#145 - the extractor quest could never be completed. Extractors are placed
onto a planet from space and live in GameState.extractors, with their own
position, stock and id; they are not in `buildings`. So the goal asked
has_building_of_type("extractor"), which is false however many the player
builds. Not the death the reporter guessed at - the quest was simply asking
a question that had no yes.
structure_exists() is the question anything wanting "does the player have
one of these" should ask, and the quest model asks it now. The regression
test builds every structure quest's target THE WAY THE GAME BUILDS IT and
watches the goal flip, rather than knowing which array each one lands in -
the knowing is what got this wrong in the first place.
#144 - the build menu's status line is anchored to the top of the panel and
its grid to the panel's centre, so the gap between the two is half the panel
height. It was a written-down constant, correct only at 1280 tall; at 1080
the grid started four pixels ABOVE the status line and drew through it.
Nothing about that geometry is written against a screen size any more. The
band is measured from the header that is actually there, the pitch closes up
to fit it (never below a row's own height, which is what makes overlap
impossible rather than unlikely), and the column count rises until the rows
fit - so a short window gets a wide grid instead of one running off the
bottom. Ten structures now lay out as 5 columns at 900px tall, 4 at 1080, 3
at 1280 and 2 at 1600, clearing the header at every one, which is what the
test walks.
#143 - a hangar caption is "Gas Bomber\n2 available": two lines before
autowrap and three after it in a narrow column, at a size fixed in the
scene. Labels do not clip by default, so the third line was drawn over the
icon of the row below. The size is fitted to the box the layout works out,
and the box clips - the first keeps it legible, the second keeps it correct
however the vessel names grow.
Its box also overhung by exactly HANGAR_LABEL_GAP: the layout subtracted one
gap where it needed two, above the caption and below it. Two pixels, but two
pixels inside the next row's icon.
2026-08-29 12:51:09 +02:00
|
|
|
for i in range(pair[0].size()):
|
|
|
|
|
var caption: Label = pair[0][i]
|
|
|
|
|
if not caption.clip_text:
|
|
|
|
|
return _fail("hangar caption %d can draw outside its box" % i)
|
|
|
|
|
var font: Font = caption.get_theme_font("font")
|
|
|
|
|
var size_px: int = caption.get_theme_font_size("font_size")
|
|
|
|
|
var needed: float = font.get_multiline_string_size(caption.text,
|
|
|
|
|
HORIZONTAL_ALIGNMENT_CENTER, caption.size.x, size_px).y
|
|
|
|
|
if needed > caption.size.y + 0.5:
|
|
|
|
|
return _fail("caption \"%s\" needs %.0fpx at size %d and has %.0f" \
|
|
|
|
|
% [caption.text.replace("\n", " / "), needed, size_px, caption.size.y])
|
|
|
|
|
# And the box itself must not reach the row below it.
|
|
|
|
|
for slot in pair[1]:
|
|
|
|
|
var below: Rect2 = Rect2(slot.position, slot.size)
|
|
|
|
|
if below.position.y > caption.position.y \
|
|
|
|
|
and Rect2(caption.position, caption.size).intersects(below):
|
|
|
|
|
return _fail("caption \"%s\" runs into the icon below it" \
|
|
|
|
|
% caption.text.replace("\n", " / "))
|
2026-08-31 02:18:08 +02:00
|
|
|
var probe: Label = controller.hangar_menu.available_labels[0]
|
#145, #144, #143: a quest that could not be finished, and two boxes that overhung
#145 - the extractor quest could never be completed. Extractors are placed
onto a planet from space and live in GameState.extractors, with their own
position, stock and id; they are not in `buildings`. So the goal asked
has_building_of_type("extractor"), which is false however many the player
builds. Not the death the reporter guessed at - the quest was simply asking
a question that had no yes.
structure_exists() is the question anything wanting "does the player have
one of these" should ask, and the quest model asks it now. The regression
test builds every structure quest's target THE WAY THE GAME BUILDS IT and
watches the goal flip, rather than knowing which array each one lands in -
the knowing is what got this wrong in the first place.
#144 - the build menu's status line is anchored to the top of the panel and
its grid to the panel's centre, so the gap between the two is half the panel
height. It was a written-down constant, correct only at 1280 tall; at 1080
the grid started four pixels ABOVE the status line and drew through it.
Nothing about that geometry is written against a screen size any more. The
band is measured from the header that is actually there, the pitch closes up
to fit it (never below a row's own height, which is what makes overlap
impossible rather than unlikely), and the column count rises until the rows
fit - so a short window gets a wide grid instead of one running off the
bottom. Ten structures now lay out as 5 columns at 900px tall, 4 at 1080, 3
at 1280 and 2 at 1600, clearing the header at every one, which is what the
test walks.
#143 - a hangar caption is "Gas Bomber\n2 available": two lines before
autowrap and three after it in a narrow column, at a size fixed in the
scene. Labels do not clip by default, so the third line was drawn over the
icon of the row below. The size is fitted to the box the layout works out,
and the box clips - the first keeps it legible, the second keeps it correct
however the vessel names grow.
Its box also overhung by exactly HANGAR_LABEL_GAP: the layout subtracted one
gap where it needed two, above the caption and below it. Two pixels, but two
pixels inside the next row's icon.
2026-08-29 12:51:09 +02:00
|
|
|
print("captions fitted to %dpx and clipped; \"%s\" fits its %.0fpx box" \
|
|
|
|
|
% [probe.get_theme_font_size("font_size"),
|
|
|
|
|
probe.text.replace("\n", " / "), probe.size.y])
|
|
|
|
|
|
Cover the last batch of tickets with tests
The previous ten tickets shipped with almost no coverage - only #109, #113,
#115 and #117 touched a test. That was a gap, not a decision: everything
before it had its behaviour pinned, and #116 in particular added a whole
subsystem nothing was watching.
Four new files and one extended case:
test_spacial_workshop #116 - the repair economy end to end: the
cost of a repair scales with the damage, the
workshop asks logistics for that ore and
stops at its buffer, a drone spends when it
LEAVES so two cannot double-charge one wall,
and a target levelled in flight sends its
load home rather than swallowing it
test_desktop_controls #118/#121 - both driven through the real
routing, because the routing is what was
missing; a test calling handle_mouse_button()
itself would have passed against both reports
test_enemy_bomber #114 - it flies, it faces where it flies, its
bombs arrive, and it bombs structures with no
fleet in sight
test_menu_polish #111/#112/#119/#120 - what each panel shows
test_wave_system (case G) #110 - the dev button, and that it does not
exist outside dev mode
One assertion worth recording: the craft caption is checked as an EXACT
match against the vessel's display name rather than by hunting for resource
words in it. The first version failed on "Gas Bomber" - a vessel named after
a resource, and always will be. What #111 removed was the price spelled out
underneath, not the name.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 12:10:31 +02:00
|
|
|
# --- D. every skill node has a mark -----------------------
|
|
|
|
|
var tree_view: Control = scene.get_node("UI/SkillMenu/Tree")
|
|
|
|
|
var marked: int = 0
|
|
|
|
|
for node in GameState.SKILL_TREE:
|
|
|
|
|
var icon: int = game_state.skill_node_icon(node)
|
|
|
|
|
if icon < 0:
|
|
|
|
|
return _fail("skill node \"%s\" has no icon" % node.id)
|
|
|
|
|
marked += 1
|
|
|
|
|
var unlocks: String = String(node.get("unlocks", ""))
|
|
|
|
|
if unlocks == "":
|
|
|
|
|
continue
|
|
|
|
|
var definition: Resource = game_state.building_definition(unlocks)
|
|
|
|
|
if definition != null and icon != int(definition.menu_icon):
|
|
|
|
|
return _fail("\"%s\" unlocks the %s but draws a different icon" \
|
|
|
|
|
% [node.id, unlocks])
|
|
|
|
|
if tree_view._glyphs.size() != marked:
|
|
|
|
|
return _fail("%d nodes have icons but the tree built %d glyphs" \
|
|
|
|
|
% [marked, tree_view._glyphs.size()])
|
|
|
|
|
print("%d skill nodes, every one marked, unlocks matching their building" % marked)
|
|
|
|
|
|
|
|
|
|
# --- E. the formation shows the real fleet ----------------
|
|
|
|
|
scene.get_node("Fleet").spawn_ships(2, Vector2.ZERO, PackedStringArray([
|
|
|
|
|
GameState.VESSEL_INTERCEPTOR, GameState.VESSEL_SHIELD]))
|
|
|
|
|
elapsed = 0.0
|
|
|
|
|
stage = 1
|
|
|
|
|
return false
|
|
|
|
|
1:
|
|
|
|
|
if elapsed < 0.2:
|
|
|
|
|
return false
|
|
|
|
|
var editor: Control = scene.get_node("UI/FormationMenu/Editor")
|
|
|
|
|
var crewed: PackedStringArray = game_state.fleet_vessel_types
|
|
|
|
|
if crewed.size() != 2:
|
|
|
|
|
return _fail("the fleet mirror holds %d types, expected 2" % crewed.size())
|
|
|
|
|
var interceptor: Resource = game_state.vessel_definition(GameState.VESSEL_INTERCEPTOR)
|
|
|
|
|
var shield: Resource = game_state.vessel_definition(GameState.VESSEL_SHIELD)
|
|
|
|
|
if interceptor.hull_points == shield.hull_points:
|
|
|
|
|
return _fail("the two vessels share a hull, so this case proves nothing")
|
|
|
|
|
if not editor.has_method("_draw_vessel_slot"):
|
|
|
|
|
return _fail("the editor has no per-vessel drawing at all")
|
|
|
|
|
# The panel draws from the mirror, so the mirror having the right
|
|
|
|
|
# types in the right order IS what makes the markers differ.
|
|
|
|
|
if String(crewed[0]) != GameState.VESSEL_INTERCEPTOR \
|
|
|
|
|
or String(crewed[1]) != GameState.VESSEL_SHIELD:
|
|
|
|
|
return _fail("the fleet mirror is %s, not the order they were crewed in" \
|
|
|
|
|
% str(crewed))
|
|
|
|
|
print("formation draws a %s and a %s, in the slots they fly in" \
|
|
|
|
|
% [interceptor.display_name, shield.display_name])
|
|
|
|
|
|
|
|
|
|
print("TEST_MENU_POLISH: PASS")
|
|
|
|
|
quit(0)
|
|
|
|
|
return true
|
|
|
|
|
return false
|