[Scripte] Grundsätzliches zum Einstiegsverhalten

Das Forum befindet sich im reduzierten Betrieb. Die Addon- und Supportforen bleiben weiterhin verfügbar.
Bitte beachte, dass OMSI nicht mehr weiterentwickelt wird. Ein Teil der Entwickler widmet sich inzwischen der Entwicklung eines neuen Simulators. Weitere Informationen zum LOTUS-Simulator findest Du hier.
  • Recht hast du. Ich habe mir mal die ganze "Berliner" .osc (Beitrag #15) eingefügt, und konnte das Problem reproduzieren. Leider ist diese .osc mit dem 4.4 3-Türer solo Citaro, den ich bis jetzt im Rahmen dieses Threads zum Testen verwendet habe, nicht ganz kompatibel (die Trigger der .osc stimmen mit den [mouseevent]s der model.cfg des verwendeten Fahrzeuges nicht überein), was das Testen erheblich erschwert. Könntest du mir verraten mit welcher .bus-Datei aus welchem Morphi-Paket die .osc normalerweise zu nutzen wäre?

  • Servus, die door_auto.osc aus dem Gelenkzug (MB_O530 G Auto Door Main.bus) mit der Morphiversion 4.5. Aber ich denke, ob Gelenkzug oder Solo sollte beim Citaro der 1. Generation eig. unerheblich sein da die Befehle insgesamt doch die gleichen sein müssten?

  • Ich habe die .osc ein bisschen überarbeitet. Leider kam nach einem gewissem Punkt doch subjektiver Geschmack ins Spiel, was zu mehr Veränderungen als absolut notwendig führte. Ich hänge das ganze trotzdem mal an, in der Hoffnung dass du etwas damit anfangen kannst. Da Dateien verändert wurden die von anderen Fahrzeugen ebenfalls benutzt werden, würde ich empfehlen diese in separate Dateien einzufügen, und die MB_O530 G Auto Door Main.bus entsprechend anzupassen.


    1. door_auto.osc


    2. door_varlist.txt


    3. passengercabin_O530 Main.cfg (Auschnitt)


    4. passengercabin_O530 Trailer E3.cfg (Auschnitt)


    5. In der model_O530 G Automatic.cfg:

    • Unter O530_G\Wagen_haelt.o3d, die Variable des visible-Befehls von haltewunschlampe zu door_haltewunschlampe ändern.
    • Unter O530_G\Knopf.o3d, den Trigger-Namen (mouseevent-Befehl) von bus_doorfront1 zu door_kinderwagenwunsch ändern.

    6. In der model_O530 G Automatic Trail.cfg:

    • Unter O530_G\Wagen_haelt.o3d, die Variable des visible-Befehls von haltewunschlampe zu door_haltewunschlampe_2 ändern.
    • Unter O530_Trail\Haltewunschtaster.o3d, den Trigger-Namen (mouseevent-Befehl) von door_haltewunsch zu door_haltewunsch_2 ändern.

    7. In der sound_euro3.cfg, folgenden Abschnitt


    ...gegen folgenden austauschen:


    8. In der cockpit.osc, nach (L.L.haltewunschlampe) suchen, und zu (L.L.door_haltewunschlampe_all) ändern.


    9. In der VDV_Euro3.osc, nach (L.L.haltewunsch) (2x) suchen, und zu (L.L.door_haltewunschlampe_all) ändern.


    10. Aus der MB_O530 G Auto Door Main.bus den Skript-Eintrag script\summer.osc entfernen (und die Skript-Anzahl um 1 reduzieren).


    * * *


    Und nun eine kurze Übersicht der Änderungen:

    • In der passengercabin.cfg werden beide Flügel der 1. Tür nicht als {noticketsale} bezeichnet, stattdessen aber als {withbutton}. Obwohl beides nicht erforderlich ist, hilft es dennoch (meistens -- es sei denn man hält genau auf Höhe der wartenden Menschen an) der KI sich die 1. Tuer nur dann zum Einstieg auszuwählen wenn Ticketkauf erwünscht ist.
    • Im Skript, am Anfang des Door_Frame-Makros, werden die PAX_EntryN_Open-Variablen nur dann auf 1 gesetzt, wenn kein Passagier gerade durch den N. Flügel aussteigen möchte (PAX_ExitN_Req = 0). Dass reduziert das Ein-/Ausstiegs "Chaos" / "Drängeln" ein wenig. Man hätte es natürlich auch so machen können, dass kein Flügel pro Paar zum Einstieg freigegeben wird, solange auch nur einer zum Ausstieg verwendet wird. Da kannst du selbst beliebig weiter experimentieren, was am besten funktioniert.
    • Der (sichtbare) Außentüröffner der 2. Tür funktioniert nun als Kinderwagenwunsch-Taster.
    • Die Wahrscheinlichkeit des zufälligen KI-Kinderwagenwunsches wird nun wie folgt berechnet: Es entsteht rund um die Uhr eine Grundlinie von 10%. Zwischen 8 und 20 Uhr wird diese Wahrscheinlichkeit zufällig pro Haltewunsch um bis zu 10% erhöht. Dazu spielt noch die Anzahl der Fahrgäste eine Rolle: Für jede 10 Passagiere wird die Grundwahrscheinlichkeit um bis zu 10% erhöht. Man kann die allgemeine Zufallsrate erhöhen, indem man den Wert 90 bei Zeile 415 reduziert. Nebenbei, gilt der Zufall jetzt auch bei einsteigenden Fahrgästen (nur Tür 2).
    • Die Haltewunschtaster des Vorderwagens sind nur an die 2. Tür gekoppelt; diese des Hinterwagens hingegen nur an die 3.
    • Drückt man einen Haltewunschtaster bevor die Türen freigegeben werden, geht die entsprechende Tür nach der Freigabe trotzdem auf (es sei denn die Stromversorgung wird zwischendurch unterbrochen).
    • Haltewunschlampe im Vorderwagen ist nun von der des Hinterwagens getrennt. Daschboard zeigt weiterhin deren Logische "OR"-Kombination (eine-oder-alle-beide-an) an.
    • Haltewunschlampen gehen nur dann an wenn entweder ein Kinderwagenwunsch ausgelöst wurden ist (und Türfreigabe + Dashboard-Kinderwagenschalter 2. Tür nicht aktiv), oder ein Haltewunsch ausgelöst wurden ist während die Türfreigabe nicht aktiv ist. Drucken der (virtuellen) Außentüröffner wird in dem Sinne nicht berücksichtigt (sonnst würde es bei jeder Haltestelle, an der jemand hinten einsteigen möchte, "klingeln"). Der Haltewunsch-Sound ertönt einmalig genau unter den selben Bedingungen, mit anderen Worten genau dann wenn sich eine der Haltewunschlampen zum ersten Mal anschaltet (und vorher keine eingeschaltet gewesen war).
    • Der von der KI verwendeter int_haltewunsch Trigger wurde beseitigt. Er brachte nichts außer zusätzliche Komplexität. KI-bezogene Hintertürlogik funktioniert nun wie folgt:
      • Will ein Mensch aussteigen (PAX_Exit0~3_Req = 1), ist es so als ob der Nutzer einen der entsprechenden Haltewunschknöpfe betätigt hätte: Die Tatsache wird gespeichert, und die Tür wird sobald freigegeben auch geöffnet -- ob dann der Fahrgast weiterhin noch aus genau dieser Tür (oder überhaupt) aussteigen möchte oder nicht.
      • Will ein Mensch einsteigen (PAX_Entry2~5_Req = 1), geht die Tuer nur dann auf wenn zu diesem Zeitpunkt freigegeben; sonst wird die Tatsache (das drücken des virtuellen Außentüröffners) nicht berücksichtigt.

    * * *


    Bezüglich deiner letzten Frage: Die groben Funktionen (Dashboard-Schalter) sind natürlich die selben. Die Tastaturbefehle und viel mehr deren Implementierung (die dazugehörigen {trigger:...} ... {end}-Blöcke im Skript) bleiben leider nicht immer unverändert. Insbesondere bei Türtastern, 20-Uhr Schalter, Türfreigabe, und Taster fürs manuelle Öffnen der Automatischen Hintertüren, kommt es des öfteren zu gewisser Abweichung. In diesem Fall setzte beim 4.4 Skript / model.cfg der Befehl für die Türfreigabe die Variable bremse_halte_sw (und baute darauf auf), das 4.5 Skript / model.cfg hingegen die Variable bus_dooraft_sw (und baute wiederum darauf auf). Zusätzlich löste der Befehl des 4.4 Skripts / model.cfgs für den 20-Uhr Schalter im 4.5 Skript hingegen die Türfreigabe aus (man klickte auf den einen Taster und es bewegte sich buchstäblich der andere). Fürs Testen / Debuggen also nicht gerade optimal.

  • Servus,


    danke bis hier hin! Entschuldige bitte wenn Antworten und Tests etwas länger dauern, aber mit freier Zeit siehts bei mir grad eher mau aus.

    Zum Post, ich hab das mal 1:1 mit einer neuen .bus probiert, die dazugehörigen Dateien (door, model, sound) vervielfältigt und den Inhalt von hier eingefügt, es klappt soweit, allerdings laufen die Leut nachwievor bei geschlossener 2. Tür vor zur 1. statt diese von außen zu öffnen, wenn diese mal offen steht steigen sie hinten auch ein. Scheinbar fehlt noch irgendetwas, denn wenn die Leut hinten am einsteigen sind, will die Tür nach 3 Sekunden wieder zulaufen, aber durch die blockierte Lichtschranke springt sie wieder auf.

  • Hallo,


    Ist in Ordnung (und gilt meinerseits ebenfalls, sollte ich mich mal über ein paar Tage oder Wochen nicht zurückmelden).


    In meinen Tests läuft es wie folgt ab: Halte ich mit 1. Tür auf Höhe der wartenden Menschen an, wollen sie an der 1. auch einsteigen. Halte ich hingegen mit der 2. Tür ihnen gegenüber gerichtet, öffnen und steigen sie -- zumindest diese von ihnen die bereits ein Ticket besitzen -- hingegen durch die 2. ein. Will man nun dass die Menschen bedingungslos die 2. Tür benutzen, muss man die beiden [entry]s dieser, vor denen der 1. Tür in der .cfg deklarieren. Zusätzlich muss man noch alle PAX_(Entry|Exit)_(0|1)_(Req|Open) Instanzen im Skript zu PAX_(Entry|Exit)_(2|3)_(Req|Open) ändern, und umgekehrt. Allerdings kann ich nicht garantieren dass die KI dann überhaupt noch die 1. Tür benutzt wenn Ticketkauf erwünscht ist.


    Übrigens muss ich gestehen dass mir dank Vorführeffekt in die Implementierung der oben beschriebenen Kinderwagen-Zufallsfunktion ein Bug hinein gerutscht ist. Da die Funktion in ihrer jetzigen Form eh sinnlos ist (die Passagiere öffnen ja sowieso die Türen und steigen ein, ob sie vorher einen Kinderwagenwunsch ausgelöst hatten oder nicht), will ich nebenbei versuchen sie so anzupassen dass die KI dann bedingungslos wartet bis der Nutzer den Kinderwagenschalter betätigt hat (vielleicht sogar die Rampe aufgeklappt hat). Und schließlich würde ich noch gern das Skript so umstrukturieren, dass es, gegeben einer .cfg mit abweichender [entry]-/[exit]-Reihenfolge, leichter anpassbar ist, indem gezielt nur eine bestimmter Abschnitt bearbeitet werden muss, statt Dutzender. Zu diesen 3 Punkten melde ich mich dann erneut, wahrscheinlich übers Wochenende, mit einem Patch (Beitrag #26 wird dann editiert).


    Edit: Das Phänomen dass die Tür zugehen will obwohl noch Leute am einsteigen / aussteigen sind, kommt bei mir nicht vor. Am liebsten Software wie dieses verwenden, um sich zu vergewissern dass auch wirklich alle .osc-Differenzen übernommen wurden. Im Patch werde ich mal genau die Stellen markieren die bearbeitet wurden.

  • Servus, ja kein Ding, wir sind alle nur Menschen.


    Das einzige was ich nicht übernommen habe ist der {Withbutton} für die 1. Türe

    da hier hauptsächlich die hinteren Türen genutzt werden (Ein- und Ausstieg an allen Türen).

    In meinen Tests setz ich das Fahrzeug, rüste es auf, ziehe zur Einstiegshaltestelle vor, schildere mit Linie/Kurs/Route und gebe dann erst die Türen frei. I.d.R. stehe ich dabei eher weiter vorne dass auch alle Türen bündig sind, somit ist der Würfel bei Stillstand ungefähr auf Höhe der 2. Achse, trotzdem rennen die vor zur 1. Türe.