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!

    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.

    Ob die Ansage im stehen kommt, war eigentlich eine Frage, keine Idee :D

    Ah. Also bisher hatte die Geschwindigkeit keinen Einfluss, aber ich habe soeben das Tutorial im Startpost geändert, sodass der Timer bei unter 1km/h angehalten wird.

    An alle, die das ganze bereits eingebaut haben:


    Sucht im Script nach

    Code
        (L.L.Ansage_timer) (L.S.Timegap) + (S.L.Ansage_timer)

    und ersetzt es durch

    Code
        (L.L.Velocity_Ground) 1 >
        {if}
            (L.L.Ansage_timer) (L.S.Timegap) + (S.L.Ansage_timer)
        {endif}

    Das wars auch schon mit der Änderung.


    LG Niklas

    Hier nochmal ein falscher Hilfspfeil: Auf der 591 richtung Rödingerfeld kommt nach der Hst. Bornholmerstr. ein Pfeil nach rechts, es steht irgendwie sowas wie "über Mühler zur Schule" oder so. Die 591 kann aber zur Mühlerstrasse geradeaus fahren ;)

    Der Hilfspfeil zeigt, dass Busse über Mühler Schule da rechts rein sollen. Wenn du nicht über Mühler Schule fährst, Interessiert dich dieser Hilfspfeil nicht und du folgst der Vorfahrtsstraße bis zum nächsten Hinweis ;)

    Heute SEV mit dem zweiten ex.-SWEG-Wagen von Aust Reisen, einem 2003er Citaro G. Der wagen war für eine Badenova-Dauerwerbung blau lackiert und wurde nun mit einer Volksbank-Werbung Beklebt.



    Map: Waldhofen 2013

    Bus: Citaro G

    Ich muss sagen, mir gefällt die Map und Fas Fahrplankonzept (mit Schichtsystem, Schulbussen ect.) ziemlich gut!


    Ein paar kleinere Sachen, die ich dennoch gerne Anmerken würde:


    - Die Stellplätze auf dem Aust-Betriebshof sind sehr eng, sobald links und rechts von einem Busse oder die Laterne steht, fährt man sich theoretisch den Spiegel ab

    - Mir hat ein Hilfspfeil an der Einfahrt zum Aust-Betriebshof gefehlt (bin mit Fahrplan gefahren)

    - (ich weiß, das ist was wirklich kleines) Laut Fuhrparkliste haben die Citaro Facelift Euro IV bzw. Euro V - Abgasnorm, am Heck klebt aber bei allen das EEV-Emblem drauf

    - An einigen stellen nutzen die KI-Busse Busspuren nicht (z.B. am Neuen Rathaus) oder biegen von einer linken Spur ab, obwohl dies laut Beschilderung nur von der Rechtenspur möglich ist und auch machbar (z.B. zw. Schwarzwaldstr. und Kaserne)

    - Ich fahre gerade einen Gelenkbusumlauf mit E87-Verstärker ab Fachhochschule mit 100% Fahrgastaufkommen, da würde ich mir wünschen dass mehr als nur 6 Leute an der FH einsteigen.

    - An der Einfahrt zum Tunnel rtng. Beisenbruch verkeilen sich Fahrzeuge:


    Bin die alte Version von Waldhofen aber kaum Gefahren und kann deshalb nicht sagen, von dem gerade die Pfade jetzt kommen ;)


    LG Niklas