Beiträge von jjb

Und genau dies ist eben ein Problem. OMSI versucht den Bus zu laden und kann die Datei aber nicht finden. Entweder du installierst den fehlenden Bus oder du bearbeitest die AI-Liste.

 OMSI Script Extension

OMSI Script Extension für Visual Studio Code bietet Syntaxhervorhebung, Bearbeitungstools und Analysefunktionen für OMSI Script. Das macht die Entwicklung von Skripten noch einfacher!

Download: https://marketplace.visualstud…?itemName=jjb-pro.osc-ext

 Features

 Code-Analyse:

Die Erweiterung erkennt automatisch Fehler, sodass OMSI nicht erst gestartet werden muss, um sie zu finden. Sie informiert dabei über Syntaxfehler, undefinierte Systemmakros und vieles mehr.

 Code-Vervollständigung mit Dokumentation:

Die Erweiterung hilft ebenfalls, Code schneller zu schreiben, indem sie während der Eingabe Vorschläge gibt. Sie zeigt Optionen wie Variablen, Makros und Befehle an, die bereits verwendet wurden, aber schlägt auch Systemmakros vor. Sogar eine Dokumentation der Befehle wird angezeigt, sodass sofort ersichtlich ist, was sie tun.

 Dokumentformatierung:

Mit dieser Funktion wird das gesamte Dokument aufgeräumt, indem Kommentare und Code automatisch geordnet werden. Sie korrigiert die Einrückung, damit alles sauber und leicht lesbar wird.

 Syntaxhervorhebung:

Die Erweiterung fügt eine Syntaxhervorhebung hinzu, um den Code durch Einfärbung von Schlüsselwörtern, Variablen und anderen Elementen lesbarer und verständlicher zu machen.

Changelog:

• 1.0.1: Erste Testversion

Hallo zusammen,

in Bezug auf die Luftbilder habe ich Folgendes herausgefunden:

• im GitHub-Repository findet ihr zusätzlich noch das Projekt OMSI-toquad, das die Links zu den verschiedenen Anbietern zurückgibt: OMSI-toquad auf GitHub
• OMSI nutzt die WGS84-Projektion

Falls das technisch jemanden interessiert, hier der Code zur Berechnung des Breiten-/Längengrades:

class Map
    REAL_TILE_COUNT = 65536
    REAL_TILE_WIDTH_DEG = 360.0 / REAL_TILE_COUNT
    REAL_TILE_EQUATOR_LENGTH = 6378137.0 * Math::PI * 2
    # returns the latitude and longitude of the tile placed at x, y
    def self.world_tile_coordinates(x, y)
        rlat = Math::atan(Math::sinh(Math::PI * (2.0 * y / REAL_TILE_COUNT)))
        lat = 180.0 * (rlat / Math::PI)
        lon = x.to_f / REAL_TILE_COUNT * 360.0
        {latitude: lat, longitude: lon}
    end


    # returns the width (in meters) of the tile placed at x, y
    def self.world_tile_width(x, y)
        rlat = Math::atan(Math::sinh(Math::PI * (2.0 * y / REAL_TILE_COUNT)))
        lon_mpdeg = REAL_TILE_EQUATOR_LENGTH / 360.0 * Math.cos(rlat)
        lon_mpdeg * REAL_TILE_WIDTH_DEG
    end
end

(Ich bin kein Ruby-Programmierer 🤣.)

Vielleicht wäre es sinnvoll, das PHP-Skript auf der Webdisk zu hosten? Dadurch könnte man die Verlinkung zu gcmods.de vermeiden und man wäre nicht mehr von der Verfügbarkeit abhängig.

Hallo,

seit einiger Zeit schon bin ich auf der Suche nach meinem Performanceproblem. Und zwar:

• Kacheln laden langsam
  • Wenn ich ca. 200 m von der Kachel entfernt bin, lädt diese erst; manchmal lagt es dabei auch – dies ist aber von Tag zu Tag auch unterschiedlich, obwohl ich andauernd mit den gleichen Optionen spiele.
  • Der Bus hüpft, wenn die Kachel erscheint, einmal kurz in die Luft (FPS-Drop).
  • „Gesamte Karte beim Start laden“ ist jedoch auch keine Option, da dann in OMSI gar nichts mehr geht.
• Texturnachladen
  • Ich schaue kurz nach links und dann wieder nach rechts und die Texturen auf der rechten Seite sind wieder weiß. D. h. schon geladene Objekte verlieren ihre Textur, wenn man sie nicht andauernd anschaut. Das Laden der Texturen resultiert natürlich wieder in Lags und weniger FPS.
  • Vor kurzer Zeit habe ich alle meine Texturen verkleinert, dies hatte aber keine Verbesserung gebracht.
  • Außerdem habe ich das Format von allen Texturen von *.png auf *.dds umgestellt. Das Resultat: Eine kleine Änderung zum Negativen.
• Lags beim Abbiegen
  
  • Der Blick zur Seite oder auch das Abbiegen resultieren in teilweise extrem langen Lags. Vor allem an zwei Stellen gibt es dieses Problem, ansonsten konnte ich keine Regelmäßigkeit feststellen.
• wenig FPS in verschiedenen Blickrichtungen und auf verschiedenen Kacheln
  • Wenn ich nach links schaue, in den Spiegel gucke oder wenn ich mal nach hinten schaue, habe ich mehr FPS. Dies liegt aber von der Kachel ab. Manchmal bringt der Blick nach Vorne auch mehr FPS.
  • Es gibt tatsächlich Abschnitte mit ca. 40 FPS (diese sind meist kurz) und danach folgen Abschnitte mit 10–20 FPS. Die Karte befindet sich nicht im Stadtzentrum, sodass solch niedrige FPS höchst fragwürdig sind.
• auf zwei Kacheln: sehr schlechte Performance, ungefähr 10 FPS
  • Ich habe versucht, die Ursache dafür herauszufinden und habe versucht nachzuschauen, welche Spline/welches Objekt diese Performanceprobleme verursacht, doch leider ohne Erfolg.
  • Die niedrigen FPS treten aber nur in eine Blickrichtung auf – schaue ich in eine andere Richtung, habe ich plötzlich wieder um die 20 FPS.

Interessant aber ist, dass diese Probleme in dieser Stärke nur auf einer meiner selbstgebauten Karte auftreten und das auch sehr unregelmäßig – obwohl es der gleiche Computer, die gleiche Uhrzeit, der gleiche Bus und die gleichen Optionen sind. Manchmal läuft OMSI ziemlich flüssig (sogar 160! FPS auf der Karte ohne Bus) und sehr oft werde ich beim Fahren vom Laden und Lags gequält (ohne Bus dann 40 FPS). Der 4 GB-Patch ist natürlich drin. Ich habe ebenfalls versucht, alle Skripts zu deaktivieren – es hat keine Änderung bewirkt. Ich habe beim Bau der Karte auf Performance geachtet – was die Karte aber unterscheidet ist, dass ich viele hochauflösende Texturen (1024 × 1024 – 2048 × 2048) verwende; Low-Texturen mit max. 512 × 512 px zu nutzen hilft aber auch nicht. Außerdem habe ich sehr viel mit der „Count to Spline“-Funktion gearbeitet. Aber die finale Position wird ja eh nur einmal beim Laden berechnet. Die Logfile habe ich mir ebenfalls angeschaut und nach jeder Fahrt alle Fehler behoben – diese beinhaltet also nur noch Fahrzeugfehler. Ich bin wirklich kurz vorm Verzweifeln …

• Informationen zum Laptop:
  • Prozessor: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz 2.81 GHz
  • Installierter RAM: 12.0 GB
  • Systemtyp: 64-Bit-Betriebssystem, x64-basierter Prozessor
  • Betriebssystem: Windows 11 (23H2)

Vielen Dank im Voraus für die Hilfe!

Problem endlich gefunden! Beim Abgleich, ob überhaupt ein Ziel vorhanden ist, habe ich = genutzt. Strings vergleicht man aber mit $=.

'    …
'     Informationen nur anzeigen, wenn  Bus auch kommt
    0 (M.V.GetArrBusTerminus) "" =

'    …

Du musst die fehlenden Dateien (qtinf.dll, qtinf70.dll, etc.) aus dem OMSI 2-Ordner kopieren und in den SDK-Ordner (der Ordner mit OmsiXConv.exe) einfügen.

OMSI Script Console cannot load variables from the running OMSI instance (although it would be possible to implement this). It's simply a console that can run OMSI Script. I.e. you enter e.g. 1 2 + and with %stackdump% you can see that there is a 3 on the stack. This means that it is no longer necessary for users to load OMSI and try out the script in it. This console allows the user to execute simple scripts in it. Here, as an example, is the calculation of the day of the week. This makes it easy to execute the code for that algorithm on the console, and (the result) can also be debugged with debugVar or $msg.

Neues Update für den OMSI Textures Manager

Das Programm hat endlich zwei wichtige Verbesserungen erhalten:

• bei der Größenanpassung wird die Textur nicht mehr auf den Höchstwert vergrößert, wenn sie kleiner ist als dieser
• wenn die Textur kleiner ist als der Höchstwert und auch kleiner als der Höchstwert für die Lowtextur, wird die Texturgröße der Lowtextur auf einen Wert unter die Texturgröße reduziert

Neues Update für die OMSI Script Console

Das Programm ermöglicht nun die Übergabe von Argumenten:

• Scripts können nun im Explorer per OMSI Script Console gestartet werden
• ein Argument kann beim Start an das Programm übergeben werden; z.B. in PowerShell:

• Start-Process "OMSI Script Console.exe" -ArgumentList "1 2 + %stackdump%"
• Start-Process "OMSI Script Console.exe" -ArgumentList "runMore C:\Program Files (x86)\Steam\steamapps\common\OMSI 2\Vehicles\MAN_NL_NG\MAN_EN92_main.bus"

Hier geht es weiter: RE: Various OMSI Tools [by jjb].

OMSI Script Console

Download - WebDisk

Führe OMSI-Skripte aus, ohne OMSI zu starten!

• Ausführen von OMSI-Scripts
• viele Debugmöglichkeiten, bspw.: Ausgabe von definierten Macros, Triggern, Variablen
• Scriptdateien, Konstantendateien, Variablendateien laden und nutzen
• einfache Befehle mit Erklärung
• einige simulierte Systemvariablen

Hallo,

ich arbeite gerade an einem neuen Menschen für OMSI. Leider habe ich Schwierigkeiten mit dem Export aus Blender, da die Vertexgruppen nicht exportiert werden, obwohl sie in Blender vorhanden sind.

Ich habe bereits versucht, sowohl den integrierten *.x-Exporter als auch ein Add-On zu verwenden, jedoch ohne Erfolg. Selbst nachdem ich einen anderen Human (*.o3d) importiert habe – dieser hatte VertexGruppen – und erneut exportiert habe, sind die Vertexgruppen beim Export verschwunden.

Vielen Dank im Voraus für Eure Unterstützung!

Mir ist aufgefallen, dass wenn es in der nächsten Zeit 6 Fahrten gibt, auch wirklich alle 6 Zeilen angezeigt werden. Ansonsten fehlen immer einige Zeilen.

Das kann man auch bei der Tangential-to-Spline-Funktion bemerken. Diese funktioniert in dem Splinestück, an dem das Objekt angehängt wurde. An anderen Splinestücken werden die Objekte nicht passend geneigt.

Mal wieder was dazugelernt 🙂.

Zitat von PingPong

Deine Logfile ist nicht vollständig

Warum soll die nicht vollständig sein? So sieht eine Logfile aus, wenn man keine Karte lädt und aber das Hauptmenü …

Falls nur die Karte Szczecin nicht gefunden werden kann und alle anderen in der Auswahl vorhanden sind, hast du die Karte wahrscheinlich nicht richtig installiert. In dem Mapordner von OMSI sollte sich ein Unterordner der Karte befinden (Projekt Szczecin oder so) und dort drin sollte eine global.cfg-Datei liegen. Bsp.: OMSI 2\maps\Projekt Szczecin\global.cfg.

Das Problem lag darin, dass die sehr lange Autobahn in mehrere Splines unterteilt war. Dadurch haben sich die Count-to-Spline-Bäume vervielfacht, wie es komischerweise in OMSI üblich ist. Die Bäume habe ich dann manuell aus der *.map-Datei gelöscht.

Die Textfelder habe ich neu erstellt und nun funktioniert die Anzeige. Wo genau der Fehler lag, ist unklar.

Nach langer, langer Zeit habe ich die Fehlerquelle gefunden. OMSI mag es nicht, wenn man die Haltestellenwürfel mit der Count to Spline-Funktion setzt. Falls so ein ähnlicher Fehler bei jemanden auftreten sollte, muss man alle Haltestellenwürfel löschen und ohne die oben genannte Funktion neu setzen …

Wahrscheinlich lag damals der Fehler darin, dass ein Bus/Objekt nur einen Frame-Abschnitt haben kann. Deshalb wurde das Script nicht ausgeführt. AUXI bietet seit kurzer Zeit eine Variable an, über die man die Entfernung zur nächsten Haltestelle auslesen kann.

Zitat

One final change coming to AUXI 1.3, a last minute request, is the beginning of OMSI scripts being able to access some stuff in AUXI.

- AUXI
This variable just confirms whether AUXI is active, it's always set to 1 if it is.

[...]

- AUXI_Get_NextBusStopDistanceMeters
Gets a fairly precise distance to the next bus stop in meters, if available. If this isn't known then it will return -1.

Alles anzeigen

Vielen, vielen Dank! Ich war kurz vorm Verzweifeln …

So sieht die Kreuzung nun aus:

Die pinkfarbene Fläche ist das Deformationsmesh, das Texturierte ist die Kreuzung und das Graue ist die Fläche, die bewirkt, dass die Kreuzung in dem Abschnitt nicht mehr verschwindet.