Die Knappheit wird noch lange bestehen. Man hat zwar nun die Hash-Leistung bei der 60er (Ti?) halbiert und wird das sicher ähnlich machen bei Refreshes der 70er und 80er, allerdings lässt man sich ja auch nicht die Butter vom Brot nehmen und wird auf der anderen Seite spezielle Chips und Karten fürs Mining anbieten. Und da Samsung und TSMC auch nicht beliebig die Mengen hochschrauben können bleibt das Problem weiterhin, es werden dann eben weniger Chips für den Gaming Markt hergestellt. Und das nächste Bitcoin-Halving (Halbierung der mining rewards) wird erst für 2024 erwartet, und wenns so weiter geht bringt das auch nur ganz kurz eine Entspannung. Bleibt nur zu hoffen dass der Strom in Asien und vor allem China schnell teurer wird.
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! -
-
Das hier ist alles viel zu aufwendig
Du erstellst einfach nur einen Trip, trägst bei diesem Trip dann den anderen Buswürfel ein und trägst im Fahrplaneditor einfach nur den anderen Trip an dieser Uhrzeit ein. Das ganze sieht dann so aus:
Also separate Morgens- und Nachmittagstrips, und vielleicht extra Schultrips, von denen man aber als User an sich nix merkt? Und Verwendung der gleichen Hofdatei wenn die Namen der Buswürfel gleich sind? Ja, das wäre die Alternative. Ist jetzt die Frage was praktischer ist. Dazu müsste man beide Systeme auf einer Linie ausgiebig probiert haben. Ich denke aber Deine Variante ist auf jeden Fall dann praktischer, wenn man bei der Gelegenheit auch grundsätzlich die Lastrichtungen steuert, also morgens Wohngebiet -> Arbeit/Bahnhof. Nachmittags Arbeit/Bahnhof -> Wohngebiet. Schulen und spezielle Großbetriebe sind da wieder spezifischer. Wenn ich aber eine Karte hätte die schon so ausgelegt ist wie Du das machst, dann würde ich da auch nicht mit Ghost Trips rummachen.
-
Bei X10 habe ich bei einer Schule einen zweiten Würfel mit anderem Namen hingesetzt, der entsprechend mehr Ein-/Aussteiger hatte. Die Fahrten zu den betroffenen Uhrzeiten haben dann einen anderen StationLink, damit die KI da vernünftig langfährt. Ghost-Fahrzeuge brauche ich nicht.
Der Spieler kriegt keine extra IBIS-Route, weil die Fußgänger eh nur nach dem Zielschild gucken. Wer X10 hat, kann sich das Spektakel anschauen, in dem er z. B. die mitgelieferte Situation "Überraschung am Schweizerhofpark" spielt.
Stimmt, mir ist ja mal aufgefallen dass die X10 AI-Liste D92er in einer Ghost-Gruppe enthält. Also normale D92er. Wie funktioniert das dann? Ich lasse den Ghost fahren weil sonst doch keine Fahrgäste generiert werden würden wenn da nicht auch was lang kommt. Der Ansatz scheint ja der gleiche zu sein, nur wie kommst Du ohne Fahrzeug aus bzw. wozu die D92?
-
Falls jemand ein Ghost-Fahrzeug erstellen möchte (hab zumindest selbst keins gefunden), nur zu. Ich glaube die erwähnte Ghost-Straßenbahn ist da suboptimal für. Zumindest in einem Moment habe ich mal kurz ein weisses Fahrzeug gesehen, was bedeuten würde dass sie einige unnötige Polys hat und eine durchsichtige Textur. Hier würde aber schon was in der Größe einer Ameise ausrechnen, wenn möglich kollisionsfrei. Wobei ich auch schon überlegt habe diese Pseudo-Tracks auf benachbarte Gehwege zu legen statt auf die Straße, hab aber die Befürchtung dass OMSI dann eventuell die Log mit Fehlern vollschreibt.
-
Moin!
Mich hat es immer in OMSI genervt dass nicht wirklich eine Art Stoßverkehr in eine bestimmte Richtung simuliert werden konnte, z.B. morgens in die Stadt, Abends in den Vorort. Hat man nämlich eine morgentliche und eine Feierabendspitze eingestellt, wirkt sich diese auf alle Haltestellen um den Faktor aus. Wenn man also morgens viele Fahrgäste in die Stadt hat, dann hat man genau das gleiche am Nachmittag. DIe erste Idee war dann jeweils zwei unterschiedliche Buswürfel zu nehmen für die Touren vormittags und nachmittags, und somit 2 verschiedene Trips. Hätte aber den Nachteil dass dann auch verschiedene Routen wohl auszuwählen wären bei Bussen wo man dies selbst eingeben muss. Ist aber jetzt auch nur ein Gedankenspiel, mag sein dass das unproblematisch wäre.
So viel zum generellen Problem. Zumindest aber für Haltestellen, die beispielsweise über den ganzen Tag kaum Ein- oder Aussteiger haben, aber zu ganz bestimmten Zeiten erhebliche Spitzen hätte ich eine einfachere Lösung. Wir nehmen als Beispiel eine Schule, wo nebenan eine Haltestelle ist. Der Buswürfel hat maximal 3 Ein- und Aussteiger eingestellt, weil außer der Schule ist da nix. Wenn aber Unterricht ist sollen an dieser Haltestelle zwischen 13:00 und 13:30 Massen an Leuten warten, morgens soll es ebenso viele geben die dort aussteigen. Wir belassen den Buswürfel bei seinen Einstellungen, und kopieren ihn und stellen das Duplikat direkt daneben. Dort stellen wir nun 0 Einsteiger ein und z.B. 80 Aussteiger. Bei der Haltestelle in Gegenrichtung machen wir das gleiche umgekehrt: 80Ein / 0Aus. Wichtig: der Buswürfel sollte so heißen wie sein original. Jetzt machen wir das gleiche dort wo die "Schüler" hin sollen, beziehungsweise wo sie her kommen sollen. 80 Einsteiger / 0 Aussteiger und Gegenrichtung umgekehrt.
Jetzt richten wir einen Track oder einen StnLink ein der diese Route abdeckt, einmal hin und einmal zurück. Track ist vielleicht besser, denn wir brauchen dann gleich im Trip nur die Pfadsegmente mit den Haltestellen, sonst nix. Natürlich können wir gemäß dieser Logik auch Zwischenhaltestellen einbinden, hier im Beispiel belasse ich es bei den beiden. Jetzt also die beiden Trips erstellen, sie sind die Grundlage für unseren "Geisterbus". Ach ja, wir brauchen einen unsichtbaren Bus... Da hätte ich gerade nur die Geister-Straßenbahn aus dem Ruhr-Straßenbahn-Addon. Wer eine Freeware-Variante weiss, bitte verlinken. Diese muss nämlich auch in die AI Liste rein, damit wir einen Fahrplan erstellen können. Für unsere Schule hieße das dass wir z.B. um 7:30 und 7:40 zwei Kurse vom Bahnhof (Wohngebiet, oder was auch immer) zur Schule erstellen, und um 13:10 und 13:20 Kurse in Gegenrichtung. Diese sollten abgestimmt sein auf die dann fahrenden "echten" Linien, und vielleicht so 5 Minuten vor ihnen starten. Bei den Trips ist zu beachten dass als Terminus jeweils das gleiche eingetragen ist wie beim folgenden "echten" Bus, sonst steigt die Masse nicht ein. Dabei müssen wir also die Linien und Linienvarianten berücksichtigen, die da um diese Zeit tatsächlich verkehren, und müssen gegebenfalls mit Kopien der Trips arbeiten, welche den jeweils benötigten Terminus eingetragen haben.
Die Schule ist das einfachste Beispiel das anzuwenden. Prinzipiell gehts also zum Haltestellen, wo das Fahrgastverhalten zu ganz bestimmten Zeiten stark vom Normalzustand abweicht. Das kann auch eine bestimmte Fabrik mal sein. Für einen Stadionverkehr lohnt sich das wohl weniger, weil es einfacher wär das per Chrono zu lösen. Aber auch da kann man sich die Mühe machen, denn warum sollen dann an diesen Haltestellen schon 7 Uhr morgens die Leute wie die Hühner auf der Stange stehen...
-
Ja, aber leider ignoriert Omsi die car_use manchmal.
Bei mir zur Zeit auf ALU saß der Fehler immer vor dem Bildschirm. Irgendein Bock war dann irgendwo drin wenns mal nicht hingehauen hat. Das Dumme ist nur dass diese Fehler an Stellen sein können die man gar nicht vermutet oder nur schwer findet. Beispielsweise wenn auf anderer Linie ein Fahrzeug zugeteilt wurde, dessen Repaint aber beispielsweise nicht existiert, weil man z.B. einen Verschreiber in der AI Liste da hatte. Dann lief auch auf anderen Linien hier und da was schief. Oder die erwähnten TABs an Stellen wo sie nicht hingehören. Sieht man aber auch nicht so leicht in der AI List... Es muss halt alles tipp top sein.
Soviel wie ich weiß, hat das mit dem alten Tracks&Trips System noch niemand ausprobiert, das könnte durchaus sein, das es damit sogar funktioniert.
Hmm da hatte ich ja eher den Eindruck dass man vor allem ei Freewarekarten T&T bevorzugt. Es kann sein dass dies der Grund ist, bzw. einer der Gründe. Letzter Versuch mit StnLinks war bei mir auf Aachen und ging schief. 70% der Busse fuhren ohne Kennzeichen mit Standard-Repaint durch die Gegend. Soweit ich weiss waren aber die Hof-Namen und das Gültigkeitsdatum richtig. Die Repaintzuweisung in der AiLIst nehme ich mal an hatte auch keine Fehler, da sie weitgehend original war. Kann aber sein dass da die erwähnten TABs oder ähnliches eine Rolle gespielt haben, oder halt die StnLinks selber. Gleiches auf Spandau, nur das ist schon lang her und die AIList war auch ziemlich modifiziert und möglicherweise mit Fehlern.
Übrigens habe ich auf ALU auch Mehrfach-Tour-Zuweisungen:
Hier wird pro Tour aus zwei Bussen gewählt. Dazu gibts noch eine Datei für die gleiche Linie die unter [onlytypes] nur Gelenkbusse eingetragen hat. Ergebnis: Die Montags bis Samstags Kurse werden mit Gelenkbussen gefahren, die Sonntags-Kurse entweder mit einem NL263 oder O530. Bei solchen Konstellationen habe ich erstmal die spezifischen Zuweisungen im Alphabet über den generellen, weil ich dachte vielleicht spielt das auch eine Rolle. Da bin ich mir aber noch nicht so sicher. Jedenfalls sind gerade die Sonntags-Kurse über den Mo-Fr Zuweisungen und es scheint gut zu gehen.
Man muss natürlich jetzt immer dran denken die Dateien aktuell zu halten. Ändert man einen Hof-Namen, Namen der Bus-Datei oder gibts Zuwachs in der Flotte muss aktuallisiert werden. Ebenso in meinem Fall wenn es zusätzliche Sonntags-Kurse gäbe oder sich ihre Tournamen ändern. Und es kann sein dass wenn ich z.B. die Tour "SO01 S" in "SO01" umbenenne dass dann auf einmal garnix mehr geht, auch auf anderen Linien.
-
Genau. Weiterer Vorteil: da man weniger "Höfe" hat, weil eben nicht z.B. Gelenkwagen und Solowagen unterschiedliche Höfe dann sind, kann man auf den gesamten Hof die Zufallsauswahl des Spielerfahrzeugs beim Dienstbeginn anwenden. Das ist nahezu unmöglich auf Karten die für jeden Fahrzeugtyp einen eigenen Hof verwenden. Und man braucht dann auch nicht im Hinterkopf zu behalten welches Fahrzeug nun gemäß AI Liste welches Repaint hat.
Es wird halt kaum verwendet weil es eben die erwähnten Tücken hat. Wenns läuft ist die Funktion fantastisch.
Sorry, kleiner Moderationsunfall.
-
Da fällt mir gerade noch ein Schuss in ne andere Richtung ein: Kann man das "Durchknallen" der Texturen evtl. durch low-res-Kopien verhindern? Das heißt TGA-Texturen für Texturen, bei denen Komprimierung nicht gewünscht ist, als Ausweichmöglichkeit aber eine _#low-Textur im DDS-Format, die OMSI dann stattdessen lädt, wenn der eingestellte max-Speicher für hochauflösende Texturen zur Neige geht (an anderer Stelle wurde ja schon geklärt, dass die Texturen immer dann schwarz werden, wenn der Speicher nicht mehr ausreicht - was widerum teilweise(!) auch Einstellungssache ist - sind z.B. 500MB eingestellt, werden natürlich trotzdem mehr Texturen geladen, nur nicht mehr hochauflösend).
Ich bin nicht sicher ob das funktionieren würde. Meines Wissens nach greifen die _#low-Varianten wenn man die Option LowRes Texturen verwenden aktiviert hat. Und dann nimmt OMSI immer diese, sofern vorhanden (man kann den Spieß auch umdrehen und sich unter _#low besonders hoch aufgelöste bereitstellen...)
Was anderes ist wiederum "alle Texturen auf 256 Pixel reduzieren": hier lädt offenbar OMSI die Texturen (auch normale, _#low nur wenn das auch aktiviert ist) und reduziert diese intern. Sieht natürlich furchtbar aus;-)
Was nun passiert wenn man den maximalen Speicher niedrig eingestellt hat weiss ich nicht genau. Entweder aktiviert sich dann die Variante mit _#low oder halt die Reduzierung auf 256x256. Probiers mal aus, ich denke im Debug-Fenster siehst Du dann anhand der Texturnamen was passiert.
-
Moin!
Ich hatte es eigentlich schon aufgegeben car_use für die Zuteilung von Fahrzeugen zu verwenden, denn es ging immer schief. Ergebnis war immer dass zum Teil Busse ohne Kennzeichen herumfuhren mit dem Standardrepaint des Busses, und auch auch sonst hab ich immer gesehen dass völlig grundlos die Einstellungen im Car_use Verzeichnis ignoriert wurden.
Ich habe es nun aber auf ALU Updated erneut versucht. Es gab erstmal ein paar Fehlschläge, die ich aber auf Fehler in der AI-Liste (z.B. ein unnötiges TAB nach dem [end] oder dem Bus-Pfad, etc) oder fehlerhafte Repaints identifizieren konnte. Nun läuft alles wie geschmiert. Seit Wochen entdecke ich keinen wirklich falsch zugewiesenen Bus. Dabei sind die Zuweisungen zum Teil recht komplex: ich habe für eine Buslinie eine "allgemeine" Zuweisungen von Gelenkwagen für die ganze Linie, und eine separate Datei zur gleichen Linie, welche die Sonntags-Touren Solowagen zuweist. Läuft, und ich staune nicht schlecht, denn wie gesagt, es hat meist nicht funktioniert wie es sollte.
Meine Vermutung wäre jetzt auch dass car_use vielleicht besser mit dem alten Tracks&Trips System klar kommt als mit StnLinks. Das ist aber nur hypothetisch und eigentlich wäre es unlogisch, denn Car_use wurde auf Spandau sicher eher mit StnLinks getestet in der Entwicklung als mit T&T. Aber wer weiss.
Die zweite Annahme: es muss alles peinlichst genau stimmen. AI-Liste muss absolut Fehlerfrei sein, keine TABS ioder Leerzeichen wo keine sein dürften, keine Fahrzeuge die fehlerhafte oder nicht vorhandene Repaints zugewiesen haben und und und... Darüber hinaus könnte es sein dass die Zuweisung des Standard-Depots in der global.cfg richtig sein muss, denn die ist auch bei den meisten Karten falsch. Nur um ein Beispiel zu nennen: das Standarddepot von X10 ist nicht "X10 Berlin" sondern müsste "BVG Solo", "BVG Gelenk" etc heissen. Beispiel ist nur zur Veranschaulichung, weiss nicht aus dem Kopf wie die Benennungen da konkret wären. Depot ist halt Depot und nicht Karte, und das ist eben zu 99% schon mal falsch, ob bei Freeware oder Payware. Ob die Zuweisung korrekt ist sieht man daran ob bei Wahl der Busses das Feld da ist für mit "nur die zum Depot zugehörigen Nummern verwenden". Dann das Datum: in der global.cfg ist ein Zeitrahmen angegeben zu dem die Karte gültig ist. Die Start- und Enddaten bei den car_use Dateien müssen innerhalb dieses Rahmens liegen. Wenn Ihr Spandau also 2021 spielt werden die alten car_use Dateien nicht richtig greifen, sie sind schon ungültig. Habt Ihr neue car_use Dateien mit Gültigkeit außerhalb der Kartengültigkeit wirds wohl auch nicht hinhauen.
Drittens: es müssen natürlich ausreichend Fahrzeuge vorhanden sein um die Regeln zu bedienen. Wenn da was nicht stimmt kann es sein dass das System zusammenbricht.
Also: etwas Mut wieder car_use zu verwenden;-)
-
Sehr schön, nach 10 Jahren wird nicht mehr mehr jpg und png ins Spiel gebracht sondern es geht nur noch darum wann tga und wann dds. Wir sind also weitergekommen;-D Und in der Tat ist diese letzte übrig gebliebene Frage gar nicht so einfach, und insbesondere was die Qualität betrifft gibts wohl erhebliche Unterschiede welches Tool man dafür verwendet. Nutzt eigentlich jemand dieses dds-Plugin von Intel für Photoshop? Das ist jahrelang an mir vorbei gegangen aber mittlerweile nutze ich das fast ausschließlich, auch in Kombination mit der Batch-Funktion in Photoshop. DXTBMP stürzt gerne mal ab, das nicht. Qualitativ kann ich das aber nicht beurteilen, ich sehe zumindest keine Unterschiede. Jemand der aber jeden Pixel seines Busses kennt wird da sicher mehr zu sagen können.
Über TGA würde ich auch fast nur in Zusammenhang mit Bussen oder Fahrzeugen nachdenken, für Häuser etc grundsätzlich dds nehmen. Sogar die Bäume habe ich alle mittlerweile in dds und sehe keinen Unterschied.
Der Punkt bei dds ist ja auch dass OMSI es einfach bevorzugt behandelt. Nimmt mal einen Bus der TGA oder sonstwas in den Configs und Meshes verwendet, platziert aber eine gleichnamige dds-Datei neben der originalen Textur. OMSI wird trotzdem die dds nehmen.
Die Dateigröße auf dem Datenträger ist mittlerweile nicht mehr so entscheidend. der Flaschenhals von OMSI ist ja das Problem, nicht mehr die Geschwindigkeit des Datenträgers, eine SSD mal vorausgesetzt. Hatte aber auch oft den Fall gesehen dass die dds deutlich größer war als die TGA nach der Wandlung, vermutlich weil ich eben nicht das optimale Format gewählt habe, und trotzdem hat im Ladefluss die dds einfach besser "geflutscht". Ein weiterer Vorteil wäre noch dass es im VRAM komprimiert gehalten wird, während alle anderen Formate zunächst entpackt werden und im Speicher dann wie eine BMP Pixel für Pixel gehalten werden. VRAM ist aber immer noch ein Problem, auch bei heutigen Grafikkarten, denn OMSI kann nicht den kompletten VRAM adressieren. Auch mit dem 4GB Patch ist der Adressraum stark beschränkt, und der VRAM muss dabei immer mitberücksichtigt werden, was oft vergessen wird. Irgendwann ist halt Sense und dann fliegen die Texturen als erstes einem über die Ohren.
Ein Nachteil von TGA wäre auch noch zu nennen: es kann wie bei PNG und Co auch passieren dass die Texturen plötzlich durchknallen, allerdings bei weitem nicht so häufig. Und anscheinend spielt dabei auch die Einstellungen "maximale Größe in Reflexionen" in den OMSI-Optionen eine Rolle. Setzt man die auf 0 ist man ganz gut dagegen gesichert.
Und grundsätzlich sollte man halt auch gucken dass man wirklich das Format und die entsprechende Variante davon nimmt die man wirklich braucht. Ein stumpfes Konvertieren wird unnötig große Dateien erzeugen. Zum Beispiel ist eine dds ohne Alpha nur halb (oder ein viertel?) so groß wie mit Alpha...
-
Hast du das Hafencity-Addon?
Falls ja, such mal in der Webdisk nach meinen KI-Fahrzeug Repaints. Der Transporter hat da auch ein paar Firmenvarianten bekommen.
Ja, das sind auch meine Standardautos auf Karten in der heutigen Zeit.
Erst einmal vielen Dank für das Lob der KI Autos.
Es sind in jedem Karten AddOn neue Fahrzeuge dabei, auch bei den beiden aus Frankreich.
Zusätzlich haben wir ja auch noch die KI Packs.
In Sachen Farbgebung ist uns bis jetzt wenig negatives Feedback mitgeteilt worden. Da wir immer von einem fertigem Modell mit Fototexturen ausgehen, gibt es auch wenig Möglichkeiten das anders darzustellen, wenn man andere Farben haben möchte. Außer, man hätte für jedes Fahrzeug optimale Texturen in allen Farben verfügbar. Das aber ist höchst selten.
Die unterschiedliche Farbgebung über einfache Farbänderung der Textur ist daher die einzige Möglichkeit eine Farbvielfalt zu zeigen.Ich habe die KI-Packs. Beim ersten sind die Autos in der Masse nur einsetzbar auf ganz dünn bebauten Karten. Sie sind sehr performancelastig, sehen aber gut aus. Beim AI Pack 4 ist das abhängig von den Autos. Der Golf und der Smart sind super für die Performance, T5, Vectra und Zaffira sind okay. Die Luxusautos habe ich nicht, aber da glaub ich kann man sich auch paar Polys mehr gönnen da man die eh nicht in Masse einsetzen würde um eine realistische Häufigkeit zu haben, ausser man fährt in Monte Carlo rum;-D. Und was die anderen Addons betrifft so finde ich liegt performancetechnisch Bad Hügelsdorf in der Mitte, ebenso Bremen. Der optische Stil der AI-Pack-Autos aus Bremen, Bad Hügelsdorf und den AI-Packs ist das was ich bei den X10/BRT Autos bemängele. Perfekt wäre ein X10/BRT Polycount zusammen mit der Texturierung wie bei den anderen erwähnten Addons, aber halt auch als 1024er dds.
Wichtig sind halt die Butter und Brot Autos die eine ganze Generation repräsentieren und häufig im Straßenverkehr vorkommen, die ganzen Golfs, Skodas etc.
Man darf auch nicht vergessen, dass vor allem die parked-Varianten Performance fressen, insbesondere da wo große Parkplätze sind oder gar Parkhäuser. Das haben auch zum Glück viele Kartenersteller erkannt und bestückeln solche Bereiche mit reduzierten Parklisten (z.B: Bad Hügelsdorf), denn da schaut man ja eigentlich als Spieler nicht so genau hin was so in der hintersten Ecke steht.
-
Ich hab geschaut, die Schranken und Ampeln sind dort Objekte ohne Pfadstück. Und die würde ich ungern tauschen. Aber ich schau mal ob das Script was hergibt. Kann mir vorstellen dort eine Abfrage einzubauen "wenn Phase=100 dann Dauerrot, wenn Phase=101 dann Dauergrün". Glaube nicht dass ich dann Pech habe und die Schranke oder Ampel auf einer anderen Karte wiederfinde auf einer Kreuzung die mehr als 99 Ampelphasen hat;-D
-
An der Stelle sind die Pfade für Autos normallerweise gesperrt. Ich müsste mal gucken ob die nicht vielleicht doch ein Pfadstückchen als Ampelobjekt haben. Ich glaube aber nicht, da sie im Originalzustand kein Parent-Objekt zugewiesen hatten, und die ganze Kreuzung eigentlich auch irgendwoanders her "ausgeliehen" war;-D
-
Nicht viel;-D Ich weiss nur dass die Phasen in einem Kreuzungsobjekt festgelegt werden können, deshalb die Idee mit dem Pseudo-Kreuzungsobjekt. Da wird aber kein Bus durchfahren, sondern nur normale PKW-KI, deren Pfade normallerweise gesperrt sind, während des Chronoevents aber offen. Und an der Stelle gibts nix was sie zum stehen bringen würde bei roter Ampel, es ist ein ganz normaler Pfad. Deshalb die alles-oder-nichts-Lösung, weil sonst wirds echt friemelig. Wenn Du es genau wissen willst: es geht um die Zufahrt zum großen Parkplatz an der ICB-Halle auf ALU Updated. Normal sind da die Schranken zu und Ampeln rot, und auch nicht verknüpft. Ich muss sie aber verknüpfen um sie zu öffnen. Schade eigentlich dass man nicht einen manuellen Modus erzwingen kann, z.B. durch Eingabe eines bestimmten Werts.
Obwohl... Eventuell doch im Script der Ampel durch ein zwei zusätzliche Zeilen an der richtigen Stelle... Das wäre ein ganz anderer Ansatz, aber könnte auch gehen.
-
Moin!
Folgende Situation würde ich gerne lösen: eine bestimmte Einfahrt oder Ausfahrt soll normallerweise dauerhaft mit roter Ampel + Schranke gesperrt sein, in einem Chrono-Event soll es aber eine offene Schranke und grün geben. Mir kam die Idee eine Art unsichtbare Kreuzung dafür zu verwenden, die per Chrono getauscht wird, und in dem einen Zustand eine grüne Dauerwelle liefert, im anderen eben eine rote. Mit dieser wären dann Schranke und Ampel verknüpft. Bei meinen Versuchen mit einer normalen Kreuzung als Verknüpfung fiel mir auf dass eine Änderung der Ampelphase, z.B. von 0 auf 1 per Chrono anscheinend keine Auswirkung zeigt, zumindest nicht im Editor. Diese Ampel-Schranke-Kombination soll aber auf keinen Fall dauernd umschalten, da die Autos sonst ihr Vorhandensein ignorieren würden, da es kein Ampelobjekt in den betroffenen Pfaden gibt und ich auch keins reinfriemeln werde. Wie wäre es nun am geschicktesten?
-
Ich möchte was zu einem Teilaspekt des Addons sagen: die neuen KI-Autos. Hier finde ich es eigentlich schade dass diese genau wie die X10-Autos texturiert sind. Okay, so passen sie natürlich gut dazu, aber optisch ist das leider nix. Und das ist wirklich sehr schade, denn die auch die neuen BRT Autos gehören mit denen von X10 zu den performantesten, was den Polycount angeht (Vermutung aufgrund von Beobachtung und Dateigröße+Zusammensetzung der Modelle). Ich denke aber dass das auch mit besseren Texturen ginge, denn dass sie so aussehen wie sie aussehen hat eher den Grund dass die Metallspiegelungen etc aus der Textur genommen werden und nicht vom Material stammen. Würde das jemand mal entsprechend repainten (ich kanns leider nicht...), dann wären diese Autos Wahl Nummer 1 für alle Karten, und würden auch als parked-Varianten auf großen Parkplätzen weniger die Performance belasten als jedes andere OMSI-KI-Auto, zumal sie wohl auch LODs haben.
Trotzdem ist es natürlich sehr schön dass es neue Autos gibt und es nicht die gleichen wieder und wieder durchgekauten Modelle sind, due auch noch mit Polys nicht geizen und kein LOD haben. Wenn da die Texturen nicht wären... Jetzt bräuchten wir nur noch mehr Commercials und LKWs, ohne dass sie gleich einem Bus vom Polycount nahkommen. Irgendwann hat man sich ja satt gesehen an M+R Umzugswagen, dem Hippie-VW und den Blumendiensten.
-
Jetzt hatte ich versucht per Repaint-CTI einen Texturwechsel bei der IBOX und beim Fahrgast-Monitor herbeizuführen. Das vorgehen war folgendes: habe in die model-cfg des Busses zwei zusätzliche [CTCTexture] Einträge gemacht, einmal für die IBOX Textur und einmal für den Monitor und dort auf die Standard-Texturen verwiesen. In der CTI dann entsprechend bei den Repaints wo das auch getauscht werden soll auf das entsprechende neue Farbschema verwiesen. Ergebnis war aber dass die IBOX komplett weiss wurde, beim Fahrgastmonitor sich keine Änderung ergab, es blieb beim Original. Die Pfade in der CTI müssten richtig gewesen sein, aber irgendwas fehlt da wieder, oder?
Zu erwähnen wäre noch dass die IBOX nicht zum Bus selbst gehört sondern ein eigenes Mesh darstellt. Ist das ein Problem beim Textur-Change? Klimaanlagen auf dem Dach werden ja auch gerne umgepinselt über die CTI.
Diese beiden Dinge hätte ich nämlich gerne "regionalisiert".
-
Prinzipiell kannst Du das ja belegen wie Du möchtest. Ich finde die Standardbelegungen mehr als unpraktisch und möchte die wichtigsten Tasten auch blind erreichen ohne drauf zu schauen. Dazu gehören vor allem Blinker und die Sichtumschaltung, denn die benutze ich dauernd. Übrigens: auch wenn ich Blinker wie erwähnt auch auch beim Mausrad-links/rechts aktiviert habe, nutze ich das zu 90% auf der Tastatur... Die Maus hat noch zig andere Tasten, aber egal was ich da mal sonst wo drauf gelegt habe, es hatte nie lang Bestand. Es kommt aber auf die Maus an und wie man sie greift. Ich zum Beispiel hab den Zeigefinger (wie wohl die meisten) auf linker Maustaste liegen und den Mittelfinger auf der rechten. Manch andere haben aber den Mittelfinger auf der mittleren Maustaste/Mausrad liegen und den Ringfinger auf der rechten.
-
Das ist hier kein wirkliches TUT, eher ein Tipp, welchen ich aber für wichtig halte, da er mich endlich von den grundlegenden Problemen als "Mausfahrer" befreit hat, die mich schon seit OMSI 1 plagen. Lang hat's gedauert bis ich drauf kam...
Problem:
Als Mausfahrer passiert es immer wieder mal dass man beim Fahren aus Versehen die rechte Maustaste erwischt und somit die Maussteuerung deaktiviert. Schlimmer noch: wenn man ausrutscht zommt man sich die Sicht kaputt und schon ist der Unfall geschehen. Verwendet man die alternative Maussteuerung, zoomt man sich zwar nicht die aktuelle Sicht kaputt, man macht sich die ganze Sicht kaputt beim ausrutschen. Abhilfe war bei mir immer eine Art Nottaste zu belegen um einerseits die Sicht wieder auf Standard zurückzusetzen und andererseits die Maussteuerung wieder zu aktivieren. Das dauert alles aber im Fall der Fälle viel zu lange, vor allem wenn man ausgiebig von den Blicken in den rechten Spiegel beim Abbiegen gebrauch macht. Das Problem ist natürlich bei jedem unterschiedlich ausgeprägt, wer zum Beispiel garnicht dazu neigt aus Versehen die rechte Maustaste zu drücken, der kann den Tipp getrost ignorieren. Dann hängts auch von der Sensibilität der Maus ab: Bei der G502 ist der "Klick" sehr empfindlich, bei anderen Mäusen wirds anders sein.
Lösung:
In OMSI aktiviert man die alternative Maussteuerung in den Optionen, die nicht Gebrauch von der mittleren Maustaste macht. Doch damit nicht getan, es geht um ja um die rechte Maustaste. Hier geht man nun in die Logitech Gaming Software und legt sich (sofern noch nicht vorhanden) ein Profil für OMSI an. Danach konfiguriert man die Tasten um, so dass die Funktion der rechten Maustaste auf die mittlere gelegt wird. Ergebnis: in OMSI dreht man sich nun in der Aussenansicht und bei den Innenansichten mit der mittleren Taste, zum zoomen verwendet man zusätzlich zur mittleren Taste SHIFT. Die rechte Maustaste ist nun frei, hier bietet es sich nun an sie entweder zu belegen mit dem zurücksetzen der Mausauflösung, man kann sie aber auch mit der Taste belegen, die man in OMSI für das zurücksetzen auf Standardsicht definiert hat, so für den Notfall. Bei anderen Mäusen dürfte es ähnliche Funktionen geben die analog anzuwenden wären.
Weitere Tipps fürs Mausfahren:
Legt Euch am Besten auf A und D in OMSI die Sichtumschaltung auf links bzw. rechts, und auf Q und E die Blinker. S kann Speichern sein für alle die die automatische Speicherfunktion wegen dem Ruckler hassen, W können Ansagen sein oder Fernlicht. Ich bevorzuge da Fernlicht. SPACE auf Aktivierung der Maussicht, TAB auf Feststellbremse, R auf Haltestellenbremsen, < auf Fahrplansicht, C auf Ticketverkaufssicht. Somit habt ihr alles wichtige auf der linken Hand im WASD Bereich und den Daumen auf SPACE. Türen, Kneeling etc könnt Ihr auf den Ziffernblock legen, denn da habt Ihr meist die Hand nicht an der Maus. Zusätzlich verknüpfe ich die Mausrad-nach-links und Mausrad-nach-rechts Funktion im Logitech Profil mit den Blinkern.
Die Lösung ist aber etwas nachteilhaft für den Editor, da empfiehlt es sich das Profil auszuschalten oder auf eine andere OMSI.exe-Kopie dabei zu verwenden.
Viel Spaß, es wird weniger Unfälle geben;-)
-
Also das scheint wirklich von den Temperaturen und anderen Werten abzuhängen... Ich bin auf ALU auf nasser Straße ins Rutschen gekommen, danach gings nur noch langsam voran, da sonst der Bus nicht zu kontrollieren gewesen wäre (ASR hat die ganze Zeit geklackert...). Im Betriebshof hab ich mir dann etwas mehr erlaubt und man konnte gut gleiten mit dem Bus;-D Hab dann schnell das Objekt untersucht, dort sind Betonplatten verlegt mit den üblichen Puddles/Moisture Einträgen. Bei "WinterSnow" gab es nix extra und "WintersnowFall" war es noch zu wenig Schnee. Passiert ist das alles bei Hamburger Wetter, -6 Grad mit Nasser Straße vom Schnee. Am Anfang der Fahrt war allerdings kein Rutschen da, ich glaub erst nach einem Wetterupdate. Wer es sich konstruieren möchte kann es mal mit Nässe und Temperaturen unter dem Gefrierpunkt versuchen.
Ich finde das funktioniert so wie es sollte... Ich bin über einige Segmente gefahren die falsch einsortiert waren zu "WinterSnow", da war zumindest das ASR auch beschäftigt.
