Beiträge von wurstbrot

Hallo!

Ich möchte die Trigger für das Ziel-Rollband vereinheitlichen, da ich für Rollband-Busse nicht zwei unterschiedliche Geräte gleichen Namens in den Inputs haben möchte. Fürs Zielrollband nutze ich die Saitek-Konsole, und wie bei Lenkrädern kann man nicht zwei Trigger auf eine Taste legen wie bei der Tastatur, und auch möchte ich vermeiden irgendwelche Umleitungssoftware des Signale zu nutzen. Anderen ist vielleicht das Problem bekannt durch die Vielzahl an Kneeling-Triggern, hier geht es ums Rollband.

In OMSI hat man prinzipiell hier zwei verschiedene Trigger:

bus_rollband_up_step und bus_rollband_dn_step wie beim SD77

und

bus_rollband_up und bus_rollband_dn wie bei O307

Letztere Variante ist die, die ich gerne universal verwenden möchte, auch beim SD77-Typ, da sie auch bei den Liniennummern zum Einsatz kommt.

Also hab ich im SD77 Rollband.-Skript folgendes modifiziert:

{trigger:bus_rollband_up}
    (L.L.rlbnd_activekurbel) 1 =
    {if}
        (L.L.rlbnd_ln1) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln1)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 2 =
    {if}
        (L.L.rlbnd_ln2) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln2)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 3 =
    {if}
        (L.L.rlbnd_ln3) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln3)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {endif}
    {endif}
    {endif}
{end}

{trigger:bus_rollband_dn}
    (L.L.rlbnd_activekurbel) 1 =
    {if}
        (L.L.rlbnd_ln1) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln1)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 2 =
    {if}
        (L.L.rlbnd_ln2) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln2)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 3 =
    {if}
        (L.L.rlbnd_ln3) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln3)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {endif}
    {endif}
    {endif}
{end}

{trigger:bus_rollband_up}
    (L.L.rlbnd_activekurbel) 1 =
    {if}
        (L.L.rlbnd_ln1) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln1)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 2 =
    {if}
        (L.L.rlbnd_ln2) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln2)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 3 =
    {if}
        (L.L.rlbnd_ln3) (L.S.timegap) 1 / + 0 max 15 min (S.L.rlbnd_ln3)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 4 =
    {if}
        1 (S.L.rlbnd_auf_pressed) 
        (T.L.rlbnd_taste_ein)
    {else}
    (L.L.rlbnd_activekurbel) 4 =
    {if}
        0 (S.L.rlbnd_auf_pressed) 
        (T.L.rlbnd_taste_aus)
    {endif}
    {endif}
    {endif}
    {endif}
    {endif}
{end}

{trigger:bus_rollband_dn}
    (L.L.rlbnd_activekurbel) 1 =
    {if}
        (L.L.rlbnd_ln1) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln1)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 2 =
    {if}
        (L.L.rlbnd_ln2) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln2)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 3 =
    {if}
        (L.L.rlbnd_ln3) (L.S.timegap) 1 / - 0 max 15 min (S.L.rlbnd_ln3)
        (M.L.rollband_actu)
        (M.L.rollband_refresh_setLineTo)
    {else}
    (L.L.rlbnd_activekurbel) 4 =
    {if}
        1 (S.L.rlbnd_ab_pressed) 
        (T.L.rlbnd_taste_ein)
    {else}
    (L.L.rlbnd_activekurbel) 4 =
    {if}
        0 (S.L.rlbnd_ab_pressed)
        (T.L.rlbnd_taste_aus)
    {endif}
    {endif}
    {endif}
    {endif}
    {endif}
{end}

Ergebnis ist aber nicht zufriedenstellend, denn nach Betätigung der Taste rollt das Band dann durch, da die Taste im Bus am Steuergerät durchgedrückt wird. Es sollte sich aber so verhalten wie beim bus_rollband_dn_step und bus_rollband_up_step Trigger. Dort klappt es nämlich dass beim einmaligen Drücken der Taste das Band nur eine Position weiter rollt und beim gedrückt halten so lange rollt wie man gedrückt hält.

Was stimmt also in meiner Modifikation nicht?

Zitat von Lion's Coach - Fan

In der envir.cfg gibt es ein Schlüsselwort, was regelt wann die Dämmerung startet bzw. endet. [twilight_start_end] heißt das. Eventuell könnte dort das Problem liegen. Bei mir habe ich da die Werte -7 und 7 als ganz passend herausgefunden, allerdings nutze ich selbst erstellte Himmel-Texturen. Da müsstest du mal ein bisschen herumprobieren was gute Werte für dich sind.

Ich habs mal ausprobiert mit einem Test-Save von vor paar Tagen. Es ist tatsächlich mit -7 und 7 viel besser, es wirkt aber für mich wie ein Turbo-Sonnenauf- oder Untergang. Zum Beispiel um 21 Uhr ist es noch Mittelhell, 15 Min später aber zappenduster. Beim Sonnenaufgang kurz nach 5 ähnlich. Das würde ich dann doch ein wenig glätten, aber ist schon mal deutlich realer. Also vielen Dank!

Bei mir ist das so:

    Setzt die Texturen des Himmels, erst Tag, dann Dämmerung, dann Nacht:

[sky_textures]
Texture\skybox\day01.bmp
Texture\skybox\sunset01.bmp
Texture\skybox\night01.bmp


    Setzt Start und Ende der Dämmerung als Höhenwinkel. Höhepunkt (letzte obige Textur
    wird zu 100% dargstellt) ist dabei dann, wenn die Sonne gerade aufgeht (Höhenwinkel = 0).
    Aus diesem Grunde muss der erste Wert kleiner Null, der zweite größer Null sein.

[twilight_start_end]
-18
10

Da es aber wohl wie im Text steht Winkel sind sagt mir das so garnichts;-D Ich werde es aber mal mit -7 und 7 versuchen.

Ich vermute mal das regelt dann wann die 3 obigen Texturen sich überblenden, nur sagen mir die Werte garnix. Aber Uhrzeiten wären da ja auch nicht angebracht aufgrund unterschiedlicher Koordinaten.

Hab gestern gesehen dass im Code die Koordinaten gefehlt haben. Komisch, war ja Original-Spandau... Also hab ich die eingetragen und fand es dann noch schlimmer;-D Gegen Mitternacht okay, aber schon gegen 2:30 fängt es an heller zu werden. Tiefe Nacht also etwa nur 23-2 Uhr doch ein wenig kurz...

Jetzt vielleicht checken ob die entsprechende Sky Textur vielleicht zu hell ist. Das wäre zumindest eine Idee. Es ist die vom Enviroment Pack, tagsüber find ich die ja gut. Es macht aber auch einen Unterschied ob ich OMSI das Wetter herunterladen lasse oder AUXI. AUXI ist da Nachts einen Tick heller als wenn das aus ist, ein großer Unterschied ist es aber nicht und löst das grundsätzliche Problem nicht.

genau, ich fahre Mai 1990 und habe da folgendes:

[DST]
19900325
19900930
2
3
1

Die Datei mit den Zeitumstellungen enthält die korrekten Daten für Sommer/Winterzeit... Hmm...

Zwischenstand:

Einerseits war für den hellen Himmel AUXI verantwortlich, dessen Wetterfunktion da tatsächlich einen helleren Himmel geladen hat, andererseits aber auch die envir-Datei des Enviroment Packs. Beides abzuschalten bzw. auf default zu stellen brachte eine Verbesserung. Schade, denn tagsüber fand ich die Farbeinstellungen des Enviroment Packs eigentlich gut... Von dem hab ich nur die Himmelstexturen belassen, ansonsten ist die Envir-Datei vanilla. Aber vielleicht hat einer damit rumgespielt und bessere Ergebnisse?

Was mich auch noch ein wenig stört ist die Zeit des Sonnenuntergangs. Ich hab mit aktuellem Datum in Spandau gespielt und um 23 Uhr gab es noch einen gut geröteten Himmel. Das ist für unsere breiten und die Jahreszeit doch ein wenig spät, es sind ja die Koordinaten von Berlin und nicht Helsinki...

Dann wunderts mich aber jetzt warum in manchen Bussen wo der Druckertyp CTI-abhängig ein- und ausgeschaltet wird dann zum Beispiel das Tastengeräusch ertönt obwohl der Drucker nicht vorhanden ist. Ich meine im O307/407 hätte ich das bemerkt.

Ich suche ein IBIS zum Einbau in den O305G. Mir wäre am liebsten das aus den SD200 bzw. dem O305, aber so wie ich das sehe hängt das Teil am jeweiligen Dashboard. Gibt es denn in irgendeinem Bus das Ding einzeln? Ein IBIS 2 täte es auch, IBIS 1 wäre mir da aber am liebsten. Damit würde ich gerne die BVG-Version des O305G ausstatten. Gab es so nie, hätte aber gerne das analog zu den anderen Fahrzeugen der Zeit., und eventuell mal für Mainz, wo die O305G mit einem (ansagefähigem) IBIS1 ebenfalls nachgerüstet waren.

Oder bleibt mir nur die Möglichkeit ein ganzes Dashboard zu migrieren? Wäre mir dann wieder zu viel des guten...

Ja natürlich, und hinzu kommen die verschiedenen Soundsysteme beim anhören. Und der Eindruck "zu leise" / "zu laut" hat oft mehr mit dem Frequenzgang zu tun als mit physischer Lautstärke. Für mich auf meinem System wirkt der NLC vorne total stumm, ich nehme nur die extremen Geräusche wahr zum Beispiel beim Vollgas. Ich kann auch die Geschwindigkeit des Busses sehr schlecht dadurch einschätzen, da hier auch viel der Sound macht in der Immersion mangels physisch wirkender Kräfte. Für mich musste ich also nachbasteln und hab es stumpf über eine deutliche Anhebung der Lautstärken bei den Innensounds gelöst. Das war bisher bei keinem anderen Bus in der Form nötig, aber es hätte mir den ganzen Spaß an diesem Bus vermiest, wo er doch bis auf den Fahrscheindrucker ansonsten ziemlich gut gelungen ist.

Zitat von Maxi G

Das Neoman Overhaul Pack ist von Sobol. Also nicht von dem selben Ersteller, wie der MAN New Lion´s City. Die Motor und Türsounds von dem MAN New Lion´s City, hören sich exakt an, wie bei den realen Vorbildern.

ja, nur sind sie im spiel vorne kaum noch wahrnehmbar, sogar im solo, während ich in real auch im gelenkbus noch alles gut höre.

Seit heute geht der Zoom/Lehnen Hotkey wieder und das Fenster zum Einstellen des Fahrersitzes ist wieder aufrufbar. Ich hatte aber zunächst einen ganz seltsamen Fehler wo die dynamische Kamera nicht auf der Standard-Kamera war, konnte ich aber durch Löschen des Inhalts des Busses-Verzeichnisses anscheinend beheben.

Doch zu früh gefreut. Der Menüpunkt ist wieder ausgegraut und der Hotkey zum nach vorn lehnen geht auch wieder nicht. Ziemlich seltsam, denn ausser OMSI Neuladen zwischendurch wurde nichts geändert. Version 1.3.1.1, wie vor 2 Stunden auch.

Die fahrgäste sind der springende Punkt AUXI das machen zu lassen. Verkehr kann man wie gesagt gut in den traffic_dens Dateien regeln. Fahrgäste gehen aber nur globnal für alle Wochentage. Somit braucht man mehrere global.cfg um erhöhtes abendliches Fahrgastaufkommen an den Wochenenden zu haben, oder halt keine Berufsspitzen an den Wochenenden. Parkende Autos sind sind auch ein Punkt, finde ich aber weniger wichtig. Ich meine sogar dass sich oarkende Autos auch nach der Verkehrsdichte der Normal Cars richten, jedoch nicht den eingestellten Prozentwert überschreiten. Hab ich aber noch nie genau geprüft...

Bei den Fahrgästen ist das aber in AUXI relativ durcheinander. Da addieren oder multiplizieren sich die Werte mit denen der global.cfg irgendwie seltsam anstatt sie zu überschreiben. Ich hätte nämlich eigentlich gerne dass ich da z.B. "1.2" einstelle und es hätte dann zu der Zeit genau den Effekt wie 1.2 in der global.cfg, aber unabhängig davon was wirklich dort eingetragen ist.

AUXI hinterlässt Spuren: nachdem man dort die KI eingestellt hatte, ändert AUXI laufend die Werte in den Optionen. Die bleiben dann auch nachdem man das vielleicht in AUXI abgestellt hat. Man muss also seine Fahrgast-/KI/Auto-Optionen danach komplett neu einstellen. Das ist auch nicht grundsätzlich ein Fehler von AUXi, denn so arbeitet AUXI eben, dass es on the fly die Werte ändert. Daher am Besten vor dem Experimentieren mit der KI in AUXI seine normalen Optionen abspeichern um sie später aufrufen zu können.

Ich denke da wirst Du nicht fündig. Ich hab den Inhalt auch kürzlich gelöscht um zu schauen ob das den Fehler behebt, es änderte aber nichts. Trotzdem könnt Ihr selber mal nachschauen, hab es aus dem Papierkorb wiederhergestellt: Buses.zip

Im großen und ganzen habe ich die Fahrersitz-Funktion nur genutzt um schnelle Werte für die Bus-Datei zu ermitteln und diese dann fest dort einzutragen, da ich auch andere Sichten abändere. Sehr nützlich war aber der Zoom/Nach-vorne-Lehnen Hotkey, der nun nicht geht.

In der Tettau-Situation bin ich seit Nachmittag gefahren. Bei Grunddorf hab ich die Uhr auf Mitternacht gestellt um das zu testen. Du meinst also hätte ich die Situation direkt auf 0 Uhr gestartet wäre alles normal? Jedenfalls so wird auch für mich diese AUXI-Funktion unbrauchbar, da ich dann wieder auf das OMSI-Echtzeitwetter umstellen muss. Ich verlink mal den Thread hier im AUXI-Support-Thread, vielleicht kann sich das da jemand anschauen.

Jetzt wo Du das Wetter erwähnt hast: das regelt AUXI über tomorrow.io. Ich habs mal ausgeschaltet und auf "Bestes Wetter" gestellt und zumindest der Himmel wurde dunkel. Irgendwie lädt also AUXI da wohl eine unpassende Himmelstextur die vielleicht für die Dämmerung taugt aber nicht für Nachts. Oder es gibt eine Diskrepanz zwischen realer Uhrzeit und OMSI Uhrzeit. Allerdings bin ich gestern (real) um Mitternacht rum gefahren und es sah so aus wie auf den vorhin gemachten Screens.

Hier mal Beispiele aus Tettau um kurz vor 23 Uhr.

Bin dann auch etwas rausgefahren wo es keine Laternen gibt. Immer noch viel zu hell.

Edit: und hier noch Grundorf um Mitternacht:

Ich hab es jetzt auf Tettau bemerkt, hab aber noch nicht verglichen. Ich erinnere mich nur dass mir das mal vor Jahren generell auch nachts zu hell war und ich das mit einem Mod behoben hatte. Kürzlich habe ich aber OMSI auf den Urszustand zurück versetzt, und denke mal daher ist das nun wie original, bzw eventuell hat hier das Enviroment Pack was geändert.

AUXILog.txt

Hier die Log. Hatte jetzt auf Debug Modus gestellt und einfach eine Situation geladen. Kanns am Abend gerne auch mit anderen Bussen versuchen.

Noch etwas gefunden im Zusammenhang mit der Wetterfunktion, wo ich zunächst annahm es hätte mit was völlig anderem zu tun, siehe ursprünglicher Thread. Relevant sind dann die Antworten von heute Abend: RE: Mod mit dunklerer Nacht

Zusammengefasst: die Wetterfunktion scheint nachts den Himmel viel zu hell zu machen und eventuell auch die Lichtverhältnisse negativ beeinflussen. Im Thread sind auch einige Screens, geschossen um etwa Mitternacht mit aktivem AUXI-Tomorrow.io Echtzeitwetter. Am auffälligsten der viel zu helle Himmel.