forked from Ports/goldeneye-pc-port
James Dansereau
81054e4c98
* docs+probe(D219): new lead -- explosion.c never clears G_LIGHTING before particle draws explosion.c's 15 particle DLs (assets/oddtextures.c globalDL_0x078..0x9a8, all G_CC_INTERFERENCE+G_CC_MODULATEIA2) never get G_LIGHTING cleared by any of explosion.c's own gSPClearGeometryMode calls. If lighting is left on from a prior draw (e.g. a nearby lit character model), the port's vertex path (gfx_pc.cpp:1301-1346) reinterprets the particle's authored RGBA tint as a normal vector, turning SHADE into a scene-light color instead of red/orange -- state-dependent, would explain "game-wide, live-play-only" exactly as reported, and why the M-90 scripted repro (no nearby lit models) came back clean. Extends the existing D172 multitex-tri probe (GE_D172=1, already proven reliable and uniquely keyed to this particle family) to also flag geometry_mode & G_LIGHTING. Sanity-checked against the known-clean M-90 repro: still fires 40/40, all LIGHTING=off, matching the prior clean result -- confirms the probe works without false-positiving. Not a fix -- needs one live GE_D172=1 capture during a real explosion to confirm or rule out before touching any rendering logic. * fix: regenerate findings-index.csv via tools_pc/gen_findings_index.py Hand-edited the CSV directly in the previous commit instead of running the generator -- CI's "validate" job caught the drift.