Beiträge von Busfanat

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.
Ein communitybetriebenes Nachfolge-Forum wird hier verlinkt, sobald es gegründet und bereit ist.

    Guten Abend,

    Sorry, mir leider nicht bekannt.

    Das kann gut sein. Der erste Bus, der damit ausgerüstet wurde, war ein Kamaz-Rework. Weiß nicht mehr, welcher genau. Aufgrund der geringen schöpferischen Höhe (90% des Codes ist von Marcel, nur an eine andere Stelle kopiert) habe ich nichtmal in der Revision History was dazugeschrieben.

    Wo ist der Unterschied zur Weiterschaltung nach den Haltestellen in der roten Zeile + Wegstrecke?

    Dieses Script ist älter und schaltet gleichzeitig mit der roten Zeile um. Hat Vorteile bei sehr geringen Haltestellenabständen wie z.B. zwischen den letzten beiden Haltestellen der Grundorfer 76er-Linie Richtung Einsteindorf.


    Allerdings glaube ich, dass das nicht meine Modifikation ist, da meine auch zurückschalten kann, das ist bei der Dokumentierten Modifikation nicht der Fall. Da FlofiX3291 behauptet, das Script aus Bahnfans Solaris zu haben, kann es auch sein, dass es eine Eigenentwicklung von Bahnfan ist. Bitte abklären, ich möchte mich nicht mit fremden Federn schmücken.


    Ich wünsche euch noch einen schönen Abend,


    Busfanat

    Guten Abend,


    Ich hab imemr bei Omsi1 Fehler bei Berreichsprüfung.

    Nein, du hast OMSI2, die Fehler in Bereichsprüfung gabs in OMSI1 noch nicht, da bin ich mir zu 95% sicher. Daher falsche Version heruntergeladen, weil die OMSI1- Version natürlich nicht für OMSI2 konvertiert ist

    HILFE!!! ich will Bad Kinzau heute noch spielen weil ich fahre morgen in Urlaub.

    Ich hoffe mir kann jemand helfen.

    Schon allein wegen der Meldung hätte ich bis morgen um 7 in der Früh mit der Antwort warten sollen. Aber ich bin ja kein komplettes Arschloch, sondern nur zu 90%.


    pBuch, ich möchte mich erstmal dafür bedanken, dass du deine Arbeit auch für die OMSI1-Nutzer unter uns zur Verfügung stellst. Im Vergleich zur V2 gefällt mir besonders, dass die Kreuzung vor Saasdorf deutlich entschärft wurde. Weniger gefällt mir, dass auf dem Linienweg der 299 (konnte leider erst die testen, Rest teste ich kommendes Wochenende, bin schon gespannt) einige Bäume/Büsche in den Straßenbereich ragen, ich werde sie mir mindestens für mich selbst etwas drehen bzw. von der Straße wegschieben. Als zweiter kleiner Kritikpunkt, was mich bereits bei Version 2 gestört hat, ist der Bahnhof in Bad Kinzau, wo ein Gleis von zwei Bahnsteigen bedient wird. Das habe ich in der Realität noch nie gesehen. Ansonsten denke ich, dass du dem "Klassiker" einen würdigen Nachfolger verschafft hast und ich freue mich auf meine Fahrten nächstes Wochenende.


    Leider haben es wieder mal die üblichen Verdächtigen geschafft, die Readme/das Handbuch gekonnt zu übersehen und unnötige Fragen zu stellen. Es wäre wünschenswert, hier von der Moderation unterstützt zu werden indem man derartige Beiträge melden darf und diese mit Vermerk "Readme lesen" gelöscht würden. Das würde der Disziplin in diesem Forum sicher gut tun.


    Ich wünsche euch noch einen schönen Abend,


    Busfanat


    Sorry hab kein Spoiler gemacht..


    Sorry, werde dich nicht auf deinen Fehler aufmerksam machen. <entfernt>

    Guten Abend,


    entschuldige, wenn ich etwas unhöflich werde, aber sollen wir dir alles aus der Nase ziehen?

    Und wenn wenn es nicht geht kommt eine Fehlermeldung.

    Wärst du vielleicht in deinem eigenen Interesse so gütig, auch dazu zu schreiben, WELCHE Fehlermeldung kommt? Zusätzlich könnte eine Logfile, die den/die aufgetretenen Fehler dokumentiert, helfen.


    Schönen Abend,


    Busfanat

    Servus,


    Besteht in OMSI die Möglichkeit, dass ein Bus mit leerem Tank plaziert wird?

    Nein, das ist nicht möglich. Im engine-Script wird definiert, dass der Bus immer mit mindestens 50 Litern Tankinhalt gespawnt wird, was 20% entspricht.


    Allerdings könnte ich mir vorstellen, dass OMSI im Pause-Modus ist. Ich glaube, dass der Pause-Hinweis in der roten Zeile erst mit OMSI2 kam... Wenn die Tastaturbelegung nicht verändert wurde, mit Shift+Z (also links auf der Tastatur die untere Großschreibtaste gedrückt halten und auf den Buchstaben Z drücken - befindet sich unter 6 und 7 - danach die Großschreibtaste wieder loslassen) die rote Infozeile oben links einblenden. Da dann schauen, ob die Uhrzeit läuft. Wenn nicht, mit P (wieder Standardbelegung vorausgesetzt) den Pause-Modus verlassen. Danach auf E, das IBIS sollte zu piepsen beginnen.


    Außerdem würde ich dich bitten, auf deine Rechtschreibung zu achten, schließlich solltest du für deinen Sohn ein Vorbild sein.


    @NicHildesheim: da fallen mir mehrere Gründe ein... kein Steam, damit Wiederherstellbarkeit von Vorgänger-Releases, wenn die neue Version schlechter läuft als die vorher, vielleicht auch nicht damit beschäftigt, bevor gekauft wurde, möglicherweise durch den Titel "Best of" irritiert

    Ich habe das Omsi Der Bussimulator Best of. Mit dem 92er durch Berlin-Spandau

    Servus,


    ne, DeZio, das Ding nennt sich zwar Trigger, ist aber kein Script-Trigger, der hier benötigt würde, sondern ein Sound-Trigger, der vom Script per (T.L.ev_Stamper) aufgerufen werden könnte. Bringt also leider nichts.


    Schönen Nachmittag noch,


    Busfanat

    Guten Abend,


    Ich teile deine Abneigung gegenüber OMSI 2 zwar nicht, aber ja, das ginge wohl auch problemlos.

    Naja, ehrlich gestanden ist es eine Abneigung gegen Steam, keine direkte Abneigung gegen OMSI2, aber das ist OT. Die vielen geposteten "OMSI-2-Bugs" scheinen großteils wie schon zu OMSI1-Zeiten nutzergeneriert zu sein.

    Mit den Termini habe ich angefangen, das war mir aber zu unflexibel, weil man immer fixe Nummern vergeben muss.
    Hier wäre eine Funktion "GetTerminusIndexByIdent" vonnöten.

    Stimmt, das habe ich vergessen. Naja, die OMSI2-Standard-Globalstrings mit den Indizes 4, 5 und 6 beziehen sich sowieso auf die Liniensuffixe bei N/M/X-Linien, was zur OMSI1-Zeit eh wurscht ist. Ich denke aber, dass ich hier selbst kompetent genug bin, hier zu improvisieren

    ;)

    Das Problem ist einfach, dass für meinen Geschmack viel zu wenig auf universelle Skripte gesetzt wird.
    M+R haben diese Möglichkeit in ihren Bussen mit den constfiles ja schon wunderbar demonstriert.
    Der Trend geht heute leider in Richtung "eine door.osc pro Türsteuerung" (siehe z.B. Morphi-Soundmods, alterr Solaris, usw.).
    Dabei könnte man das alles universell über ein Skript regeln.

    Grundsätzlich schließe ich mich dem an. Allerdings ist meiner Meinung nach zu beachten, dass das Scripten "neu" in der Bussim-Szene ist. 3D-Modelle, Texturen und Sounds gab es schon zu vBus-Zeiten, während die Scripts durch OMSI neu sind. Ich denke, es haben sich einfach noch zu wenige wirklich intensiv mit den Möglichkeiten der Scripts auseinandergesetzt. Möglicherweise ist der Unterschied auch jener, dass M&R bzw. jetzt M&J es mehr Leuten "Recht machen" wollten, damit sich OMSI2 besser verkauft, während die Freeware-Entwickler auch einfach nach der "Friss-oder-stirb"-Methode ihren Favoriten bauen können, ohne zwingend auf die Nutzerschaft zu achten. Was diesen aber auch nicht zu verübeln ist, denn sonst müsste es 5000 und mehr Konstanten geben, wo dann die lesefaulen/Readme-blinden/whatever Nutzer den Thread vollballern, wie man den Bus ihrer Heimat "Hinterwelt-Kaffingen" am besten nachstellt und am besten noch eine dritte/vierte Tür per Const schaltbar (geht zwar schon allein wegen der Pfade nicht, aber das weiß ja von denen, die das fordern, keiner). Ein Loch ohne Boden.


    Trotzdem Danke nochmal für deinen genialen Grundgedanken,


    Schönen Abend,


    Busfanat

    Servus,


    sorry, aber die Idee finde ich genial. Wenn man nämlich weiterdenkt, kann man damit die GlobalStrings auch in OMSI 1 nutzen, womit ich noch einen Grund weniger hätte, mir OMSI2 zu holen.
    Das könnte dann so aussehen:

    Code
    1. "..\..\Announcements" 0 (M.L.GetDepotStringGlobal) "\" $+ $+ (L.$.act_busstop) $+

    statt

    Code
    1. "..\..\Announcements" 0 (M.V.GetDepotStringGlobal) "\" $+ $+ (L.$.act_busstop) $+


    und das ausführende Macro würde dann bspw. so aussehen:

    Code
    1. s7 "DepotStringGlobal" (M.V.GetBusstopIndex) l7 (M.V.GetBusstopString)

    und die Haltestelle in der Hof-Datei bspw. so:

    Code
    1. [addbusstop]
    2. DepotStringGlobal
    3. Spandau
    4. Spandau
    5. Spandau_94
    6. 35
    7. 36
    8. 28

    Hier muss man nur aufpassen, dass man nicht mehr GlobalStrings hat als HST-Strings bei "normalen" Haltestellen. Daher sollte man vllt. auf die Termini ausweichen, wo man standardmäßig 6 Strings hat, anstatt der 4 bei den Busstop-Einträgen.


    Auch die Ergänzung von faaabiii finde ich gut, weil man damit dann auf den vom Nutzer leichter anpassbaren Bus-Standard zurückfällt.


    Mich hast du von dieser Idee begeistert, ich bin gespannt, ob die Busbauer das auch umsetzen werden. (Wahrscheinlich nicht, aber die Hoffnung stirbt zuletzt)


    Schönen Abend noch,


    Busfanat

    Servus,


    wie du wahrscheinlich bei deinen Versuchen in der Hofdatei bereits festgestellt hast, sind die Routen dort Codes im Format LLLRR zugeordnet. 1- bis 3-stellige Liniennummer + 2-stellige Routennummer.


    Angenommen, du wolltest nun eine Route 123 für die Linie 92 definieren, wäre der Routecode 92123 identisch mit dem Routecode der Linie 921, Route 23. Natürlich wäre es möglich, im IBIS-Script das so umzuschreiben, dass du 1- bis 4-stellige Liniennummern mit 3-stelligen Routennummern unterstützt, allerdings bräuchtest du dann für alle Maps für deinen Mod komplett neue Hofdateien.


    Ich halte es also für geschickter, die Finger davon zu lassen.


    Schönen Tag noch,


    Busfanat

    Schönen Nachmittag,


    Eine Frage hätte ich jedoch: Bei der Krüger schreibst du "Die temporäre Zwischentextur wird pixelweise ausgelesen und von links nach rechts auf die anzuzeigende Scripttextur aufgemalt." Genauer gesagt besteht die Anzeige m.W. doch aus zwei Flächen und es wird der Alphakanal der Textur auf der vorderen (bzw. zuletzt gerenderten) Fläche an den passenden Stellen auf Volltransparenz geändert, so dass man die hintere Textur an diesen Stellen sehen kann. Also ähnlich wie bei den Ziel-Rollbändern. Oder liege ich da falsch?

    Nein, du liegst nicht falsch. Aber im Wiki-Artikel geht es um die scriptmäßige Umsetzung. Und damit die Scripttextur von links nach rechts animiert werden kann, muss bereits vor dem ersten Animationsschritt feststehen, wie die Anzeige nach der vollständigen Animation ausschaut. Und das läuft über diese angesprochene Zwischentextur ab. Ich kann, da ich OMSI2 nicht habe, jetzt nur auf die Krüger-Modifikation genauer eingehen, aber ich nehme an, beim Original ist es gleich oder ähnlich. Als erste Scripttextur ist in der model-cfg eine "canvas"-Textur definiert, deren Auflösung sowohl in der Höhe als auch in der Breite nur ein Viertel der fertigen, auf den Matrizen angezeigten Texturen beträgt. Das ist die angesprochene Zwischentextur.

    Dann nehm ich das zurück. Bisher habe ich keinen anderen Bus mit deiner Matrix installiert. Hab ich ein Update für den Bus versäumt?

    Das wurde, glaube ich, auch nie rausgepatcht. Allerdings habe ich die Vollmatrix z.B. auch in meinem (privaten) Script-Test-Bus eingebaut und da passt das exakt.


    Andere Frage: Geht es eigentlich, eine LED-Busfanat-Matrix auf eine Flipdotmatrix des gleichen Typs umzubauen? Die stört mich im Citaro schon so extrem....(ok, Krüger Plus wär noch eine Möglich keit)?

    Im Scriptordner findest du eine Matrix_constfile.txt. Da gibt es eine Konstante, die LED-Modus oder so heißt. Die 1 darunter ersetzt du durch eine 0 und schon hast du den FlipDot-Effekt wieder. Allerdings braucht die Animation mehr Rechnerleistung.


    Schönen Tag noch,


    Busfanat

    Guten Abend,


    Darf ich mich dann auch mal einmischen?


    Gut. Dann als erstes: Link im OMSI-Wiki
    Hier fehlen noch die Weiterentwicklungen der Krüger, also Krüger+ und Krüger++, die muss ich i-wann einarbeiten, wenn ich mir die Scripts angeschaut hab.


    Und danach erlaube ich mir, hier im Beitrag etwas parteiischer zu sein, als ich es im OMSI-Wiki sein will.


    Was bringen mir diese ganzen Typen für Vorteile?

    Das sind einfach nur unterschiedliche Verhübschungen für die Busse. Für die OMSI-Passagiere ist nur die Variable "target_index_int" ausschlaggebend, ob sie einsteigen oder nicht.

    welche sollte man verwenden?

    Als User die, die der Bus mitliefert. Wenn man keine Ahnung hat, ärgert man sich nur über Fehlermeldungen. Als Busersteller die, mit der man sein Vorbild am besten nachstellen kann.

    gibt es irgendwelche must-have mods in dem Bereich?

    Wenn du 10 Leute fragst, wirst du 12 verschiedene Antworten erhalten. Reine Geschmachssache.

    Damals eine Top-Sache, hängt aber heute der Krüger in Flexibillität etwas hinterher

    Bullshit. Meine Matrix ist nach wie vor das EINZIGE Vollmatrix-Script für OMSI, in dem man für jeden Bus die Anzahl der Dot-Spalten (also wie breit die Anzeige ist) individuell pro Anzeige (Front, Seite, Linie) einstellen kann, ohne dafür andere Bitmaps oder im Falle der BUSE-Matrix gar andere Hofdateien zu brauchen. Wenn man das bei der Krüger(+(+)) macht, sind die Bitmaps für die Sonderziele für'n Enddarm. Auch wenn beim Vorbild die Matrizen unterschiedliche Farben haben (also zB. vorne orange, seitlich grün), ist dies ohne Sonderziel-Bitmaps NUR mit meinem Script möglich.

    Die Addonbusse aus dem 3 Generationen Addon nutzen nochmals eine eigene Matrix, die allerdings sehr unflexibel ist.

    Darius hatte halt historisch gesehen das Problem, selbst etwas entwickeln zu müssen. Damals beim HH-Addon zu OMSI1-Zeiten gab's nur die BUSE und meine. Es scheint, als wollte er die BUSE nicht nutzen (keine Ahnung, ob er eine Verkaufserlaubnis erhalten hätte) und für meine hätte er die Erlaubnis zum Verkauf nicht gekriegt. Er hat das dann nur konsequent in sein zweites Produkt übernommen. Die Grundidee für seine Matrixumschaltung ist nicht schlecht, leider gibt es halt diese (in meinen Augen unnötige) Unterscheidung zwischen HH-Hofdateien und "Standard"-Hofdateien.

    Zumindest konnte ich beim O405N2 von Julian schon beobachten, dass die aktiven Dots und die inaktiven nicht so recht zusammenpassten von ihrer Position her. Bei der Krüger passt das hingegen immer perfekt.

    Wieder Bullshit. Julian hatte beim N2 einfach den Stress, bis Weihnachten fertig zu werden, deshalb ist der Matrix-Hintergrund nicht 100%ig mit Mapping und Textur übereinstimmend. Es ist sehr wohl möglich, das exakt auszurichten.


    Die Schriftart lässt sich sowohl bei der BUSE als auch bei der Krüger(+(+)) und auch bei meinem Vollmatrix-Script für das jeweilige Vorbild anpassen.
    Natürlich bleibt aber festzuhalten, dass die Krüger-Matrix durch die verwendeten OMSI2-Funktionen performanter sein dürfte (Ich nutze nach wie vor OMSI1, kann es also nicht überprüfen), als meine Entwicklung. Selbst wenn das nicht zutrifft, ist zumindest das Script übersichtlicher geschrieben als meins

    ;)

    Aber ich war vorher da

    :P


    Zuletzt bleibt mir nur, mich bei Airbus_A330 dafür zu entschuldigen, seinen Thread für diese Klarstellung missbraucht zu haben, aber dieses "Seit OMSI2 ist die Busfanat-Vollmatrix scheiße/überholt" geht mir gehörig auf die Eier.


    Schönen Abend noch,


    Busfanat

    Hallo,


    auch ich habe zu 1) keine Ahnung, aber bei 2) vllt. einen Ansatz. Möglicherweise bringt es dir was, per Script die Frontscheibe temporär auszublenden und dann kannst du vielleicht den Maustrigger der Weiche durch das "Loch" durch aktivieren.


    Hab aber keine Ahnung, ob das geht, schließlich bin ich nach wie vor OMSI1-Nutzer.


    Schöne Grüße,


    Busfanat

    Griaß enkch,


    da sich die Textur während der Laufzeit eh nicht ändern soll, würd ich erstmal alles in den init-Tag packen. Spart CPU.


    Ich habe mich jetzt mal ein bisschen mit dem Thema beschäftigt, gebe aber keine Garantien ab.
    Die Beschriftung 0 bezieht sich, wie es scheint, immer auf den ersten Eintrag in der Stringvarlist. Beschriftung 1 ist dann der zweite und deine Reiterbeschriftung muss dann in der Dritten Zeile der Stringvarlist deklariert sein.
    Vielleicht hilft dir diese Information schon.


    Schönen Tag noch,


    Busfanat

    Guten Abend,


    deshalb hab ich das lokal fett markiert. Bitte unterscheide zwischen dem globalen und lokalen Koordinatensystem.
    Wie gesagt, ich kenne 3Dsmax nicht. In Blender gibt es den Object Mode und den Edit Mode. Im Object Mode kann man die Objekte als ganzes inkl. dem lokalen Ursprung verschieben/drehen.


    Ob es bei 3Dsmax ähnlich ist, muss jemand beurteilen, der sich dort auskennt.


    Es gibt aber auch die Möglichkeit, die Animationsachse in der cfg zu ändern. Aber das weiß ich nicht auswendig.


    Schönen Abend noch und viel Erfolg beim Ausprobieren,


    Busfanat

    Guten Abend,


    die Drehachse, die durch "origin_from_mesh" angesteuert wird, ist der lokale Ursprung des Objekts. Ich sag noch gleich dazu, bevor es heißt, der dreht sich um die falsche Achse: Die Rotationsachse ist die lokale X-Achse.


    Da ich mich mit 3dsmax nicht auskenne, kann ich dir da leider nicht weiter helfen.


    Zum Schluss noch ein kleiner Tipp: Eine Rotation um 0,1° wirst du kaum sehen

    ;)


    Schönen Abend noch,


    Busfanat

    Guten Abend,


    Je tiefer die ist, desto mehr Grip hat man, stimmt's?

    Nein.


    Der Grip zwischen Straße und Reifen hängt unter anderem vom Gummi des Reifens, den Temperaturen von Straße und Reifen, ob die Straße staubig, trocken oder feucht ist, ab. Die Profiltiefe spielt nur eine Rolle, wenn man Wasser, das die Haftung zwischen Straße und Reifen vermindert (Aquaplaning sagt dir was?), verdrängen will oder der Vortrieb nicht durch Reibung an der Straße sondern durch Abstoßen am Belag, in dem man eingesunken ist (Schneeketten), entstehen soll.


    Zurück zur ursprünglichen Frage:

    Ich wollte schnell fragen, ob und wo man den Grip der Reifen ändern kann.

    Mir ist kein Weg bekannt. Zumindest in OMSI1 war es nicht möglich, bspw. das Fahrverhalten von Schneeketten zu simulieren. Ob sich das mit OMSI2 geändert hat, kann ich nicht sagen, da ich nach wie vor mit OMSI1 arbeite. Ich glaube aber, dass eine derartige Neuerung nicht "versteckt" worden wäre. Zudem konnte ich bis dato auch nichts diesbezügliches im OMSI-Wiki finden.


    Und zum Abschluss noch ein kleiner Tipp:

    Grund ist nicht so wichtig

    ist natürlich äußerst motivierend für Forennutzer, die dir helfen wollen.


    Schönen Abend noch,


    Busfanat


    P.S.: Vorsicht! Dieser Beitrag könnte Spuren von Ironie enthalten. Allergikern und Suchtentwöhnten wird vom Konsum abgeraten.

    Guten Abend,


    ich misch' mich dann auch mal wieder ein...


    Kurz zusammengefasst, ich geb euch beiden, ACMG und Tatra, zu einem gewissen Teil Recht.


    Natürlich würde man, um jedes Anzeigesystem in OMSI realitätsgetreu mit einer einheitlichen Hof-Datei einsetzen zu können, eine riesige Hofdatei brauchen. Ob im pseudo-csv-Format oder XML sei mal dahingestellt. Solange sich M&J zu diesem Thema nicht äußern, müssen wir sowieso die Möglichkeiten nutzen, die uns OMSI aktuell gibt.


    Wenn man sich aber anschaut, wie viele Busse, die umgesetzt wurden, mit großteils den gleichen Scripts rumfahren, dann ist meiner Meinung nach der Bedarf nach verschiedenen Strings sowieso bald gedeckt. Ich glaube, mit 25 Strings pro Zielcode kommen wir die nächsten Monate wenn nicht Jahre über die Runden, weil sich einfach die Anzahl der Scripter in Grenzen hält.


    Mein Gedankengang zu dem Thema ist halt, besser die Anzeige weicht zu 5% von der Realität ab, als dass sich die lautesten und nervigsten Stimmen im entsprechenden Thread (wenn sie sich wenigstens auf den Thread beschränken würden und nicht das ganze Forum zuspammen, aber das ist ein anderes Thema...) darüber aufregen, dass man schon wieder eine eigene Hof-Datei braucht, bzw. warum "die Anzeige auf Bus XY falsch is"...


    Schönen Abend noch,


    Busfanat

    Guten Abend,


    Auch wenn es manchem als Erbsenzählerei vorkommen wird, möchte ich mich zu deinem Satz äußern, Rumpelhans:

    Am besten ist die Idee einer universellen HOF-Datei in der Krüger+(+) umgesetzt, da die spezifischen Ziele mit 20.000 addiert werden, was eine Eingabe über das IBIS unmöglich macht.


    Nur weil es über das IBIS unwahrscheinlich ist, diesen Zielcode einzutippen (man kann natürlich das IBIS-Script ändern und die Anzahl der Zielcode-Ziffern erhöhen), ist das nicht ideal. Insbesondere Einsteiger könnten bei ihren ersten Gehversuchen in OMSI im ALT-Menü bei der Zieleinstellung den 20 000er-Code erwischen.


    Ganz klar festzuhalten bleibt, dass die Anforderungen an Hofdateien im Laufe der Zeit gestiegen sind. Am Anfang gab es schließlich nur Rollband oder ANNAX. Beide waren in der gleichen Hof-Datei möglich und es gab nur Routen und Ziele.
    Heute werden in der Hof-Datei zum Beispiel Wechselziele gespeichert. Manche haben in Eigenregie Zielwechsel während der Fahrt in die Hofdatei gespeichert oder Anschlussrouten definiert, die nach Fahrtende automatisch vom IBIS eingestellt werden.


    Wer weiß, welche Informationen in Zukunft in der Hofdatei gespeichert und vom Bordcomputer-Script verwertet werden?


    Ich halte ein einheitliches Hofdateienformat grundsätzlich für eine gute Idee. Trotzdem bin ich gespannt, ob sich diese Idee durchsetzt. Schließlich müssen die Busbauer bzw. deren Scripter das erst als "Standard" anerkennen und dann danach handeln. Weil sonst ist die Geschichte für die Fische.


    Übrigens eine kleine Randnotiz: Zu OMSI1-Zeiten war es sehr wohl möglich, eine einheitliche Hofdatei für meine Vollmatrix und die ANNAX zu erstellen. Hat aber fast niemand wahrgenommen. Leider dies seit OMSI2 und den $cutSpaces bzw. $SetLengthC-Befehlen in den ANNAX-Scripten nicht mehr ohne Scriptänderungen möglich.


    Ich wünsche euch noch einen schönen Abend,


    Busfanat