Skip to content

Patch Notes

This page records notable changes to the Screeps AI.

Patch notes are listed newest first. Each release should summarize player-visible behavior, important fixes, operational changes, and any actions required after deployment.

Unreleased

  • Added finite or explicit "forever" operator approval for Launch Control work classes. debug.approveLease() prioritizes real current demand for an ordinary available lease slot without increasing capacity or overriding the CPU governor, reopening stage, work horizon, request freshness, or emergency safety. Use debug.approvedLeases() to inspect approvals and debug.clearApprovedLease() to remove one.

  • Fixed a Launch Control reopening deadlock where a previous large bucket loss could keep optional work closed after CPU charge recovered.

  • Remote-development CPU leases now include their lightweight scouting prerequisite, allowing fresh intelligence to be consumed during the same committed window while scout-only leases remain unable to start remote work.

  • Completed remote-container repair now survives intentional terminal build-order pruning by validating the durable approved plan topology, and remote-construction debug output no longer lets unrelated retired plans mask the current blocker.

  • Added coarse CPU work admission with sticky, fairly rotated leases. Scouting and remote development no longer wake together whenever the governor briefly opens; useful admitted work can continue across normal governor descent, while emergency protection remains authoritative and remote-backed spawn demand is suppressed outside its admission window.

  • Fixed infrastructure package summaries that could remain indefinitely stale because their refresh phase could never coincide with the staggered manager phase or because CPU recovery deferred that manager. Package counts now refresh during stats collection too, and retained completed packages no longer count as pending approval.

  • Normal infrastructure now defaults to persistent autonomous authority, so ordinary build orders and aggregate local-road/extension packages no longer wait for console approval. debug.infrastructureAuthority() inspects or switches between autonomous and manual; remote roads remain manual.
  • Autonomous authorization still uses the existing execution-time ownership, revision, RCL, structure-limit, exact-tile, topology, site-suppression, and remote-operation checks. Enabling it releases existing pending canonical work without creating duplicate plans, packages, or orders.

  • Reduced infrastructure Memory by omitting autonomous approval tickets and duplicated approval metadata, and by compacting proposal-only candidate evidence once an autonomous execution snapshot exists.

  • Extended the local mineral pilot through primary Storage. A completed native mineral operation now protects one density-derived deposit cycle in Storage, treats the resulting effective energy ceiling as full pressure, and lets ordinary idle local haulers move the exact approved container backlog only as physical capacity becomes available. Terminal staging, sends, markets, industry, remote minerals, and dedicated mineral haulers remain absent.

  • Prevented continuous ordinary energy/link work and constrained CPU mode from starving a physically serviceable mineral route. At most one existing local hauler may take mineral work while another preserves energy service; urgent delivery, critical CPU mode, emergency austerity, and economy recovery still block new collection. Receiver-link unload jobs now release when Storage has no effective energy capacity.

  • Prevented same-room scout exit approaches from routing through an adjacent room, eliminating the observed E49N11/E49N10 boundary loop and repeated pathfinding CPU spikes.

  • Reduced routine movement CPU by extending Screeps' bounded built-in path reuse for stable local work targets, room transitions, and remote travel. Destination or interaction-range changes continue to replace cached paths.
  • Fixed scout room-boundary traversal by tracking crossings across ticks and settling through a walkable inward tile or diagonal instead of repeatedly issuing one blocked cardinal move. Scouts also reselect a viable exit after bounded no-progress retries while approaching a boundary.
  • Reduced idle scout CPU usage by caching the next meaningful retry tick when every available adjacent room is temporarily avoided.

Added

  • Added zero-padded numeric approval tickets, generic approval inspection and action commands, registry-driven console help, and bounded operator history.
  • Added room-scoped final spawn-count overrides with temporary or explicit indefinite duration and a live spawn-decision preview.

Changed

  • Logistics route performance now persists fixed-width path-cache signatures, versioned traffic-tile tuples, and structured anomaly evidence. Existing verbose route Memory migrates automatically per room; route evaluation, health thresholds, traffic policy, cache eligibility, and operator wording remain unchanged.
  • Completed infrastructure plans now discard proposal-only candidate evidence and shorten their terminal reason, while work-package children encode route membership as package-local indexes. A backward-compatible, per-room schema migration reduces persistent Memory parsing and serialization pressure without changing approval or construction authority.
  • Infrastructure packages now store fixed-width current, approved, and topology fingerprints with an approval-preserving schema migration. Logistics routes retain only their two highest-priority component diagnostics while preserving complete aggregate counts and critical blockers.
  • Approval tickets now retain fixed-width fingerprint hashes only while pending; a bounded schema migration compacts legacy references without weakening revision-specific validation.
  • CPU profiling deliberately triggers lazy Memory parsing before population policy work, correcting attribution between those two sections.
  • Infrastructure work-package children now avoid repeating package identity, structure type, and write-only observation metadata. Existing room Memory is compacted once without changing package geometry, approvals, placement, or debug behavior.
  • Hauler movement now skips fatigued and already-in-range calls, suppresses duplicate same-tick intents, reuses stable built-in paths longer, and avoids routine path visualization without changing target selection or priority.
  • Infrastructure proposal output now presents a copyable numeric ticket before the canonical ID while retaining canonical command compatibility.
  • Operator spawn overrides are applied after economic, RCL, CPU, and colony safety policies, so the requested count is the true final target.
  • Approval reference cleanup now follows automatic expiry, completion, invalidation, and remote retirement without adding another routine scan.

Fixed

  • Closed or stale approval tickets can no longer be reopened by a failed canonical command or advertised against the wrong canonical target.
  • Pending inspection keeps full-capacity legacy proposals visible through safe canonical recovery actions and excludes tickets from visibly lost rooms.
  • Remote-road approval now refuses routes whose backing remote operation has retired, even when routine road planning has not recently run.
  • Remote-road approval now also fails closed for blocked fingerprints and empty route geometry.
  • Global spawn-override cleanup now removes stored entries for rooms whose ownership was later lost, preventing an indefinite override from reactivating after a future reclaim.

Documentation

  • Documented approval revision safety, command aliases, help categories, spawn-override warnings and cleanup, operator history, and CPU characteristics.

Operator Notes

  • Existing pending infrastructure proposals receive numeric tickets lazily on the first approval-console inspection; no Memory reset is required.
  • A "forever" spawn override remains active until explicitly cleared. Review debug.spawnOverrides() after deployment.
  • debug.clearSpawnCounts() without a room clears every stored room override, including stale entries for rooms that are no longer owned.

0.3.7.2 — Multi-Room Readiness

Released: July 29, 2026

This release continues preparing the colony for expansion by reducing assumptions that every room is either the single home room or its single remote room.

Added

  • Multi-room-safe ownership and room-context foundations.
  • Additional safeguards for starting the same codebase from tick 1 in the Screeps simulator.

Changed

  • Room and remote-operation logic now relies less heavily on single-room assumptions.
  • Internal boundaries between home-room management and remote-room activity were clarified.
  • Infrastructure state handling was made more incremental and CPU-conscious.

Fixed

  • Reduced unnecessary infrastructure-memory writes by updating persistent state only when meaningful data changes.
  • Corrected simulation startup behavior where missing or incomplete room intelligence could cause initialization failures.

Documentation

  • Updated architecture and roadmap documentation to reflect multi-room readiness work.
  • Added this patch-notes page to the documentation site.

Operator Notes

  • No Memory reset should be required.
  • Run the normal verification suite before deployment:
npm run check
  • Deploy the development build to the Screeps beta branch:
npm run deploy:beta

Release Template

Copy this section when preparing a new release.

X.Y.Z — Release Name

Released: Month DD, YYYY

One or two sentences describing the purpose of the release and its most important outcome.

Added

  • New systems, commands, behaviors, telemetry, or documentation.

Changed

  • Existing behavior that now works differently.
  • Architectural or policy changes worth knowing about.

Fixed

  • Bugs, regressions, incorrect decisions, or reliability problems.

Performance

  • CPU reductions, caching improvements, reduced Memory writes, or bounded work.
  • Remove this section when the release has no meaningful performance changes.

Documentation

  • New or substantially updated documentation.

Operator Notes

  • Required deployment steps.
  • Memory migrations or resets.
  • Configuration changes.
  • New console commands.
  • Recommended live verification.
  • Write No special operator action is required. when applicable.

Known Issues

  • Remaining bugs or limitations discovered during the release.
  • Remove this section when there are no noteworthy known issues.

Versioning Notes

The project generally uses version numbers to identify completed roadmap milestones and incremental patches.

  • Major versions represent major stages of colony development.
  • Minor versions represent roadmap milestones or significant capabilities.
  • Patch versions represent smaller implementations, fixes, tuning, or follow-up work.
  • Additional numeric segments may be used for incremental parts of a larger milestone.

The roadmap remains the authoritative source for planned work. Patch notes describe what was actually delivered.