Beiträge von DerGrafikfehler

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!

    Kommt auch stark auf die Einstellungen an, bei mir ist eigentlich immer nicht gerade wenig los. Kommt selten vor, dass ich mal an einer Haltestelle durchfahren kann.


    Selbst wenn die Anzahl der Personen voll hochgedreht ist: Lufttransporte im 15-Minutentakt gibt es immer wieder mal, wenn auch seltener im Regionalverkehr.

    Mit eingebautem Hintergrund kann man den Text auch mit [useScriptTexture] gut lesen: (verschobene Liniennummer und Ziel bitte ignorieren)




    mach mal STNewTex, STLock, STLoadTex und dann STUnlock. dann kurz fahren oder nen speichern erzwingen und die entsprechende scripttextur im mapordner prüfen. wenn sie dort korrekt dargestellt wird, sollte es rein technisch funktionieren

    Das war meine ursprüngliche Methodik, auf der Scripttextur passt alles. Sowas ähnliches habe ich in einer der allerersten Script-Versionen vor drei Jahren auch beobachtet: Da habe ich die UI auf ein eigenes Plane mit Freetex gelegt, aber auch dort nur die tatsächlich aktiven Pixel drauf gehabt. Hat den gleichen Effekt wie oben gehabt, nur noch schlimmer. Aus der Distanz wie am Screenshot waren die UI-Elemente gar nicht mehr erkennbar.


    Also bei mir funktioniert es nur zur Hälfte. Ich habe es mit einer .tga ausprobiert, dort wird alles genauso übernommen, auch die Transparenzen. Was jedoch Probleme macht, ist das Schreiben mit Text darauf. Dort wird einfach der neue Alpha-Wert auf die Skripttextur geschrieben, ohne dass der darunterliegende Pixel beachtet wird. Gibt es dafür auch eine Lösung? Falls das nicht zu verstehen war, hier mal ein Ausschnitt:

    das ist tatsächlich eine Einschränkung, die sich so einfach nicht beheben lässt - zumindest ist mir da kein Weg bekannt, der sich performancetechnisch relativieren lässt. schreibst du mit einer alpha auf die vorhandene textur, wird diese ja auch entsprechend übernommen. im script könntest du aber beispielsweise einen großen Rahmen in Weiß auf den Alphakanal der Scripttextur zeichnen, um die transparenzen zu entfernen - dann hast du allerdings einen Rahmen um die einzelnen Buchstaben. Hier hilft nur, den Background des Fonts an den Hintergrund des Displays anzupassen und gegebenenfalls durch verschiedene Fonts durchzuschalten, je nach Hintergrundfarbe.


    Rein technisch gäbe es auch dafür eine Lösung: Zwei Scripttexturen. Dazu erstellt man zwei Scripttexturen gleicher Größe und nutzt wie bei den VMatrizen einen "Pixelcursor", um Pixel für Pixel von der einen Textur in die andere zu übertragen.
    Ist die Ausgabe von STReadPixel an Position X/Y in den RGB Werten kleiner als 50, wird der Pixel ignoriert, ist er größer als 50 (oder ein beliebiger selbst definierter Schwellenwert) wird der Pixel von der einen auf die andere Scripttextur übertragen.

    Den gleichen Effekt erzielst du, indem du die Font-Bitmap aufmachst, den Kontrast-Regler voll aufdrehst und mit dem Helligkeits-Regler etwas nachjustierst. Erzielt den gleichen Effekt, aber ohne Rechenaufwand und Script-Dschungel auf Omsi-Seite.

    Das gesamte Display mit ein- und ausgeschalteten Pixeln auf die Scripttextur zu holen habe ich tatsächlich noch nicht probiert, das schaue ich mir mal an.

    Mir erschließt sich trotzdem nicht ganz, wieso die Scripttextur selber als Textur verwenden ein anderes Ergebnis liefert als selbige Scripttextur für eine gleichfarbige "normale" Textur zu verwenden. Gefiltert ist alles.

    dann zuallererst deine hintergrund-bitmap in die scripttextur laden, dann deinen text drauf addieren

    Funktioniert das überhaupt? Das habe ich vor einigen Jahren schon mal probiert, aber mit keinen sinnvollen Ergebnissen.

    Zweieinhalb Jahre später muss ich mich doch korrigieren. Es sollte mit Scripttexturen möglich sein. Dafür musst du anstelle von [matl_transmap] den Befehl [useScripTexture] verwenden. Der Befehl macht das gleiche wie [useTextTexture], allerdings mit Scripttexturen. Die Handhabe ist ebenfalls identisch:


    Damit wird die Textur des Materials durch die Scripttextur ersetzt, statt als Alpha-Maske verwendet zu werden. Die auf der Scripttextur verwendeten Farben werden somit auch angezeigt. Wie das mit Piktogrammen aussieht, habe ich nicht getestet. STTextOut hat jedenfalls die Möglichkeit, zwischen Font-Farbe und Vollfarbe zu unterscheiden und das funktioniert auch.


    ABER:

    Diese Konstellation ist nur bei dunkler Schrift auf hellem Hintergrund sinnvoll verwendbar. Es scheint hierbei Probleme bei der Darstellung zu kommen, wodurch helle Schrift auf dunklem Hintergrund nur sehr schwer erkennbar ist:


    Links ist mit [useScriptTexture], rechts mit [matl_transmap]


    Bei dunkler Schrift auf hellem Hintergrund ist der Unterschied zwar auch vorhanden, aber wesentlich weniger extrem:

    Das Ding war auf der Gamescom ausgestellt, Preis soll anscheinend bei um die 380€ liegen. Die Idee eines solchen Simulator-fokussierten Lenkrades ist sicher sehr gut, insbesondere mit den Lenkstockschaltern. Aber für den Preis... Da werden wohl viele bei Logitech bleiben.

    aber wenn ich eins weiß, dann ist es das, das der A47 vom A21 abstammt und lediglich nur gekürzt wurde um auf seine 10m zu passen.

    Ist zwar reine Erbsenzählerei, aber...

    Der A47 hat einen stehenden Motor und baut daher auf dem A37 auf. Eine 10m-Version des A21 gab es als solches nie, Göppel hat aber einige CNG-Midis gebaut, die zumindest auf dem A21 basieren. Die findet man mit ganz viel Glück als MAN A22 CNG, fahren/fuhren unter anderem in Uppsala.

    Es scheint tatsächlich so zu sein, dass Toshiba spezielle Controller-Boards für Festplatten herstellt, die die typische USB-SATA-Brücke gleich komplett umgehen und die Festplatte selber mit einem USB-Anschluss ausstatten. Das habe ich in der Form auch noch nie gesehen oder gehört... :/


    Nachdem ich die Platte auf die Schnelle nur mit Micro-USB auf Festplatten-Seite gesehen habe: wenn die den Anschluss hat, probiere mal ein normales Micro-USB 2.0 Kabel. Die Platte wird (oder zumindest sollte) damit auch funktionieren, aber halt merkbar langsamer. Vielleicht hilft das auch in Sachen Stabilität. Habe selber zwei Micro-USB 3.0 Adapter da und die sind beide sehr zickig, wenn man die mit einem USB 3.0-Kabel betreibt. Der eine wird so gleich gar nicht erkannt.

    Hatte dafür letztens auch einen Adapter gekauft, allerdings hat der PC die Platte dann gar nicht mehr erkannt.

    Sata-> USB oder USB-C -> USB-A?

    Die Festplatte selber ist an sich nichts anderes als eine 2.5"-Laptop-HDD, die einen einfachen SATA-Anschluss besitzt. Du kannst also einfach das Gehäuse öffnen, die Festplatte ausbauen und entweder direkt an dein Mainboard anschließen (Strom nicht vergessen!) oder über einen anderen USB-Sata-Adapter verbinden. Fallweise könnte das helfen.


    Sollte das keine Abhilfe schaffen, muss die Platte auf jeden Fall von einem Reparaturlabor geklont werden. Das kostet zwar eine riesige Stange Geld, wäre aber die letzte Lösung.

    Wenn du den für die Fonts den Linux-Style beibehalten willst, kann ich dir DejVu Sans Mono in Fett als Omsi-Font anbieten. Die habe ich für ein anderes Projekt schon realisiert.


    Zu den Sonderansagen: Mach die dynamisch und Hof-gebunden. Das ist meiner Ansicht nach die einfachste Methode, die einfach flexibel mit dynamischen Anzeigetexten zu bekommen. Siehe z.B. IBISController und mein ICU.

    Das Problem ist auf dem Discord von Sobol vor einiger Zeit im Detail diskutiert worden und ich habe es mit deinem C2 schon selber erlebt. Das Problem liegt ziemlich sicher an der Gesamtgröße der Scripts im Bus. Es gibt zwar an sich kein wirkliches Limit für die Größe der Scripts, aber ab einem bestimmten Punkt fängt Omsi an, ein solches Verhalten zu zeigen. Ich gehe ganz stark davon aus, dass der größte Übeltäter das riesige Script vom Atron ist. Wenn ich den durch ein anderes IBIS oder einen anderen Drucker ersetze, dessen Script kleiner ist, habe ich keine Probleme mehr.


    Schau da bitte nach, was du da alles kürzen kannst im Script. Gerade im Part zum Wechseln des Atron-Modells mit 340 Zeilen mit solchen ifs:

    Code
        (L.L.atron_ticketpad_Tickets_erweitert_1) 1 =
        {if}
        1 (S.L.atron_ticketpad_Tickets_erweitert_1_N)
        {else}
        0 (S.L.atron_ticketpad_Tickets_erweitert_1_N)
        {endif}

    die sich (fast) alle auch einfach so anschreiben lassen:

    Code
    (L.L.atron_ticketpad_Tickets_erweitert_1) (S.L.atron_ticketpad_Tickets_erweitert_1_N)

    gibt es einiges an Optimierungs-Potenzial, mit dem das Script auch wesentlich kleiner wird.



    Auch das Macro CharToCapital, das man auf die letzten vier Abfragen kürzen kann, weil der Rest nichts macht und ähnliche solche Script-Abfragen lassen sich sehr schön in der Größe optimieren. Ähnlich schaut es bei vielen anderen String-Abfragen aus.