Shows Input.get_axis() values, weapon slot states, and fire
state in the window title bar — visible even when print()
output is lost on Windows GUI exports.
get_window().grab_focus() was insufficient on Windows GUI exports.
Replaced with OS.move_to_foreground() + Input.set_mouse_mode(CAPTURED)
+ deferred retries to ensure the game window holds keyboard focus
after the connection UI is dismissed.
A debug-print attempt from earlier inadvertently appended a second
_rollback_tick function (with spaces instead of tabs) at the end of
weapon_manager.gd:419, causing the entire script to fail compilation.
This meant the WeaponManager node had NO script attached:
- 'has_method("set_default_loadout")' returned false
- Client-side loadout init never ran
- All weapon operations silently did nothing
This is the real root cause of why weapons never worked on the client.
- Removed the is_predicting() early-return in weapon_manager._rollback_tick
which blocked all weapon actions on the client (player owned by server)
- Added client-side weapon loadout initialization in player-spawner._spawn
so the player has weapons immediately, before server state sync arrives
- Server reconciles via rollback state sync
Movement was fixed in v0.2.2 (window focus grab). This addresses
the remaining 'can't switch or use weapons' issue.
Added explicit window focus grab after connecting (lan-bootstrapper.gd)
so keyboard input is properly received by the input system.
Also added diagnostic debug prints to trace input pipeline.
- Changed _gun_model type from MeshInstance3D to Node3D
(all imported GLB/GLTF weapon models have Node3D root)
- Added check_models.gd diagnostic script
The type mismatch at WeaponManager._load_weapon_models:73
was the only script error in the user's game.log.
Headless bot tests confirm movement still works fine.
- Move _clock.set_time(0.) inside the 'if not server' block in
NetworkTimeSynchronizer.start() so the server's SystemClock isn't
reset to zero — fixes -1.78 billion second offset panic on client
- Skip spawning peer 1's avatar on clients (the server replicates
all avatars; spawning peer 1 locally creates a duplicate that
the dedicated server doesn't have)
lan-bootstrapper.gd and noray-bootstrapper.gd both had a host_only()
function that referenced BrawlerSpawner (class_name from forest-brawl).
Since examples/forest-brawl/ is excluded from exports, the type was
undefined, causing the entire script to fail loading with:
'Could not find type BrawlerSpawner in current scope'
This meant the Join and Host button signal handlers never existed,
so clicking them did nothing — no error shown, no connection, no UI change.
Fix: remove the unused host_only() function from both bootstrapper files.
The dedicated server was spawning a host avatar (peer 1) via
player-spawner._handle_host() and _handle_new_peer(1) on startup,
which registered RollbackSynchronizer subjects with the netfox
rollback system. Since no client input exists for peer 1, the
rollback system tried to record state for freed/recycled objects,
flooding the log with property-pool.gd errors.
Fix:
- Add spawn_host_avatar @export flag to player-spawner.gd
- Set it false in headless_server.gd before starting the ENet server
- PlayerSpawner._handle_host() skips avatar spawn when flag is false
- PlayerSpawner._handle_new_peer(1) skips avatar spawn when flag is false
Server startup is now clean: no property-pool errors, no RPC path errors.
shawn