EscapistsReintroduced/docs/environment.md

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 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.