Beiträge von Darius

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.

    Schaut doch mal ins Handbuch im Ordner Addons im OMSI2-Ordner (standardmäßig C:\Program Files (x86)\Steam\SteamApps\common\OMSI 2).
    Dort wird die Bedienung des Fahrscheindruckers erklärt.

    Moin, hier die Änderungen der aktuellen Version 3.1:


    - Lücke im Asphalt Alsterdorfer Str. korrigiert
    - Fehlende Textur Alsterchaussee ergänzt
    - KI-Verkehr in vielen Bereich optimiert
    - Darstellungsfehler auf Schriftfeldern korrigiert
    - Fehlende Ansage Hbf. ZOB "Fahrtende" ergänzt
    - Stadtrundfahrt-KI fährt wieder problemlos
    - Fehlende Regenreflektionen auf Asphalt ergänzt
    - Ansage Bf. Altona kommt nicht mehr doppelt
    - Einige Objekte und Hilfspfeile korrigiert
    - Fehlerhafte Umläufe der 109 korrigiert
    - Zielcodelisten werden immer angezeigt
    - Verbesserung der Ampeln und Verkehrspfade Stephansplatz/Gänsemarkt
    - Bremsverhalten KI-PKW angepasst

    Eigentlich sollte seit dem ersten Update nur noch der linke Spiegel in der Fahrersicht sichtbar sein und gerendert werden. Oder habt ihr extrem kuriose Bildschirmauflösungen? Falls ihr den Innenspiegel in der Fahrersicht seht, ist der Patch wohl nicht installiert.


    Wenn im Doppelgelenkbus keine Ansagen kommen, im Solo hingegegen schon, evtl. mal die Soundanzahl höher stellen. Die verwenden ja das gleiche Druckerskript.


    Zum Fahrkomfort mit Ecomat auf Euro 3 sage ich mal nichts

    ;)

    In den Grafikoptionen kann man unter Stencil Buffer die Schatten deaktivieren.


    Michael: Bitte lies auch meine Antworten, damit ich nicht alles mehrfach erklären muss: Der Spiegel wird nur gerendert, wenn er im Sichtfeld ist. Also wenn ihr in der Fahrersicht geradeaus fahrt, nur der linke Außenspiegel.
    Die Spiegel auszukommentieren, ist übrigens überflüssig, da man diese in den OMSI-Optionen auf ökonomisch oder komplett aus stellen kann.



    Bei den Stringabfragen der Hofdatei. Da ist wieder das übliche Chaos drin. Blöderweise fragt Omsi aber die anderen Strings mit ab und erstellt dann die richtige Anzeige. Also auch auf der Hamburger Map mit der Hamburger Hofdatei, werden blöderweise die Strings 1-4 abgefragt. Bei dem Van Hool hast du scheinbar auf den letzten String verzichtet, weil hier nur die Strings 0-3 oder (auf Fremd-Maps) 1-3 abgefragt werden.


    Deine Ausführungen verstehe ich nicht, da sie technisch nicht nachvollziehbar sind. Die Abfragen im Matrixskript sind in if-Schleifen gestaffelt, sodass die jeweils nicht zutreffenden Inhalte nicht abgefragt werden. So wird z.B. erst geprüft, ob es sich um Hamburg handelt, dann, ob Großschrift eingetragen ist. Ist dies nicht der Fall, werden die folgenden Schritte übersprungen.


    Zur Performance von Skripten hatte ich ja bereits einiges geschrieben. Diese sind im Gegensatz zu Systemmakros und Texttexturen unkritisch. Problematisch sind also z.B. aufwendige moderne Cockpits mit Touchscreen-Druckern, VDV-Display usw., da deren funktionsfähige Umsetzung nicht so effektiv möglich ist, wie z.B. ein alter Bus mit Analoganzeigen. Grund ist hierfür u.a. die Anzahl der zu aktualisierenden Texttexturen und die Komplexität der model.cfg.


    Beispiel Haltestellenbremse: Wieso muß im Script 7 mal abgefragt werden, ob das Gaspedal betätigt wurde, um die Haltestellenbremse zu lösen? Wenn ich die Gaspedalstellung 6 mal rauslösche, dann muß immernoch das Gaspedal betätigt werden um die Haltestellenbremse zu lösen. Und hier gibt es keine Abfrage der Hofdatei.


    Bei der Hofdatei ging es auch nur um Matrix/Drucker

    ;)

    Und da macht die Abfrage natürlich Sinn, da die Anzeigen unterschiedlich formatiert werden.
    Das Beispiel verstehe ich allerdings nicht ganz. Die Abfrage des Throttle im door.osc ist in allen Zeilen auskommentiert und im Bremse existiert es nur 1 mal.


    Morphi: Ich weiß es ehrlichgesagt nicht genau mit dem Heizungssymbol. Platz wäre ja da. P/N hat er aber definitiv nicht.


    Make sure it's a .dds texture with alpha channel for transparency. There is no texture change for decals set up yet though, so you will have to add this to each model.cfg or replace the original .dds.

    Die String-Erklärungen in der Hofdatei beziehen sich nur auf Hamburg. Für andere Maps, dies erkennt der Drucker am Name der Hofdatei, verwendet die Matrix eine einfache Logik, damit alle normalen OMSI-Hofdateien funktionieren. Dies gab es übrigens schon in der allerersten OMSI1-Version von Hamburg.


    Wenn man jetzt schnell eine andere Hofdatei mit z.B. Großschrift bauen will, könnte man diese "Hamburg (HHA)" nennen (oben in der Hofdatei unter name eintragen). Dann muss man keine Drucker-/Matrixskripte ändern.


    Zum Performance- und Physikproblem gibt es noch heute einen Patch.

    Das ist ja kurios.


    Ich möchte mich noch zu dem "Gerücht" äußern, dass das Skript des Fahrscheindruckers performancefressend wäre. Jeder, der etwas von OMSI-Skripts versteht, weiß, dass Skripte absolut performance-unkritisch sind. Das lässt sich auch einfach testen, indem man im Main-Skript den Makroaufruf für Fahrscheindrucker etc. auskommentiert, man wird nicht ein einziges FPS mehr erhalten. Was Performance kostet, sind Systemmakros, die auf die Hofdatei oder Tickets zugreifen. Diese werden aber im Drucker nur so oft wie nötig (Tickets z.B. nur einmalig beim Start) aufgerufen. Genauso gibt es z.B. für die Matrix einen Timer, sodass diese nicht in jedem Frame aktualisieren muss, sonst würde OMSI einfrieren, sobald man den Bus im KI-Verkehr einsetzt.


    Kritisch für die Performance sind hingegen Texttexturen, diese werden z.B. für Displays mit Texten, das VDV-Display, die Verspätungsanzeige usw. benötigt. Im Vergleich zum C2 wurde hier massiv eingespart, auch die Textur des Druckers wird nun nicht mehr über die teure Funktion matl_freetex, sondern einzelne Meshes mit fixen Texturen geregelt. Ebenfalls kritisch sind Spiegel mit Reflektionstexturen. Daher würde ich jedem empfehlen, die Echtzeitreflektionen auf eine geringe Auflösung und "ökonomisch" zu stellen! Desweiteren ist es sinnvoll, den KI-Verkehr (Busse und PKW) zu reduzieren.

    Das Problem mit der letzten Tür ist bekannt, allerdings hatte ich dies bisher wohl nur für den Ausstieg behoben. Das wird im ersten Update berücksichtigt werden.


    Eine Tankanzeige hatte ich aus Performancegründen nicht umgesetzt, die ist im Original auf der 3. Seite im Infodisplay.


    Wenn Fahrgäste trotz genügend Platz nicht einsteigen, bist du vielleicht am Haltestellenwürfel vorbei?