Hat jemand vielleicht eine Liste mit den weiteren Tastatur-Events?
Noch paar Fragen zur PL-Version:
Auf Fikt. Szczecin fahren sie bei mir ohne Kennzeichen rum, auch beim eigenen Bus. Woran kann das liegen? Und ich habe keine polnischen Umlaute auf den Matrix-Anzeigen, obwohl ich die HOF-Datei der Strecke verwendet habe, die so wie ich verstanden habe für diese Variante des Solaris gedacht ist.
Für OMSI 2 lohnt eine NVME tatsächlich nicht. Ich hatte bei mir OMSI auf diversen SSDs (zwei mal SATA und einmal Samsung NVME) und es macht null komma null Unterschied. Der Flaschenhals ist hier nicht der Durchsatz sondern OMSI selbst...
Ansonsten ist die Zusammenstellung von ZoraxDave gut. Im Hinblick auf OMSI würde ich aber eventuell bei der Grafikkarte versuchen was einzusparen und nicht zur 2070S greifen. Eher auf 2060er oder vergleichbare AMD Karten setzen und das gesparte Geld in 3600er RAM stecken.
Falls wirklich selber zusammengebaut wird: beim Netzteil auf ein modulares setzen. Ist etwas teurer, aber praktischer beim Bauen und man hat stets ein aufgeräumtes Inneres. Lässt man es zusammenbauen und plant nicht mittelfristig weitere Aufrüstungen dann kann es auch non-modular sein. Läden wie Mindfactory verkabeln es schon vernünftig. Und wenn man denen zum Beispiel sagt dass man z.B. den Einbau einer weiteren SSD plant, werden die entsprechend das vorbereiten.
Aber bloß nicht erwarten dass OMSI perfekt läuft. Das würde es nicht mal wenn Du 5000 Euro ausgeben würdest.
Man sieht im Taskmanager leider nur die Gesamtauslastung, Du siehst da also nicht welches Programm Deine Kerne auslastet. Kann aber sein dass man auch das irgendwo da einstellen kann... Ich ham OMSI mehr oder weniger isoliert damit es Kerne rein für sich zur Verfügung hat und da nichts anderes auf diesen läuft während OMSI aktiv ist. Das mach ich mit dem Tool "Prozess Lasso" und Teile OMSI Kerne 5 bis 8 zu (3 bis 8 brachte auch nur 4 Spitzen...), während ich mein OS und alles andere auf 1 bis 4 reduziere. Und dort beobachte ich immer bis zu zwei OMSI-Threads mit einer hohen Auslastung, und zwei bis drei mit einer geringeren. Man sollte aber die mit der gerinigeren nicht vernachlässigen: wenn auf einem Quad-Core System diese sich reinzwingen müssen mit anderen Threads zusammen kann das schon einen Unterschied machen.
Ich bin mal gespannt was das Windows 10 November-Update bringt. Den Informationen nach soll sich was am scheduling ändern. Vielleicht kriegt es dann Windows endlich von alleine in solchen Szenarien sinnvoll die Last zu verteilen.
Bei der "Trennung" wie ich sie mit Prozess Lasso mache sollte man auch Eigenheiten der CPU beachten. Zum Beispiel ist es in meinem Fall so, dass die CPU-Architektur (erste Ryzen-Gen, 1700X, 8 Kerne 16 Threads) aus zwei Compute-Complexes (CCX) besteht. Die 8 Kerner teilen sich auf in zwei CCX je 4 Kerne, die 6 Kerner in zwei CCX je 3 Kerne. Die Latenz in der Kommunikation zwischen den CCX ist aber etwas höher als innerhalb. Läuft also ein Programm in beiden CCX je 2 Threads, könnte das schlechtere Leistung bringen als wenn sie 4 Threads in einem CCX fährt. Daher bekommt OMSI bei mir die Cores 4 bis 8. Die neueren Ryzens haben da viel geringere Latenz, es gibt sie aber noch. Bei anderen Architekturen, zum Beispiel Intel seit Sandy Bridge ist das wiederum nicht so ein Thema, aber eventuell muss man da wieder auf andere Dinge achten.
Wobei eine Frequenz von 3600MHz dann doch ganz schön ins Geld gehen kann. 3200MHz unterstützen die neuen Ryzen-Prozessoren bereits ohne OC und entsprechend in Ordnung ist hier dann auch das Preis-Leistungs-Verhältnis (unter 70€ für 16GB DDR4-3200 CL16). Bei 400MHz zusätzlich kommt man bei gleicher CAS-Latenz auf einen Preisunterschied von ca. 100€ und die Unterschiede in diversen Benchmark-Tests sind eigentlich kaum wahrnehmbar. Da ist die Frage ob einem der minimale Unterschied so viel Geld wert ist, genauso wie beim Verbau eines Ryzen 7 3800X anstelle eines Ryzen 7 3700X, der ca. 60€ günstiger ist und nur 100MHz mehr im Boost erreicht.
Ich würde mal behaupten dass bei CPU-lastigen Spielen es mehr bringt sich einen 3700X mit 3600er RAM zu holen als einen 3800X mit 3200er. Der schnellere RAM bringt nur bedingt höhere Durschnittsframeraten, "untenrum" sorgt er aber für Stabilität, sprich weniger Spikes runter. Und bis 3600 MHz skalieren die neuen Ryzens ziemlich gut, ab da gibts ein Loch wegen dem Speicherteiler, weshalb es dann wieder erst ab 4500 MHz (+/-) ungefähr wieder spannend wird, was aber absolut nicht mehr im Preis-Leistungs-Rahmen ist. Ich würde bei den ganzen R7ern empfehlen zu gutem Speicher zu greifen und nur unterhalb davon Überlegungen anstellen ob man da was sparen kann. Und wer einen 3800 überhaupt erwägt, dem wird der Unterschied bei den RAM Preisen egal sein. Wenn man aber wegen dem Preis zwischen einem 3700er und 3800er schwankt, ganz klar 3700X + 3600er RAM.
Nabend zusammen
Lohnt es sich bei Omsi auf einen 8 Kerner zu setzen, oder reichen 6? Bzw. spürt man einen Unterschied, oder nicht?
Danke für eure Antworten
Da ich Process Lasso immer aktiv habe und auf dem Zweitmonitor sehe was da so passiert kann ich Dir folgende Erfahrung mitteilen: OMSI hat einen Hauptthread und meistens bis zu 3 Nebenthreads. Sprich theoretisch bist Du sogar mit einem Vierkerner sehr gut bedient. Aber: das Betriebssystem, Dein Virenscanner und vor allem Dein Browser nehmen sich immer mal CPU Zeit. Somit hat OMSI so gut wie NIE, und gerade dann nicht wenn es das brauchen würde, seine Kerne alleine für sich zur Verfügung in einer normalen Betriebsumgebung. Du kannst zwar viel per Hand im Taskmanager abschießen, aber gerade wenn Du irgendwas von Google (aber auch anderen) installiert hast, werden die sich trotzdem immer wieder im Hintergrund zuschalten und wertvolle Ressourcen klauen. Mehr Kerne schafft hier auf jeden Fall Freiraum. Meine Faustregel ist dass man immer zwei Kerne mehr haben sollte, als die Software es eigentlich bräuchte, aber "doppelt so viel" ist noch besser, weil man sich dann eben weniger kümmern muss. Wenn also OMSI Dein wichtigstes oder am meisten forderndes Spiel ist: 6 Kerne ist okay, mit 8 hast Du weniger sorgen. Aber ganz wichtig: es geht hier nicht um die maximalen oder durchnittlichen fps, sondern um weniger Unterbrechungen des Spielflusses durch plötzlich abfallende Framerate. Die hat man trotzdem immer mal, weil der Code einfach alt ist, aber schon deutlich weniger. Aber ich würd auch dringend raten nicht wegen OMSI aufzurüsten, sondern wenn dann wegen anderen Spielen, Programmen, die mehr Nutzen draus ziehen. Meine erwähnte Kern-Regel gilt dann aber auch;-)
Beim Umstieg vom i7-920 (OC 3,4 GHz) auf R7-1700X (OC 3,8 GHz) war der Unterschied enorm, welcher auf die wesentlich höhere Single-Core Leistung zurückzuführen war. Solch ein Unterschied würde das jetzt nicht sein, aber man kann schon Schlüsse aus anderen Engines ziehen. X-Plane 11 ist zum Beispiel ähnlich: sehr CPU-Single-Core lastig und unoptimiert. Aber allein ein Umstieg von der Ryzen 2000er Serie auf die 3000er bringt da eine enorme Steigerung, weit über dem was zu erwarten wäre von reinem IPC und Taktunterschied. Offenbar gehen die 3000er viel besser mit schlechtem unoptimierten Code um als die Vorgänger, was für OMSI durchaus Hoffnung macht. Was noch fehlt sind hier konkrete Ergebnisse und Vergleiche. Aber ich bin mir jetzt schon auch sicher dass z.B. mit langsamen RAM auch die neuen CPUs schlechter performen werden als mit schnellem. Bei den 3000ern erreicht man mit DDR4-3600 so ziemlich das Optimum dann.
Ist eigentlich jemand in der Community im Besitz eines Ryzen-Prozessors der 3. Generation und kann etwas zur durchschnittlichen Performance auf üblichen großen Karten wie "Ahlheim und Laurenzbach Updated" insbesondere in dessen Problembereichen wie Hauptbahnhof sagen (dazu ein Screenshot aus den Grafikeinstellungen wäre zudem hilfreich).
Viele Grüße
Oldenburger
Ich plane einen Umstieg vom 1700X auf den 3900X. OMSI skaliert eigentlich gut mit der reinen Kernleistung und dem Takt. Ich würde mal ganz grob drauf tippen dass bei gleicher Taktfrequenz 1000er zu 3000er Serie schon mal eine Steigerung von 10-15% zu erwarten ist. Da die 3000er aber höher boosten kommt da auch gut was drauf noch. Realistisch hätten wir dann knapp 25% Plus, was sich gerade an kritischen Stellen auszahlen sollte wo man zum Beispiel derzeit mit um die 20 fps rumkrebst. Ihr solltet aber wenn Ihr umsteigt das bei exakt gleichen Einstellungen vergleichen. Und wesentlich interessanter wäre ob sich auch leicht das Nachladeverhalten bessert, denn in diesen Momenten wird meist der Kern maximal belastet.
Danke für die ausführliche Erklärung! Dieses "zwischen den Frames arbeiten" ist das Hauptübel bei OMSI, nicht nur bei Bremsscripten sondern vor allem auch beim Nachladen vom Terrain etc. Müssen wir mit leben. Ich bin tatsächlich nach langer Zeit den NL/EN von M&R gefahren und habe auch auf das Bremsen geachtet. Es ist so wie Chrizzly schreibt: die Phänomene sind die gleichen, nur eben unauffälliger. Aber man merkt sie, vor allem in framemässig traditionell schwierigen Bereichen. Bei 144fps würden wir vermutlich garnicht über dieses Thema reden.
Ich wollte nicht dass in diesem Thread rumgehackt wird auf dem Entwickler, sondern wollte einerseits wissen was da Stand der Dinge ist und andererseits ob es vielleicht andere Lösungsansätze / Hotfixes gibt. Da ich selber mit meinen Einstellungen und ailisten immer versuche weitgehend über 30fps zu sein ist das auch kein Drama, nur eben unschön.
Die Kopfbewegungen haben auf jeden Fall erheblichen Einfluss drauf, und ein an/abschalten macht große Unterschiede. Von daher stimmt die Aussage auf jeden Fall dass ein abschalten Besserung bringt. Es ist aber bei OMSI grundsätzlich so dass Bremsscripte Performance einnehmen, sogar die M&R Busse, Nur fällt es eben bei manchen weniger auf, bei anderen mehr. Also selbst wenn der Bug beseitigt wird, es wird immer Situationen geben wo man beim Bremsen leichtes ruckeln spüren wird, je weniger fps desto heftiger. Ob mit Kopfbewegungen oder ohne.
Yes, on the MAN I use the AI variant, and indeed the lights.osc is not used, just those ones:
But the Urbino has no separate AI version and behaves the same. And here the script structure is much different (maybe only by name), it even has no lights.osc, I'm not sure which script would be the equivalent here.
Es ruckelt immer, nur ist es bei weniger fps deutlich wahrnehmbarer. Selbst bei 40-50fps ist es wahrnehmbar und fühlt sich nicht flüssig an, auch wenn die Framerate anscheinend stabil bleibt. Bei unter 30 wirds aber unerträglich.
In the MAN's lights script your quoted part looks exactly the same, but the busses behave different when having a break, so it might be another section of code.
Ich habe die Steam-Version, gemäß aufgespieltem Changelog müsste es die 1.01 sein. Nach Erscheinen des Addons tauchte schon ein Thread bezüglich des Bremsruckelns auf, welches sich aber offenbar auf die 1.0-version bezieht: Urbino II Bremsruckeln
Es sollte ja im Patch gehoben werden, als vorübergehenden Workaround wurde genannt die Kopfbewegungen abzuschalten. Das funktioniert auch, allerdings hat die aktuelle Steam-Version immer noch diesen Bug. Das Abschalten der Kopfbewegungen ist leider langfristig keine Lösung, da sich so das Fahren ziemlich steif anfühlt, und wenn man kein Lenkrad mit Forced Feedback hat kriegt man bei abgeschalteten Kopfbewegungen eher nicht mit wenn man dabei ist am Bordstein zu schleifen. Wird das also noch irgendwie angegangen hier eine "saubere" Lösung zu bekommen?
Was auch nirgends erwähnt wurde bisher: mich wundert etwas das Anfahrverhalten der Gelenkvariante. Während der Solo ganz normal losfährt wie man es gewohnt ist und man theoretisch sogar mit Kickdown los sprinten könnte, würde sich der G nicht von der Stelle rühren. Egal ob nach Haltestellenhalt oder an der Ampel, das Ding kommt nur ganz träge vom Fleck weg. Mir als Maus-Fahrer kommt es vor als müsste ich um loszufahren erst etwas Gas geben, dann leicht abbremsen und dann wieder beschleunigen, ansonsten ist die aktuelle Ampelphase schon rum... Eine gewisse Trägheit hat ein Schub-Gelenkbus ja durchaus, aber das wirkt hier irgendwie als wäre es ein 20-Wagen-Zug mit Schublokomotive und nicht bloß ein 18-Meter-Bus. Ich weiss nicht ob das in der Form so gewollt ist. Ich kann mir auch vorstellen dass es nicht bei allen Steuerungsmethoden auftritt, kann es aber definitiv für die Maussteuerung beschreiben.
Moin!
Mir ist aufgefallen dass die Stadtbus MANs und Urbinos im KI-Betrieb an den Endhaltestellen die ganze Zeit den rechten Blinker an haben. Die Ursache wird wohl die gleiche sein, denn ich denke mal das Scriptkonstrukt ist das gleiche. Die OMSI-Standardbusse blinken ja beim Anfahren der Endhaltestelle, sobald sie jedoch den Motor abschalten wird auch der Blinker vorübergehend deaktiviert. Beim Weiterfahrten fangen sie dann wieder an zu blinken. Der Stadtbus-MAN und Urbino blinken aber durch, was ich ziemlich irritierend finde. Gibt es da Lösungsansätze?
Es gibt keinen perfekten PC für OMSI. Und wenn es den gäbe hätte er vielleicht 128GB RAM im Quad-Channel (davon das meiste für die OMSI-RAM-Disk), einen 6-Kern-Prozessor von dem 4 Kerne gleichzeitig in der Lage sind mit 10-12 GHz zu laufen. Damit hätte man zur HVZ am Rathaus Spandau mit Mühe und not 40 FPS bei zwei Nachbarkacheln. Mutmaßen kann man darüber wie das Nachladeverhalten dann wäre. Ich tipp mal drauf dass trotz RAM-Disk es immer noch stocken würde.
Bei den Einstellungen ist es so, dass diese nicht nur von PC zu PC unterschiedlich sein müssen, sondern auch von Karte zu Karte. Wenn man alleine X10 mit Original-Spandau vergleicht verhalten sich beide Karten so untertschiedlich dass man eben nicht die gleichen EInstellungen haben kann. Spandau hat FPS-Probleme wenn dann am Rathaus, ansonsten durchweg hohe raten. X10 ist FPS-hungriger mit Einbrücken am Zoo und paar wenigen anderen Stellen. Dafür krankt Spandau sehr am unerträglichen Nachladeverhalten, während X10 da besser läuft. Also muss man beispielsweise in Spandau die Nachbarkacheln durchaus erhöhen auf 2 oder 3 mit Reduktion bei unter 25 fps, während man bei X10 diese am besten auf 1 lässt. Andere Karten, andere Maßnahmen nötig...
Marc schrieb ja das mit dem Datum in den global-cfg. Vielleicht muss man auch penibel aufpassen dass die valid-Werte in den car-use Dateien exakt zu den Chrono Events passen und vielleicht nicht wie bei von Jesu Christi Geburt bis zum Weltuntergang gelten, denn wenn das schon so penibel eine Rolle spielt könnte da noch mehr sein. Oder bei irgendwelchen Ungereimtheiten in der AI List. Aber schon selten dass es bei manchen Linien klappt und bei manchen nicht, nur erkenne ich da keinen Zusammenhang...
Ausserdem weiss ich nicht ganz in wie weit man verschiedene Modi wie types prefered oder types tour kombinieren kann. Die Beispiele von M&R zeigen dass das geht, z.B. bei dem einen 92er Beispiel wo sowohl ganz spezielle Wagen speziellen Touren zugewiesen werden als auch ein Wagentyp bei einer Tour.
Also ein Map-Update im Falle von Spandau ist nicht zu erwarten;-)
Aber sehr interessante Lösung: die Taxis stehen dann quasi im Stau an der Stelle, mal mehr oder weniger, und sind sind jeweils über die ailist_#upd austauschbar...
Ich habs jetzt aber so gelöst auf der X10 Karte dass ich die per Hand getauscht habe. Geht ja eigentlich ganz gut von statten wenn man sie findet. Bei X10 brauch ich auch die alten nicht... Bei Sprandau verfahre ich ähnlich,a ber per Chrono, da ich mir offen halte auch mal wieder in der Vergangenheit zu spielen.
Moin!
Bei der Modernisierung von Spandau kam ich wieder auf die Idee den Fahrzeugeinsatz per car_use Ordner zu steuern. Aber ich habe den Eindruck dass das irgendwie nicht so läuft wie es soll. Meine AI-Liste dürfte pro Fahrzeugtyp eigentlich ausreichend Wagen haben um sie entsprechend zu Verteilen:
Sie wird am 01.01.2010 mit einem Chrono-Event aktiv und funktioniert auch: alle PKWs sind ausgetauscht damit, es verirrt sich auch kein SD200 mehr auf die Linien. So weit so gut.
Am Rathaus Spandau sehe ich aber auf den Linien 638 und 657 die meist gemeinsam pausieren dass dort nur EN92er Wagen eingesetzt werden. Dabei müssten laut beiden Dateien im car_use Verzeichnis überwiegend Gelenkbusse auf den Linien sein (wobei ich mir das noch genau überlegen werde, ich sehe schon wie sie da die zweite Spur blockieren...).
Hier die Datei beispielhaft für 638:
Der Hof "Havelland" (siehe oben AI-Liste) hat ja vor allem ausreichend GN92er, und trotzdem sehe ich nur die ENs.
Das Datum unter [valid] ist bewusst auf "fast immer", da es so eigentlich alle Zeiträume abdeckt. Auch die Gültigkeit der Karte ist in der global-cfg auf mindestens bis 2030 erweitert, getestet wurde mit aktuellem Datum 2019.
Auf anderen Linien ist es ähnlich. Einzig beim 145er sehe ich eigentlich nur noch Gelenkbusse des Typs Solaris und MAN NG 313, so wie es gemäß meiner Definition sein müsste:
Also warum scheint das eine zu funktionieren und das andere nicht?
An dieser Stelle danke an Marc1972 , irgendwo habe ich in einem Uralten-Thread gesehen dass Du zu dem Thema meintest man müsse in der global.cfg das Datum für die Gültigkeit der Karte anpassen. Das habe ich getan, aber sehe keine großen Auswirkungen. Ausserdem erfüllt Spandau mit dem Einsatz der StnLinks eine weitere Voraussetzung für das Funktionieren von car_use, was ja auch genutzt wird für die 54er/94er und andere Besonderheiten. Aber vielleicht hast Du eine Idee woran es hier haken könnte?
Moin!
Ich möchte auf einigen Maps die stehenden Taxis austauschen an den Taxiständen, da es meist der olle Mercedes und zum restlichen modernen Verkehr nicht ganz so passt. Jetzt wäre die Frage was da am sinnvollsten ist. Denn einerseits könnte man die neuen Taxen als Objekte hinzufügen zum Beispiel aus den parked-Versionen der KI-Taxen, aber dann sind sie immer da und bei einem neuen Tausch würde die ganze Arbeit von vornelos gehen. Ich könnte aber auch eine neue parklist erstellen mit einem Index und es mittels parking car Objekt zuweisen. Problem was ich hier sehe wäre dass dann aber keine Schlange von Taxen da wäre sondern halt je nach Einstellung in den Optionen wären diese Slots zufällig mit Taxen gefüllt. Oder lassen sich die parking cars Objekte irgendwie so Verküpfen dass sie eine Schlange bilden, also vom Anfang bis X mit Autos aufgefüllt werden?
Wie würden das die Profis unter Euch lösen?
Eine Grafikkarte wird in OMSI dann wichtig wenn man mit hohen AA Stufen fahren möchte um die Bildqualität zu verbessern. Ab 4x AA samt 4x SGSSAA wirds merklich ob eine Grafikkarte ebenfalls zum limitierenden Faktor wird oder nicht. Ich zum Beispiel fahre mit besagter Einstellung und habe eine GTX1080, welche den Boost knapp über 2 GHz dauerhaft hält. Geh ich nun weiter beispielsweise auf 8x / 8x merke ich schon die ersten Einbußen, während bei allem drunter es keinen Unterschied macht. Als ich einen Rechner mit einer GTX 970 hatte war dieses 4x/4x Setting nicht sinnvoll. Grob gesagt: um mehr Qualität aus dem Bild bei gleichen FPS rauszuholen bringt eine moderne Grafikkarte schon was, nicht aber um bei Standard-Settings die FPS erhöhen.
Zur Kernfrage:
OMSI nutzt hauptsächlich zwei Threads. Theoretisch langt dafür ein Dual Core. Praktisch ist es aber so dass mit mehr Kernen der PC bzw. das Betriebssystem den Threads unter Last mehr Luft verschafft. Und allein schon ein sauberes Windows 10 wurschtelt so einiges im Hintergrund, was häufig sich durch stottern und niedrigere Minimum-FPS sich bemerkbar macht. Je weniger Kerne desto mehr muss man sorge tragen dass nichts im Hintergrund dazwischen funkt. Mein Schritt von 4 auf 8 Kerne vor zwei Jahren hatte ungefähr den gleichen Aha-Effekt wie der Einbau der ersten SSD: alles war immer ansprechbar und lief stabiler, selbst die Gurken-Programme die nur einen Kern nutzten, den aber auslasteten. Ich würde heutzutage bei wenig Budget mindestens auf 6 Kerne setzen, aber mit Option auf mehr aufrüsten zu können. Hier ist natürlich die AMD-Plattform im Vorteil, denn das geht je nach Board mit einfachem CPU-Tausch sogar bis zum 16-Kerner. Ansonsten würde ich schauen was noch so gespielt wird und was da so an Kernen genutzt wird und dann nochmal 4 Extra Kerne drauf legen wenn es das Budget zulässt um eben diesen Headroom zu haben und eben diesen Spielen wirklich freie eigene Kerne zur Verfügung stellen zu können.
Ob AMD oder Intel ist einzig eine Preisfrage, da bei der 3000er Serie auch die Single-Core Leistung ähnlich ist. Bei einem Spiel mehr auf AMD- beim anderen mehr auf Intel-Seite, meist aber im Rahmen des kaum wahrnehmbaren. Anders verhält es sich etwas bei alten Titeln. Hier haben Intel-CPUs Vorteile, weil früher einfach nicht entsprechende AMD CPUs da waren. Allerdings sprechen wir auch wirklich vom oberen Ende und vergleichen die aktuellen Generetionen wie z.B. R7-3700X vs i9-9900K. Der erstgenannte dürfte natürlich alle unter dem 9900K bis auf wenige Ausnahmen schlagen. Aber es würde mich nicht wundern wenn der 9900K in OMSI besser performt als der 3700X. Pauschal zu sagen "Intel ist besser als AMD" oder "AMD ist besser als Intel" ist fast so als würde man zwei Autos allein aufgrund der Farbe vergleichen.
Vielen Dank! Das wäre eine (Teil-) Lösung gewesen. Ich habe es aber nun hinbekommen mit der Steam-Reparatur-Funktion. Einfaches Häkchen bei den Addons wegmachen und neu setzen brachte da wirklich nix, und es fehlten noch zig mehr Fonts wie ich danach feststellen musste;-D
Ich frage mich nur was da passiert sein muss, denn das Font-Verzeichnis rühre ich nie selber an. Auch seltsam dabei ist der Umstand dass ich ursprünglich X10 von DVD installiert hatte (Steam es also erstmal auch nicht listete), die "Fehler" aber zum Anlass nahm mir die Steam-Version zu besorgen, was ich eh längst tun wollte bei irgendeinem Sale. Aber anstatt dass die Steam-Version vollständige Daten zu liefern ebenfalls nur die 6 Font-Dateien installierte beim ersten Mal, ebenso beim zweiten. Ziemlich kurios wie ich finde;-D
Aber nun ist es erledigt, läuft. Vielleicht hilfts mal jemanden der ein ähnliches Problem hat.
