claude
f70de1b825
ci / verify (push) Successful in 45s
The real cause of the ship/bullet separation, which the previous commit only half-addressed. The server dropped inputs past a lead of 12 while the client only re-synced past 16, so a client whose lead drifted into 13-16 had every input silently rejected while believing its timing was fine. The server coasted on held_input and then stopped; the client kept predicting. The two separated permanently and the reconciler fought it every snapshot -- "shoved around". It needed two independent clocks to drift, hence "only after some time", and nothing in the loop could notice, hence "then persists". The listen-server diagnostic could never reproduce it: one process, one physics tick, lead constant by construction. Two defences: INPUT_MAX_LEAD (40) is now far wider than the client's correction band (3..20), asserted by tests/unit/test_input_lead.gd so narrowing it fails a test; and an ack-stall detector re-syncs when last_input_tick stops advancing, which catches the whole class regardless of cause -- lead alone cannot, because a wrong lead looks normal from the client. diag_prediction.gd now injects a +14 tick drift and exits non-zero unless the gap recovers. Also: - No invulnerability frames. Every bullet that touches a player lands; i-frames made dense patterns safer than sparse ones, which inverts the genre. Measured: a stationary player survives ~13.6s of the Warden's opening phase, ~17.5s drifting. spawn_grace remains the only invulnerable state. - Death is exited with a HUD button, disabled for the first 3s. The lockout is enforced in SimWorld, not just by graying the button -- a client that ignores its own UI still waits. The interact key no longer respawns. - Joining a server that is not there no longer drops the player into an empty lobby they cannot act in. Net.join() only creates an ENet object; the game scene now waits for the server to actually place us in an instance, with an 8s timeout, and headless runs exit non-zero instead of idling. Protocol 2 -> 3. 98 tests; check.sh, test.sh and smoke.sh all pass.
71 lines
2.8 KiB
GDScript
71 lines
2.8 KiB
GDScript
extends GutTest
|
|
## The client numbers its input frames a fixed "lead" ahead of the server's
|
|
## tick, and the server accepts a window around its own tick. These two numbers
|
|
## have to be chosen together.
|
|
##
|
|
## They were not, and the result was the worst kind of bug: the server silently
|
|
## dropped every input from a client whose lead had drifted into the gap between
|
|
## "server stops accepting" and "client notices", the client never corrected
|
|
## because by its own reckoning nothing was wrong, and the server coasted on a
|
|
## stale input forever. It needed two independent clocks to drift apart, so it
|
|
## only appeared after a few minutes -- and then never went away.
|
|
|
|
var world: SimWorld
|
|
const PEER := 5
|
|
|
|
|
|
func before_each() -> void:
|
|
world = SimWorld.new(1)
|
|
world.add_player(PEER, "tester")
|
|
world.tick = 1000
|
|
|
|
|
|
func _queue_at_lead(lead: int) -> void:
|
|
var frames: Array[InputFrame] = [
|
|
InputFrame.make(world.tick + lead, Vector2.RIGHT, 0.0, 0)]
|
|
world.queue_input(PEER, frames)
|
|
|
|
|
|
## The invariant that was violated. The client corrects itself at
|
|
## INPUT_LEAD_MAX; the server must keep accepting well past that, or there is a
|
|
## band where the server refuses input the client still thinks is fine.
|
|
func test_the_server_accepts_every_lead_the_client_tolerates() -> void:
|
|
assert_gt(SimConfig.INPUT_MAX_LEAD, SimConfig.INPUT_LEAD_MAX,
|
|
"the server's acceptance window must be wider than the client's " +
|
|
"correction band, or drift lands in a silent dead zone")
|
|
|
|
|
|
func test_inputs_across_the_whole_client_band_are_accepted() -> void:
|
|
for lead in range(SimConfig.INPUT_LEAD_MIN, SimConfig.INPUT_LEAD_MAX + 1):
|
|
world.players[PEER].input_queue.clear()
|
|
world.players[PEER].last_input_tick = 0
|
|
_queue_at_lead(lead)
|
|
assert_eq(world.players[PEER].input_queue.size(), 1,
|
|
"lead %d is inside the band the client will not correct, so the " % lead +
|
|
"server has to accept it")
|
|
|
|
|
|
func test_absurd_lead_is_still_rejected() -> void:
|
|
_queue_at_lead(SimConfig.INPUT_MAX_LEAD + 1)
|
|
assert_eq(world.players[PEER].input_queue.size(), 0,
|
|
"the window is wider, not gone -- a client claiming a far-future tick " +
|
|
"still buys nothing")
|
|
|
|
|
|
## What the drift actually looked like from the server's side: nothing arrives,
|
|
## so it coasts on the last input it saw. That is correct behaviour for a brief
|
|
## hiccup and catastrophic as a permanent state, which is why the client now
|
|
## has a stall detector rather than relying on its lead estimate alone.
|
|
func test_a_starved_server_coasts_then_stops() -> void:
|
|
var p: SimPlayer = world.players[PEER]
|
|
_queue_at_lead(SimConfig.INPUT_TARGET_LEAD)
|
|
world.step()
|
|
var moved_once: Vector2 = p.pos
|
|
assert_ne(moved_once, Vector2.ZERO, "setup: the input should have moved us")
|
|
for _i in SimConfig.INPUT_MAX_AGE + 5:
|
|
world.step()
|
|
var coasted: Vector2 = p.pos
|
|
for _i in 60:
|
|
world.step()
|
|
assert_eq(p.pos, coasted, "coasting has to end, or a silent client drifts forever")
|