mirror of
https://github.com/jkdansereau/goldeneye-pc-port.git
synced 2026-10-24 00:02:45 +02:00
James Dansereau
53219c18ae
M-163's live playtest smoothed prop->pos completely (log-verified) but the visible camera shake was unchanged -- the camera's look-at filter doesn't read prop->pos at all. It reads field_488.pos, a separate variable computed from render_pos (the model's own animated-skeleton transform), independent of prop->pos even though both happened to show the same period-4 cycling symptom through a probe that only logged one of them. Retargeted the suppression at field_488.pos's actual write site (bondview2.c:10495-10497, GE_D243X3-gated, freezes it while POSEND is active). User's live playtest: "yep camera shake is gone now" -- the first positive result across the whole D243 investigation. Not a real fix -- GE_D243X3 unconditionally freezes state rather than correcting why the model's skeleton animation cycles in the first place. User also reports Bond's own rendered body still visibly duplicates/glitches, expected since this only freezes the camera-feed copy, not the render_pos draw-path read -- likely the same underlying mechanism observed through a different consumer, not yet isolated. porting-notes.md D11 gets the generalized lesson: confirm the actual consumer reads the field you fixed before spending a live-test cycle on it -- two fields can show the same symptom from one shared root cause while being genuinely independent data paths.