Beiträge von der_Nik_

Willkommen in der OMSI-WebDisk!
Als Gast kannst du nur Inhalte in deiner ausgewählten Sprache sehen. Registrierte Nutzer können die Sichtbarkeit anderer Sprachen in ihrem Kontrollzentrum aktivieren, weitere Infos hier.
Alle Themen sind in den Foren mit einer Sprachflagge gekennzeichnet: = Englisch [EN], = Deutsch [DE], = Französisch [FR]. Wenn du die angegebene Sprache nicht beherrschst, schreibe auf Englisch!

    Es ist aber nicht sehr ratsam, den gleichen Repaintordner zu nutzen, weil die Fahrzeuge nicht die gleichen Repaints nutzen. Beim Außenmesh unterscheiden sie sich z.B. durch die SST und einige Details, die noch so auf dem Template drauf sind.

    Falls Ihr noch was habt, könnt Ihr Vorschläge und Wünsche äußern, bis Samstag.

    Wäre es irgendwie mögllich, 2 verschiedene Schriftstärken in einer Zeile zu verwenden? Kenne die funktion hier von den LAWO-Anzeigen.

    Da steht in einer Zeile "Weil am Rhein Tullastr.", das "Weil am Rhein" in etwas dicker (2 dots breit), das "Tullastr." nur 1 dot breit (kann dazugerne ein Foto nachliefern).


    LG Niklas

    Gibt das ein oder andere schöne Einfamilienhaus, auch das ein oder andere große Gebäude eignet sich, Berlin besteht ja nicht nur aus Wolkenkratzer.

    Desweiteren bietet X10 auch brauchbare Gewerbegebäude wie z. B verschiedene Autohäuser o.Ä.

    Mir fällt gerade auf, dass ich als BRT- , aber nicht-X10-Besitzer auch die Objektordner X10_Objekte ect. habe (was irgendwie auch Sinn macht). Habt ihr zufällig mal getestet, ob das Addon BRT für die Map ausreicht? X10 wäre das einzige was mir fehlt.


    LG Niklas

    Hallo,

    neben den kleinen Scriptänderungen bin ich aktuell an etwas komplexerem Code für ein Zonensystem für den AFR200, welcher aber im Groben und ganzen mit einem Standard-Ibis-Script arbeitet.


    Grundsätzlich soll das so Funktionieren:

    - Wenn keine Route aktiv ist, gibt es keinen Ticketverkauf (die Berechnungen lösen in dem Fall Bereichsprüfungsfehler aus, von daher blieb mir nichts anderes übrig, ist aber auch realistisch).

    - Es gilt nicht Zielcode = Zone, wie man es aus dem GSÜH kennt, sondern viele Zielcodes sind einer Zone untergeordner (diese können aber theoretisch auch identisch sein, wenn man es so will).

    - Standardmäßig wird der Zielcode der letzten Haltestelle (im Script "Linienzielcode" genannt)

    - Das Script liest jeweils den Start- und Zielzielcode auus und prüft, ob diese in der gleichen Zone liegen (=Kurzstrecke) oder nicht (=normaler Fahrschein).

    - Um Änderungen an den Routen zu vermeiden ist es möglich, Haltestellen als "Zonengrenze" zu markieren, diese haben dann 2 Zielcodes für entsprechend 2 verschiedene Zonen.

    - Die Angabe in der Hofdatei erfolgt in String 4 (Zielcode) und 5 (Zone), dort wird entweder einfach der Zielcode/die Zone eingetragen, oder man trägt z.B. "#0011_0021" in Zielcode und "0001_0002" in Zielzone ein, das wäre dann die Zonengrenze. Das Script soll dann beide Zonen verarbeiten und jeweils alle möglichen Kombinationen abgleichen.

    - Für die Zielcodeeingabe benötigt außerdem jeder Zielcode einen eigenen Haltestelleneintrag, welcher als Ident den Zielcode, String 0 den Namen und String 1 die Zone enthält.


    Testen tue ich das ganze auf Grundorf mit diesem Konzept:


    Was bisher funktioniert (oder auch nicht):

    - Das Script erkennt die Route und Haltestellenanzahl korrekt

    - Daraus errechnet das Spiel die Startzielcodes korrekt

    - Bei den Linienzielcodes ist OMSI sehr Zickig. mit Route 7601 erkennt er gar keinen Linienzielcode, in die Rückroute erkennt er diesen nur auf den ersten Haltestellen, obwohl sich an dessen Berechnung im Verlauf der Route nichts ändern sollte. Ich konnte bereits herausfinden, dass es scheinbar am Macro "GetRouteBusstopIdent" bzw. der Berechnung drumherum liegt, da der String nach diesem teilw. komische Zahlen statt dem Haltestellennamen anzeigt. Diese könnten von einer der "Tachorouten", welche den Code 9907601 bzw. 9907602 hat und anstelle der HST-Namen die Distanzen enthalten hat, kommen, was mich aber wundert, weil das Script ja vor der Abfrage den Routenindex extra neu berechnet.

    - Irgendwo wirft das Script einen Bereichsprüfungsfehler aus, dieser wird aber nicht in die Logfile gespamt, sondern nur 2-3 Zeilen und ist dann wieder weg.


    Hier alle relevanten Scriptteile, bei Beadrf kann ich auch das gesamte AFR200-Script hochladen (hab bereits eine Erlaubnis von Protinus).


    Frame:

    Die Variable für den Reset wird z.B. bei der HST.-Fortschaltung oder einer neuen Routeneingabe aktiviert. Die Varibale "AFR_Verkauf_Mode" bestimmt die Art des Ticketverkaufs, 1=Zonensystem


    Macros:


    Und hier die Hofdatei:


    Konkrete Ideen, wo der Fehler liegt:

    Mir ist unklar, warum beim Linienzielcode der Routenindex der Tachoroute statt dem der normalen Route aufgerufen wird, das konnte ich mithilfe von einer "Debuganzeige" im Ticketdrucker herausfinden.

    EDIT: Ich musste eben Feststellen, dass der Routenindex für Fahrt 7601 korrekt mit "0" erkannt wird, dennoch wird als "Busstopident" die Endhaltestelle der Route 9907601 angegeben. Ich bin verwirrt....


    Über Hilfe würde ich mich freuen!

    LG Niklas

    Ich hab die Lösung soeben gefunden. Eigentlich dachte ich, da ich die Suffixeingabe von der Linieneingabe getrennt habe und diese ja standardmäßig eine eigene Variable hat, dass das "IBIS_Linie_Complex" irrelevant ist und hab deshalb einfach die Liniennummer in diese Variable geschrieben. Das Script übermittelt aber genau diese Variable an die Matrix, d.h. wenn ich Linie 76 eingegeben habe, war das für das Script die Linie 000, Suffix 76. Ich habe dies nun geändert, jetzt wird bei der Linieneingabe "Linie * 100" in die Variable geschrieben und das Suffix daraufaddiert.


    Ich würde den Thread mal noch unerledigt lassen, da ich recht wahrscheinlich im Verlauf des Scriptens noch auf weitere Probleme stoßen werde (oder soll ich dann einen neuen Thread erstellen?).

    Mittlerweile bin ich etwas tiefer in die Materie des Druckers eingestiegen, genauer gesagt in die Linie/Fahrt-Eingabe.

    Theoretisch will ich, dass der Drucker bei Linie 9999 Resettet wird und ansonsten die Linieneingabe an die Matrix überträgt, in der Praxis passiert aber genau das Gegenteil (er wird zwar bei 9999 resettet, die Matrix wird allerdings nur bei 9999 aktualisiert, nicht bei anderen Linien), was für mich nicht wirklich Nachvollziehbar ist. Die Logfile meldet keine Probleme seitens des Scripts.

    Ich konnte bereits herausfinden, dass die Variablen "IBIS_LinieKurs", "IBIS_Linie_Complex", "IBIS_Linie_Suffix" und "IBIS_Route" korrekt beschrieben werden.


    Kann mir diesbezüglich vielleicht einer weiterhelfen?


    Hier der EIngabetrigger: EDIT: Ich konnte das Problem durch teilweises Austauschen durch Originalscripts konkret auf den Bereich "Input Teilen.." zurückführen, unnötiges Entfernt

    LG Niklas

    aber z.T. sehe ich zwecks Formatierung im Download auch schneller den Fehler.

    Dafür gibt es die Code-Spoiler, da bleibt die Formatierung erhalten.


    Aber ab einer Gewissen Dateigröße wird es einfach zu unhandlich im Forum, da ist eine Logfile im Anhang besser.

    Ich meine, irgendwo Mal eine Variable oder ein Marko für die Entfernung zu einer Haltestelle gesehen zu haben. Finde ich bloß gerade nicht mehr...

    In den Macrolisten der Wiki taucht nichts diesbezüglich auf.


    Aber mithilfe eines Tipps aus dem Discord hab ich es nun soweit hinbekommen, jetzt (im 3. Anlauf) wird die Entfernung aus der Raddrehung heraus pro Frame gemessen. Einziges Problem ist da noch eine Kombination aus hohen Geschwindigkeiten und sehr niedriger Performance (bei 86km/h/20FPS hatte noch noch keine Probleme), denn sobald die Raddrehung pro Frame mehr als 75% beträgt, kommt das Script mit hoher Wahrscheinlichkeit durcheinander (hat mit einem Schutzmechanismus zu tun, wenn die Umdrehung von 359° auf 0° springt). Da wird noch einiges an Tests und Feinjustierungen nötig sein.


    Für alle Interessenten hier der Code, ein Tutorial gibt's dann wenn es wirklich fertig ist.


    Abschnitt im Frame-Bereich für Fortschaltung:

    Und hier die Debug-Tachoanzeige im Display für die Streckenmessung:


    Der Debug-Reset wird durch ein Simples "1 (S.L.IBIS_Debugreset)" im Trigger der Auslösen-Taste ausgelöst.

    Auskommentiert sieht man hier noch die anderen getesteten Varianten.


    Das hier habe ich im Macro für den Busstop-Refresh eingefügt. Dadurch wird entweder die neue Entfernung ausgelesen oder bei Manueller Fortschaltung eine Konstante (50m) eingefügt, nach welcher der Drucker fortschalten soll. Heißt, die Manuelle Fortschaltung sollte nur exakt an der Haltestelle passieren, weil ansonsten alles durcheinandergerät. Ist/War in der realität aber genauso.



    Ich bin für weiteres Feedback und Verbesserungsvorschläge/Lösungsansätze offen!


    LG Niklas

    Hallo,

    ich Lagere Hilfegesuche beim Scripten mal aus meinem Tutorial-Thread hierher aus.


    Ich bin am versuchen, eine Distanzgesteuerte Haltestellenfortschaltung zu scripten, wie ich sie hier aus den ehem. AFR200-Druckern kenne. Das System soll später auch für Distanzgesteuert verzögerte Ansagen genutzt werden. Dazu habe ich mir einen "Debug-Mode" in den AFR200-Drucker eingebaut, welcher als Tacho während der Fahrt mitläuft und die Distanz aus den Scriptberechnungen anzeigt (v.a. für die Messung der Haltestellenabstände, aber auch zur Kontrolle).


    Für diesen Tacho habe ich 2 Lösungsansätze versucht:


    1. über den Tachostand (errechnet durch (L.L.kmcounter_km) 1000 * (L.L.kmcounter_m) +, dieser wert wird beim Reset gespeichert und jeweils verglichen, die Differenz aus beiden Werten ist die Gefahrende Distanz

    Problem: Trotz Abfrage jedes Frame zeigt mir OMSI die Distanz stehts in 64m-Schritten an, unabhängig von der gefahrenen Geschwindigkeit o.ä.. Das ist für das Projekt definitiv zu unpräzise. Ist das OMSI-Bedingt oder habe ich einen Fehler im Script gemacht?


    2. über S=V*T, also (L.L.Velocity) 3.6 / (L.S.Timegap) *. Diese Methode hat zwar den Realismus dabei, dass z.B. durchdrehen der Reifen die Fortschaltung beeinflusst und gibt auch Metergenaue Angaben (nicht in 64m-Schritten), dafür wird z.B. die Zeit von Rucklern als gefahrene Distanz mitberechnet (hatte z.B. beim Ausmessen 200m Differenz durch einen Loading-AI-Ruckler).


    Also sind beide Methoden noch nicht optimal, kennt hier vielleicht jemand einen Lösungsansatz, eine der Methodens ins brauchbare zu verbessern?

    Ich vermute mal, da beide Methoden im Grunde funktionieren (=die annähernd korrekte Distanz anzeigen) und beide Methoden identisch im Script eingebaut waren, helfen euch weitere Scriptteile nur Bedingt weiter, bei Bedarf kann ich diese aber gerne Liefern.


    Danke schonmal für Hilfe!

    LG Niklas


    Ich wünsche euch allen ein frohes neues und hoffentlich besseres Jahr 2021!


    Oben zu sehen der einzige Bus, der um Mitternacht noch durch das ländliche Kandertal fährt, die Einrückfahrt der Regiobus-Linie 54 zum Betriebshof. Und im Hintergrund das böllerfreudige Binzener Dorfvolk, wie man es dieses Jahr vermisst *ironie aus lol

    Ich persönlich hoffe ja auf ein Release der ersten Linie des Projekt Dreiländereck in 2021 (auch weil ich nach dem Abi & vorraussichtlichem Umzug nicht weiß, inwiefern ich noch weiterbauen werde), versprechen kann ich aber nichts.


    LG Niklas

    Du kannst alles Abfragen was du willst, es muss nur ein Abfrage von dir erstellt werden.

    Gucke dazu am besten mal in die Wiki (OOF), was alles von OMSI ausgegeben wird.

    Ich weiß, das hab ich immer offen beim Scripten.

    z.B. über (M.V.GetRouteBusstopIdent) "Wie heißt die Xte Bushaltestelle der Route"

    Da steht in der Beschreibung des OOF-Wiki, dass der Haltestellenindex, nicht der Name ausgegeben wird, d.h. das ist falsch und ich kann damit den in der Route angegebenen Namen abrufen?


    Man kann Debug Meldung rausgeben

    Wäre nicht verkehrt zum ausprobieren, danke für den Tipp.

    Du denkst ein bisschen zu kompliziert.

    Bin aktuell am Überlegen, ob man nicht einfach eine Parallelroute (also z.B. 99LLLRR) erstellen könnte, welche anstelle der Haltestellennamen die Abstände enthält. Aber sehe ich es richtig, dass es keinen Macro "Wie heißt die Xte Bushaltestelle der Route" gibt? Ansonsten müsste man ja für jede Meterangabe noch einen Busstop erstellen...

    Das Script teste ich erstmal anhand einer AFR200-Haltestellenfortschaltung, wie sie in den SWEG-AFR genutzt wurde, daraus kann man ja dann auch das Ansagenscript ableiten.


    Damit durch eine Hin- und Rückfahrt alle Abstände in die Logfile ausgegeben werden.

    Wie genau meinst du das?

    Alles gut, dass mit den Hofdateien ist ja nicht allzu schwer, denke das kann jeder hinbekommen.

    Wie gesagt, man muss die Karte Analysieren, wo welche Linien gemeinsame Strecken haben und wo nicht, entsprechend dem schauen, wo man gleiche Haltestellen nutzen kann und wo nicht, dann sämtliche Haltestellen klonen und entsprechend benennen, dort die Meterangaben hinzufügen und danach alle Routen neu Sortieren. Mit einem simplen Eintrag pro Haltestelle ist es eben nicht gemacht.


    Ich hab derweil mal noch eine weitere kleine Scriptspielerei von mir im Startpost eingefügt, für alle denen Ansagen zu modern sind.

    Mhh ich würde mich jedenfalls freuen wenn man das irgendwie mit den abstandsgebundenen Ansagen hinbekommt:)

    Wenn genug Interesse dafür besteht könnte ich schon das Script schreiben, aber das quasi-neumachen der Hofdatei kann ich euch nicht ersparen.


    Grundsätzlich sind die Grenzen in OMSI immer relativ. Durch umfunktionieren z.B. von Haltestellen kann man im Grunde so viele Mapgebundene Informationen, wie man will, nutzen. Da hat das Zonensystem vom GSÜH ja auch schon ordentlich mit herumgespielt.

    Es ist eigentlich ganz simple, dann noch die Abstände in der Hof-Datei hinterlegen.


    cooper

    Den Gedanken hatte ich auch schon durchgespielt. Dann hätte man aber kein allgemeines Script mehr, sondern mpsste komplett neue Hof-Dateien erstellen, weil ja jede Linie in jede Richtung eine extra Haltestelle braucht, da sich die Längen je richtunng ja unterscheiden. Mit einfach bzw. simpel hat das dann meiner Meinung nach nicht viel zu tun.