Beiträge von Lenn

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!

    Ich finde es schade, dass es keine Sounds mehr für die Konversationen gibt? Warum wurde das überhaupt entfernt? Haben sich zu viele Leute davon erschrocken oder was war da los?

    Dieses Plugin hat einfach nicht eine besonders hohe Priorität und wurde daher entfernt. Jedes Plugin weniger erleichtert das Update auf die neue Forensoftwareversion.

    Aber das hat Bamp im allerersten Beitrag hier doch bereits begründet ;)

    Du kannst es dir hier natürlich zurückwünschen, aber der Grund, warum es entfernt wurde, sollte eigentlich klar sein.

    Ja also du musst in irgendeiner Constfile (vorteilhaft wäre in der cockpit_constfile.txt) folgenden Eintrag machen:


    Code
    [const]
    single_front_door
    X

    Und für X irgendeinen entsprechenden Wert einsetzen. Ich weiß nicht, was da hinkommen muss, aber sobald dieser Eintrag existiert ist der Fehler jedenfalls weg.

    Doofe Frage, aber funktioniert der Bus denn sonst normal?


    Code
    168 10:27:09 -  -   Error:           Fehler: im Befehl "(C.L.single_front_door)" (vehicles\MB_O530_Rebus\\script\cockpit.osc) <SC_ErrorInCommand_constantinvalid>

    Du hast da eine Const, die in keiner Constfile eingetragen ist.

    Hallo,

    ich arbeite gerade an einem Matrixskript, welches neben FlipDot eben auch LED enthält. Per setvar kann man zwischen 19x126, 19x112 und 16x112 wechseln, aber bei 16x112 LED habe ich das Problem, dass auf der ST1 zu genau drei Zeilen zu wenig übertragen werden.


    Ich habs hier zur Verdeutlichung mal eingefärbt.


    Ich hab mich skriptmäßig an anderen LED Matrizen orientiert und das funktioniert auch super bei den 19-zeiligen Anzeigen.

    Bei 16x112 sieht der Bereich entsprechend so aus:

    Also hier wird erst geguckt, ob die Auflösung 16x112 (hier 2) ist und dann die normale Prozedur, dass ich vorne die Auflösungen in binär umwandle, die Stellen der 1 rückwärts und nullbasiert zähle, das dann 2^X nehme und dann meinen Makroaufruf reinmache. Dann dasselbe nochmal für Seite, bzw. Linie heck. Ich hab die ganzen Zahlen nochmals überprüft und da hat sich kein Fehler eingeschlichen.


    Ich glaube, dass die Problematik beim tatsächlichen Übertragen liegt.


    Code
    'X und Y berechnen:
    'l0: Ebene (vorne/Seite)
    'l1: X
    'l2: Y
    
                (L.L.Matrix_RefreshCursor) (L.L.Matrix_HxW) % (L.L.Matrix_Height) / trunc s1
                (L.L.Matrix_RefreshCursor) (L.L.Matrix_HxW) % (L.L.Matrix_Height) % s2

    Wenn man da mal für HxW und Height konkrete Werte einsetzt, verhält sich das natürlich alles etwas anders, weil die Ergebnisse dieser Berechnungen in den Registerplätzen 1 und 2 gespeichert werden, die dann beim STDrawRect aufgerufen werden.

    Code
    'Pixel zeichnen:
                1
                l1 (L.L.Matrix_PixelFactor) * s4
                l2 l0 (L.L.Matrix_Height) * + (L.L.Matrix_PixelFactor) * s5
                l4 (L.L.Matrix_PixelFactor) + 2 -
                l5 (L.L.Matrix_PixelFactor) + 2 -
                (M.V.STDrawRect)

    Der PixelFactor ist 8.


    Ich hoffe, jemand kennt sich damit gut aus und kann mir helfen :D


    Viele Grüße


    Moin,

    also das Problem hat sich jetzt gelöst.

    Der Fehler bestand beim Auslesen des aktuellen Pixels.


    Code
                        0
                        l1
                        l2 l0 19 * +
                        (M.V.STReadPixel)

    0 = Texturindex

    l1 = X

    l2 = Y

    l0 = Ebene (vorne/seite, hier Seite, also 1)


    Die Y-Koordinate wird ja wiefolgt berechnet:


    l2 + (l0*19)


    Mit eingesetzten Beispielwerten:


    4 + (1*19)


    Also 4+19, weil l0=1, wenn l0=0 (Front), dann wäre es ja +0, also würde er oben bleiben, und nicht um 19 Pixel nach unten verschieben.

    Weil ich jetzt hier eine 16-zeilige Anzeige habe und keine 19-zeilige, muss dort statt l0*19 eben l0*22 stehen, damit er schon drei Zeilen weiter unten anfängt, den Pixel auszulesen. Würde er weiter oben anfangen, macht er die letzten drei Zeilen nicht mit, weil ich dafür nicht genug Makroaufrufe pro Frame habe.

    Moin,

    also wegen des Problems mit dem Fahrscheindrucker: du könntest natürlich einerseits der Font ein Komma hinzufügen oder die halt tauschen.

    Die Font ist die RUHR_RBL.oft

    Die ist bei Texttexture 24 eingetragen im RUHR Solaris.


    Und damit die Linie angezeigt wird auf der Matrix musst im Matrix Skript alle Stringvariablen mit L.$.Matrix_Nr bzw. S.$.Matrix_Nr durch L.$.Matrix_Linie bzw. S.$.Matrix_Linie ersetzen.

    Ich denke mal, dass das ein Textfeld sein wird. Hast du einen entsprechenden [texttexture] Eintrag in die model.cfg übernommen? Und der Texttexture ist eine Stringvariable zugewiesen. Mit Programmen wie fnr kannst du (falls es nicht offensichtlich ist, welches Skript es ist) im Skriptordner in allen Dateien gleichzeitig nach (S.$.<Die Variable von dem texttexture Eintrag>) suchen und dann gucken, wo das gesetzt wird. Die Datei, in der das gefunden wird, ist dann dein benötigtes Skript.

    Aber mit einer Kreuzung spart man Faces. Ein Spline, der einen Radius > 0 bzw. < 0 hat, werden in Omsi überflüssig viele Faces generiert. Von daher ist eine Kreuzung eigentlich performanter. Sieht man mMn auch auf Hamburg ganz gut, weil da ja auch so gearbeitet wurde. Ein PC lädt lieber ein größeres Objekt, als ganz viele Faces von einem einzigen Splinestück.