Session 132duodecimus (suite 13h) — Phase C portes : LE bug fondamental, signe de Y

Diagnostic enfin lumineux

Grace aux logs runtime de s13g, j’ai enfin pu voir l’etat reel du systeme :

[DoorControl RUN] zone=5 dist=0.39 trigger=3.00
  currentRoofY=0.000  want=true  canPass=false  rbcInSpace=true
[DoorControl RUN] zone=5 dist=0.39 trigger=3.00
  currentRoofY=0.781  want=true  canPass=false
[DoorControl RUN] zone=5 dist=0.39 trigger=3.00
  currentRoofY=2.346  want=true  canPass=false
[DoorControl RUN] zone=5 dist=0.39 trigger=3.00
  currentRoofY=3.909  want=true  canPass=false
[DoorControl RUN] zone=5 dist=0.39 trigger=3.00
  currentRoofY=4.000  want=true  canPass=false  <-- toujours false !

currentRoofY MONTE de 0 a 4 (positif). Ca veut dire que :
– closedRoofY = 0 (porte fermee)
– openRoofY = +4 (porte ouverte)

La convention JME est Y positif = HAUT (standard, comme partout en
3D). La fonction WorldScale.worldYToJme(y) = -y/Y_SCALE negate le Y
Amiga (qui est en convention inversee) pour donner du Y JME standard.
Depuis 5 sessions je codais a l’envers en pensant que JME etait inverse.

Le bug canPass

// Avant (FAUX) - hypothese Y negatif=haut
boolean canPass = currentRoofY < (corridorFloorY - PLAYER_HEIGHT - 0.05f);
// Avec corridorFloorY=0, PLAYER_HEIGHT=1.5 -> seuil = -1.55
// currentRoofY=4 > -1.55 -> canPass = false TOUJOURS

La formule etait inversee dans les deux sens : < au lieu de >,
et - au lieu de +. C’est pourquoi le rbc n’etait JAMAIS retire du
PhysicsSpace.

// Apres (CORRECT) - Y positif = haut (convention JME standard)
boolean canPass = currentRoofY > (corridorFloorY + PLAYER_HEIGHT + 0.05f);
// Avec corridorFloorY=0, PLAYER_HEIGHT=1.5 -> seuil = 1.55
// currentRoofY=4 > 1.55 -> canPass = true ✓

Bonus : simplification du ratio

// Avant (correct mais avec total negatif - confusing)
float total = closedRoofY - openRoofY;  // = -4
float ratio = (closedRoofY - currentRoofY) / total;  // -X/-4 = +X/4

// Apres (plus naturel)
float total = openRoofY - closedRoofY;  // = +4
float ratio = (currentRoofY - closedRoofY) / total;  // X/4

Correction de la doc

J’ai retire toutes les mentions « En JME, plus on est haut, plus Y est
petit » qui m’avait induit en erreur. La doc affirme maintenant la
convention JME standard.

Fichiers modifies

• DoorControl.java :
• controlUpdate : canPass = currentRoofY > (corridorFloorY + PLAYER_HEIGHT)
• updateMeshes : ratio simplifie avec total = openRoofY - closedRoofY
• JavaDoc de la classe : convention JME standard

Tests prevus

Avec la combinaison s13f (yBotPanel=currentRoofY) + s13h (canPass
inverse) la porte devrait :

1. Fermee : panneau plein de yBot=0 a yTop=4, texture chevron
   complete visible, joueur bloque par rbc.
2. Pendant ouverture : yBot monte vers yTop=4, V_top descend vers 0
   (la grille rentre dans le linteau, les chevrons restent visibles).
3. Ouverte (currentRoofY=4) : panneau invisible (yBot=yTop), rbc
   retire du PhysicsSpace, joueur peut traverser librement.
4. Logs OPEN, collision REMOVED apparaissent enfin.

Apres validation, on retire les logs verbeux et on attaque la zone 30
(trou noir des cotes) puis les lifts (Phase C lifts).