Screeps: Why Game.rooms[roomName] Is Undefined
Learn why Game.rooms[roomName] is undefined without current room vision, how to guard live Room reads, and why Memory.rooms does not prove visibility.
TOPIC · 24 GUIDES
Focused English articles connected to debugging, organized with the same filters used by the main article library.
Learn why Game.rooms[roomName] is undefined without current room vision, how to guard live Room reads, and why Memory.rooms does not prove visibility.
Use fill: 'transparent' for unfilled RoomVisual circles and rectangles, then add debug labels and target paths without confusing visuals with game results.
Call Game.notify(), use groupInterval and simple Memory incident state to avoid repeated alerts, preserve the checked engine result, and keep scheduling separate from external email delivery.
Read the previous tick's Room events, distinguish parsed and raw mode, filter event-specific data safely, match actor and target IDs when attribution matters, and keep optional history bounded.
Build a four-mode Screeps CPU degradation scheduler with hysteresis, consecutive-tick confirmation, critical-first task tiers, stable staggering, CPU headroom guards, and gradual recovery.
Coordinate Creep.pull(), the puller's movement, and target.move(puller) in the same tick, handle adjacency and fatigue correctly, and verify the pair moved later.
Diagnose room.energyAvailable below energyCapacityAvailable by reconciling active Spawn and Extension Stores, holding one stable fill target, preserving transfer() results, and matching the processed Energy transfer on the next tick.
Treat ticksToDecay as the next decay pulse, reject unsafe path deadlines, preserve repair() results, explain the current-engine repair-before-decay boundary, and verify EVENT_REPAIR amount and Energy spent on the next tick.
Measure one code section with Game.cpu.getUsed() deltas, compare equivalent server ticks, separate bucket context from profiling, and protect essential work before optional tasks.
Verify movement over later ticks, then isolate fatigue, repeated movement intents, traffic, cached paths, room edges, and impossible stop ranges.
Capture the actual Spawn request, interpret each documented return code, separate dryRun from the final submission, and verify scheduled spawning across later ticks.
Catch JavaScript exceptions at room or subsystem boundaries, retain bounded rate-limited evidence, pause repeatedly failing optional work, and retry after cooldown without confusing API return codes or CPU termination with exceptions.