Beiträge von wurstbrot

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!

    Das wäre auch eine Möglichkeit, vor allem wenn ich tatsächlich die Idee umsetzen würde die Aesys im MAN Stadtbus als die dortige LED-Ersatzvariante einzubauen, aber in friedlicher Koexistenz mit der FlipDot- und LCD-Variante die Setvar gesteuert sind. Bei der Idee stört mich aber noch dass dann zwei Matrix Scripte gleichzeitig laufen würden. Und die Flipdot gefällt mir da auch nicht, es wäre also so oder so komplizierter als es halt simpel zu lösen.

    Das wäre glaub ich in den meisten Fällen bei mir zu umständlich. Am schnellsten ist tatsächlich blanke Testmap und dann im Spiel eben neu laden.


    Bei der Gelegenheit: wie teste ich eine Straßenbahn? Da geht es auch ums Modell, da ich einen Matrix-Umbau vorhätte. Wie kriege ich denn die Bahn als Userfahrzeug am einfachsten auf eine Testmap oder von mir aus Grundorf? In die KI einbauen und warten bis sie kommt ist keine Option.

    Jetzt zicken die E6-(G)Ü doch wieder. Hab ich wohl nicht ausreichend überprüft. Hatte die Texttextures mit Kennzeichen aufgefüllt bis zur 37, aber das ruckelte beim Test auch sowohl beim Beschleunigen als auch beim Bremsen. Beim Rollen war es augenscheinlich okay. Hab dann die Kennzeichen-Einträge mit denen für Number getauscht, hat aber auch nix gebracht. Der "normale" E6-Ü läuft butterweich, hab direkt einen Vergleich gemacht.


    Hier der aktuelle Texttextures-Abschnitt:

    Sieht da jemand einen Fehler oder einen Grund für dieses Ruckeln?

    Aber das hier müsste doch auch ohne auslösen:

    Also wenn es nicht auch mit der Setvar verscriptet ist... WIe gesagt, die Matrix wurde angezeigt aber falsch beschrieben. Nur fand ich im Script bisher nixXD

    Ich komme ein wenig durcheinander wenn ich NICHT die Setvars in die Modeldatei einbaue, beispielsweise wenn ich nur eine Aesys-Variante verbaue und das nicht bräuchte. Immer wenn ich das Versuche wird zum Teil eine falsche Schriftgröße genommen.


    Also mal angenommen die CTI Datei enthält keine Setvars beim Repaint für die Matrix: damit sie funktioniert müsste es meinem Verständnis nach doch reichen den visible-Part in der Modeldatei auszulassen, oder? Kann es sein dass irgendwo im Script darauf auch zugegriffen wird?

    Moin!

    Bei so Dingen wie Einbau einer Matrix und das austüfteln deren Position frage ich mich ob es möglich ist OMSI im laufenden Betrieb dazu zu zwingen die neue Version eines Objekts zu laden? Um dann halt nicht dauern OMSI verlassen und neu laden zu müssen um Änderungen am Modell zu sehen. Irgendwie einen "Direct3D Lost" erzeugen oder sowas? Es würde eine Menge Zeit sparen, denn selbst Grundorf dauert ja einen Moment bis es geladen ist.

    Moin!

    Ich hatte beim C2 eigens für die KI spezielle Versionen erstellt mit reduzierten Details vor allem durch weglassen von unnötigem Kram. Gepaart war das ganze mit der K++ Matrix passend zu sen Spieler-Bussen und lief und läuft einwandfrei. Jetzt erstelle ich Versionen mit der DGM Matrix, und da gibt es bei den KI Varianten Probleme. Spielerversion ist top, auch im KI-Betrieb, die KI-Version spuckt aber haufenweise das aus:


    177 20:22:26 - - Error: Fehler bei Bereichsprüfung: CV.Calculate - J2 (Vehicles\MB_C2_EN_BVG\DGM_MB_C2_E5_Gn_main_KI.bus)


    Ausgehen dafür war meine K++ KI-Version, wo einfach nur die Matrix samt Scripten getauscht wurde. Ich versteh aber nicht wo ich nun nach dem Fehler suchen muss wo erstens die Spielerversion funktioniert und zweitens die K++ KI Version auch. Ich tippe auf was scriptiges und nicht was im Modell, aber wer weiss?

    Hab letztens beim C2 den Wert auch ändern müssen. Stanard war in meiner Vorlage auf "nur Zieltext", habe aber beim C2 die Kombination gebraucht. Und hat astrein geklappt durch Umstellen in der Const.


    Hier nun ein Beispiel für die unterschiedlichen Formatierungen vorne und hinten, so wie ich es haben wollte:

    Da ist die Seitenanzeige (und auch die hinten) noch etwas zu dunkel, das liegt aber glaub ich am Bus selbst.

    Wie hast du es mit den Textteturen gemacht?

    Wenn man da den Eintrag vom Tacho zuoft kopiert hat kamen solche Ruckler.

    Ich habe Display Text in dem Bus kopiert zum Auffüllen...


    [texttexture_enh]

    Display_Text

    C2_Display_Mx200

    480

    70

    0

    255

    255

    255

    1

    1


    Ist das der Tacho? Das würde ja irgendwie erkklären warum es in Bewegung ruckelt.

    Beim Einbau der DGM Matrix in den MX200 C2 E6 Ü ist mir aufgefallen dass dort die IVU Box irgendwie Probleme macht. Sie funktioniert augenscheinlich astrein, ind er Log hab ich auch keine Errors, aber mir fiel auf dass der Bus auf Grunddorf beim fahren extreme Ruckler verursacht. Im stehen alles okay, und wie gesagt keine Fehlermeldungen. Sein E5-Bruder (Standard 2 Türer) verhält sich hingegen einwandfrei. Warum ich da einen Zusammenhang mit der IVU Box sehe: ich hatte testweise die .bus Datei neu aufgesetzt um dort Fehler zu vermeiden und dabei vergessen die c2_main.osc auf die c2_main_ivu.osc zu leiten, hatte somit die Box funktional deaktiviert. Der Bus verhielt sich dabei normal, keine Ruckler. Jetzt bin ich etwas ratlos warum der E5er läuft und der hier sich derart eigenartig verhält. Ich hab ja schon in so manchen Bus die IVU eingebaut aber das ist mir nie irgendwo aufgefallen. Jemand ne Idee?

    Die Variable matrix_BoldMode steuert die Zieltext-Formatierung für die Zusätz *B und *K. Wenn du die Abschnitte für matrix_BoldMode=10 und matrix_BoldMode=11 bei den Font-Abschnitten für die 16er Höhe entfernst und die if-Abfrage für matrix_BoldMode=0 rausnimmst, passiert das auf der Seiten- und Heckmatrix nicht mehr, dafür aber auch nicht auf der Frontmatrix mit 16 Pixel Höhe.

    Ich kann das Prinzip anwenden, da ich die 16er nur an der Seite habe und vorne eine andere. Aber das brachte noch nicht das gewünschte Ergebnis: Die Höhe war nun gleich in beiden Zeilen, allerdings war die erste Zeile weiterhin fett und die zweite dünn. Ich hätte gerne wenn die Länge es zulässt beide in fett, unabhängig vom *B oder *K in der Hofdatei. Ich hoffe das geht ohne gleich das Script neu zu schreibenXD

    An den Schnittstellen kommst Du nicht drumherum die Straßen per Hand zu verbinden, sei es durch Splines oder Objekte. Fahrpläne und Tracks/Trips wirst Du zum Teil auch neu machen müssen weil dann etliche IDs nicht mehr stimmen werden. Außerdem wäre eine dermaßen große Karte vermutlich sowieso nicht alltagstauglich wegen schlechter Performance.


    Und ich wage mal zu bezweifeln dass gerade bei diesen drei Karten schön sauber mit Weltkoordinaten gearbeitet wurde. Ich denke dass da vermutlich so garnix zusammenpasst.