Laut Liste von Mircosoft braucht man mindestens Intel 8000er Reihe ODER Ryzen 2000
Okay, hatte 7000er bei Intel im Kopf und 2000er bei AMD;-)
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! -
-
wurstbrot, heisst ein 6700k wird mit Win11 nicht funktionieren?
Ich finde es nur schwierig eine bezahlbares neues Komplettsystem zu finden, was einerseits zukunftsfähig, andererseits aber auch eine hohe Singlecoreleistung abrufen kann, welches die älteren Games wie MSTS, TrainSimulator oder eben auch Omsi benötigen.
So ist es. Bei Intel geht es glaub ich ab 7000er Reihe los wenn sich nichts ändert.
Ich finde es ehrlich gesagt jetzt ziemlich unnötig, davor zu warnen, dass ein 6700k möglicherweise nicht ohne Tricks mit Win11 laufen wird. Kaum ein normaler PC-Nutzer, für den der Kübel einfach nur funktionieren muss, wird sich direkt am Releasetag Win11 installieren. Dazu kommt auch noch, dass Win10 als Ablaufdatum den 14. Oktober 2025 hat, also noch knapp viereinhalb Jahre. Ich wage in diesem Fall zu behaupten, dass die vorhandene Hardware (zumindest CPU+Mainboard) zu dem Zeitpunkt schon länger erneuert wurde.
Schlimmstenfalls: TPM-Modul nachrüsten und gut is. In den letzten Jahren sind eh so gut wie keine Mainboards mehr erschienen, die nicht wenigstens einen TPM-Header haben. Auch die kleinsten H110-Boards haben so gut wie nie keinen Header drauf.
Der Druck auf Windows 11 umzusteigen wird aber von Monat zu Monat größer. Das "neue" System wird dann auch unverkäuflich wenn man es loswerden will. Man investiert also wohlwissend in ein Loch. Es reicht ja nur dass Steam "aus Sicherheitsgründen" dann plötzlich um es vollständig nutzen zu können Windows 11 voraussetzt, oder die Grafiktreiber nicht mehr aktualisiert werden. Der Ärger ist einfach vorprogrammiert. Ich bin mir sicher dass es Wege geben wird es trotzdem hinzukriegen, würd ich aber keinem unerfahrenem User raten. Mal unabhängig davon würde ich eine Mühle wie den 6700K sowieso niemandem raten, ausser für Ramschpreise von vielleicht 10 Euro für die CPU.
-
Achtung bei älteren CPU-Generationen... Windows 11 wird aller Voraussicht nach nur recht aktuelle CPU-Generationen ohne Tricks unterstützen. Ich würde auf gar keinen Fall mehr ein System kaufen welches von MS nicht offiziell unterstützt wird. Bei bereits vorhandenen Systemen kann man sich ja mit Tricks etc behelfen, aber bei Neuware würde ich es nicht drauf ankommen lassen.
Im übrigen lohnt sich zur Zeit ein Blick auf Komplettsysteme, was noch vor Monaten nicht galt. Aufgrund der Marktlage bei Grafikkarten haben die großen Hersteller eher gute Konditionen bei den Lieferanten als der Retail-Markt. Auf jeden Fall Finger weg bei High End - Grafikkarten von Gebrauchtware: der Markt wird ziemlich überschwemmt werden von chinesischen Karten aus dem Miningbetrieb. Reines Glücksspiel ob und wie lange so eine Karte dann noch läuft.
-
Stimmt, das Fadenkreuz hätte ich ja ganz vergessen... In The Bus gibts an der Seite rechts so ein HUD-Fenster was die Richtung anzeigt. Ziemlich unbrauchbar beim Fahren, aber unabdingbar an Haltestellen damit man nicht nach dem Tür schließen wie eine Rakete ungewollt losschießt.
Eine andere Sache die mir so gar nicht gefällt ist das Fahrgefühl an sich. Ob man nun 30, 40, 50 oder 60 fährt: man fühlt die Geschwindigkeit garnicht. Man weiss sie nur wenn man aufs Tacho schaut. In OMSI entwickelt man dafür je nach Bus ein Gefühl was unterschiedlich ist, aber immer da ist. Schon nach ein zwei Kilometern mit einem neuen Bus geht das in Fleisch und Blut rüber, in The Bus leider gar nicht. Einzig am Sound wirds nicht liegen, es gibt ja auch bei OMSi guten und schlechten Sound, aber das Fahrgefühl ist irgendwie immer da. In The Bus denke ich immer ich verschiebe einen Holzklotz, oder eher ich steuer über einen Traffo ein rechteckiges Ding was wie ein Bus aussieht. Ich hoffe es liegt nur an noch nicht ganz optimalen Fahrzeugwerten. Zum Vergleich: der noch völlig unfertige DD in Lotus ist ein Traum dagegen.
-
Das mit der Tastatur ist leider keine gute Option. Eine Taste kann nur gedrückt oder nicht gedrückt sein, und das ist dann das Problem dabei: Vollgas und Vollbremse, immer schön im Wechsel... Durch die Mausrichtung ist das dann stufenlos bis hin zum Kickdown. In OMSI funkioniert das astrein, ich verstehe nicht wieso da versucht wird das Rad neu zu erfinden anstatt es einfach mal richtig zu machen. Ich kann mir nur vorstellen dass es da um eine Art Firmen-Ego geht und man bewusst es nicht so macht wie bei OMSI. Aber man baut ja auch keine eckigen Räder ein, bloß weil andere runde Räder haben. Ich finde es gibt Standards die mal gesetzt wurden und die sich etabliert haben, und die sind dann halt die Messlatte.
Übrigens: die Mauslenkung im ETS 2 ist zwar etwas besser als bei den TML spielen, kommt aber auch bei weitem nicht an OMSI ran. Da dort der Sound ja fertig ist, hört man auch schön bei jedem Bremsen wie das Bremspedal von null auf 100 durchgedrückt wird;-D Grauenhaft....
-
C:\Users\<user>\AppData\Local\TheBus\Saved\Config\WindowsNoEditor\GameUserSettings.ini
Geht auch (und ist wahrscheinlich sogar besser, weil das andere auf jeden Fall mit jedem Update zurückgesetzt wird)
Theproloser Danke fürs Verbreiten dieser Informationen! Sowas sollte eigtl schon etwa vom Menü aus klar werden, per Slider noch weiter erhöhbar sein und in der Standardkonfiguration anders sein. Habe das auf jeden Fall mal angemerkt. 👍
CPU/GPU Limitierung hat nichts mit einem Framelimiter zu tun. Es ist einfach die Grenze ab der man keine höheren Raten mehr erreicht bzw eine Komponente die andere ausbremst. Was den Effekt hat dass man z.B. an den Regeln hin und her dreht und es ändert sich nichts an der Framerate. Um ein CPU oder GPU Limit auszuloten sollte man KEINEN Framelimiter aktiv haben, weder per Treiber (ist eh immer ganz bäh das zu machen) noch ingame. Dies ist auch der Grund warum Tests von CPUs immer mit starken Grafikkarten gemacht werden in abartig niedrigen und eigentlich nicht gebräuchlichen Auflösungen, und warum für Grafikkartentests immer nur die stärksten CPUs genommen werden.
Wenn Ihr bei The Bus fast dauerhafte 60 sieht, Euer Monitor 60 Hz hat und ihr Vsync aktiv habt, seht Ihr nicht ob ihr im CPU-Limit seid. Wenn Ihr aber eh mit 60Hz spielt ist das auch nicht weiter schlimm. Nur wenn ihr dann überlegt welche Komponente wäre denn die aktuelle Schwachstelle dann macht es Sinn die Framelimits abzustellen und das auszuloten. Mal angenommen jemand ist nun total The Bus begeistert und möchte nun seine GTX 1070 gegen GTX 3080 tauschen, könnte ihm ohne so einen Test leicht passieren dass er über 1500 Euro für nichts ausgibt;-D Es ist wie bei OMSI, nur auf einem etwas anderem Niveau.
Und für alle die es interessiert hier meine Werte:
Meine fps taumeln zwischen 38 und 45. Dabei ist es relativ wurscht was ich bei den Grafikeinstellungen mache, ob episch oder minimal. Ganz klares CPU Limit des 1700X, und die Vermutung dass ich nur mehr fps haben kann wenn ich die CPU tausche entweder gegen eine mit mehr Kernen und/oder eine mit mehr IPC. Vermutlich hilft beides, und vermutlich würde ein 5900X oder 5950X mir viel mehr bringen als eine neue Grafikkarte.
-
Nee. Solche Limitierungen sind Engine bedingt und auch nichts unnormales. Jedes Spiel hat irgendwo solch eine Limitierung, vor allem CPU-seitig. Man muss nur wissen dass es sie gibt und ausloten wo sie bei eigenem System sind. Denn dann kann man ruhigen Gewissens die Regler auf der nicht limitierten Seite hochdrehen ohne weitere Einbrüche. Allerdings Achtung: es ist nicht gesagt dass jeder Regler im Grafik-Menü nur GPU-affin ist. Und je nach GPU kann man dann auch auf eine GPU-seitige Limitierung stoßen. In meinem Fall scheint es die zur Zeit nicht zu geben.
-
Das mit dem Lenken/Bremsen etc klappt aber nur wenn man über einen mit Achsen gesteuerten Controller spielt, nicht bei Maussteuerung. Die ist fix und nur durch die Sensitivität und Deadzones beeinflussbar. Und egal was man da macht wird man den Eindruck nicht los dass das ganze absolut nicht linear zur Mausbewegung ist, Häkcchen bei "Geschwindigkeitsabhängig" hin oder her. Es wirkt immer so als liefe das irgendwie stufenweise: Maus um x Zentimeter bewegt -> Beschleudigungsmodus 2 etc. Gleiches beim Bremsen. Schwer zu beschreiben... Ich kann nur sagen dass selbst die schlechtesten Busse in OMSI das besser hinkriegen. Wenn man sich den KI Verkehr an Ampeln anschaut offenbart sich vielleicht dass das Problem von grundsätzlicher Natur ist: auch die KI brmest und beschleunigt völlig unnatürlich, und auch da sind diese Stufen zu beobachten. So als könnte die KI nur 0, 10, 20, 30 usw km/h und keine Geschwindigkeiten dazwischen. Ich finde auch dass das Fahren des Scania so wirkt als hätte es kein Getriebe, obwohl der Drehzahlmesser mir was anderes sagt. Es ist eher vergleichbar mit einer S-Bahn als einen Bus. Es ist aber auch wirklich schwer zu sagen ob es einfach nur an den noch nicht optimalen Werten des Busses liegt oder der grundsätzlichen Physik.
Interessant ist auch dass die Haltestellenbremse sich höchst seltsam verhält. Einerseits funktioniert der Schalter nicht, was aber nicht schlimm ist, das kann man noch ändern. Aber an Haltestellen löst die Hst-Bremse sofort nach betätigen des letzten Türtasters. Bei Mausfahrern schießt dann der Bus gerne sofort von alleine los. Glaube kaum dass im Scania nicht ein erstmal ein kräftiger Druck auf die Bremse nötig ist, zumal da ja noch das Auto-Kneeling zu werke ist....
Performancemässig riecht mir The Bus zur Zeit als stark CPU-limitiert. Ich erreiche nahezu die gleichen Frameraten bei jeder Grafikeinstellung bis hin zur allerhöchsten. Wenn Fahrplan-KI mal dazu kommt könnte diese Limitierung noch krasser ausfallen, sprich es wird eine noch schnellere CPU für die gleichen Frameraten benötigt. Wäre aber nicht weiter schlimm, zumal das Multithreading wirklich gut skaliert über alle Kerne und Threads. Die Kombi gute Vielkern-CPU + Mittelklassengrafikkarte könnte also für The Bus eine gute Wahl sein, und in Zeiten von astronomischen Grafikkartenpreisen ist das prima.
-
Ich habe auch zwei Runden gedreht. Grafisch auf jeden Fall gelungen, wenn auch die ganzen Materialien nach Plastik wirken. Die Steuerung und Funktionalität des Busses ist allerdings tatsächlich reinste Arcade, selbst bei Einstellungen wo man alles auf real stellt. Die Busse bremsen schon beim kleinsten drücken auf die Bremse wie bei einer Vollbremsung, und das ohne dass irgendwelche Deadzones oder zu hohe Sensivität eingestellt wäre. Zumindest bei Maussteuerung. Ähnliches beim Beschleunigen: als gäbe es eine Mindestgeschwindigkeit, auf die der Bus sofort ab einer Schwelle schießt, bei höheren Geschwindigkeiten ist das auch sehr sehr unausgewogen. Lenken ist auch eher Glückssache als Präzision. Aus gleichem Grunde hütet der Fernbus Sim bei mir auch ein Schattendasein und kam nicht auf mehr als ein paar Runden. Kein Vergleich zum Beispiel zum Doppeldocker aus Lotus, der sich auf Anhieb wunderbar fuhr, obwohl er noch weit weniger fertig ist als die Scanias in The Bus. An der Fahrphysik muss sich noch sehr sehr sehr viel tun. Man wird tatsächlich übers ganze Spiel den Eindruck nicht los es wäre ein Konsolenspiel für die Couch, was auch die sehr fummeligen Menüs belegen. Aber das stört mich nicht so sehr, am wichtigsten ist das Fahren.
-
Die 15W Variante heisst 2700U und entspricht bis auf 100 MHz im Boost und leicht andere GPU dem 2400G.
-
Der 2400G ist schon fast ein alter Hut, zählt noch zur ersten Ryzen-Generation. Die aktuellen sind um Welten schneller in der Single Core Leistung. Hinzu kommt dass diese Ryzen Generation eine erhöhte Latenz hat wenn sich ein Prozess auf zwei CCX aufteilt, und da wirds bei einem 4 Kerner eng. Mein 1700X hat zwar die gleiche Latenz, aber 8 Kerne, ich kann also OMSI schön auf auf die letzten 4 Kerne legen und nichts kommt da in die Quere und es ist in einem CCX. Unterschied ist spürbar und messbar. Außerdem halte ich vor allem in heutiger Zeit auch für OMSI 4 Kerne zu wenig, es sollten schon 6 sein um das Spiel von sonstigen Prozessen zu trennen. OMSI nutzt einen Kern stark, die anderen 3 aber gerne auch mal bis zu 50%. Bei einem 4-Kerne wird das sehr sehr schnell dann eng und vor allem die Minimum-fps werden leiden und die Frametimes dürften sehr schlecht sein.
Den 2400G würde ich nur noch für extrem günstige Tablets empfehlen. Was gut beim 2400G ist das ist die Grafikleistung, aber auch nur verglichen mit den Intel-APUs und vielleicht der Low-Low-End Klasse bei Grafikkarten wie einer Geforce 1030 etc.
-
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.
-
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;-)
