Terminus und umschildern an gleicher Stelle (wie in Neuendorf am Tierpark)

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.

    Hallo, ich benötige Hilfe beim erstellen von Station Links und Trips.

    Die KI soll am Terminus halten, Leute aussteigen lassen, auf die Abfahrtszeit warten, an Ort und Stelle umschildern, Leute zusteigen lassen und abfahren.

    In Neuendorf wurde das mit zwei BusStop Würfeln gemacht. Allerdings noch mit der alten Methode Tracks & Trips - ohne Station Links.

    Wenn ich das Ganze mit Station Links versuche, fehlt im Fahrplan die "SmoothTrans" weil die aufeinander folgenden Trips nicht mit der gleichen Bushaltestelle enden und beginnen.

    Die KI fährt nach dem Aussteigen los und despawned am Ende des Splines...


    Gibt es eine Möglichkeit, das gewünscht Ergebnis auch mit Station Links zu erreichen? Danke im Voraus.

  • User23392

    Hat das Thema freigeschaltet

    Dann springt der Fahrplan aber nicht weiter und man hat das Problem, wie zb auf Ruhrau.
    Zwischen den beiden Buswürfel muss eine Luftlinie von mindestens 60 Metern liegen, weshalb ich von diesem System auch kein allzu großer Fan bin und immer noch das T&T System benutze


    Probier mal die "Rheinhausener Methode". In den Fahrplandaten mußt Du an der Terminus-/Starthaltestelle einen Aufenthalt programmieren, also die Häkchen am ersten Halt rausnehmen, bei Arrival 0.0 und Departure 1.0 eintragen; am besten das KI-Verhalten auf always/wait on dep. time auswählen. In der Folge wird die KI, sobald die Zeit für den Trip ran ist (0.00) die Türen zumachen und umschildern. Dann wird ihr auffallen, dass bis zur Abfahrt noch Zeit ist und die Türen wieder aufmachen und die Abfahrtszeit (1.00) abwarten. Und nicht vergessen: In den Time-Tables die Abfahrten um eine Minute vorziehen, sonst hängts ne Minute. ;)

    Ich habe es auf einer Testmap mit unterbrochenen Pfaden und nebeneinander liegenden H-Würfeln ausprobiert: Die KI fährt ganz normal den Fahrplan durch unf schaltet die Haltestellen weiter. Das Problem mit dem Fahrplan konnte ich also nicht reproduzieren. Wenn ich allerdings die Zeit verstelle, verschwindet die KI manchmal. Nach mehrmaligen vorstellen der Zeit taucht die KI irgendwann mit xxx Minuten Verspätung wieder auf. Ist das ein neues Problem oder hängt das mit dem von Schleswig-Holstein beschriebenen Problem zusammen?


    Die Rheinhausener Methode konnte ich noch nicht bei mir testen. Feedback folgt.

    Ist ein neues Problem, hängt aber leider auch mit den StnLinks zusammen.
    Dieses Phänomen ist bis jetzt bei jeder map aufgetaucht... Vor allem nachts ist das sehr ärgerlich, wenn die Straßen leer sein sollten und dir dann plötzlich mehrere Betriebsfahrten von 7 Uhr morgens entgegenkommen (wie es zb auf Rheinhausen ist)

    Wie gesagt ich bin auf Grund dieser Problematiken kein Fan von diesem System und würde immer noch T&T-System bevorzugen

    Hi. Ich habe die Testmap auf T&T umgebaut und getestet. Leider verschwindet die KI immer noch bei Änderungen der Uhrzeit. Hat wohl doch nicht nur mit StnLinks zu tun.

    Ich kann irgendwie kein Muster erkennen. Meistens tritt es ein, wenn zur neuen Uhrzeit der Bus am Terminus Pause macht. Irgend eine Idee, woran es liegen kann? Oder unvermeidbares Omsi-Poblem? Danke schonmal.

    Wenn dann auch alle Tracks innerhalb eines Trips korrekt miteinander verbunden sind, fällt mir leider auch nix mehr ein.


    Ich bin einer der wenigen, wie ich erfahren habe, der OMSI nach folgendem Prinzip spielt: Ich übernehme an irgendeinem Knotenpunkt einen KI Bus, fahre diesen weiter und gebe ihn dann nach gewisser Zeit an einem Knotenpunkt wieder ab. Bzw rücke am Anfang aus oder am Ende ein. Platzieren eines eigenen Busses einfach an der Endhst gibt es bei mir nicht.

    Und bis jetzt hatte ich noch nie Probleme damit, dass ein KI Bus mal nicht vorhanden war. Entweder kam er ganz normal oder er steckte irgendwo fest. Es kann lediglich mal vorkommen, dass du eventuell mal ein zwei Kacheln weitergehst, um zu gucken, wo der KI Bus denn ist, dann findest ihn nicht, gehst zu deiner Ursprungskachel zurück und dann taucht er plötzlich auf, weil er beim Laden der Kachel auch neu platziert wird.

    Ja, hast recht. Wenn man ein paar Kachel weiter geht und wieder zurück geht, erscheint die KI wieder an richtiger Stelle (nur bei T&T-Methode). Damit kann ich leben. Dann häte ich mit meiner Ringlinie nur noch ein kleines Problem: Beim Einsteigen der ersten Fahrgäste wird eine "unechte" Verspätung angezeigt, die der Pausenzeit entspricht = Leute meckern. Ein Beispiel:

    Ankunft 07:12 Uhr am Terminus. H-Würfel liegt auf dem letzten Pfad des Tracks. Der linke im Bild. Leute steigen aus. Alle Türen bleiben auf!

    Abfahrt laut Fahrplan soll um 7:20 Uhr sein. Zweites Bild.



    Nächster Track startet mit gleichem Pfad wie oben, gleicher Würfel als erste Haltestelle im Trip. Direkt dahinter auf nächstem Pfad ist die zweite Haltestelle im Trip für den Einstieg. Der rechte Würfel im Bild.



    Bus schildert an Ort und Stelle um und Leute steigen ein (Türen sind nämlich noch auf). Leider macht er das schon um 7:19 Uhr und 40 sek. Es wird immer noch der linke Würfel als nächste Haltestelle angezeigt und 7 min. Verspätung. Leute meckern. Um 7:20 Uhr wechstelt erst der Fahrplan im Bus und die Verspätung ist weg. Dann wartet er wie im Profil gewünscht noch eine Minute - die eigentlich zum Einstieg gedacht war - und fährt ab.


    Hab´s auch mit nur einem Würfel probiert. Hab auch in obigem Beispiel die erste Haltestelle im letzten Screenshot weg gelassen. Immer das gleiche Ergebnis.

    Was kann ich tun, damit beim Umschildern keine Verspätung angezeigt wird?

    Nimm den ersten Buswürfel mal aus deinem Fahrplan raus. Also es reicht, wenn du nur den Einstiegswürfel anklickst.


    Das sollte aber ein Problem sein, was nur der KI-Bus hat.

    Gucke drüber hinweg und fertig :D Sowas solltest du ja normalerweise gar nicht mitbekommen und bei dem eigenen Bus funktioniert ja dann alles korrekt. Das ist auch kein Problem was nur bei T&T oder nur bei StnLinks ist. OMSI lässt die Verspätung einfach weiter anwachsen bis der KI Bus wieder losfährt.

    Nur ganz am Rande sei erwähnt dass es Skript-mäßig möglich ist das KI-Verhalten dynamisch pro Haltestelle zu beeinflussen. Mich persönlich stört bei solchen End-/Starthaltestellen nicht so sehr die Verspätung, sondern eher die Tatsache dass die KI so tut als ob sie gleich abfahren würde (Motor anlassen, Türen schließen), bloß um eine halbe Sekunde später es wieder rückgängig zu machen (Türen öffnen und vielleicht sogar Motor abschalten, wenn Starthaltestellenaufenthalt > 1 Minute). Um insbesondere dieses Problem, indirekt aber auch das eigentlich geschilderte (jammerndes KI- Volk), zu umgehen, verwende ich seit längerer Zeit folgende KI-Logik (Pseudocode, da Matrix, Motor, und Türfunktionen pro Fahrzeug variierend):


    - Ist es laut OMSI Abfahrtzeit (AI_Scheduled_AtStation = -1)?

    -- Wenn ja, dann a) gib OMSI Bescheid, dass du gerade abgefahren bist (setze AI_Scheduled_AtStation auf 0), ohne b) sonst etwas sichtbares zu unternehmen (lasse den Motor aus, schließe die Türen nicht, und schildere nicht um). Zusätzlich, merke dir für den nächsten Durchlauf a) diese Entscheidung, b) den Haltestellenindex (GetTTBusstopIndex), und c) die Zeit seit Simulationsbeginn (GetTime).

    - Sonst, ist es laut OMSI noch nicht Abfahrtzeit (AI_Scheduled_AtStation = 1)?

    -- Wenn ja, war es im letzten Durchlauf andersherum (prüfe im obigen Schritt gespeicherte Entscheidung)?

    --- Wenn ja, hat sich der Haltestellenindex trotzdem verändert (um auszuschließen dass es sich um einen "Parkmanöver" an der selben Haltestelle handelt, falls vorher der Pfad von einem anderen Bus besetzt war)?

    ---- Wenn ja, ist Zeit-Kontinuität trotzdem bewahrt (stelle sicher dass du nicht in eine "Zeitlücke" wegen eines Respawns des KI-Fahrzeugs geraten bist, indem du GetTime in der Gegenwart mit dem während des letzten Durchlaufes gespeicherten Wert vergleichst, und erforderst dass die Differenz nicht größer als die Durchlaufzeit (Timegap (+/- 0.1 Sek. wegen Präzisionsverlust)) ist)?

    ----- Wenn ja, handelt es sich wahrscheinlich um eine "Doppelhaltestelle". Jetzt darfst du umschildern und den Motor anlassen. Am liebsten wartest du noch 10~20 Sekunden länger, um den Fahrgästen (die erst jetzt anfangen sollten sich Richtung Bus zu bewegen) genügend Zeit zu gönnen das Fahrzeug im gemütlichen Tempo zu erreichen.

    - In jedem anderen Fall, tue was OMSI von dir verlangt.


    Ja, klingt kompliziert und ist es auch, Leider weis man nie genau wie weit OMSI bereit ist inkonsequentes Skript-Verhalten "runter zu schlucken", und ab wann es sich mit Fehlermeldungen oder sonst bizarrem Verhalten beginnt zurück zu wehren. Immerhin habe ich positive Erfahrungen mit dieser Taktik gemacht. Im schlimmsten Fall wartet der Bus an der ersten Haltestelle halt umsonst eine halbe Minute länger als im Editor vorgeschrieben. Aber sogar dann ist es gut möglich (ich würde mal pessimistisch mit 10% Erfolgsrate auf einer typischen Deutschen Map rechnen) dass es sich um einen ZOB/Hbf./sonst zentral liegenden Haltepunkt handelt, von dem eine leicht verspätete Abfahrt noch marginal realistisch wirken würde.


    Sorry fürs OT. Es ist mir natürlich bewusst dass es sich nicht um einen Lösungsansatz handelt auf den man sich im Allgemeinfall verlassen kann. Vielleicht hilft der Gedanke den einen oder anderen zukünftigen Leser, der auf der Suche nach Fahrzeug-orientierten Lösungen zu dieser Problematik ist, dennoch ein wenig weiter.

    Im dritten Bild die erste H (linker Würfel) meinst Du? Das heißt, erst auf dem zweiten Track-Pfad verknüpfe ich den rechten Würfel als erste Haltestelle?


    @ Unorthodox Paradox: sehr schön und ausführlich beschrieben. Danke. Für mich zu hoch. Das muss ich mir noch n paar mal durchlesen ;)