1ede87a135
Audit during N.3 follow-up uncovered that WB's TerrainUtils CalculateSplitDirection uses a different math expression than retail's FSplitNESW (the AC2D-cited polynomial 0x0CCAC033 etc that our visual terrain mesh and physics already share). Substituting TerrainSurface.SampleZ with WB's GetHeight in isolation would re-introduce the triangle-Z hover bug from earlier work — physics and visual mesh would pick different diagonals on disputed cells. Updates: - ISSUE #51 documents the divergence with file references and the research that's needed when N.5 picks this up. - Roadmap N.2 entry flags the dependency on N.5 and the reasoning ("not low-risk after all"). N.1's conformance proved slope-filtering equivalence (boolean walkable verdict), not formula equivalence. The lesson is captured in memory (feedback_wb_migration_formulas.md, not in-repo). Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| architecture | ||
| audit | ||
| plans | ||
| research | ||
| superpowers | ||
| bugs.md | ||
| ISSUES.md | ||