From e86a423d1bc4956ae912901dedf34f21c8d0146d Mon Sep 17 00:00:00 2001 From: Valithor Obsidion Date: Fri, 30 Oct 2026 08:15:41 -0400 Subject: [PATCH 1/2] Research fixed-tick recovery and life-support evidence --- docs/research/README.md | 1 + .../entries/R-001-modern-rendering.md | 6 ++ ...2-fixed-ticks-recovery-and-life-support.md | 57 +++++++++++++++++++ .../experiments/E-001-rendering-baseline.md | 4 ++ docs/research/reference-manifest.csv | 5 ++ 5 files changed, 73 insertions(+) create mode 100644 docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md diff --git a/docs/research/README.md b/docs/research/README.md index 0bba42d..4b0f433 100644 --- a/docs/research/README.md +++ b/docs/research/README.md @@ -7,6 +7,7 @@ This is Frontier Systems' version-controlled knowledgebase for design decisions | Entry | Topic | Outcome | Evidence limit | Next step | | --- | --- | --- | --- | --- | | [R-001: modern rendering optimization leads](entries/R-001-modern-rendering.md) | Rendering/performance | proposed | Official engine/vendor guidance and pinned source inspection; no reproduced rendering gains | [E-001: baseline and shared wall resources](experiments/E-001-rendering-baseline.md) | +| [R-002: fixed ticks, recovery, transport and life support](entries/R-002-fixed-ticks-recovery-and-life-support.md) | Simulation, persistence, multiplayer and engineering design | proposed | Public primary-source review and pinned source inspection; no experiments run | Select one bounded scenario after confirming current work | | [Reference manifest](reference-manifest.csv) | Cross-topic provenance | existing registry | Each row states its reviewed scope and rights limits | Append targeted sources; preserve the CSV contract | | [Foundational capability matrix v1](foundational-capability-matrix.v1.csv) | Engineering-game design | existing audit | Historical capability/gap statements have their own evidence dates | Revalidate a row before treating it as current implementation | diff --git a/docs/research/entries/R-001-modern-rendering.md b/docs/research/entries/R-001-modern-rendering.md index a7336c0..03e60c7 100644 --- a/docs/research/entries/R-001-modern-rendering.md +++ b/docs/research/entries/R-001-modern-rendering.md @@ -52,3 +52,9 @@ Repeated resource construction offers a narrow presentation experiment while pre A future comparison should establish actual 1080p render targets and CPU/GPU/frame-tail timing, then change only resource sharing. Supported AA comparisons and room/shadow budgets follow separately. Dynamic geometry makes baked lighting/occlusion less straightforward; visibility must follow authoritative observations without becoming simulation authority. **No custom GI, deferred renderer, motion-blur or AA rewrite is justified by this entry.** First identify a measured project bottleneck and preserve motion readability. Runtime reproduction, target lower-end hardware, VR/stereo behavior, video publication date and the unreviewed outro remain open. See E-001 for falsifiable controls and acceptance limits. + +## Follow-up source review: 2026-10-30 + +[GPU optimization](https://docs.godotengine.org/en/4.7/tutorials/performance/gpu_optimization.html), Godot documentation contributors, 4.7 documentation (publication date not stated; mutable page, accessed 2026-10-30), describes separate CPU/driver/GPU bottlenecks and notes that overlapping transparent surfaces and shadow/post-processing work can increase fragment cost. This is engine guidance, not a Frontier measurement; the page's API discussion includes older graphics APIs and is not evidence about a particular D3D12 driver. + +**Proposed diagnostic:** E-001 adds a separate render-resolution sensitivity comparison after establishing actual viewport sizes and frame pacing. A measurable GPU-time change with resolution is a clue about pixel-dependent work, not proof of a particular shader or whole-game gain. Validate any subsequent optimization with its own fixed-resolution comparison and motion/readability checks. Outcome remains **proposed**, with no run or adoption. diff --git a/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md b/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md new file mode 100644 index 0000000..ada691d --- /dev/null +++ b/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md @@ -0,0 +1,57 @@ +# R-002: fixed ticks, recovery, transport and life support + +- **Topics:** simulation, persistence, multiplayer/networking, engineering-game design +- **Outcome/status:** proposed; public source and Frontier source inspected 2026-10-30; no experiment executed or design adopted +- **Project snapshot:** [115f0e3c2fbf059819a4844ccdeffb64182af062](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/README.md); compare with the then-current integration head and active work before execution. +- **Next decision:** select one scenario and define its acceptance threshold before a separately authorized isolated test. These are research proposals, not implementation assignments. + +## Sources and context + +All sources below were accessed on 2026-10-30; documentation pages are mutable even where versioned. Publication/update dates are included when available. + +| ID | Primary source | Author/date/version and reviewed scope | +| --- | --- | --- | +| S1 | [Fix Your Timestep!](https://gafferongames.com/post/fix_your_timestep/) | Glenn Fiedler, 2004-06-10; fixed-step accumulation, catch-up headroom, interpolation and overload discussion; unversioned article | +| S2 | [High-level multiplayer](https://docs.godotengine.org/en/4.7/tutorials/networking/high_level_multiplayer.html) | Godot documentation contributors; date not stated; 4.7, transfer modes/channels; page may change without a documentation commit pin | +| S3 | [Atomic Commit In SQLite](https://www.sqlite.org/atomiccommit.html) | SQLite project; date not stated; mutable article, rollback-journal mode, flush ordering and failure assumptions; WAL uses a different mechanism | +| S4 | [Environmental Control and Life Support Systems](https://www.nasa.gov/reference/environmental-control-and-life-support-systems-eclss/) | NASA Marshall Space Flight Center; page updated 2025-04-04, editor Beth Ridgeway; ISS air revitalization and oxygen generation; descriptive real-world reference | + +The user-designated [HELLION baseline](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/design/hellion-baseline.md) remains primary. NASA describes ISS equipment, not HELLION gameplay. Its system split is a research question, not an attributed HELLION mechanic or an instruction to adopt real-world thresholds. No source code, creative assets, full articles or game content are imported. + +## Claims, independent evidence and proposed tests + +### Fixed-step catch-up (simulation) + +**Source claim:** S1 argues that a fixed simulation step with limited catch-up work avoids unbounded work accumulation; limiting steps can instead slow apparent simulation. Interpolation between simulation states smooths presentation at the cost of displaying older state. A fixed step alone does not prove cross-platform determinism or identical physics. + +**Frontier inspection:** [SimulationRunner](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/src/core/simulation/simulation_runner.gd) documents fixed physics cadence, a default 16,667 µs tick budget and bounded command counts; [the rate matrix](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/development/simulation-rate-benchmark-matrix.md) already flags changes in work per second and tick-based health semantics at 72/90 Hz. Existing reports are historical, not measurements from this pass. Engine frame scheduling/catch-up policy and a real overloaded host were not verified. + +**Proposed experiment:** at a fixed 60 Hz, compare matched low-load and bounded burst workloads on an isolated authorized fixture, preserving workload and inputs, warmup, capture windows and hardware. Record per-tick p95/p99/max, queue age/depth, budget overruns, simulated ticks per wall second and any catch-up/slowdown; separately capture render pacing. Include command ordering and conserved state checks. Compare work per *simulated second* as well as per tick. Do not change the scheduler or infer a new rate from a microbenchmark. **Cost/limit:** burst fixtures can miss expensive real-world combinations; profiling itself adds overhead. + +### Commit and acknowledgement boundaries (persistence) + +**Source claim:** S3 explains rollback journaling and ordering under stated filesystem/device assumptions; journal durability and recovery depend on correct locking and flush behavior. Its commit mechanism is SQLite-specific and differs in WAL mode. + +**Frontier inspection:** [checkpoint recovery](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/development/checkpoint-recovery-milestone.md) describes alternating slots, validated staging/readback/promotion and prior fault-injection tests. It explicitly limits its assurance to the local protocol and does not prove device power-loss durability, directory sync or a per-command journal. This pass did not rerun those tests. SQLite is not established as the project's current store. + +**Proposed experiment:** extend the existing isolated fault-injection suite only if a fresh gap remains after reviewing active work: compare interruption immediately before promotion, after promotion before acknowledgement, and after acknowledgement, using a retained original request. Assert either old or new valid committed snapshot, correct captured tick/sequence, and explicit unknown-outcome reconciliation without duplicate material or blind replay. Negative controls: corrupted staging and same-sequence/different-content retry. Record the actual filesystem/OS and injected boundary. **Cost/limit:** process-level injections cannot establish real power-cut or device flush ordering. No storage-engine migration is proposed. + +### Channels versus current WebSocket transport (multiplayer) + +**Source claim:** S2 describes reliable/unreliable transfer modes and separate channels in Godot's high-level multiplayer API; separate streams can avoid one logical reliable stream blocking another. This is API/transport-specific, not a universal WebSocket behavior. + +**Frontier inspection:** [FirstPlayableHost](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/src/adapters/network/first_playable_host.gd) uses `TCPServer` and `WebSocketPeer`; [adapter contract](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/architecture/first-playable-adapters.md) describes bounded frames, rate/queue limits and slow-consumer closure. These facts do not show ENet channels in the current path, real packet-loss latency or production-network behavior. + +**Proposed experiment:** use an isolated injected/mock transport with a fixed two-client command stream and large observation bursts. Control A sends normal-sized observations; B injects bounded backpressure/delayed reads using the same WebSocket path. Measure command admission-to-completion p95/p99, queue occupancy, disconnect/reconnect and duplicate or missing outcomes. Verify authoritative order, authorization and no double application in both arms. If a future ENet comparison is authorized, test it separately with matched security, payload and reliability semantics; channels are not a setting to apply to the current socket. **Cost/limit:** mocks cannot establish internet latency, congestion behavior or security equivalence. + +### Air supply versus carbon-dioxide removal (engineering design) + +**Source claim:** S4 describes ISS oxygen generation and air revitalization as distinct functions with different processes. It is neither a HELLION mechanics source nor evidence of Frontier behavior. + +**Frontier inspection:** [breathing/pressure design](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/design/breathing-mixtures-and-pressure-control.md) documents detached species-aware records and a fictional prototype policy; its bulk airlock solver has only total moles, and runtime metabolic consumption/scrubbers remain planned. No health, pressure or UI test was run this pass. + +**Proposed design experiment:** after verifying the HELLION version's actual life-support behavior and existing implementation lanes, compare two scripted scenarios with identical starting mixture and oxygen supply: functional versus disabled CO₂ removal. Track constituent quantities, readable indications, conservation and recovery path, without importing NASA values as game balance. Verify authorized repair/failure outcomes and retained resources through restart only when a relevant system exists. **Cost/limit:** real ISS architecture is not proof of HELLION parity; adding a separately simulated scrubber could increase UI, persistence and tick costs. Treat deviations as explicit design decisions, not as automatically approved features. + +## Outcome and ownership + +All four experiments are **proposed**, not executed; no measured performance improvement, storage guarantee, network advantage, implemented gameplay or HELLION feature parity follows from these references. Reuse existing harnesses and coordinate with active implementation owners before testing. A future result must link exact commit/diff, inputs, OS/engine/transport, raw evidence where separately authorized, failed and not-run cases, and a decision rationale. Keep unpublished/private research, logs and credentials out of public updates. diff --git a/docs/research/experiments/E-001-rendering-baseline.md b/docs/research/experiments/E-001-rendering-baseline.md index 94ff646..5059685 100644 --- a/docs/research/experiments/E-001-rendering-baseline.md +++ b/docs/research/experiments/E-001-rendering-baseline.md @@ -29,6 +29,10 @@ Use a fixed camera path containing a stationary room, movement past thin wall de Measure end-to-end frame intervals (p50/p95/p99), render CPU and GPU timings with their boundaries, simulation/physics timing separately, wall creation/removal time, node/resource counts, draw calls/primitives and CPU/GPU memory gauges. Label unavailable measurements rather than infer them from FPS or engine counters. Engine gauges do not establish full process/driver memory or input-to-display latency. Investigate unexplained refresh-aligned waits before claiming a throughput difference. +## Separate diagnostic: render-resolution sensitivity + +After Stage A, compare two explicitly recorded 3D render scales with the same window, camera path, wall count, renderer/API, AA and scene settings. Record the actual pixel dimensions of each viewport, including the habitat subviewport. Interleave at least five warmed pairs and retain per-run GPU/render CPU and end-to-end p50/p95/p99 frame intervals. Keep native-resolution Stage A as the baseline; resolution changes image quality and is not a wall-sharing A/B. Compare moving-edge readability and labels separately. If pacing masks a change, or GPU timings are unavailable/too noisy, mark the diagnosis inconclusive. A resolution-sensitive GPU result suggests pixel-dependent cost; it does not identify a specific pass. **Proposed; not run.** + ## Stage B: single-variable A/B - **A/control:** existing wall presentation and fixed topology. diff --git a/docs/research/reference-manifest.csv b/docs/research/reference-manifest.csv index 45f0712..ded2542 100644 --- a/docs/research/reference-manifest.csv +++ b/docs/research/reference-manifest.csv @@ -22,3 +22,8 @@ Godot,https://docs.godotengine.org/en/4.7/classes/class_multimesh.html,Class des AMD GPUOpen,https://gpuopen.com/learn/rdna-performance-guide/,RDNA Performance Guide: Command buffers; Pipeline state objects; Barriers; Memory,Mutable guide with RDNA 3 updates; exact latest update unverified,2023-03-22,2026-10-25,Vendor documentation reference; no code or creative asset reuse.,Low-level submission state barrier and memory costs need API/hardware context.,R-001: use vendor guidance to form a measured question; Godot owns low-level renderer work.,Independent summary and links only; AMD/RDNA guidance is not measured RTX or whole-game performance. Godot,https://godotengine.org/article/introducing-reverse-z/,Introducing Reverse Z; introduction and shader compatibility discussion,Historical 4.3 introduction article by Clay John,2024-04-29,2026-10-25,Official article reference; no code or creative asset reuse.,Godot introduced reverse-Z in 4.3 with compatibility implications for some custom shaders.,R-001: do not propose existing engine depth behavior as new Frontier work.,Independent summary and link only; historical article flags that later documentation supersedes old details. HELLION,https://steamcommunity.com/app/588210,Steam community official game description; Steam store About This Game,Public descriptive pages; mutable; no game build or mechanics inventory reviewed,,2026-10-29,Third-party proprietary game; no code or creative asset reuse rights established.,Stranded survivors explore derelict ships and stations and seek air fuel and equipment; store describes multiplayer space-survival simulation.,Primary Frontier gameplay/mechanics baseline; map observed version-specific behavior to independent requirements and acceptance before extensions.,Description-only reference; no game code assets branding UI text or media copied. No official affiliation or implemented parity claimed. +Godot,https://docs.godotengine.org/en/4.7/tutorials/performance/gpu_optimization.html,GPU optimization: bottlenecks; post-processing and shadows; transparency,4.7 docs; mutable; documentation commit not captured,,2026-10-30,Official documentation reference; no code/assets reused.,CPU driver and GPU bottlenecks differ; transparent overdraw and shadow work can add fragment cost.,R-001 / E-001: compare matched render scales as a pixel-cost diagnostic after baseline and pacing analysis.,Independent summary only; older API discussion is not D3D12-specific; no Frontier performance gain reproduced. +Gaffer On Games,https://gafferongames.com/post/fix_your_timestep/,Fix Your Timestep!; fixed step catch-up and interpolation,Unversioned article; Glenn Fiedler,2004-06-10,2026-10-30,Descriptive technical reference; no source code copied.,Bounded catch-up trades runaway work against potential simulation slowdown; rendering may interpolate older states.,R-002: compare fixed 60 Hz low-load/burst queue age tick tails and state invariants in an authorized fixture.,Independent summary only; no Frontier scheduler behavior or determinism established. +Godot,https://docs.godotengine.org/en/4.7/tutorials/networking/high_level_multiplayer.html,High-level multiplayer: transfer modes and channels,4.7 docs; mutable; documentation commit not captured,,2026-10-30,Official documentation reference; no code/assets reused.,High-level networking describes separate channels and transport-specific reliability/ordering.,R-002: measure backpressure on the current WebSocket path before considering transport comparisons.,Reference is not a claim that current TCP/WebSocket has ENet channels; no network experiment run. +SQLite,https://www.sqlite.org/atomiccommit.html,Atomic Commit In SQLite: rollback journal flushing and crash assumptions,Mutable unversioned rollback-journal article; WAL differs,,2026-10-30,Official technical reference; no code/assets reused.,Rollback-journal atomicity depends on ordered writes flushes locking and filesystem/device assumptions.,R-002: review existing local-checkpoint fault tests at promotion and lost-acknowledgement boundaries.,Conceptual comparison only; Frontier is not claimed to use SQLite or have device power-loss guarantees. +NASA,https://www.nasa.gov/reference/environmental-control-and-life-support-systems-eclss/,Environmental Control and Life Support Systems; ISS air revitalization and oxygen generation,NASA Marshall Space Flight Center; mutable page; editor Beth Ridgeway,2025-04-04,2026-10-30,Public descriptive reference; no creative assets or code copied.,ISS oxygen generation and cabin air revitalization are distinct functions with different processes.,R-002: consider a controlled air-supply versus CO2-removal scenario after validating HELLION behavior and project scope.,Not a HELLION source or project implementation evidence; do not import medical thresholds or claim parity. From 9a27d744acb7497325b9b84d3dcb1c7e21f3e561 Mon Sep 17 00:00:00 2001 From: Valithor Obsidion Date: Fri, 6 Nov 2026 08:28:24 -0500 Subject: [PATCH 2/2] Document camera, migration and cold-start research [skip ci] --- docs/research/README.md | 2 +- .../entries/R-001-modern-rendering.md | 10 ++++++ ...2-fixed-ticks-recovery-and-life-support.md | 36 +++++++++++++++++++ docs/research/reference-manifest.csv | 5 +++ 4 files changed, 52 insertions(+), 1 deletion(-) diff --git a/docs/research/README.md b/docs/research/README.md index 4b0f433..44d4ed3 100644 --- a/docs/research/README.md +++ b/docs/research/README.md @@ -7,7 +7,7 @@ This is Frontier Systems' version-controlled knowledgebase for design decisions | Entry | Topic | Outcome | Evidence limit | Next step | | --- | --- | --- | --- | --- | | [R-001: modern rendering optimization leads](entries/R-001-modern-rendering.md) | Rendering/performance | proposed | Official engine/vendor guidance and pinned source inspection; no reproduced rendering gains | [E-001: baseline and shared wall resources](experiments/E-001-rendering-baseline.md) | -| [R-002: fixed ticks, recovery, transport and life support](entries/R-002-fixed-ticks-recovery-and-life-support.md) | Simulation, persistence, multiplayer and engineering design | proposed | Public primary-source review and pinned source inspection; no experiments run | Select one bounded scenario after confirming current work | +| [R-002: fixed ticks, recovery, transport and life support](entries/R-002-fixed-ticks-recovery-and-life-support.md) | Simulation, persistence, multiplayer and engineering design | proposed | Public primary-source review and pinned source inspection; 2026-11-06 follow-up; no experiments run | Select one bounded scenario after confirming current work | | [Reference manifest](reference-manifest.csv) | Cross-topic provenance | existing registry | Each row states its reviewed scope and rights limits | Append targeted sources; preserve the CSV contract | | [Foundational capability matrix v1](foundational-capability-matrix.v1.csv) | Engineering-game design | existing audit | Historical capability/gap statements have their own evidence dates | Revalidate a row before treating it as current implementation | diff --git a/docs/research/entries/R-001-modern-rendering.md b/docs/research/entries/R-001-modern-rendering.md index 03e60c7..ce55f93 100644 --- a/docs/research/entries/R-001-modern-rendering.md +++ b/docs/research/entries/R-001-modern-rendering.md @@ -58,3 +58,13 @@ A future comparison should establish actual 1080p render targets and CPU/GPU/fra [GPU optimization](https://docs.godotengine.org/en/4.7/tutorials/performance/gpu_optimization.html), Godot documentation contributors, 4.7 documentation (publication date not stated; mutable page, accessed 2026-10-30), describes separate CPU/driver/GPU bottlenecks and notes that overlapping transparent surfaces and shadow/post-processing work can increase fragment cost. This is engine guidance, not a Frontier measurement; the page's API discussion includes older graphics APIs and is not evidence about a particular D3D12 driver. **Proposed diagnostic:** E-001 adds a separate render-resolution sensitivity comparison after establishing actual viewport sizes and frame pacing. A measurable GPU-time change with resolution is a clue about pixel-dependent work, not proof of a particular shader or whole-game gain. Validate any subsequent optimization with its own fixed-resolution comparison and motion/readability checks. Outcome remains **proposed**, with no run or adoption. + +## Follow-up source review: 2026-11-06 + +**Source:** Godot documentation contributors, [Reducing stutter from shader (pipeline) compilations](https://docs.godotengine.org/en/4.7/tutorials/performance/pipeline_compilations.html), Godot 4.7, publication date not stated; accessed 2026-11-06. The versioned page is mutable and no documentation commit was captured. + +**Claim:** For Forward+ and Mobile, the docs describe pipeline precompilation and cumulative compilation monitors. First instancing or newly encountered rendering features can still lead to compilation during play. Shader baking produces an intermediate format, not the final driver-specific pipeline, and headless export cannot perform that baking. + +**Frontier evidence:** The pinned [project settings](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/project.godot) declare Forward+ and Windows D3D12. The [existing client benchmark](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/tools/godot/benchmark_client.gd) records frame intervals and render timing for a stationary scene; it does not establish pipeline compilation as a cause of stutter. No compilation monitor or GPU experiment was run here. + +**Proposed diagnostic:** In a separately authorized isolated environment, compare a repeatable first encounter with the same subsequent encounter, keeping scene, camera path, renderer, viewport sizes and frame pacing fixed. Record frame-interval p95/p99 and first-encounter spikes alongside compilation-monitor deltas and loading time. Record engine, GPU, driver and actual cache state; if the driver cache is uncontrolled, label the first encounter accordingly. Never delete shared driver caches. Compare visible output and startup cost before proposing any warmup change. **Limit/cost:** compilation counters are cumulative, attribution is correlational, and a warm cache is hardware/driver dependent. No optimization is adopted or performance gain demonstrated. Outcome: **proposed**. diff --git a/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md b/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md index ada691d..6ff187a 100644 --- a/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md +++ b/docs/research/entries/R-002-fixed-ticks-recovery-and-life-support.md @@ -55,3 +55,39 @@ The user-designated [HELLION baseline](https://github.com/Valgorithms/Frontier-S ## Outcome and ownership All four experiments are **proposed**, not executed; no measured performance improvement, storage guarantee, network advantage, implemented gameplay or HELLION feature parity follows from these references. Reuse existing harnesses and coordinate with active implementation owners before testing. A future result must link exact commit/diff, inputs, OS/engine/transport, raw evidence where separately authorized, failed and not-run cases, and a decision rationale. Keep unpublished/private research, logs and credentials out of public updates. + +## Follow-up source review: 2026-11-06 + +The following are new sources for existing research questions, reviewed 2026-11-06. All outcomes remain **proposed**; no experiments ran. Prior source and experiment records above are retained. + +### Camera interpolation and simulation authority + +**Source:** Godot documentation contributors, [Advanced physics interpolation](https://docs.godotengine.org/en/4.7/tutorials/physics/interpolation/advanced_physics_interpolation.html), 4.7; publication date not stated, mutable page, no documentation commit captured. It describes following an interpolated target for camera presentation, current physics transforms for gameplay, and the fact that an uninterpolated child can still inherit its moving parent's interpolated rendering transform. + +**Frontier evidence:** [Camera motion smoothing](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/development/camera-motion-smoothing-milestone.md) documents angular presentation smoothing while preserving body/collision behavior and existing selection-ray contracts. It reports historical checks, not evidence collected this week. It does not establish that Godot's optional physics interpolation is enabled or that a different hierarchy is warranted. + +**Proposed experiment:** After coordinating with existing owners and obtaining separate execution authorization, compare the current camera setup with a presentation-only interpolation fixture at fixed physics cadence and two recorded render cadences. Inspect first/third-person motion, parent/child inheritance, a discontinuity/reset and wall occlusion. Assert the same authoritative snapshots, movement/collision results, reach validation and selection/occlusion correctness. Record camera delay, visible discontinuities and any picking mismatch; establish acceptance thresholds beforehand. **Tradeoff:** smoothing can add visible/input latency and hierarchy complexity; the source does not prove that a change is needed in Frontier. + +### Network snapshot smoothing + +**Source:** Glenn Fiedler, [Snapshot Interpolation](https://gafferongames.com/post/snapshot_interpolation/), 2014-11-30, unversioned article, accessed 2026-11-06. Its illustrative snapshot buffering trades added display delay for smoother reconstruction under jitter; the example's UDP workload, loss and timing are not Frontier targets. + +**Frontier evidence:** [First-playable adapters](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/architecture/first-playable-adapters.md) describe authoritative host state, disposable client observations, bounded WebSocket/TCP transport and reconnect invalidation. This is not proof that a snapshot interpolation buffer currently exists or that network motion is jittery. + +**Proposed experiment:** With isolated, injected WebSocket observation delivery and fixed authoritative inputs, compare immediate presentation against a bounded visual-only snapshot buffer across recorded delay/jitter patterns. Include disconnect/reconnect, stale session generations, teleports and missing updates. Record display age, visible position error and buffer underruns; assert commands, collision, reach checks and persisted state are identical. Choose buffer size and acceptable latency before testing. **Tradeoff:** extra delay and stale visual information; a mock does not establish Internet performance or justify copying UDP loss/rate assumptions. + +### Storage mode and multi-owner boundaries + +**Source:** SQLite project, [Write-Ahead Logging](https://www.sqlite.org/wal.html), unversioned mutable documentation, publication date not stated, accessed 2026-11-06. It describes WAL's separate log/checkpoint behavior, same-host shared-memory requirement and lack of atomicity across a set of attached databases in WAL mode. These details are conditional on SQLite/WAL, not general guarantees for files or networks. + +**Frontier evidence:** [Local checkpoint recovery](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/development/checkpoint-recovery-milestone.md) describes two JSON slots and bounded recovery; [persistence design](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/design/persistence-and-command-boundary.md) describes a separate repository contract. Neither establishes SQLite as the current adapter or proves hardware power-loss durability. + +**Proposed experiment:** Only if a future SQLite adapter is separately considered and authorized, design isolated tests using one database transaction versus two attached databases, recording SQLite build, journal/synchronous modes, filesystem, storage failures and OS. Interrupt at transaction/checkpoint boundaries and compare restored owner revisions and invariant results; treat unsupported or uncertain outcomes as failures to establish the guarantee. Do not modify the present checkpoint protocol or imply WAL is a selected dependency. **Tradeoff:** WAL/checkpoint lifecycle and sidecar files complicate backup and operation; this source does not establish actual Frontier latency or atomicity. + +### Save compatibility versus behavioral compatibility + +**Source:** Factorio team / Wube Software, [Friday Facts #449: 2.1 Stable](https://www.factorio.com/blog/post/fff-449), 2026-10-23, accessed 2026-11-06. The authors state that 2.0 saves load in 2.1 but circuit input/output changes may break existing factory designs, and updated saves/blueprints cannot be downgraded to 2.0. This is Factorio's report, not an observation of Frontier or HELLION. The linked FFF-442 was not independently reviewed for this entry. + +**Frontier evidence:** [Control circuit runtime](https://github.com/Valgorithms/Frontier-Systems/blob/115f0e3c2fbf059819a4844ccdeffb64182af062/docs/architecture/control-circuit-runtime.md) documents versioned records and restoration of circuits, wires and queued pulses. A valid decoded record by itself does not show that a particular old factory retains equivalent behavior after migration; no migration test was run here. + +**Proposed experiment:** When a real control-schema change is proposed, preserve an isolated fixture of an old-version circuit with known inputs, outputs, power and pending pulse state. Compare an old-version replay with the migrated circuit under the same tick-indexed inputs; check outputs, sequence/order, retained resources and documented exceptions. Include unknown-version and incompatible-route rejection, and confirm the original fixture stays available for rollback. **Tradeoff:** semantic compatibility may require preserving older behavior or an explicit user-visible migration, not merely accepting serialized fields. Treat Factorio as a secondary engineering lesson; establish HELLION behavior independently before adopting gameplay differences. diff --git a/docs/research/reference-manifest.csv b/docs/research/reference-manifest.csv index ded2542..2e94850 100644 --- a/docs/research/reference-manifest.csv +++ b/docs/research/reference-manifest.csv @@ -27,3 +27,8 @@ Gaffer On Games,https://gafferongames.com/post/fix_your_timestep/,Fix Your Times Godot,https://docs.godotengine.org/en/4.7/tutorials/networking/high_level_multiplayer.html,High-level multiplayer: transfer modes and channels,4.7 docs; mutable; documentation commit not captured,,2026-10-30,Official documentation reference; no code/assets reused.,High-level networking describes separate channels and transport-specific reliability/ordering.,R-002: measure backpressure on the current WebSocket path before considering transport comparisons.,Reference is not a claim that current TCP/WebSocket has ENet channels; no network experiment run. SQLite,https://www.sqlite.org/atomiccommit.html,Atomic Commit In SQLite: rollback journal flushing and crash assumptions,Mutable unversioned rollback-journal article; WAL differs,,2026-10-30,Official technical reference; no code/assets reused.,Rollback-journal atomicity depends on ordered writes flushes locking and filesystem/device assumptions.,R-002: review existing local-checkpoint fault tests at promotion and lost-acknowledgement boundaries.,Conceptual comparison only; Frontier is not claimed to use SQLite or have device power-loss guarantees. NASA,https://www.nasa.gov/reference/environmental-control-and-life-support-systems-eclss/,Environmental Control and Life Support Systems; ISS air revitalization and oxygen generation,NASA Marshall Space Flight Center; mutable page; editor Beth Ridgeway,2025-04-04,2026-10-30,Public descriptive reference; no creative assets or code copied.,ISS oxygen generation and cabin air revitalization are distinct functions with different processes.,R-002: consider a controlled air-supply versus CO2-removal scenario after validating HELLION behavior and project scope.,Not a HELLION source or project implementation evidence; do not import medical thresholds or claim parity. +Godot,https://docs.godotengine.org/en/4.7/tutorials/performance/pipeline_compilations.html,Pipeline precompilation monitors; first-use features; shader baking limitations,4.7 docs; mutable; documentation commit not captured,,2026-11-06,Official documentation reference; no source or assets reused.,Pipeline compilation can occur during first use; the shader baker does not bake hardware-specific final pipelines.,R-001: compare isolated first and subsequent encounters and monitor deltas without clearing shared caches.,Source guidance only; no project stutter cause benchmark or optimization established. +Godot,https://docs.godotengine.org/en/4.7/tutorials/physics/interpolation/advanced_physics_interpolation.html,Advanced physics interpolation: parent transforms; cameras; current physics transforms,4.7 docs; mutable; documentation commit not captured,,2026-11-06,Official documentation reference; no source or assets reused.,Presentation interpolation and physics transforms have different purposes; child local opt-out does not cancel parent interpolation.,R-002: compare camera presentation while checking movement collision reach and selection invariants.,No Frontier interpolation behavior or performance outcome tested. +Gaffer On Games,https://gafferongames.com/post/snapshot_interpolation/,Snapshot Interpolation: buffering jitter and display delay,Unversioned article; Glenn Fiedler,2014-11-30,2026-11-06,Descriptive technical reference; no source code copied.,Buffered visual snapshots trade display latency for smoothness under jitter.,R-002: isolated visual-only buffered versus immediate presentation using the existing WebSocket context.,Original UDP example timings/rates are not Frontier targets; no experiment or transport change. +SQLite,https://www.sqlite.org/wal.html,Write-Ahead Logging: operation; checkpointing; same-host and attached-database limits,Mutable unversioned documentation; SQLite WAL mode,,2026-11-06,Official technical reference; no source code copied.,SQLite WAL has sidecar/checkpoint considerations and its multi-database atomicity differs from a single database.,R-002: only if a future adapter is separately authorized compare isolated transaction recovery and multi-owner invariants.,Frontier is not claimed to use SQLite; no database migration performance or durability result. +Factorio,https://www.factorio.com/blog/post/fff-449,Friday Facts 449: Before you update; circuit network,Factorio 2.1 stable announcement; Factorio team / Wube Software,2026-10-23,2026-11-06,Public game-design description; proprietary content and reuse rights not established.,2.0 saves load in 2.1 but changed circuit I/O may break designs; updated saves and blueprints cannot downgrade.,R-002: compare versioned circuit migration outcomes against prior tick-indexed behavior when an actual change is proposed.,Secondary design lesson only; no HELLION or Frontier parity claim and no source/assets copied.