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

## Mission view distance

Administrators can set **World → View distance** in `/esc menu`, or use:

- `/esc mission viewdistance set 3000` — request 3,000 metres for the mission.
- `/esc mission viewdistance set default` — release the mission override.
- `/esc mission viewdistance show` — show the saved request and server limit.

`viewDistanceMetres` accepts 500–10,000 metres, or 0 (`default`). Older valid settings files receive 0 in memory without being rewritten. Successful saves apply during the current round and persist for later rounds. Random selection is unavailable for this setting.

The server publishes the requested distance bounded by its configured maximum. Replicated state reaches existing clients and late joiners. Each graphical client also respects its platform limits. The override resumes within one second after closing inventory/video/admin menus, which can temporarily own the native view distance. Default and mission teardown release the temporary override; player video preferences are never written. If another camera owner has already changed the native distance at release, that value is preserved.

This controls camera rendering distance, not network entity streaming range or weather/fog. A saved request above the server maximum cannot increase that maximum.

`tests/test_view_distance.py` executes the production bounds, temporary override/restore and command bodies with substituted engine boundaries, including save failure, default, dedicated-server no-op and changes by another camera owner. The [native environment run](evidence/native-2026-09-30-view-distance/report.json) completed 90 assertions with no script/runtime failures: the camera reported 2,500 → 3,000 → 2,500 metres, and native JSON reload and unauthorized-command rejection passed. Cleanup and unchanged launch source were confirmed. The strict report retains 13 existing resource/property/localization errors plus one Steam statistics error; this is local Workbench evidence, not dedicated-server/client or join-in-progress qualification. The [full repository checks](evidence/check-2026-09-30-view-distance.log.txt) pass.

The [native admin-menu/prisoner-kit run](evidence/native-2026-09-30-view-distance-menu/report.json) completed 366 assertions without script/runtime failures, including the new Default control, help text fitting its 936×20 widget, and rejection of Random for this fixed-only field. The [initial run](evidence/native-2026-09-30-view-distance-menu-initial/report.json) retained a fixture failure from the old assumption that all menu fields support Random; the fixture now checks `Randomizable` and explicitly verifies rejection for fixed-only fields. The successful rerun retained the same 14 engine errors, with cleanup and unchanged launch source confirmed.

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