Hmm man könnte statt dem Kennzeichen auch irgendwas anderes nehmen... Aber stimmt schon, wird sehr fehleranfällig dann wegen UseTextTexture...
MX200 C2 soll den bei mir auch bekommen.... oh oh oh....
Beiträge von wurstbrot
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! -
-
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.
-
Wenn du es über bmp-files und nicht über Script lösen möchtest kann ich https://beta-kpp.genav.ch/#/ empfehlen.
Das wäre sehr unflexibel für etwas was auf so gut wie allen allen Nicht-K++ Systemen problemlos geht;-)
-
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.
-
Dienst in den Weihnachtsferien.
Bus: MX 200 C2G E5
Map: Mainz
-
Das Chicago DLC habe ich nicht, und hab es auch nicht vor zu kaufen. Mir würde es einfach reichen das Script des vorhandenen Feuerwerks entsprechend anzupassen.
-
Moin!
Ich überlege das Fireworks-Script anzupassen, damit es für Großfeuerwerke genutzt werden kann. Das Originalscript Scheint mir auf so Dinge wie Silvester ausgelegt zu sein, und mit dem High/Low wird auch eine gewisse Knallerei vor und nach dem eigentlichen Ereignis simuliert. Ideal für Silvester, ich hätte aber gerne auch an bestimmten festgelegten Terminen zum festgelegtem Datum mit Uhrzeit ein konzentriertes Großfeuerwerk. Dazu würde ich mir das Feuerwerk-Objekt kopieren und mit einer Scriptkopie verknüpfen. Nur verwirrt mich das im Originalscript eben mit den Angaben zum Tag vorher und mit dem Low. Die Feuerwerke die ich im Kopf habe sollten 22:00 Uhr beginnen und dann etwa eine halbe Stunde dauern ohne random Knallerei ausserhalb dieser Zeiten.
Vielleicht hat ja schon einer von Euch so ein modifiziertes Script parat?
Die Termine wären übrigens einzeln mit Jahr einzutragen, es wäre nicht immer jedes Jahr der gleiche Tag.
-
Ja, die Schrittgeräusche lasse ich auch. Ich hab für das Addon ja bezahlt, also verwende ich immerhin zumindest das noch, Bei der Installation kann man halt nur auswählen alles oder nichts. Ich finde es übrigens nicht schlimm dass gewisse Fehler da sind, ich finde es nur schlimm dass anscheinend kein Interesse besteht da irgendwas dran zu ändern. Genug Zeit ist ja nun vergangen und passiert ist nichts.
-
Probier auch mal den Logitech G-Hub downzuloaden und zu installieren. Der sollte das Lenkrad erkennen und in OMSI solltest Du es dann sehen und einstellen können.
-
Meine Erfahrung mit dem Heavy Equipment Pack war dass das Lenkrad in OMSI zwar funktionierte, aber eine schlechte Auflösung hatte. Die Lenkung war nicht direkt sondern stufig, fast wie bei der Tastatursteuerung. Daher (und wegen der sehr minderwertigen Qualität des Lenkrads und der Pedale) hab ich das nach wenigen Tagen zurück gegeben und nur das Side Panel einzeln gekauft. Denn das ist durchaus cool und brauchbar für OMSI, und in Kombination mit dem kompletten G29 samt Pedalen und Shifter super Ergänzung.
Also auch wenns alles andere als gut war, funktioniert hat das Lenkrad aber in OMSI im Sinne von "ist nicht kaputt".
-
Jupp, das Dauerlicht wurde im AI-Script eingeschaltet. X10 und BRT KI spuckt MASSENWEISE Fehler aus wenn man das Pack installiert hat. Aber auch die KI anderer Addons, es wurde zum Beispiel von Bremen mehrfach berichtet. Alles Fehler die nicht auftreten wenn man das Pack nicht hat.
Ich habe wirklich nicht die geringste Lust jetzt per Hand irgendwelche KI-Autos zu reparieren, die eigentlich nicht kaputt sind. Daher weg damit und gut ist. Erfahrung gemacht, von dem Entwickler kommt nix mehr auf die SSD.
