Beiträge von wurstbrot

So, aktuell versuche ich die Matrix in den Mainzer MAN LC einzubauen. Noch sind die Positionen nicht angepasst, aber will erstmal die Kiste zum laufen bringen und dann positioniren. Dazu hab ich zunächst einfach die o3d Files vom NeomanOverhaul reingtepackt, weil die so einigermaßen an der gewünschten Stelle sein sollten. Problem ist aber erstmal meine Model Datei. Der Bus lädt nur mit Fahrer und die Log weist mich auf Fehler in Zeile 88 hin:

143 16:14:03 - - Error: In "vehicles\MAN_LC_MVG\model\MAN_LC_DGM_IVU.cfg" there was an error in line 88!

Sonst keine Errors zum Bus. Anfangs hatte er noch RBL_Linie, RBL_Suffix und RBL_TerminusIndex angemeckert, das hab ich dann in die Varlist mit reingemacht und es wurde nicht mehr angekreidet.

In Zeile 88 ist aber der zweite Font des Busses und ich wüsste nicht was falsch an dem sein sollte. Die Fonts des Config-Zettels sind angehängt, ebenso Matrix Speicher und später natürlich der Konfig-Zettel gefolgt von den eigentlichen Matrix-Einträgen.

Was könnte der Fehler nun sein? Hier mal die Model-Datei: MAN_LC_DGM_IVU.cfg

Bei der im Beispiel gezeigten Haltestelle habe ich vor einer Weile aus Spa0 die -1 bei Minimum auf 0 gesetzt und gestern gesehen dass ich da tatsächlich Fahrgäste hatte, Das kanna lso doch sein dass die negativen Zahlen da Probleme machen können.

Eine andere Möglichkeit wäre noch die folgende, sie bedarf aber einigen Scriptkenntnissen, ist erstmal also reine Theorie:

Man bräuchte dazu Autos als verscriptete Objekte, die nur zu bestimmten Uhrzeiten sichtbar sind. Also ähnlich wie das bei diversen Marktobjekten (HH Winterhude Markt+Fischmarkt?) gelöst wird. Das Script sorgt also dafür dass die Autos nur zu genau festgelegten Zeiten erscheinen, ansonsten nicht.

Dann müssen wir uns um die Pfade kümmern. Wir bräuchten auf jeden Fall parallel Pfade für die Umfahrung der Autos als auch Pfade die durchfahren für die Zeit wo die Autos nicht erscheinen.

Als drittes brauchen wir für jeden AI Typ zwei Varianten, eine die umfährt und eine die nicht umfährt. Für diese müssen wir dann entsprechend die Uhrzeiten und Tage in der trafficdens-Datei festlegen wann sie offen sind. Bei Buslinien bräuchte es dann eben verschiedene Trips. Mit StationLink sollte es gehen, wäre aber in dem Fall komplizierter.

So was ähnliches habe ich auch beobachtet, aber nicht beid er AI LIst sondern bei den Trip Dateien. Da hatte ich zum Beispiel ein "ü" im Zieltext und das wurde dann im Editor zum Buchstabensalat. Ich weiss jetzt aber auch nicht mehr ob ich den Trip schon Notepad++ bearbeitet hatte und sich dabei das irgendwie auf UTF 8 umgestellt hat oder nicht. Denn manchmal editiere ich die Trips außerhalb von OMSI, und ich vermute mal einfach das war hier auch so. Und ich glaube auch dass es erst seit Windows 11 passiert.

93: https://s1.busphoto.eu/photo/04/23/16/423164.jpg

77: https://busphoto.eu/photo/592696/

Ansonsten muss man anmerken dass die IBIS Codes im Laufe der Jahre nur selten ausgetauscht wurden, eher kamen neue hinzu und die alten blieben. Die ursprüngliche Hof-Datei die mit den LC's zur Karte Mainz mitgeliefert wurde hat die originalen Codes und Ziele mit Stand von ca. 2013/14. Bis auf einige Anpassungen gelten diese heute weiterhin. Der Datenmüll geht sogar soweit dass man wohl heute immer noch die uralten Routen aus den 90ern aufrufen kann.

Ich baue ja keine neue Karte, ich baue aber eine um die überwiegend aus Invis-Splines bestand. Bedeutet aber in 80% der Fälle dann doch einen Neubau was Paths und Kreuzungen betrifft. Es ist jetzt natürlich schon 1000 mal besser als vorher, aber es wurmt unglaublich wenn man eine Situation hat wo es funktionieren müsste, es aber nicht tut. Man könnte es sich auch einfach machen und genau diese Pfade abschalten. Es juckt am Ende keinen wenn von einem Waldweg eben kein Linksabieger-Verkehr käme. Aber ich finde dann doch lieber den Grund dafür finden und das woanders dann vermeiden. Und vielleicht begünstigt die ursprünglicb "falsche" Pfadrichtung das Verhalten an diesen Stellen.

Mir ist nun aufgefallen dass bei den meisten Fällen mit der Problematik dass die Vorfahrt grundsätzlich missachtet wurde es sich um gemirrorte Pfade gehandelt hat. Das war schon auffällig als ich mir das diesbezüglich angeguckt habe. In einem Fall aber nicht, da liefen zwei Pfade zusammen die schon von Anfang an die gleiche Richtung hatten. Könnte eine Rolle spielen? Jetzt wäre es aber ultra kompliziert genau diese Pfade richtig herum zu verlegen. Ich glaube das würde nicht exakt das gespiegelte Ergebnis bringen, was ich aber bräuchte um diese Annahme zu prüfen. Denn den Pfad zu löschen und dann Pi mal Daumen direkt richtig herum zu verlegen könnte auch zu Folge haben dass es aus Zufall oder anderen Gründen dann funktioniert. Also kennt jemand eine Methode einen solchen Pfadstrang genau umzudrehen?

Ich glaube diese Diorama Map als es noch keine KI gab man da im Kreis fuhr hatte auf meinem alten Rechner 80-100 fps. Wenn ich jetzt ohne KI etc um die 150 fps schaffen würde dann wäre das ziemlich enttäuschend. Aber man kann das nie 1:1 hochrechnen, da muss man echt schauen wie es dann mit KI ist und das dann beurteilen.

OMSI kann allerhöchstes 4096 MB Speicher verwalten. Hierzu gehören die Adressräume vom Arbeitsspeicher UND Videospeicher. Wenn allein die Texturen schon dermaßen viel verbrauchen ist das völlig klar dass es knallt. Meistens sind die Busse schuld weil man es mal wieder übertrieben hat, aber theoritisch können es auch irgendwelche Objekte sein. Wenn ich mich in der Webdisk bei den Repaints aber umsehe und sehe dass für jede Wagennummer ein eigenes Repaint verwendet wird wundert mich sowas überhaupt nicht. Ich kann es nur wiederholen: zum testen die AI Liste reduzieren oder gleich nur mit MAN NL/NG oder so testen. Und dann sich vortasten wo der oder die Übeltäter liegen. Um zu schauen ob es grundsätzlich an Bussen liegt könnte man auch testweise Anzahl der Fahrplan-Fahrzeuge in den Optionen auf 0 setzen.

Ja, ich hatte die IVU Box dort eingebaut. Funktioniert auch, leider weiterhin ohne Übermittlung der Liniennummer.

Der Bus hat im Original Texttexturen, 0 bis 36. Wenn jetzt die Ticketbox Texturen 50 bis 55 hat (mal angenommen...) Dann musst Du 37 bis 54 "auffüllen". Dazu kopierst Du am Besten die 36 entsprechend als Textur 37, 38, ... , 49 und hängst dann erst 50 bis 55 der Tickenbox an. Die Zahlen sind übrigens nur Orientierung, wichtig ist die Anzahl. Und da hilft die Zahl wegen der Übersicht. Denn hängst Du die Texttexturen der Ticketbox direkt an haben sie als Index 37 bis 42 und werden somit nicht in der späteren Config aufgerufen.

Deine Busse liefern massenweise Fehler. Der O530 Facelift und der Volvo haben Scriptfehler ohne ende und die Model-Configs sind auch alles andere als sauber, daher die vielen Warnings bezüglich Texturen. Mich würde s nicht wundern dass die Problematik da her kommt, daher würde ich erstmal das ausschließen indem ich die Busse so aus der AI Liste nach und nach entferne bis solche Fehler in der Log nicht mehr auftauchen. Und dann eben schauen wie sich OMSI verhält. Oder ganz einfach die Standard-AI List von HH laden und schauen.

Weiße Bussen kommen sonst wenn die OMSI.exe knapp über 3,2 GB erreicht (mit 4 GM Patch!). Das kann auch schneller gehen als man denkt, insbesondere wenn man es bei der AI Liste zu gut gemeint hat. Dann sind aber meistens auch die Texturen mitschuldig, da wäre man nicht bei nur 700MB bei den Texturen. Aber theoretisch kann das auch sein.

Ist mir bisher zumindest nicht aufgefallen, aber gut zu wissen;-)

Schade ist dass der NLC in der normalen Version so gar nicht KI-tauglich ist. Der schleicht dann herum oder steht. Das macht ihn für ablösbare Linien nicht brauchbar, da man hier schlecht die KI-Version fahren lassen kann. An und für sich ist ja das Vorhandensein einer KI-Version sehr löblich, vor allem wenn sie so gut skriptreduziert ist wie beim NLC, ich finde aber die normale Version sollte auch in der Lage sein als KI eingesetzt zu werden.

Moin!

Ich habe mal bei den Mainzer DFI's das Blinken wieder aktiviert, wenn die Abfahrtzeit kleiner als eine Minute ist. Wie zu erwarten belastet das die Simulationsperformance immens, es gibt während des Blinkens krasse Schwankungen der Frametimes, und das merkt man auch. Je nachdem wie viele DFIs so ind er Nähe sind ist das ein Ruckler alle Sekunde. Aus gutem Grund war das Blinken also im Script abgeschaltet. Allerdings habe ich in OMSI schon mehrfach DFIs gesehen die auch geblinkt haben, jedoch ohne die Frametimes so zu belasten. Was könnte ich denn am Code ändern um das auch hier hinzukriegen?

{init}

{end}

{frame}


'Blinkgeber:
    (L.S.GetTime) 2 % 1 < (S.L.Blink)

'ZEILE 1 ==============================================


'Zuerst prüfen, ob das Ziel valide ist:

    0 (M.V.GetArrBusTerminus) (S.$.Terminus)
    "" $=
    {if}
'Wenn nicht, dann nix anzeigen:
        0
    {else}
'Abfahrtszeit schonmal zwischenspeichern unter s0:
        0 (M.V.GetArrBusTimeDiff) 60 / s0

'Wenn die Abfahrtszeit weniger als eine Minute ist, dann blinken: (wenns blinkt, ist s1/l1 wahr!)
        l0 1.0 < s1
        {if}
            (L.L.Blink)
        {else}
'Sonst anzeigen:
            1
        {endif}
    {endif}
        
'Vorherig ermitteltes Ergebnis nun verwenden als Bedingung, ob was angezeigt wird:
    {if}
        0 (M.V.GetArrBusLine) 3 $SetLengthL $+ " " $+
        0 (L.$.Terminus) 16 $SetLengthL $+ " " $+
'Wenn es blinkt, dann die Uhrzeit nicht mehr anzeigen:
        l1
        {if}
            "      " $+
        {else}
            0 l0 0 max " 2" $IntToStrEnh $+ " min" $+ 
        {endif}
    {endif}

'ZEILENUMBRUCH ==============================================

    "@" $+

'ZEILE 2 ==============================================


'Zuerst prüfen, ob das Ziel valide ist:

    1 (M.V.GetArrBusTerminus) (S.$.Terminus)
    "" $=
    {if}
'Wenn nicht, dann nix anzeigen:
        0
    {else}
'Abfahrtszeit schonmal zwischenspeichern unter s0:
        1 (M.V.GetArrBusTimeDiff) 60 / s0

'Wenn die Abfahrtszeit weniger als eine Minute ist, dann blinken: (wenns blinkt, ist s1/l1 wahr!)
        l0 1.0 < s1
        {if}
            (L.L.Blink)
        {else}
'Sonst anzeigen:
            1
        {endif}
    {endif}
        
'Vorherig ermitteltes Ergebnis nun verwenden als Bedingung, ob was angezeigt wird:
    {if}
        1 (M.V.GetArrBusLine) 3 $SetLengthL $+ " " $+
        0 (L.$.Terminus) 16 $SetLengthL $+ " " $+
'Wenn es blinkt, dann die Uhrzeit nicht mehr anzeigen:
        l1
        {if}
            "      " $+
        {else}
            0 l0 0 max " 2" $IntToStrEnh $+ " min" $+ 
        {endif}
    {endif}


'ZEILENUMBRUCH ==============================================

    "@" $+
'ZEILE 3 ==============================================


'Zuerst prüfen, ob das Ziel valide ist:

    2 (M.V.GetArrBusTerminus) (S.$.Terminus)
    "" $=
    {if}
'Wenn nicht, dann nix anzeigen:
        0
    {else}
'Abfahrtszeit schonmal zwischenspeichern unter s0:
        2 (M.V.GetArrBusTimeDiff) 60 / s0

'Wenn die Abfahrtszeit weniger als eine Minute ist, dann blinken: (wenns blinkt, ist s1/l1 wahr!)
        l0 1.0 < s1
        {if}
            (L.L.Blink)
        {else}
'Sonst anzeigen:
            1
        {endif}
    {endif}
        
'Vorherig ermitteltes Ergebnis nun verwenden als Bedingung, ob was angezeigt wird:
    {if}
        2 (M.V.GetArrBusLine) 3 $SetLengthL $+ " " $+
        0 (L.$.Terminus) 16 $SetLengthL $+ " " $+
'Wenn es blinkt, dann die Uhrzeit nicht mehr anzeigen:
        l1
        {if}
            "      " $+
        {else}
            0 l0 0 max " 2" $IntToStrEnh $+ " min" $+ 
        {endif}
    {endif}
'ZEILENUMBRUCH ==============================================

    "@" $+
'ZEILE 4 ==============================================


'Zuerst prüfen, ob das Ziel valide ist:

    3 (M.V.GetArrBusTerminus) (S.$.Terminus)
    "" $=
    {if}
'Wenn nicht, dann nix anzeigen:
        0
    {else}
'Abfahrtszeit schonmal zwischenspeichern unter s0:
        3 (M.V.GetArrBusTimeDiff) 60 / s0

'Wenn die Abfahrtszeit weniger als eine Minute ist, dann blinken: (wenns blinkt, ist s1/l1 wahr!)
        l0 1.0 < s1
        {if}
            (L.L.Blink)
        {else}
'Sonst anzeigen:
            1
        {endif}
    {endif}
        
'Vorherig ermitteltes Ergebnis nun verwenden als Bedingung, ob was angezeigt wird:
    {if}
        3 (M.V.GetArrBusLine) 3 $SetLengthL $+ " " $+
        0 (L.$.Terminus) 16 $SetLengthL $+ " " $+
'Wenn es blinkt, dann die Uhrzeit nicht mehr anzeigen:
        l1
        {if}
            "      " $+
        {else}
            0 l0 0 max " 2" $IntToStrEnh $+ " min" $+ 
        {endif}
    {endif}
'ZEILENUMBRUCH ==============================================

    "@" $+
'ZEILE 5 ==============================================


'Zuerst prüfen, ob das Ziel valide ist:

    4 (M.V.GetArrBusTerminus) (S.$.Terminus)
    "" $=
    {if}
'Wenn nicht, dann nix anzeigen:
        " MAINZIGARTIG MOBIL"
    {else}
'Abfahrtszeit schonmal zwischenspeichern unter s0:
        4 (M.V.GetArrBusTimeDiff) 60 / s0

'Wenn die Abfahrtszeit weniger als eine Minute ist, dann blinken: (wenns blinkt, ist s1/l1 wahr!)
        l0 1.0 < s1
        {if}
            (L.L.Blink)
        {else}
'Sonst anzeigen:
            1
        {endif}
    {endif}
        
'Vorherig ermitteltes Ergebnis nun verwenden als Bedingung, ob was angezeigt wird:
    {if}
        4 (M.V.GetArrBusLine) 3 $SetLengthL $+ " " $+
        0 (L.$.Terminus) 16 $SetLengthL $+ " " $+
'Wenn es blinkt, dann die Uhrzeit nicht mehr anzeigen:
        l1
        {if}
            "      " $+
        {else}
            0 l0 0 max " 2" $IntToStrEnh $+ " min" $+ 
        {endif}
    {endif}
    $+

'AUSGABE ==============================================

    (S.$.Displaytext)

    5 (S.L.Refresh_Strings)
{end}

Hier der Code mit aktiviertem blinken per (L.L.Blink). Ersetzt man das jeweils mit einer 1 schaltet man es wieder ab.

Alles klar, danke

Im Einsatz als KI bekomme ich in der Log folgendes ausgespuckt:

148 15:22:04 -  -   Error:           Fehler: im Befehl "(L.L.bremse_ESP_eingriff)" (Vehicles\MAN_NewLionsCity\\script\D1556.osc) ist der Variablenname ungültig!
149 15:22:07 -  -     Warning:       File Vehicles\MAN_NewLionsCity\model\KI_18C_3door_main.cfg: texture filename Fenster.tga not found in mesh file Vehicles\MAN_NewLionsCity\model\solo\Dachluken\Dachluke_V.o3d!
150 15:22:07 -  -     Warning:       File Vehicles\MAN_NewLionsCity\model\KI_18C_3door_main.cfg: texture filename Fenster.tga not found in mesh file Vehicles\MAN_NewLionsCity\model\gelenk_v\Dachluken\Dachluke_H.o3d!
151 15:22:07 -  -     Warning:       Vehicles\MAN_NewLionsCity\model\KI_18C_3door_main.cfg, line 5313: Mesh with Ident Fahrertuer not found!
152 15:22:09 -  -     Warning:       File Vehicles\MAN_NewLionsCity\model\KI_18C_3door_trail.cfg: texture filename Fenster.tga not found in mesh file Vehicles\MAN_NewLionsCity\model\gelenk_h\Dachluke\Dachluke.o3d!

Die Warnings sind glaub ich normal, der ungültige Variablenname bei D1556.osc sicher nicht. Jemand ne Idee wie man das fixen kann? Augenscheinlich funktioniert die KI-Variante aber trotzdem.

Zitat von DerGrafikfehler

Die Font ist eine mit 8 Pixel Höhe ohne Unterlänge. Die im DGM-Pack verwendete ist 8 Pixel hoch mit Unterlänge. Heißt eigentlich müssten alle anderen Buchstaben vergrößert werden.

Also Du meinst ich müsste alle Buchstaben (bis auf die mit Unterlänge) vergrößern? Man könnte sie ja nach unten lang ziehen, das verzerrt aber glaub ich die Schrift. Für mich wirkts eher als hätte man die g's und y's einfach gestaucht. Wäre doch auch einfacher?

Ich finds faszinierend wie das Script bei nicht vorhandener Unterlänge das perfekt einpasst und auch die obere Zeile vergrößert. Ist wohl eine Wissenschaft für sich

Moin!

Ich hab nun das DGM Paket entdeckt und es gefällt mir sehr gut, sodass ich gerade auch überlege alle Fahrtzeuge die ich mit K++ ausgestattet habe nun auf DGM umzurüsten. Aber zunächst teste ich das ganze noch am NewLionCity. Zwei DInge bohren mich gerade etwas und ich frage mich wie ich sie am Besten hinkriege:

1. Wie kriege ich es hin dass die Seiten- und Heckmatrix die *B und *K Befehle in der Hof ignoriert damit nur die Frontmatrix diese nutzt?

2. Aktuell nutze ich den Font Aesys 200x24 für die Front und der passt mir perfekt, bis auf Anzeigen die Buchstaben wie g, y etc enthalten. Diese hätte ich gerne bis zur Grundlinie hochgezogen wie hier im Beispiel: https://busphoto.eu/photo/610537/

Ich müsste dazu den Font entsprechend modden, aber glaube kaum dass es da ausreicht nur die betroffenen Buchstaben zu stauchen, oder? Und außerdem würde ich das wenn dann als Zusatzoption machen wollen. Oder hat es schon jemand entsprechend gemacht?

Ich blick auch den Font Aufruf iom Script nicht so ganz. Da finde ich nirgends 200x24 Fonts, höchstens 16x16 oder 16x24.

Eventuell Bug:

Wenn ich eine gespeicherte Situation lade, egal ob Autosave oder eine selbst gespeicherte, ist die Zeit um 60 Minuten verschoben. Speichere ich also um 12 Uhr sehe ich auch 12 Uhr in den Daten des Saves, im Spiel hab ich aber 13 Uhr und +60min Verspätung. Sehr umständlich, denn dann muss ich Fahrplan deaktivieren, Zeit umstellen und Fahrplan neu einstellen.

Zwei Gründe könnten mir für den Bug einfallen: entweder ist der jetzt mit der Version neu oder er tritt auf wegen der Umstellung auf Sommerzeit und fiel eben vorher nicht auf. Allerdings hatte ich im Sommer und Herbst auch AUXI genutzt. Die ganzen Synchronisationsoptionen nutze ich übrigens nicht, sie sind alle deaktiviert.

Zweite Sache:

Die Funktion wo ich per Hotkey meinen Kopf nach vorne verschieben kann (nicht Zoom!) setzt sich immer auf 2 m zurück beim Neuladen.

Ähm 1. April fast Punkt 0 Uhr und Ihr diskutiert OB das ein Scherz ist oder nicht?