Beiträge von wurstbrot

Moin!

Ich hab nun das DGM Paket entdeckt und es gefällt mir sehr gut, sodass ich gerade auch überlege alle Fahrtzeuge die ich mit K++ ausgestattet habe nun auf DGM umzurüsten. Aber zunächst teste ich das ganze noch am NewLionCity. Zwei DInge bohren mich gerade etwas und ich frage mich wie ich sie am Besten hinkriege:

1. Wie kriege ich es hin dass die Seiten- und Heckmatrix die *B und *K Befehle in der Hof ignoriert damit nur die Frontmatrix diese nutzt?

2. Aktuell nutze ich den Font Aesys 200x24 für die Front und der passt mir perfekt, bis auf Anzeigen die Buchstaben wie g, y etc enthalten. Diese hätte ich gerne bis zur Grundlinie hochgezogen wie hier im Beispiel: https://busphoto.eu/photo/610537/

Ich müsste dazu den Font entsprechend modden, aber glaube kaum dass es da ausreicht nur die betroffenen Buchstaben zu stauchen, oder? Und außerdem würde ich das wenn dann als Zusatzoption machen wollen. Oder hat es schon jemand entsprechend gemacht?

Ich blick auch den Font Aufruf iom Script nicht so ganz. Da finde ich nirgends 200x24 Fonts, höchstens 16x16 oder 16x24.

Eventuell Bug:

Wenn ich eine gespeicherte Situation lade, egal ob Autosave oder eine selbst gespeicherte, ist die Zeit um 60 Minuten verschoben. Speichere ich also um 12 Uhr sehe ich auch 12 Uhr in den Daten des Saves, im Spiel hab ich aber 13 Uhr und +60min Verspätung. Sehr umständlich, denn dann muss ich Fahrplan deaktivieren, Zeit umstellen und Fahrplan neu einstellen.

Zwei Gründe könnten mir für den Bug einfallen: entweder ist der jetzt mit der Version neu oder er tritt auf wegen der Umstellung auf Sommerzeit und fiel eben vorher nicht auf. Allerdings hatte ich im Sommer und Herbst auch AUXI genutzt. Die ganzen Synchronisationsoptionen nutze ich übrigens nicht, sie sind alle deaktiviert.

Zweite Sache:

Die Funktion wo ich per Hotkey meinen Kopf nach vorne verschieben kann (nicht Zoom!) setzt sich immer auf 2 m zurück beim Neuladen.

Ähm 1. April fast Punkt 0 Uhr und Ihr diskutiert OB das ein Scherz ist oder nicht?

Zitat von Omsi2022

Schön daß es funktioniert, aber bei einzelne User leider nicht.

Genau, und deswegen muss man auch schreiben wenn es funktioniert. Für gewöhnlich melden sich bei Fehlern nur Leute die diese haben und es kann schnell der Eindruck entstehen dass dies überwiegt und man kann auch falsche Schlüsse draus ziehen.

Ich bin heute wieder mit AUXI gefahren, ca 1,5h und konnte erneut kein abweichendes Verhalten zu früher sehen.

Kann ich so nicht bestätigen. Keine fps Einbrüche, keine Nachladeprobleme. Vielleicht hatte ich aber eben Glück. Ich kann mir aber vorstellen dass dies eventuell daran liegt dass die AUXI Logging Funktion auf höchster Stufe eingestellt ist und es dadurch zu Problemen kommt. Oder eben eine andere Einstellung die ich aktuell nicht nutze (AUXI Wetter, AUXI Ansagen sind zum Beispiel bei mir aus)

Funktioniert gut. Hatte das glaub ich auf 20 gestellt und es hat direkt an den Stellen wo das IBIS sonst immer gesponnen hat indem es zum Beispiel vorzeitig weitergeschaltet hat das Verhalten normalisiert. Nebeneffekt war dann dass an allen Haltestellen das Weiterschalten auch noch etwas früher war als vorhin. Damit kann man aber leben, eventuell dann eben im IBIS Script das ganze wieder etwas verzögern.

Zitat von Ixel

Indeed, the ability to enable or disable OMSI logging on the fly could be handy. I'm not sure if it would conflict with "-nolog" however, that's untested. I imagine "-nolog" may override AUXI's ability to enable or disable OMSI logging. If OMSI logging is disabled in AUXI then it doesn't actually begin doing that until a vehicle is assigned to the user/player. Prior to that OMSI will continue logging as normal. I've found that disabling OMSI's ability to log to file can impact some plugins such as Bus Company Simulator, but I've added a warning about this to AUXI when someone attempts to disable OMSI's logging.

Regarding the distance between stops, you are correct. It helps to address the issue in OMSI 2 where some maps have bus stops tightly positioned together, causing OMSI 2 to be unable to correctly identify the next bus stop at times.

Regarding the interception of OMSI 2's ability to save, that's an interesting idea and I will see whether it's possible, I don't imagine that's going to be easy though.

As for the weather, yeah I'm aware of the issues some users have and in a future update at some point I will make some changes to the current implementation, some of which could be:

- Add another weather API or weather source

- Allow the user to change the way cloud textures are applied by AUXI, specifically whether AUXI should override them (current - which can appear like a grey sky in the game if it's cloudy) or let OMSI 2 choose the texture (essentially might be considered hoping for the best with this one)

Alles anzeigen

If -nolog is not necessary anymore than it does not matter if it overrides it, because you would not use it anymore and let AUXI do it;-)

The weather function is good, despite the mentioned things. But there would be room for improvements. For example an weather change could be applied smoothly and not directly, so there would bei some kind of transition and not e.g. from sunny weather to a thunderstorm withhin a second. The main reason I don't use it anymore is missing clouds and low rain intensity during rain periods (ALWAYS interval wipers were enough...).

Das mit dem Loggen ist interessant. Ich schalte es gerne ab mittels -nolog, fände aber ein aus- und einschalten im Spiel viel besser. Bei Problemen einfach zuschalten hilft da schon viel.

Das mit der Haltestellenentfernung versteh ich nicht ganz. Ist damit das Problem gemeint dass manchmal an den Endhaltestellen der Fahrplan nicht auf die nächste Tour umspringt? Oder diese Irritation manchmal wo unterwegs falsch weitergeschaltet wird wenn man sich zum Beispiel über eine Brücke einer Haltestelle nähert (Aachen vor dem Campus, Mainz ZDF usw)

Gut fänd ich wenn AUXI das automatische Speichern abfangen würde und verzögern würde optional zum Beispiel bis man wirklich angehalten hat und beispielsweise die Tür geöffnet hat oder die Sicht gewechselt hat um diese Speicherruckler kurz nach dem Stillstand zu vermeiden. Oder das an/ausschalten des önokomischen Reflektionsmodus mit einem Timer versieht damit OMSI nicht es dauernd im Wechsel ein uns ausschaltet was heftige Ruckler verursacht.

Und wäre gut wenn das Himmel-Problem beim Wetter behoben wäre sowie die sehr geringe Niederschlagsmenge beim Wetter über tomorrow.to.

Zitat von Shazen_de

Eines möchte ich aber noch loswerden. Nach der Installation dieses Addon wurde meine OMSI Installation völlig ungefragt auf Fehler überprüft. Das bedeutet, alle meine Mods von allen möglichen payware Maps und Fahrzeugen wurden völlig ohne Grund zurückgesetzt. Nicht cool, Mann, gar nicht cool

Ich hoffe, das passiert jetzt nicht bei jedem Update der Map...

Das kann Dir bei jedem Kauf auf Steam passieren. Es ist völlig willkürlich, manchmal setzt Steam nicht alles zurück sondern nur was bestimmtes. Lösung ist nur vorher Backup machen und dann nach der Installation eines neuen DLC nachschauen ob die Verzeichnisse das Datum geändert haben auf den heutigen Tag. Wenn ja, dann wurde da drin was verändert. Und das kann man dann entsprechend zurück spielen. Lästig, leider.

Das waren etwa 2 Stunden. Wetter war bereits über 10 Grad, und ich habe auch manuell kurzzeitig die Temperatur auf 25 erhöht.

Das "Problem" ist beim Münchner MAN so gewollt damit Leute auch in den Anhänger einsteigen. Per Skriot wird erst nach Halt des Busses das Ziel gesetzt und erst dann reagieren die Leute. Kann sein dass das beim Düsseldorfer Solaris das gleiche System ist.

Und da drehen wir uns nun im Kreis. Selbst wenn der Bus einfach verglast ist: A die Scheiben im erwähnten Fall wurden nicht erst nach geraumer Zeit entfeuchtet sondern nie, und B eine Klimaanlage hatte der Bus und sie war auch eingeschaltet.

Beim KJ O530 fiel mir auf dass das R&G Gerät weiter piepst zur Abfahrt mit der IVU Box. Einfachste Lösung wäre ja die Einträge aus den Sound Configs rauszuschmeißen, ginge es aber nicht auch mit R&G Skript rauswerfen? Ich vermute mal dass mir dann der Bus Fehlermeldungen verursacht, aber Fakt ist ja auch dass das Skript doch Unnütz ist wenn man die IVU nutzt. Könnte man es trotzdem irgendwie entfernen ohne dass es Schäden anrichtet?

Und:

Seit dem letzten Update gibt es wieder Probleme mit der Liniennummer, und die Lösung mit (L.L.IVU_eingegebene_Linie) (S.L.IBIS_LinieKurs) im Frame funktioniert nicht mehr. Hat es jemand vielleicht wieder geschafft das für die Matrix zu übersetzen?

Ui. gerade beim NLC wäre die IVU Box gut, denn der Drucker dort ist "naja".

Der O530 unterscheidet aber offenbar die Scheiben vorne und eben die im Passagierraum. Hatte mal ins Script irgendwann geschaut, da gab es sogar glaub ich 4 Unterscheidungen. Zusätzlich wohl noch Fahrerfenster und Tür 1 wenn ich mich nicht irre. Bei M&R war es glaub ich gleich, entweder alles oder nichts.

Der Bus hatte übrigens Klimaanlage + Fahrerklima, und die Auskühlung an Haltestellen hatte ich mal in der const etwas runtergesetzt. Wärhend der Fahrerraum recht flott entfeuchtete tat sich im Fahrgastbereich ab dem ersten Fenster nix. Und immer war es beim oder NACH Regen, sonst klappte es auch ganz gut mittels Standheizung (Standheizung und Entfrostung sind wohl vertauscht im Bus).

Und man kann nach Regen dann nie wieder die Fenster im Fahrgastraum sowie die Zielanzeigen entnebeln? ;-D Nee, da stimmt was nicht. Während dem Regen hätte ich das noch irgendwie akzeptiert. Wenn ich mich nicht irre verschwindet das auch nicht nach Erhöhung der Temperatur, obwohl die Grenze für diesen Effekt exakt plus 10 Grad sind. Ich habe auch ziemlich lang gewartet, denn zumindest nach einer längeren Zeit sollte sich das dann lösen. Wenn dem so wäre dann wäre es durchaus ein Feature und kein Bug.

Jetzt hatte ich wieder das Problem dass die Scheiben im Fahrgastbereich nicht zu entnebeln waren. Es war der O530 Solo 2 Türer E2 und es hatte vorher geregnet. Nach dem Start des Busses konnte ich vorne die Scheiben recht schnell frei kriegen, im Fahrgastraum wieder nicht. Letztes mal wo ich so ein Problem hatte war es auch im oder nach Regen, daher denke ich das hängt auch irgendwie damit zusammen.

Ja, wenn mehrere Pfade übereinander oder extrem Dicht beeinander wären dann ist das sicher schwierig zu sagen auf welchem nun ist das Userfahrzeug. Ist aber hier glaub ich nicht der Fall, das sind recht simple Kreuzungen. Pfadbreite übrigens da nicht angetastet.

Solche Lücken wären das nicht, da achte ich drauf. Aber manchmal sind die Winkel nicht perfekt. Es ist zumindest gut genug dass man es im Editor kaum sieht.

Allerdings:

Auch sich einfach kreuzende Pfade (ohne Verbindung!) reagieren auf die eingestellten Verkehrsregeln ja. Denke mal an die Geradeausfahrer an einer normalen Kreuzung. Deren Pfade haben ja auch KEINEN Verbindungspunkt sondern sie überlappen sich. Für zusammenlaufende Pfade wäre dann auch das dann doch eher entscheidend und nicht ob sie dann punktgenau zum nächsten Segment übergehen, denn eigentlich interessiert dafür ja nicht der weitere Verlauf.