Beiträge von Neoplan VEST

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!

    Der MAN Lions Intercity LE (und auch der New Lions City) haben diesen Eintrag


    Im Ordner Script gibt es die Datei "_NLC_Konfig.txt" und darin wird bei "NLC_Lenkrad_Lenkwinkel" der Lenkwinkel angepasst.


    Hier ist der Lenkwinkel als 820 nach Links (-820) und nach rechts (820) angegeben.


    Dies hat man so gemacht, weil der Eintrag "[inv_min_turnradius]" auch einen Beitrag zur Lenkwinkel beiträgt. Hätte man also diese Übersetzung im Script nicht, so müsste man mehrere Umdrehung am Lenkrad machen um die Räder voll einzuschlagen.

    Tut man allerdings den Wert unter [inv_min_turnradius] verändern, wäre das Fahrzeug nicht so wendig, aber dafür weniger Lenkeinschlag.

    Die gibt es so gesehen:

    "Inputs\keyboard.cfg"

    Dort werden die Tastaturbelegungen gespeichert.


    Für "KY_Bus_dooraft" gibt es zudem eine Übersetzung für den Optioneintrag.

    Anstelle von "KY_Bus_dooraft" wird es als "Haltestellenbremse & Türfreigabe ein/aus" angezeigt.

    Diese Übersetzung findet man im Ordner "Languages\DEU_key_veh_gen.olf"

    Also Standardmäßig ist der Minus auf dem Zehnertastatur für Türfreigabe und der "Rollen" Taste (Zwischen Druck und Pause Taste) die Haltestellenbremse ohne Türfreigabe.


    Haltestellenbremse ohne Türfreigabe wäre das Event in der Option "KY_bus_20h-switch" bzw. kann es auch als als "Haltestellenbremse (ohne Türfreigabe) ein/aus" aufgelistet sein.

    Bei Türfreigabe wäre es dieser:

    "KY_bus_dooraft" "Haltestellenbremse & Türfreigabe ein/aus"

    Code
        "BROSE_F9" (M.V.GetFontIndex) (S.L.Font_7x4)
        "BROSE_F7" (M.V.GetFontIndex) (S.L.Font_7x4a)
        "BROSE_F6" (M.V.GetFontIndex) (S.L.Font_7x6)
        "BROSE_F6" (M.V.GetFontIndex) (S.L.Font_7x6a)
        "BROSE_F5" (M.V.GetFontIndex) (S.L.Font_11x5)
        "BROSE_F5" (M.V.GetFontIndex) (S.L.Font_11x6)
        "BROSE_F4" (M.V.GetFontIndex) (S.L.Font_16x7)
        "BROSE_F3" (M.V.GetFontIndex) (S.L.Font_16x7a)
        "BROSE_F2" (M.V.GetFontIndex) (S.L.Font_16x7b)
        "BROSE_F1" (M.V.GetFontIndex) (S.L.Font_16x9)

    Da hast Du einen Fehler drin:

    Code
        "BROSE_F0" (M.V.GetFontIndex) (S.L.Font_7x4)
        "BROSE_F1" (M.V.GetFontIndex) (S.L.Font_7x4a)
        "BROSE_F2" (M.V.GetFontIndex) (S.L.Font_7x6)
        "BROSE_F3" (M.V.GetFontIndex) (S.L.Font_7x6a)
        "BROSE_F4" (M.V.GetFontIndex) (S.L.Font_11x5)
        "BROSE_F5" (M.V.GetFontIndex) (S.L.Font_11x6)
        "BROSE_F6" (M.V.GetFontIndex) (S.L.Font_16x7)
        "BROSE_F7" (M.V.GetFontIndex) (S.L.Font_16x7a)
        BROSE_F8"" (M.V.GetFontIndex) (S.L.Font_16x7b)
        "BROSE_F9" (M.V.GetFontIndex) (S.L.Font_16x9)

    Bei Font_16x7b hast Du den Fontname falsch platziert.

    So musst es aussehen:

    Code
    "BROSE_F8" (M.V.GetFontIndex) (S.L.Font_16x7b)


    Außerdem scheinen bei dir die Eintragsnamen nicht ganz zu passen weil "BROSE_F7" eine 7x4 Schrift ist und keine 16x7a.

    So wäre es korrekt:

    Code
        "BROSE_F7" (M.V.GetFontIndex) (S.L.Font_7x4)
        "BROSE_F7" (M.V.GetFontIndex) (S.L.Font_7x4a)


    Zudem ist das Script nicht ganz optimal für die Brose Matrix wenn es speziell um Buchstaben wie j, g, y geht.

    Die werden ab den 16. Zeile nicht mehr dargestellt.

    Offiziell würden BROSE Anzeigen zu ein nächst kleineren Font wechseln.

    Bei Lawo in der Realität nicht. Der zentriert höchstens nur und das warst.

    Es können 3 Möglichkeiten geben:

    1.) Über Font Datei was zum Beispiel für Haltestellenschilder verwendet werden wegen Farbige Logos.

    2.) Über Scripttexturen

    3.) In der Model Konfiguration in der [texttexture] / [texttexture_enh] Eintrag.


    Letzteres kann der Eintrag so aussehen:


    Es wäre aber gut zu Wissen, ob das Bildschirm nachträglich eingebaut wurde und wenn ja, aus welcher Fahrzeug.

    Der TFT aus dem C2 Stadtbus Familie verwendet die Schriftfarbe aus dem Font.

    Weil das "Blockieren" errechnet werden musst.


    Dies geschieht in der Regel über {macro:DoorX_Calc}

    X = Türindex 0, 1, 2, 3 etc.


    Am besten Du schaust dir das mal im Türscript von einem Fahrzeug an der diese Funktion hat.

    Einfach den Eintragsnamen aus der Constfile nehmen und danach im Script suchen.


    Bin bis jetzt noch nicht dazugekommen dies selber nachzutragen.

    Schon mal dran gedacht, dass auch die Eintragsnamen im Türscript vorhanden sein müssen?

    Es bringt nix wenn Du die Werte einfügst wenn im Script nicht definiert wurde, was genau dieser Wert machen soll.


    Ich selber müsste das ganze erstmal ausprobieren um überhaupt schreiben zu können, an welche Stellen die ganzen Sachen stehen müssen.

    Das modellieren der Taster ist das kleinere Übel.

    Falsch, das ist das tatsächliche Problem. Da der Schalthebel bzw. die Manschette fest mit dem Dashboard verbunden ist, kannst du den nicht entfernen, ohne die originalen Modelldateien zu verändern und neu hochzuladen. Das ist nicht gestattet, also kannst du nur nen Automatikbus mit sichtbarem Schalthebel bauen. Das verdirbt mir z.B. komplett den Spaß daran, weswegen ich da auch nichts unternehme.

    Okay, das dieser mit andere Objekte zusammen hängt war es mir nicht bekannt.

    Das ist dann ein Riesen Manko.

    Dann müsste man neben den Taster auch noch einen neuen Dashboard bauen.


    Ich persönlich denke, dass ihn so wenige nur fahren, eben weil die Automatik-Variante fehlt....

    Das wird auch eines der Hauptgrund sein.

    Wenn ich noch richtig in Erinnerung habe, hat er zudem Problem mit der Kollision.

    Möglich ist es.

    Gar keine Frage.

    Aber Scripten und Sounds nehmen Zeit in Anspruch und dazu zählt auch, dass die Möglichkeit Sounds aufzunehmen besteht.

    Das modellieren der Taster ist das kleinere Übel.

    und wenn wir mal Ehrlich sind:

    In OMSI kann man die Lautstärke vom Radio nicht regulieren.

    Zumindest ist mir seit 2011 nicht bekannt das es möglich wäre 🤣


    Ich persönlich mag auch eher das "Heimische" Radiogerät als das im Spiel.

    Je nach Lied kann man mal leiser oder mal lauter zur Ärgernis der Nachbarn drehen.

    Und dank des FM/DAB Radio auch ohne Internet nutzbar.

    Matrix kaputt oder nicht vorhanden, oder kann nicht programmiert werden weil ein Eingabegerät fehlt.

    Oder manche wollen einfach keine Programmierung haben weil man dafür Geld ausgeben muss.

    Da kenne ich persönlich ein Betrieb wo ich den Vorfall hatte.

    Programmierung haben wollen, aber dafür nicht bezahlen und da rede ich nicht mal eben von 4-5 Zielen.


    Aber manchmal wollen die auch einfach keine Programmierung weil es nicht notwendig ist.

    Wenn das Fahrzeug nur Schulbus fährt, wird meistens ein Schulbus Schild angebracht und das warst.

    Eventuell noch Zettel hinter der Scheibe mit der Linie.


    Auch kann es einen Grund sein, dass vielleicht ein Ziel vom vorherigen Besitzer noch geschildert ist wie Schulbus, Firmenname etc. das es deswegen überklebt wird um Verwirrung zu vermeiden.


    Die Leute fragen ja eh noch 100 mal nach

    Ich sag mal so.

    Ob jetzt eine funktionierende Beschilderung oder mit Folie, einige Fragen so oder so nach.

    Es ist am Ende besser eine Folierung zu machen als gar keine Kennzeichnung und wesentlich besser als der Zettelwirtschaft in der Frontscheibe.


    Über die Folierung könnte man noch die Contra's und Pro's aufzählen :P


    Pro:

    - Kaum Wartungskosten, da bei Digitale Anzeigen mal ausfallen kann und repariert/ausgetauscht werden muss.

    - Gemäß BOKraft §33 Punkt 2 kann auf der Folierung den Streckenverlauf besser dargestellt werden als auf die digitale Anzeigetechnologie je nach Auflösung.


    Contra:

    - Musst für jeden Einsatz neu gedruckt werden.

    - Für den Umwelt nicht ganz optimal.

    - Für kurze Einsatztage nicht Sinnvoll

    Liegst völlig richtig.


    Code
    [mesh]
    Airpods.o3d
    
    
    [illumination_interior]
    1
    2
    3
    -1

    Wichtig ist halt das der Airpod auch richtig in Blender positioniert ist an den entsprechende Stelle die es im Fahrzeug befinden soll.

    Wenn Du den Eintrag mit deiner jetzigen vorhandenen Eintrag überschreiben tust sollte es weiterhin funktionieren.


    Edit:

    Die Variable "vis_front_door_separate" muss noch in der Varlist eingefügt werden.


    Wobei die Trigger "trg_bus_doorfront0_ext" und "trg_bus_doorfront1_ext" unbekannt ist.

    Müsste wenn ich richtig verfolge im Halbschlaf gegen trg_bus_doorfront0 und trg_bus_doorfront1 ausgetauscht werden.