Beiträge von wurstbrot

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!

    Funktioniert soweit alles, jetzt bin ich nur ratlos wie ich das mit der Innenanzeige mache. Ich muss ja im Script die variable eintragen:


    ' einzeilige Anzeige mit Linie + Haltestelle + Wagen haelt

    (L.$.IVU_Fahrgastinformation_Ausgang_01) (S.$.IVU_freier_Port_01)


    hab ich zu folgendem gemacht:


    (L.$.IVU_Fahrgastinformation_Ausgang_01) (S.$.GetBusstopString)


    Hat aber anscheinend nicht funktioniert. Das ist eine simple einzeilige Innenanzeige wie im D92, vermutlich zu dem auch kompatibel. Zeigt nächste Haltestelle an und beim Halt Liniennummer + Ziel. Ich meine deshalb wäre auch nur Ausgang 01 relevant, oder?

    Dann würdest Du den alten IBIS-Kram auch drin lassen? Muss ich wohl überlesen haben dass er das empfohlen hat...


    Ich hab's ja gerne sauber und performanceschonend, würd also dazu neigen das unnötige nicht drin zu lassen. Ich war mir nur nicht sicher ob die Zahl nicht wichtig ist für irgendeinen Aufruf so nach der Art "Texttextur 31 laden"... Zum Testen mach ich das aber erstmal wie Du sagst quick and dirty.


    Edit: Hat nun geklappt, danke! Jetzt noch Position und Kommunikation mit der Innenanzeige herstellen...

    Moin!

    Eigentlich ging der testweise erste Einbau der IVU.Ticketbox ganz gut vonstatten, Position hab ich noch nicht angepasst da ich es erstmal zum funktionieren bringen möchte. Und vom Script her funktioniert es auch schon, nur mit den Fonts hab ich noch ein Problem und weiss nicht was die Ursache ist.


    Folgendermaßen sieht das gerade aus:



    Der Font ist installiert, im O407 wird auch alles angezeigt.


    Ich vermute es liegt an den Texttexture-Einträgen, weiss aber nicht genau wie ich verfahren soll. Hier mal der Ausschnitt wie es jetzt ist:


    Ich hab die Nummerierung nicht geändert und die alten IBIS-Texttexturen drin gelassen. Bei der Durchnummerierung gibt es ja nun eine Lücke: 31 ist die letzte Texttextur wie sie vorher im Bus war und mit 38 geht's dann weiter bei der IVU. Hätte ich nun die Nuimmern von der IVU anpassen müssen zu 39, 40, 41 usw? Und was ist wenn ich die alten IBIS-Texturen da rauswerfe? Ist mein Fehler hier vergraben?


    Wenn das gelöst ist dann mach ich mich an die Position und dann an andere Busse...

    Wo ich gerade hier die Sitzpolster sehe: ich hab den Eindruck dass die Sitzpolstertexturen zumindest im GN-E5 falsch gemappt werden. Die Muster auf den Sitzen erscheinen mir viel zu groß. Zugegriffen wird ja auf die gleiche Textur wie beim Solo und da ist es korrekt.


    Auch scheint mir das Mapping der Regentextur sehr unvorteilhaft zu sein. Die Textur wird verkleinert und nebeneinander gemappt und hat deshalb ein ziemlich störendes Wiederholungsmuster.

    Daran dachte ich schon, sehe aber dass alle Constfiles genau die gleichen Werte haben. Und trotzdem kühlt der eine Bus schnell aus und der andere nicht;-)


    Habs gerade getestet über das Const-File. Zweckdienlich, kann man machen. Obs man jetzt im Script macht oder hier ist ja eigentlich wurscht, im Script müsste man ja auch das pro Bus anders tweaken... Wäre trotzdem gut wenn jemand wüsste was da im Script so geschieht.

    Erstmal gehts darum die Turbo-Abkühlung bei einigen Bussen wie dem MAN LC zu beseitigen beim Türöffnen. Kann ja nicht sein dass in 30 Sekunden die Temperatur um 10 Grad fällz.

    Kann ich unterschreiben, bei mir stürzt es beim Beenden auch immer ab. C2 bin ich häufig gefahren und habe ihn im KI Einsatz. Den Absturz selber merke ich nicht, ich glaube es gibt aber beim Beenden diesen Windows-Bling-Sound. Ich merke es beim nächsten laden, da meldet OMSI dass es vorher abgestürzt sein muss. Da muss ich immer aufpassen nicht aus Versehen das Multithreading zu deaktivieren, ansonsten c scheint es keine Folgen zu haben.

    Moin!

    Ich nutze in diversen Bussen die K++ Matrix. Im Grunde komme ich damit klar, aber einige Dinge würde ich gerne noch anpassen, bin mir aber nicht ganz sicher wo ich da ansetzen soll.


    1. Einzeilige Ziele:

    Bei relativ einfachen einzeiligen Zielen wie beispielsweise "45 Hauptbahnhof" oder "Betriebsfahrt" wird nicht der ganze Bereich der Matrix ausgefüllt. Ich hab den Eindruck dass dass da ein zu kleiner Font genutzt wird beziehungsweise nicht erkannt wird dass da noch Platz ist. Bei den K++ Befehlen für die Hof finde ich nix gescheites um das zu steuern: ob ich nun *B anhänge oder nicht ändert nichts daran dass das größer ginge. Script-Problem?


    2. Zweizeilige Ziele:

    Die meisten Zweizeiler hab ich mit erster Zeile größer als die zweite, wenn Platz da ist dann erste auch noch in Fett. gelöst mit einem 'B eventuell für Zeile 1 und einem *K für Zeile 2. Ich suche aber nach einer Möglichkeit die erste Zeile noch etwas zu vergrößern und die zweite etwas zu verkleinern. Ginge das? Und dann wie, übers Script?

    Ich kenne mich mit den aktuellen Notebook-Varianten der CPUs und Grafikchips nicht aus, aber grundsätzlich würde ich dann raten wenn praktisch nur OMSI gespielt wird auf eine schnelle CPU zu achten. Wichtig ist die Leistung pro Kern, daher rate ich zu einer aktuellen CPU-Generation (z.B. Ryzen 7000er / Intel 14000er) mit Modellen die mindestens 6 oder 8 Kerne haben und einen hohen Takt lange halten können ohne zu drosseln. Im Falle von Notebooks wäre hier deshalb auf eine gute Kühlung zu achten damit das gewährleistet werden kann, und bei Testberichten eben drauf achten. Anzahl der Kerne deshalb 6-8 damit OMSI dann mindestens 4 für sich hat und Betriebssystem etc auf den anderen läuft. An und für sich braucht OMSI nicht viele, so ist aber entsprechender Puffer da.


    Grafik: wenns tatsächlich nur um OMSI und Office geht kann man hier unten ansetzen. Ich weiss aber nicht ob integrierte Grafik da wirklich reichen würde oder ob die mittlerweile dafür tauglich wären. Es muss aber definitiv NICHT Geforce RTX oder ähnliches sein.


    Arbeitsspeicher: 8 GB reichen, vermutlich wird das Notebook aber 16 GB haben. Reicht locker aus, in OMSI ist eh nach 3,3 GB Sense.


    SSD: je schneller desto besser. Einfach drauf achten dass es eine native M.2 / NVME / PCIe-SSD ist und bloß kein Flash....

    Moin!

    Seit dem Herbst nerven mich bei manchen Bussen die Heizungen. Nicht nur die, sondern wohl auch wie der Luftaustausch funktioniert. Es gibt Busse da ist es schlecht gelöst und bei anderen sehr schlecht;-)


    Zwei Beispiele:

    - im Stadtbus O405 gibt es ein (!) Klappfenster, das sorgt beim öffnen für sehr schnellen Temperaturabfall. Nur dieses eine, wenn ich mich recht entsinne hinten links irgendwo. Warum?

    - MAN LC G (Mainz) kühlt bei einem einfachen Haltestellenhalt von 22 Grad auf 12 Grad runter. Lässt man die Heizung laufen zwischen zwei Haltestellen ist es wie im Kochtopf schnell bei 30 Grad. Völlig übertrieben.

    - MX 200 C2 geht so, immerhin braucht man nicht ständig rumdrehen.


    Also mal die Scripte bißchen verglichen, vor allem die Passage zum Luftaustausch. Sehe aber gerade in diesem Abschnitt kaum Unterschiede. Ich dachte hier gäbe es vielleicht irgendeinen Faktor der die Temperatur dann unterschiedlich modifiziert, aber das seh ich nicht. ALs erstes wollte ich nämlich im LC zumindest die extremen Glätten, also die Auskühlung ebenso deutlich verlangsamen als auch die Aufheizung.


    Das wäre der Part im Heizungsscript des LC:

    Ich seh da noch die Bezeichnungen aus den Doppeldeckern, werde aber nicht schlau wo diese Raten denn bestimmt werden. Zur Erinnerung: der LC hat keine Klima, sondern "nur" eine Heizung.


    Edit: Die Const-Files sind auch nahezu gleich bei den Bussen die ich verglichen habe. Da sehe ich auch keinen Anhaltspunkt.

    Eine ideale gibt es da nicht, da das ganze auch stark von den Gegebenheiten der Karte und den Einstellungen da abhängt. Ich für mich nutze nur die Funktion für Passagiere, und der Einfachheit halber stelle ich in der global.cfg für den ganzen Tag+Nacht den Wert auf 1.000 und lasse dann AUXI je nach Wochentag und Uhrezeit den Faktor regeln. Für Mo-Fr kann man da Anfangs sich die Werte aus der ursprünglichen global.cfg aus X10 eintragen, da dort meiner Meinung nach das am realistischsten eingestellt ist. Für Samstag und Sonntag passt man das dann entsprechend an, ebenso für Freitag Abend. Dann wäre das ganze grob übertragbar auf andere Großstädte. Wenn das dann halbwegs stimmig ist kann man pro Map differenzieren. Hier wäre es super wenn AUXI pro Map eine andere Datei automatisch laden könnte.

    Ich hatte sowas ähnliches anfangs auf meinem neuen Rechner. Es verabschiedete sich aber mit dem Direct X Lost Fenster (oder ähnlich) wenn ich aus OMSI kurz in ein anderes Programm gegangen bin oder eins gestartet habe. Aber nicht wenn ich OMSI geladen habe und drin blieb. Problem hat sich dann aber irgendwie von selbst gelöst. Im Moment stürzt es nur ab beim Schließen, was ich daran merke dass beim nächsten Start das Fenster kommt mit dem Hinweis auf das Deaktivieren des Multithreadings.


    Kompatibilität hab ich auf Windows 8 aktuell gestellt, Vollbildoptimierungen aus.