Build independent base gameplay and source-bound native verification

2026-09-19 08:09:14 +02:00
parent 16f397e581
commit af5146a317
580 changed files with 65780 additions and 107 deletions
@@ -0,0 +1,28 @@
+# Round date and weather
+
+Core's `ERR_EnvironmentService` applies optional date and weather selections once during server-side round preparation, immediately before the existing clock service. The native time/weather manager owns simulation and replication. There is no environment tick, local preview, player-health modification or periodic reset. Repeated starts retain the initial selection; a stopped service cannot restart.
+
+Defaults preserve the authored world. Old valid settings files without `startDateCode` and `weatherProfile` acquire zero values in memory, are not rewritten during loading, and retain every existing supported value. An explicit successful save writes the expanded schema using the existing validated temporary-file/backup flow. Present invalid environment values reject the file rather than silently defaulting.
+
+Administrators use:
+
+- `/esc mission date show` and `/esc mission date set YYYY-MM-DD` (1900–2050 inclusive), or `set authored`.
+- `/esc mission weather show` and `/esc mission weather set authored|clear|overcast|rain` (`rainy` is accepted as an alias).
+
+These commands save next-round choices. They report the current native environment separately and do not apply saved changes to the running world. Date validation covers month lengths and Gregorian leap years, including non-leap 1900 and leap 2000. The native manager also validates an explicit date before applying it.
+
+`weatherProfile` values are 0 authored, 1 Clear, 2 Overcast and 3 Rainy. An explicit profile uses the native replicated `ForceWeatherTo` route and loops that weather family. The service validates that the named vanilla state and transition manager exist before changing the date or issuing a request. It verifies the requested current/next state and looping flag. On rejection it attempts to restore the previous date and weather family/looping before startup reports failure. This is not a snapshot of every native transition queue or variant parameter. No UI preview API is used.
+
+A fixed profile selects a family deterministically; cloud variants, wind and other native weather behavior still follow vanilla rules. Existing authored wind/fog overrides are retained. The `authored` setting makes no weather request and preserves the scenario's original weather evolution. Visual intensity, remote replication, manual visibility and long-running transitions still require runtime acceptance.
+
+`startDateCode` is an internal compact integer: `(year - 1900) * 10000 + month * 100 + day`, with 0 meaning authored. For example, 1989-06-01 is 890601. It intentionally stays below 1,501,232, exactly representable by the existing settings reader's floating-point JSON path. A full `YYYYMMDD` number can exceed single-precision exact integer range and corrupt odd dates. Use the natural date command rather than constructing codes by hand.
+
+## Validation
+
+`tests/test_environment_policy.py` executes the actual settings validator and production parsing/formatting functions through the existing C++ policy harness. It compares calendar boundary cases across every supported year against Python's independent `datetime` calendar, tests malformed dates and names, and checks defaults and native family names. Existing migration tests cover the added defaults and bounds. These checks pass; they are not Enforce compilation.
+
+The opt-in WORKBENCH `ERR_NativeEnvironmentProbe` uses a dedicated test settings file, preserving the actual mission settings. It tests legacy loading without rewrite, exact odd date-code serialization, save rejection, unauthorized commands, next-round command behavior and no world mutation from saves. It then temporarily uses fresh service instances to select Clear, Overcast and Rainy with explicit/leap/authored dates, waiting at least one 500ms smoke tick per state. It verifies start idempotency, stopped-service rejection and unchanged clock/progression settings. Before completing it restores the original date, weather family and looping mode. Native transition-queue timing and cloud-variant history are not restored exactly; this is an isolated case that ends with a test-requested round reset. Native compilation and execution remain pending centralized hidden and muted testing.
+
+## Native evidence
+
+[063559](evidence/native-2026-09-19-063559/report.json) completed 67 combined environment/catalog assertions with no script/VM failures and no engine errors. Exact native catalogs retained medical and radio entries; all three weather families and a leap date applied without resetting the clock. Defaults and next-round settings behavior were exercised. This one-round development result does not establish multiplayer replication or repeated-restart reliability.