erik/acdream
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

sky(phase-5a): remove DayGroup-name rain hack, ship retail-only Overcast mapping

Browse source 
User-observed regression 2026-04-23: acdream spawned rain particles
when retail showed no rain at the same server tick. Root cause: my
Phase 3e shortcut mapped DayGroup.Name = "Rainy" → WeatherKind.Rain →
rain particle emitter. That's not what retail does.

Parallel decompile research confirms:
- Agent A (2026-04-23-physicsscript.md): PhysicsScript runtime lives
  at FUN_0051bed0 → FUN_0051bfb0, runs per PhysicsObj; sky calls it
  from NOWHERE.
- Agent B (2026-04-23-sky-pes-wiring.md): FUN_00508010 (sky render
  loop) never reads SkyObject.DefaultPesObjectId — the field is dead
  at render time. Rain/snow particles in retail come from a separate
  camera-attached weather subsystem that has NOT yet been located.

So the correct behavior is: DayGroup name should only drive
fog/ambient tone (via keyframes, already in the Snapshot path),
never spawn particle emitters. Any retail-faithful particle rain
belongs to a future phase once we find the camera-attached weather
subsystem driver.

Change: MapDayGroupNameToKind now maps all weathery substrings
(storm/snow/rain/cloud/overcast/dark/fog) → Overcast — fog-only
visuals, no particle spawn. Clear names stay Clear. The Rain, Snow,
Storm enum values remain and are still accessible via ForceWeather()
for debug overrides.

Tests updated (WeatherSystemTests): the name→kind theory now expects
Overcast for Rainy/Snowy/Stormy variants.

Also commits the four research docs from this session's parallel
hunt: PhysicsScript dat+runtime, sky↔PES wiring (negative finding),
lightning timer (negative finding — agent #3), fog on sky
(positive: retail applies fog to sky geometry).

NOTE on lightning: agent #3's research only ruled out the CLIENT-SIDE
RANDOM TIMER hypothesis for lightning. User confirms retail does have
visible lightning + thunder. A follow-up agent (#5, in flight as of
this commit) is hunting the real mechanism — PlayScript opcode,
SetLight PhysicsScript hooks, AdminEnvirons side effects, or the
weather-volume draw. This commit does NOT attempt to port lightning.

Build + 733 tests green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Erik 2026-04-24 11:04:36 +02:00
parent d5e37694ed
commit 53608e77e3
6 changed files with 1508 additions and 20 deletions
Download patch file Download diff file Expand all files Collapse all files

34
src/AcDream.Core/World/WeatherState.cs
View file

@ -189,11 +189,35 @@ public sealed class WeatherSystem
{
if (string.IsNullOrWhiteSpace(name)) return WeatherKind.Clear;
string lc = name.ToLowerInvariant();
// Order matters — "thunderstorm" contains "storm", match first.
if (lc.Contains("storm")) return WeatherKind.Storm;
if (lc.Contains("snow")) return WeatherKind.Snow;
if (lc.Contains("rain")) return WeatherKind.Rain;
if (lc.Contains("cloud")
// Retail DOES NOT spawn rain/snow/storm particles based on the
// DayGroup's NAME. Parallel decompile research 2026-04-23
// (docs/research/2026-04-23-sky-pes-wiring.md +
// docs/research/2026-04-23-physicsscript.md) verified:
//
// 1. FUN_00508010 (the sky render loop) never reads
// SkyObject.DefaultPesObjectId — the field is dead at
// render time.
// 2. The PhysicsScript runtime (FUN_0051bed0 → FUN_0051bfb0)
// has no callers from the sky-render tree.
// 3. r12 deepdive claim that retail spawns rain from a sky
// SkyObject's PES was not corroborated by the decompile.
//
// Weather particle emission in retail therefore belongs to a
// SEPARATE camera-attached subsystem, not yet located. Until we
// find and port that subsystem, we must NOT invent our own
// "Rainy DayGroup name → spawn rain particles" path — it produced
// the user-observed regression 2026-04-23 (acdream rained on a
// DayGroup that retail rendered without any rain particles).
//
// Therefore ALL weathery names map to Overcast — they get the
// correct keyframe-driven fog/cloud tone, without the particle
// emitter. Clear names stay Clear. No Rain / Snow / Storm is
// ever returned from name matching. Tests kept for Storm/Rain
// constants since ForceWeather still supports them for debug.
if (lc.Contains("storm")
|| lc.Contains("snow")
|| lc.Contains("rain")
|| lc.Contains("cloud")
|| lc.Contains("overcast")
|| lc.Contains("dark")
|| lc.Contains("fog")) return WeatherKind.Overcast;