Implement Structure.isActive() and ERR_RCL_NOT_ENOUGH checks

[misterwise]

Summary

• Implements Structure.isActive() with distance-based tiebreaking for excess structures on RCL downgrade
• Adds checkIsActive to all structure intent chains (spawn, tower, lab, link, terminal, observer, extractor harvest)
• Filters inactive spawns/extensions from energyAvailable, energyCapacityAvailable, energy drain, and spawn regen
• Removes now-redundant isActive() overrides on StructureSpawn and StructureObserver
• Checks input labs and link targets for isActive (stricter than official engine — inactive structures shouldn't participate in operations)
• Closes [Bug] Not-active extensions still count towards energyCapacityAvailable #33

Verification

• Excess spawns: exactly 1 active at RCL 1 with 2 spawns, closer to controller wins
• Inactive spawn returns ERR_RCL_NOT_ENOUGH on spawnCreep, but destroy still works
• energyAvailable excludes inactive extensions
• Controller owner mismatch makes structures inactive
• Observer inactive at RCL 7, active at RCL 8 (single-structure shortcut path)
• Tower attack and mineral harvest return ERR_RCL_NOT_ENOUGH when structure inactive
• Inactive spawns don't regenerate energy

🤖 Generated with Claude Code

[misterwise]

Pushed an additional commit (misterwise/xxscreeps@806799c) that gates creep.transfer() and creep.withdraw() on isActive() — both now return ERR_RCL_NOT_ENOUGH for inactive structures (e.g. extensions after RCL downgrade).

This closes the remaining gap from #33: the prior commits fixed energyAvailable/energyCapacityAvailable and the spawn energy draw list, but direct transfer/withdraw intents against inactive structures were still succeeding.

Tests included and validated against unfixed code to confirm they catch the bug.

[laverdet]

#active flag should be stored on relevant buildings.

[laverdet]

Come to think of it the event would also need to run on destruction of other buildings. The point stands that this function should run in constant time.

[tiennou]

Also, it might be worth considering something like this, which fixes the issue of isActive being a CPU sink in favor of precalculating and caching the active state before each tick in the engine itself.

[misterwise]

Thanks for the thorough review — pushed a rework addressing all the feedback. I now understand the rationale for inactive buildings. They work as stores without needing to be active (withdraw, transfer), but the source labs for a reaction was the biggest surprised to me. All integratd in alignment with vanilla now.

Core architecture: cached #active flag

Reworked per your guidance. isActive() now returns this['#active'] ?? true in constant time. The computation moves to a batch checkActiveStructures(room) function (matching the approach in screeps/engine#150):

• Single pass over #objects to group owned structures by type
• Per type: if count ≤ maxCount, mark all active; if excess, sort by getRangeTo(controller) and mark closest N active
• Stable sort handles the distance tiebreaker (oldest structure wins at equal range)
• Called from updateRoomStatus on level/owner changes

For destruction: OwnedStructure.#destroy invalidates #active on same-type structures (sets to undefined). After the next #flushObjects removes the destroyed structure, the lazy fallback in isActive() recomputes with the correct count. No per-tick overhead.

Vanilla-correctness fixes

• Removed checkIsActive on source labs (runReaction, reverseReaction) — only the output lab checks
• Removed checkIsActive on link transfer target — only the sending link checks
• Removed checkIsActive from creep transfer/withdraw — stores on inactive buildings still work
• Tests updated: transfer/withdraw assert C.OK, renamed to "stores on inactive buildings still work"

Style/lint fixes

• s → spawn/structure for id-length
• Multi-line #user assignment → single-line
• Level-8 extensions in level-1 test rooms → level-1
• Extension #roomStatusDidChange signature unchanged (batch handles #active separately)

[laverdet]

Just some minor nitpicks for now.

There's some other things which would be better for later. I think what I want would require a more significant lifecycle hook adjustment so it's fine to put a pin in that.