maszyna/pr-reviews/PR-263.md

Review PR #263 — ESt3 distributor: spring preload, minimum stage, releaser and AL2 timing; AI predicts the new characteristic

Autor: @pwarszawski · base: master (zbudowany na #187) · przyrost ponad #187: 4 pliki, ~+60/−15 https://github.com/MaSzyna-EU07/maszyna/pull/263

Werdykt: Approve merytorycznie; przed merge — testy golden / CI i decyzja o kolejności z #264

Recenzja dotyczy tylko przyrostu ponad #187 (interdiff policzony lokalnie).

Podsumowanie

Model rozrządu TNESt3:

• wstępny nacisk sprężyn 0.21 bar zamiast 0.05 (dPSprezyny), BVM liczone z tego samego offsetu → pełne hamowanie dalej daje MaxBP,
• minimalny stopień 0.28 bar (pStopnia), pełne odluźnienie gdy cel = 0,
• odluźniacz automatyczny: ZS 15 l z 5.0 do 0.4 bar w ~23 s (było 5.6 s),
• dTN 1.65 → 1.62 (literówka),
• AL2: komora impulsowa 1 l, dysze cylindra przeskalowane wg tablicy 3-9.

AI: TNESt3::GetBrakeRatio() zwraca rzeczywisty udział ciśnienia w cylindrze dla danego spadku w PG, więc tablice hamowania AI odpowiadają charakterystyce zaworu.

Co sprawdziłem

• GetBrakeRatio(1.0) == 1.0: spadek = MaxBP/BVM + 0.21 = HPP − LPP, cel = (spadek − 0.21)·BVM = MaxBP. ✔ Dzięki temu wywołania BrakeForceR(1.0, …) w DynObj.cpp i Train.cpp (wskaźniki siły hamowania) się nie zmieniają.
• Nowe progi w CheckState() to stare progi przeskalowane do domeny ciśnienia w cylindrze (0.01 → 0.01·BVM) — równoważne poza nowym minimalnym stopniem. ✔
• Zmiana fizyki dotyczy każdego pojazdu z ESt3 bez zmian w .fiz — opis PR mówi to wprost, zgodnie z CLAUDE.md. ✔

Uwagi

1. Testy golden / CI. Na master są ślady golden (tests/unit/data/golden/consist/, test_consist.cpp loguje m.in. BrakeForceR0.25), a także test_brakes.cpp / test_brake_cycle.cpp z pojazdami ESt3 (401W, 430W…). PR nie zmienia żadnego testu, a GitHub pokazuje stan unstable. Proszę po rebase na master sprawdzić, które testy się zmieniły, i zaktualizować golden świadomie (z opisem w PR, co się zmieniło i dlaczego).
2. Testy akceptacyjne jako unit testy. W opisie jest „valve test bench that runs the acceptance procedures” (77 → 40 wyników poza tolerancją). Bardzo proszę dołożyć choć część tych prób (stopień minimalny — próby 12/22, odluźniacz — próba 27, czasy AL2 — tablica 3-9) do tests/unit. To najlepsza ochrona tej poprawki przed regresją.
3. Kolejność merge. Opis przyznaje, że sam #263 pogarsza precyzję zatrzymań (403 → 363 w oknie 8–15 m) i daje problem z ciężkim G na śliskim spadku, który naprawia dopiero #264. Proponuję merge #263 i #264 razem (albo w jednym oknie wydania), a nie #263 osobno przed 26.11.
4. Wolniejszy odluźniacz a reszta AI. 4× wolniejsze opróżnianie ZS wpływa też na reguły control_releaser() przy łączeniu/rozłączaniu i na #265 (ruszanie pod górę z odluźniaczem). Czy scenariusze manewrowe (sprzęganie/odczepianie, odhamowanie składu po połączeniu) zostały sprawdzone? Gracz używający odluźniacza na wagonach też odczuje różnicę — warto to wspomnieć w changelogu.
5. Kod:
   • static double const dPSprezyny/pStopnia → constexpr double (wytyczne GCC/Sonar w CLAUDE.md) i najlepiej w anonimowym namespace.
   • Współczynniki AL2 0.914 / 0.885 / 0.82 / 0.8 — dopisać w komentarzu, z jakich czasów tablicy 3-9 wynikają (albo jak je wyliczono), żeby dało się je odtworzyć.
   • 0.0049 w odluźniaczu — podobnie, nazwana stała z odniesieniem do próby 27.
   • W BrakeForceR() GetBrakeRatio jest stosowane przed korektą ED (dbrake_automatic), rapidem i DMU -0.3. Wydaje się poprawne, ale proszę potwierdzić, że kolejność jest zamierzona.
6. Konsultacja z youBy — warto, żeby youBy zostawił w PR formalne approve części fizycznej; to jego model.