Es wird in der Passengercabin immer von oben herab gezählt, der erste [entry] entspricht demnach immer PAX_Entry0_Open und der erste [exit] immer PAX_Exit0_Open. Entferne ich also einen [entry] der aber über das door-Script an Tür 1 definiert ist, müssen die PAX_EntryX_Open entsprechend der Türen neu zugeordnet werden, ansonsten kommt genau das zu Stande, dass die Tür 2 zwar aufgeht, aber die KI auf das öffnen der Tür 1 wartet.
Aktuell sieht das so aus:
[exit]
15 -> PAX_Exit0_Open (Flügel 1 Tür 1)
[exit]
3 -> PAX_Exit1_Open (Flügel 2 Tür 1)
[exit]
9 -> PAX_Exit2_Open (Flügel 1 Tür 2)
[exit]
11 -> PAX_Exit3_Open (Flügel 2 Tür 2)
Alles anzeigen
Nehme ich jetzt den Exit 3 heraus, der ja scheinbar der zweite Türflügel an Tür 1 ist, dann verschiebt sich das ganze:
[exit]
15 -> PAX_Exit0_Open
[exit]
9 -> PAX_Exit1_Open
[exit]
11 -> PAX_Exit2_Open
Da jetzt aber im door-Script der KI mitgeteilt wird, dass dieser Extit an door1 (Türflügel 2 an Tür 1), wird darauf gewartet, dass ich diesen Türflügel öffne:
(L.L.door_1) 0.9 > (S.L.PAX_Exit1_Open) (S.L.PAX_Entry1_Open)
Bleiben wir bei dem Beispiel nur exit 3, müsste der Abschnitt im door-Script dann so aussehen:
(C.L.big_cabin) ! (L.L.door_0) 0.9 > && (S.L.PAX_Exit0_Open) (S.L.PAX_Entry0_Open)
(L.L.door_1) 0.9 > (S.L.PAX_Entry1_Open)
(L.L.door_2) 0.9 > (S.L.PAX_Exit1_Open) (S.L.PAX_Entry2_Open)
(L.L.door_3) 0.9 > (S.L.PAX_Exit2_Open) (S.L.PAX_Entry3_Open)
Somit steigt keiner mehr am zweiten Türflügel an Tür 1 aus.
Man muss nur genau hinschauen, einige Entwickler definieren eigene Entry- und Exit-Paths, da muss man einfach dieser logik folgen und nicht die der IDs.
Genau dieser Umstand in der Komplexität, habe ich mich dazu entschieden, das Ding zurückzugeben. Zu viel Aufwand, bin ich zu faul für, zumal man das nach jeden Update vermutlich wieder neu anpassen muss in den 33 (!) passengercabins. Nein danke...