Problem chyba polega na tym, że przebiegi na głowicy nie mają priorytetów. Najwyższy priorytet powinno mieć zjechanie spod W5, dalej wjazd pociągu ze szlaku, wyjazd na szlak, a najniższy priorytet wyjazd do W5. Obecnie wszystkie przebiegi są równoważne. Ponadto problem występuje, jeśli do Dejaw zbliżają się dwa pociągi — osobowy i towarowy. Każdy z nich ma wjazd na inny tor, przez co przebiegi mogą się ustawić w odwrotnej kolejności niż jadą pociągi.
Ogólnie obecny mechanizm obsługi przebiegów działa w taki sposób, że zbliżającemu się do stacji pociągowi zostaje przydzielony jeden z torów (a jeśli już jest na stacji, to powiązanie z torem jest oczywiste). Dla toru uruchamiana jest pętla eventowa, która próbuje zarezerwować głowicę. Wykonywane w tym celu są dwa eventy — pierwszy to warunkowy UpdateValues, który zapisuje do komórki pamięci powiązanej z głowicą (tu: dej_pd1) kod przebiegu (np. tor5 2 1), o ile ta komórka jest pusta (condition memcompare * * 0). Drugi z eventów sprawdza, czy komórka głowicy została zmieniona zgodnie z żądanym przebiegiem i jeśli tak, to przestawia zwrotnice oraz uruchamia pętlę eventową głowicy (ta z kolei podaje odpowiednie sygnały na semaforach, zależnie od zapisanego w komórce głowicy kodu przebiegu). Jeśli przebieg służy do wyjazdu pociągu na szlak, to wcześniej uruchamiane są dwa inne eventy, które — podobnie jak dla głowicy — sprawdzają, czy szlak jest wolny.
Pętle eventowe można sobie obejrzeć w pliku scenery\quark\dejawy.ctr, więc nie będę ich tu cytował. Pozostałe pliki CTR też mają podobne rozwiązania, choć mogą się różnić szczegółami, ponieważ robiąc pętle dla kolejnych stacji testowałem różne rozwiązania (w tym w zakresie nazewnictwa). Na razie nie mam pomysłu, jak rozwiązać kwestię priorytetów.
