[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.
  • Servus,


    ich hab da mal eine grundsätzliche Frage zum Thema Scripte und dem Einstieg hinten. Genauer gesagt das selbstständige öffnen der Türen von außen durch die Fahrgäste.

    Dass die Befehle in der

    auch läuft, muss der entsprechende Einstieg in der

    vorhanden sein. So weit bin ich mittlerweile mit dem Wissen.

    Jetzt aber die Krux an der Geschichte: wie beweg ich die Leut dazu die Tür selbst zu öffnen? Irgendwo muss doch in der door.osc ein Scriptschnipsel zu fehlen, den such ich an dieser stelle.


    Wäre schön wenn mir da einer nen Hinweis o.ä. geben könnte

  • Die Leute bewegt (leider) nur OMSI. Der Algorithmus ist (vermutlich) wie folgt:


    • Ist eine [entry] schon auf (PAX_EntryX_Open = 1)? Steig dort ein. Sind schon mehrere geöffnet? Dann versuch's bei der nächstliegenden.
    • Sonnst: Gibt's eine [entry] die als {withbutton} bezeichnet ist? Wenn ja, lauf zu dieser hin und warte (ewig, auch wenn mittlerweile eine andere [entry] geöffnet wird), in der Hoffnung das das Skript (mittels PAX_EntryX_Req) eventuell begreift das die Tür geöffnet werden muss (also die entsprechende PAX_EntryN_Open auf 1 setzt). Gibt's mehrere davon? Wenn ja, dann wähle die nächstliegende.
    • Sonnst: Laufe zur ersten* [entry].


    * Die erste laut .cfg -- ob es jetzt die 1. oder 2. oder 3. "physische" Tür ist spielt keine Rolle.

    ** Wenn der KI-Mensch eine Fahrkarte will, und es je nach Fall eine [entry] ohne {noticketsale} gibt, dann wird diese priorisiert.

    *** [entry]s im Trailer, wie bekannt, kommen (ohne komplizierte Workarounds zumindest) nicht ins Spiel -- es sei denn, der KI-Mensch wird erst gespawnt nachdem das Fahrzeug die Haltestelle erreicht hat.

  • Servus,


    danke, das weiß ich alles und läuft auch bereits.

    Denn scheinbar geht noch etwas anderes ab, denn aktuell steigen sie nur bei offener Türe zu, sonst rennen sie zur 1. Türe. Sie sollen die nächstiegende Tür erkennen und diese selbstständog öffnen.

  • In der Tat -- deine .cfg funktioniert nicht. Folgende jedoch scheint das erwünschte Verhalten zu erzeugen. Keine Ahnung, ob es jetzt konkret am Großbuchstaben 'W', der Reihenfolge ([entry]s mit [exit]s zusammen gemischt ), oder der Leerzeilen zwischen {noticketsale} und {withbutton} lag...


  • Entschuldige, aber ich bestehe darauf, die .cfg sei die Ursache. Ich hatte beide Schnipsel in einem 3-Türer Citaro ausprobiert. Der erste löste das von dir geschilderte Problem aus, während der zweite wie gewollt funktionierte.


    Aber auch rein theoretisch stimmt es meines Wissens nicht, dass ein Skript irgendwie dazu in der Lage sein kann, die .cfg-Einträge oder die Verarbeitung deren von OMSI zu beeinflussen. Ja, sicherlich ist ein Skript dazu fähig ein seltsames KI-Verhalten auszuwirken -- würde z.B. jede 2. Sekunde eine PAX_EntryX_Open auf 1, die anderen auf 0 gesetzt, würden wahrscheinlich die KI-Menschen auch zwischen den Türen hin und her pendeln. Aber das bedeutet trotzdem nicht dass ein Skript dazu fähig ist die Anzahl von [entry]s, [exit]s, oder Attributen deren dynamisch zu modifizieren -- sonnst wäre vielen Nutzern ein lang bestehender Feature-Wunsch endlich erfüllt.

  • Die Leut sollten geschlossene Automatiktüren von selber öffnen, in diesem Beispiel die 3. Türe. Tun sie in beiden Fällen aber nicht, sondern rennen zur nächsten offenen Türe. Wenn die 3. allerdings offen ist, steigen sie auch dort ein.

  • Und wenn keine Tür geöffnet ist, Pennratte , laufen sie weiterhin zur 1.? Tja, dann werd ich's wohl aufgeben müssen.


    In meinem Test liefen sie brav in Richtung 3. Tür, und, falls vor der Öffnung einer anderen Tür dort auch angelangt, blieben sie dort auch "ewig stecken", unabhängig davon ob das Skript jetzt eine selbst-bedienbare oder eine ganz normale vom Fahrer manuell bedienbare 3. Tür unterstützte. Sie verhielten sich mit anderen Worten genau so wie die Theorie vorhersagt.

  • ...

    In deinem Fall handelt es sich wohl um einen Skript-Fehler -- es klingt so als ob die Reihenfolge der Einstiege in der .cfg verändert wurden ist, die PAX_EntryN_Open im Skript aber nicht angepasst wurden sind. Schick mir, wenn du möchtest, deine passengercabin.cfg und door.osc mal per PN zu, und ich werfe einen Blick drauf.

    Einmal editiert, zuletzt von Staaken79 () aus folgendem Grund: Bezugsbeitrag entfernt

  • Und wenn keine Tür geöffnet ist, laufen sie weiterhin zur 1.? Tja, dann werd ich's wohl aufgeben müssen.


    In meinem Test liefen sie brav in Richtung 3. Tür, und, falls vor der Öffnung einer anderen Tür dort auch angelangt, blieben sie dort auch "ewig stecken", unabhängig davon ob das Skript jetzt eine selbst-bedienbare oder eine ganz normale vom Fahrer manuell bedienbare 3. Tür unterstützte. Sie verhielten sich mit anderen Worten genau so wie die Theorie vorhersagt.

    So läuft das hier auch ab. Wenn die Türen 1+2 geschlossen sind und nur die 3. freigegeben ist, bleiben sie vor geschlossener Tür stehen und schauen dumm. Mach ich sie auf steigen sie ein.

    Was ich bei den Befehlen gelernt hab, mit {withbutton} in der passengercabin wird nur noch die nächstliegende Tür beachtet bzw. ggf. eine geschlossene angefordert diese zu öffnen (was bei einer manuellen ja blödsinnig ist). Aber nicht die Variiable wie sie die Automatiktür öffnen, das steht in der door.osc. Und den Abschnitt such ich. Die Hilfestellungen in manch anderem Thema funktionieren leider nur teilweise, in einem Versuch mit dem O530G und Berliner Türsteuerung ging es so weit, dass sie die 3. Tür öffnen konnten aber die 2. nicht, da liefen die zur 1. Türe vor.

  • Okay, die Menschen erreichen also die 3. Tür und können sie nicht öffnen. Dann wären wir ja schon einen Schritt vorangekommen. Die Leute (OMSI) teilen dann mittels PAX_Entry4_Req und/oder PAX_Entry5_Req dem Skript mit, dass es die Tür öffnen soll. Was ab diesen Punkt passiert ist rein die Entscheidung des Skripts.


    Unterstützt das Skript schon Außentürtaster? Wenn ja, kann die selbe Logik, die auch der Nutzer per Maus/Tastatur "triggert", zusätzlich an die entsprechenden PAX_EntryN_Req Variablen gekoppelt werden, so dass sie nicht dupliziert werden muss. Wenn nicht, muss die Logik ganz vom Anfang an implementiert werden.


    Wenn du die gesamte door.osc anhängen würdest, könnte ich vielleicht einen konkreten Lösungsansatz bieten.

  • Fahrgaeste koennen eine Tuer nur dann von aussen oeffnen, wenn diese in der passengercabin mit dem Befehl {withbutton} unter einem entry versehen und im Tuerskript fuer diese Tuer ein (L.L.PAX_Entry[X]_Req) vorhanden ist. Das X steht fuer die Reihenfolge der entries in der passengercabin gezaelt ab dem Wert 0. Z.B. ist (L.L.PAX_Entry0_Req) ist der erste entry in der passengercabin.


    Wenn fuer eine Tuer ein (L.L.PAX_Entry0_Req) definiert ist, benutzen Fahrgaeste nur diese eine Tuer, wenn sie diese einmal ausgewaehlt haben. Das heisst, solange sich diese Tuer nicht oeffnet (z B Tuerfreigabe nicht betaetigt), bleiben die Fahrgaeste vor dieser Tuer stehen.


    Die Reihenfolge der entries (und exits) in der passengercabin bestimmt die Praeferenz der Fahrgaeste, bestimmte Tueren auszuwaehlen. Wenn Du zB moechtest, dass Fahrgaeste bevorzugt an Tuer 2 einsteigen, so sollten die entries der Eingaenge der Tuer 2 ueber denen der Tuer 1 (und bei 3-tuerigen Solobussen ueber den Entries der Eingaenge der Tueren 1 und 3) stehen.


    Die Reihenfolge der Entries (und Exits) in der passengercabin bestimmt auch die Bezeichnung der Einstiege im Tuerskript. Der am Anfang stehende Entry in der passengercabin ist immer "PAX_Entry0_Open", der danach folgende "PAX_Entry1_Open", usw.


    Beispiel:

    (L.L.door_2) 0.4 > (L.L.door_3) 0.4 > && (S.L.PAX_Exit0_Open) (S.L.PAX_Entry0_Open) im Tuerskript bedeutet:


    wenn die Tuerfluegel 2 und 3 mehr als 40% offen stehen, ist der Eingang/Ausgang offen, der in derPassengercabin als erster Entry /Exit gelistet ist . Damit dies auch Tuer 2 ist, muessen entry+ exit von Tuer 2 an jeweils oberster Stelle in der Passengercabin stehen. Dabei interessieren sich die Fahrgaeste nicht, ob die Tuer tatsaechlich offen steht. So wuerde:


    (L.L.door_2) 0 = (L.L.door_3) 0 = && (S.L.PAX_Exit0_Open) (S.L.PAX_Entry0_Open) im Tuerskript bedeuten:

    nur wenn die Tuerfluegel 2 und 3 geschlossen sind, ist der Eingang/Ausgang offen, der in derPassengercabin als erster Entry /Exit gelistet ist.

  • Danke bis hier her, das werd ich mal testen, danach meld ich mich wieder



    Tante Edit:

    so sieht die door aus


    in der passengercabin steht vorn

    und hinten

    und trotzdem schaffen sie es nicht doe Türen zu öffnen. Selbst mit folgenden Abschnitt bekommen sies nicht auf die Reihe:

    (L.L.door_0) 0.9 > (S.L.PAX_Entry0_Open)

    (L.L.door_1) 0.9 > (S.L.PAX_Entry1_Open)

    (L.L.door_2) 0.9 > (L.L.door_3) 0.9 > && (S.L.PAX_Exit0_Open) (S.L.PAX_Exit1_Open) (S.L.PAX_Entry2_Req) (S.L.PAX_Entry3_Req)

    (L.L.door_4) 0.9 > (L.L.door_5) 0.9 > && (S.L.PAX_Exit2_Open) (S.L.PAX_Exit3_Open) (S.L.PAX_Entry4_Req) (S.L.PAX_Entry5_Req)

  • Damit sich aus Sicht der Passagiere Tür 3 öffnet, muss folgender Ausdruck gleich 1, bzw. ungleich Null/Boolesche "Wahrheit" sein:


    (L.L.door_4) 0.9 > (L.L.door_5) 0.9 > && (S.L.PAX_Exit2_Open) (S.L.PAX_Exit3_Open) (S.L.PAX_Entry4_Open) (S.L.PAX_Entry5_Open)


    Okay, also die eigentlichen/materiellen Türflügel müssen erst einen Wert von über 0.9 (90%) haben.


    Es interessiert uns also herauszufinden, wann die beiden door_4, door_5 Variablen sich verändern, und insbesondere wann diese aufwärts, Richtung 1 (100% geöffnet) wachsen. Dafür sind die Door4_Calc und Door5_Calc Makros verantwortlich. In denen sehen wir dass die Türflügel-Variablen sich verändern wenn doorTarget_45 sich verändert: Wird sie auf einen Boolesch-wahren Wert gesetzt, wächst allmählich der Wert der entsprechenden door_X Variable, bis dieser 1 erreicht; sonnst schrumpft er, bis er 0 erreicht.


    Was aber beeinflusst den doorTarget_45 "Sollwert"? Zurück zum door_frame, wo folgender Abschnitt zu finden ist:


    Hier sehen wir das doorTarget_45 auf 1 gesetzt wird, wenn, unter anderem, exit2_lichtschranke Boolesch wahr ist, und die Türfreigabe (bus_dooraft_sw) aktiv ist.


    Jetzt müssen wir noch herausfinden was exit2_lichtschranke beeinflusst:

    Code
    1. (L.L.PAX_Exit2_Req) 0 >
    2. (L.L.PAX_Exit3_Req) 0 > ||
    3. {if}
    4. 1 (S.L.exit2_lichtschranke)
    5. {else}
    6. 0 (S.L.exit2_lichtschranke)
    7. {endif}


    Aha! Die Variable wird bei Ausstiegsanforderungen, aber nicht bei Einstiegsanforderungen gesetzt; das muss sich ändern:


    (L.L.PAX_Exit2_Req) (L.L.PAX_Exit3_Req) || (L.L.haltewunsch_2) || (S.L.exit2_lichtschranke)


    Was bedeutet denn haltewunsch_2? Such such...

    Code
    1. (L.L.door_freigabe) (L.L.PAX_Entry4_Req) (L.L.PAX_Entry5_Req) || &&
    2. {if}
    3. 1 (S.L.haltewunsch_2)
    4. {endif}


    Also genau was wir brauchen. Und mit dieser kleinen Veränderung (das zusätzliche koppeln der exit2_lichtschranke Variable an die haltewunsch_2 Variable) müssten jetzt auch die Passagiere dazu in der Lage sein die 3. Tür von außen zu öffnen, wenn freigegeben (getestet mit einem solo 3-D Citaro mit Morphi-Patch 4.4, zusammen mit der von mir verwendeten .cfg).


    Folgendes sei weiterhin zu beachten:

    • Ich habe nur diese eine Veränderung ausprobiert, nicht das gesamte Skript, da du nicht erwähnt hast um welchen Bus es sich handelt. Nichtsdestotrotz hat die .osc die ich verwendet habe eine gewisse Ähnlichkeit zu deiner (beide scheinen alTerr-/Morphi-basiert zu sein).
    • Beim Gelenkbus, wie schon im ersten Beitrag erwähnt, werden ohne weiteres die KI-Menschen nicht in der Lage sein die Türen des Trailers zu benutzen.
    • Die Variable für die Türfreigabe ist die bus_dooraft_sw, nicht die Standardmäßig vorhandene bremse_halte_sw. Glücklicherweise ist jedoch in beiden Fällen der Tastatur-Event der selbe (bus_dooraft).
  • Servus, danke bis hier her, das werd ich am Abend mal testen.


    Es gibt zwei Haltewunschschleifen da diese door.osc vom O530G mit berliner Türsteuerung stammt und somit beide hinteren Türen automatisch sind. Es sollen nicht beide Türen öffnen wenn nur eine Person den Wagen einsteigen oder verlassen will ;)


    Das Thema hab ich primär dazu eröffnet um die genauen Scriptabschnitte zum öffnen von außen zu identifizieren und diese in verschiedene Wagen einpflegen zu können (MB O530/O530G/O530 Facelift, MAN Stadtbusaddon und noch ein paar andere).

  • Verschiedene Bus- und Mod-Autoren skripten auf verschiedene Art. Manchmal aus gutem Grund, weil die simulierten Komponenten sich tatsächlich anders verhalten sollen, manchmal aber auch bloß weil sie Menschen sind, und nicht die selbe Denkweise und Präferenzen miteinander teilen. Das erzeugt bei verschiedenen Fahrzeugen Skripte die, auch wenn funktionell identisch, strukturell doch recht abweichend voneinander sein können. Daher lege ich persönlich größeren Wert darauf mir dir Mühe zu geben die Logik des Verfassers versuchen zu entziffern, als "universale Abschnitte" zu finden. Nicht das solche Abschnitte prinzipiell niemals auftauchen, bloß sind sie meiner Erfahrung nach halt nie zu 100% universal, was zu Inkompatibilitätserscheinungen führt wenn man sich ausschließlich aufs Copy/Pasting verlässt.


    Aber viel Erfolg weiterhin bei deiner Erforschung des Skript-Ökosystems. :)


    Nachtrag: Früher wünschte ich mir eine "universale" door.osc. Eine die ich mir via 1234 .cti-Variablen und Konstanten bei jeder denkbaren Variante jedes denkbaren Busses so einrichten kann, wie ich es gerne hätte. M+R und andere Mod-Autoren versuchten ebenfalls uns ähnliche, wenn auch nicht universale, doch recht flexible, .osc's anzubieten. 4 Jahre später bin ich nun zum pragmatischen Schluss gekommen das es sich nicht lohnt solch eine .osc zu nutzen. Die .osc selbst wäre zwar 100% portabel, alle anderen Skripts jedes Busses müssten dann aber mit "Bridges" versehen werden, um sich auch mit solch einer "universalen" .osc verständigen zu können. Und was man an Code-Masse gewinnt, muss man letztendlich immer in der Form von erweiterter Konfiguration zurückzahlen. Obwohl das Ergebnis "sauberer" wäre, würde sich solch ein Aufwand niemals gerechtfertigten. Morphi ist scheinbar zum selben Schluss gekommen.

  • Servus,


    ist ja auch nachvollziehbar dass die Erbauer und Modder ihre zum Fahrzeug passenden Befehle selber schreiben, nur hatte ich gehofft einen Denkanstoß bzw. Hinweis in Sachen Citaro zu bekommen, denn ich weiß ehrlich gesagt nicht um welchen Abschnitt bzw. Befehl es sich genau handelt.

  • Hallo,


    Was haben denn die Tests ergeben? Können mit der vorgeschlagenen Veränderung die Fahrgäste nun dir 3. Tür öffnen?


    Meine "Strategie" in Sachen Skript-Modding ist, zumindest in leichten Fällen wie dieser, wo Mathe/Physik kaum eine Rolle spielen, ganz einfach: Ich finde heraus welche Variable(n) verantwortlich für die Funktionen sind, die ich anpassen möchte; in diesem Fall PAX_Entry4_Open und PAX_Entry5_Open. Dann durchsuche ich die .osc-Datei nach Wertübertragungen auf diese Variable(n); hier also nach Ausdrücken die (S.L.PAX_Entry4_Open), (S.L.PAX_Entry5_Open) enthalten. Sind weitere Zwischen-variablen in solchen Ausdrücken beteiligt, suche ich wiederum nach Zuweisungen auf diese ((S.L.door_4), (S.L.door_5)), und so weiter ((S.L.doorTarget_45)) und so fort ((S.L.exit2_lichtschranke)), bis ich irgendwann auf einen relativ primitiven Ausdruck stoße, den ich für meine Zwecke mit dem geringst möglichsten Aufwand anpassen kann; hier die Bedingungen für die Lichtschranke der 3. Tuer ((S.L.exit2_lichtschranke)).


    Faustregel für die Citaros und die Mehrzahl der M+R SD-/NL-/NG-basierenden Türskripten: Man sollte sich auf Ausdrücke konzentrieren, die doorTarget_23 (Tür 2 Sollwert), doorTarget_45 (Tür 3 Sollwert), und doorTarget_67 (Tür 4 Sollwert) setzen. Diese müssen immer, direkt oder indirekt, auf die entsprechenden PAX_EntryX_Req und/oder PAX_ExitX_Req Variablen zurückgreifen.

  • Servus,


    zum testen bin ich aktuell noch nicht gekommen, als ich dann mal Zeit hatte, fiel es hinten runter. Das hol ich jetzt mal nach....



    Tante Edit: keine Veränderung.

    in der door steht folgendes:

    und mittlerweile herrscht auch Ratlosigkeit seitens der Fahrgäste an der 3. Tür wenn diess offen steht...

  • Jetzt reden wir aber von einer anderen .osc, mit feinen Unterschieden zur letzten. Lass uns uns erstmal auf die sogenannte "Berliner" Variante (Beitrag #15) konzentrieren.


    Ich habe mich im Beitrag #16 anscheinend nicht eindeutig geäußert. Ich meinte dass der Ausdruck

    Code
    1. (L.L.PAX_Exit2_Req) 0 >
    2. (L.L.PAX_Exit3_Req) 0 > ||
    3. {if}
    4. 1 (S.L.exit2_lichtschranke)
    5. {else}
    6. 0 (S.L.exit2_lichtschranke)
    7. {endif}


    komplett durch folgenden


    Code
    1. (L.L.PAX_Exit2_Req) (L.L.PAX_Exit3_Req) || (L.L.haltewunsch_2) || (S.L.exit2_lichtschranke)


    ersetzt werden muss. Keine weiteren Veränderungen werden benötigt.