Alles anzeigen
Hallo zusammen!
Das Stellaris 3.5 'Fornax' Update wird nächsten Dienstag, den 20. September, zusammen mit dem Toxoids Species Pack veröffentlicht. Wir haben @PDX-Loke aus dem Mutagenic Spas herausgelockt, um Euch diese vorläufigen Patch Notes zur Verfügung zu stellen. Tut mir leid, dass sie noch ein wenig feucht sind.
Aber wartet, es gibt noch mehr! Am Montag, den 19. September, um 1700 MESZ werden wir im offiziellen Stellaris-Discord unser Toxoids-Entwickler-Q&A abhalten!
Und jetzt wird @Caligula Caesar übernehmen und einige Dinge zu KI, Leistung und Modding sagen:
Ich werde einen Blick in das Entwicklertagebuch werfen, denn es gibt einige Dinge, die wir im Custodian-Team gemacht haben, die Euch sicher gefallen werden.
KI
Erstens: KI. Wir haben uns nicht besonders auf die KI konzentriert, aber es ist uns dennoch gelungen, eine ziemlich umfangreiche und wirkungsvolle Liste von Verbesserungen zu erstellen.
Uns ist aufgefallen, dass ein besonderes Problem darin bestand, dass die KI ihre Legierungen mit fehlerhaften Logikschleifen vergeudete: Sie baute Sternenbasen aus und baute sie dann wieder ab, oder sie baute Schiffe und löste sie dann wieder auf. Wir haben die Logik in beiden Fällen verbessert.
Bei Sternenbasen wird die KI nun generell vernünftiger mit dem Ausbau ihrer Sternenbasen umgehen. Wir haben zum Beispiel eine Logik behoben, bei der sie sich verzählt hat und dachte, sie sei über der Obergrenze, wenn sie gerade eine Sternenbasis aufrüstet. Andererseits werden nun Upgrades abgebrochen, anstatt eine aufgewertete Station herabzustufen, und es wird auch in Betracht gezogen, Sternenbasen herabzustufen, wenn die Obergrenze während eines totalen Krieges deutlich überschritten wird. Und es wird nicht mehr überall Bastionen spammen, sondern nur noch dort, wo sie nützlich sein könnten.
In Version 3.4 baut die KI keine Verteidigungsplattformen. Dies ist nun korrigiert und ein Parameter wurde hinzugefügt, der dafür sorgt, dass sie nur in der Nähe von Bastionen gebaut werden. Die KI war auch nicht besonders gut darin, Orbitalringe zu nutzen, so dass sie jetzt besser darin sein sollte, sie aufzurüsten und die besten Module und Gebäude zu nutzen.
Was die Schiffe angeht, so wird die KI jetzt nur noch Schiffe auflösen, wenn sie ihre Flottenobergrenze überschritten hat und sie sich deren Unterhalt nicht mehr leisten kann. Diese Korrektur führte zu einem etwas längeren Blick auf die Funktionsweise der KI-Budgets, was zu mehreren Folgekorrekturen führte:
- Es war möglich, den Ausgaben Ressourcen zuzuweisen, die von der KI aktiv ignoriert wurden. Dies führt nun zu Fehlerprotokollen und wird nicht mehr vorkommen.
- Wenn wir einen Maximalwert angegeben haben, den die KI einer bestimmten Ausgabe zuweisen würde, würde sie ihre Ausgaben auf diesen Wert begrenzen, aber nichts von dem Überschuss an anderer Stelle neu zuweisen. Jetzt tut sie es.
Das Ergebnis ist bei den Legierungsausgaben sehr deutlich zu sehen. Die KI hatte oft eine Obergrenze von 60k Legierungen, aber nur etwa die Hälfte davon wurde für Dinge verwendet, für die sie tatsächlich etwas ausgeben würde. Das passiert jetzt nicht mehr, und die KI wird ihre Legierungen jetzt viel eher ausgeben.
Eine weitere besondere Änderung für die Min-Maxer unter unter Euch besteht darin, dass die KI nun weiß, dass Bollwerke gut sind. Im späten Spiel (wenn die KI anfängt, auf wiederholbare Werte zu stoßen) wird sie nun Gebäude, die Flottenkapazität bieten, als wünschenswert erachten. Sie muss zuerst ein solides Einkommen haben, daher ist es wahrscheinlicher, dass dies auf hohen Schwierigkeitsgraden passiert, aber in meinen Tests erreichte sie oft über 4k Marinekapazitätsnutzung auf Großadmiral, während sie früher nur 1-1,5k erreichte.
Gleichzeitig wurde die KI dazu gebracht, Megastrukturen - insbesondere Habitate und Orbitalringe - aggressiver zu bauen. Die KI hatte mehrere Hindernisse für den Bau neuer Megastrukturen, zum Beispiel konnte sie immer nur eine bauen. Außerdem wurde sie in der Vergangenheit unter bestimmten Umständen am Bau von Habitaten gehindert. Die meisten Beschränkungen sind nun aufgehoben, so dass die KI im Allgemeinen Habitate bauen wird, wenn sie es kann, mit ein paar vernünftigen Einschränkungen, wie z. B. keine neuen Habitate zu bauen, wenn es welche zum Besiedeln gibt. Ebenso wird die KI nun immer Orbitalringe über Planeten bauen, wenn sie dazu in der Lage ist. Es gab auch Situationen, in denen die KI nicht weiterkam, z. B. baute sie keine neuen Megastrukturen, wenn sie eine aufwerten konnte, aber dazu gehörte auch die Mega-Art-Versammlung, die eine große Anzahl kleinerer Artefakte benötigt, um zu ihrer endgültigen Inkarnation aufzusteigen, so dass die KI grundsätzlich aufhörte, Megastrukturen zu bauen, wenn sie eine Mega-Art-Versammlung baute. Dies ist nun nicht mehr der Fall, obwohl die KI es immer noch vorziehen wird, zu sparen, um Megastrukturen zu verbessern, wenn sie es kann.
Es gab in der Community einige Aufregung wegen einiger KI-Probleme in 3.4, nämlich dass die KI Verbände verlassen hat, weil sie ihre Vasallen nicht mochte, und dass die KI ein bisschen zu leicht zum Vasallen werden wollte. Glücklicherweise konnten wir beide Probleme lösen.
Was die Logik der KI in der Flotte angeht, so haben wir eine bessere Logik für die KI hinzugefügt, um ihre Flotten während eines Krieges zu gruppieren, so dass die KI-Flotten jetzt viel seltener untätig herumstehen. Außerdem haben wir dafür gesorgt, dass die Prethoryn besser herausfinden, wie sie Kolonien übernehmen können.
Außerdem werden Kriege zwischen KI-Imperien, in denen keine der beiden Seiten die andere erreichen kann, nun dazu führen, dass beide Seiten einem Friedensabkommen im Status Quo sehr viel positiver gegenüberstehen. Dies löst ein Problem, bei dem KI-Imperien oft sehr lange in Kriegen feststeckten, bis ihre Kriegserschöpfung auf 100% anstieg, bevor sie einen Frieden schließen konnten. Dies war vor allem ein großes Problem für völkermordende Reiche, die eine hohe Reduktion der Kriegserschöpfung haben.
Schließlich wurde auf amüsante Weise festgestellt, dass bestimmte KIs Söldnerenklaven errichteten und diese dann sofort angriffen; dies wird nun nicht mehr passieren.
Performance
Nun möchte ich mich der Leistung zuwenden: Ich und einige andere waren mit der Leistung des späten Spiels in Stellaris nicht wirklich zufrieden. Also haben wir mit verschiedenen Methoden versucht, sie zu verbessern. Und, um ehrlich zu sein, sind die Ergebnisse recht vielversprechend.
Im Allgemeinen gibt es drei Möglichkeiten, die Leistung zu verbessern: Umständliche Logik, Zwischenspeicherung und Multithreading. Das ist allerdings nicht so einfach, denn die beiden letztgenannten Lösungen haben einige unangenehme Freunde: Caches hängen gerne mit Out Of Syncs und Rechenfehlern herum, während Multithreading sowohl CTDs als auch OOSes mag. Aber es ist uns gelungen, bei verschiedenen Problemen Fortschritte zu erzielen.
In erster Linie waren die Aktualisierungen der Modifikatoren ziemlich teuer. Wenn man z.B. ein Edikt in seinem Land aktivierte, führte dies zu einer Neuberechnung der Modifikatoren aller Planeten, Flotten, Schiffe und Populationen, die diesem Land gehören. Das bedeutet eine Menge Neuberechnungen, die eine Weile dauern können, da die Aktualisierung der Modifikatoren nicht gerade trivial war - im Grunde genommen benötigen die netten Tooltips in den Pop-Details, die zeigen, woher all die Effekte stammen, eine ganze Menge Rechenleistung, um sie zu erreichen.
Es gibt zwei Verbesserungen an dieser Front in 3.5. Erstens haben wir die Aktualisierungen der Modifikatoren in mehrere Threads aufgeteilt. Zuvor wurde alles seriell durchgeführt, was zu langwierigen Einfrierungen führen konnte, und einige tägliche Aktualisierungen dauerten viel länger als andere. Aus gutem Grund - es gab eine Menge Abhängigkeiten zu entwirren und Abstürze zu vermeiden. Dennoch hatte dies einen ziemlich großen Effekt.
Außerdem ist mir aufgefallen, dass Pops Modifikatoren hinzugefügt wurden, die irrelevant waren, wie z.B. Megastrukturkosten-Modifikatoren. Also wurde den Wirtschaftskategorien ein zusätzlicher Parameter hinzugefügt, um festzulegen, wo die Modifikatoren hingehören, was zu einer Zeitersparnis von weiteren 20 % bei der Neuberechnung der Modifikatoren führte.
Abgesehen davon haben wir eine ziemlich große Verbesserung erzielt, als wir feststellten, dass unser Multithreading-System gelegentlich ausfiel und alle Threads mehrere Millisekunden lang aufeinander warteten. Dadurch wurde das Multithreading bei relativ schnellen Operationen im Durchschnitt langsamer, und selbst dort, wo es sich noch lohnte, war es langsamer, als es sein müsste. Glücklicherweise konnte unser technischer Direktor die Situation retten und diesen Wahnsinn stoppen, was das Spielerlebnis unermesslich verbesserte.
Dies ist nur ein kleiner Vorgeschmack auf die Dinge, die wir getan haben. Im Grunde wurde viel Zeit damit verbracht, ein absichtlich absurdes Spiel zu analysieren - es wurde auf maximales Bevölkerungswachstum, Technologiefortschritt, Galaxiegröße und bewohnbare Planeten eingestellt und dann ohne Krisen oder gefallene Reiche bis 2730 durchgespielt. Das Spiel ruckelte ganz schön (ich meine damit, dass es 11 Minuten für ein Jahr brauchte), aber es stellte sich heraus, dass der Hauptgrund dafür die Bewegung der Raumschiffe war. Ich konnte dieses Problem auf keinem normalen Spielstand reproduzieren - es tritt wahrscheinlich nur während der Schlacht auf, und es waren vermutlich einige extrem große Schlachten im Gange - aber durch Multithreading wurde das Spiel tatsächlich etwas vernünftiger.
Von da an gab es eine Menge inkrementeller Korrekturen, die möglich waren. Zum Beispiel verbrachte das Spiel mehrmals am Tag ziemlich viel Zeit damit, herauszufinden, ob ein System Kolonien enthielt - etwas, das ganz einfach zwischengespeichert werden konnte. (Dachte ich zumindest. Zwei OOS-Fixes später bereute ich das). Ein weiterer großer Übeltäter waren die Kriege: Ein Land hatte keine zwischengespeicherten Kriege, in denen es kämpfte, sondern berechnete stattdessen alle Kriege, in denen es kämpfte, neu, wann immer es Informationen über einen der Kriege brauchte, in denen es kämpfte. Das war natürlich ziemlich ineffizient und zum Glück auch gut speicherbar. Wenn das Spiel dann herausfand, um welche Art von Sternenbasis es sich handelte (z. B. "Bastion") - und das geschah alle paar Frames in der Übersicht -, ging es alle verschiedenen Arten von Sternenbasen durch und entschied, welche am besten geeignet war - die Antwort? Cache, Cache, Cache.
Wir haben auch die Zeit verkürzt, die die KI brauchte, um zu entscheiden, wo sie Zweigstellen einrichten sollte. Dann fiel uns auf, dass die meiste Zeit, die für die Aktualisierung der Länder in Serie aufgewendet wurde, für die Bewertung der Gültigkeit ihrer Richtlinien verwendet wurde - etwas, das wir in einen Thread einbauen könnten. (Ok, das ist nicht ganz so einfach: Wir könnten die Berechnung im Thread durchführen, das Ergebnis zwischenspeichern und dann das Ergebnis in die nächste serielle Aktualisierung implementieren, die im Grunde direkt danach stattfinden würde). Schließlich sollten die monatlichen Aktualisierungen etwas schneller sein, da wir eine ähnliche Logik für die Berechnungen verwendet haben, welche Pops sich zusammensetzen, wachsen und abnehmen sollten, und außerdem etwa 50 % der Job-Cache-Neuberechnungen bei automatischen Migrationen entfernt haben.
Abgesehen von mindestens drei OOS und zwei Abstürzen, die mit dieser Arbeit eingeführt und behoben wurden, stellten wir nach einer Weile fest, dass das Spiel nicht ganz so schnell war, wie wir es erwartet hatten. Tatsächlich fror es alle paar Tage vorübergehend ein. Es stellte sich heraus, dass dies daran lag, dass - dank einiger Logikkorrekturen mit unbeabsichtigten Folgen - die KI sehr genau darüber nachdachte, wo sie ihre Megastrukturen platzieren sollte. Es waren also einige Änderungen erforderlich, um die teureren Kontrollen dort zu platzieren.
Welche Auswirkungen wird dies alles haben? Nun, ich kann keine bestimmte Zahl versprechen, und zwar aus verschiedenen Gründen. Zum einen wurden die meisten dieser Verbesserungen im Juli vorgenommen, und es ist immer möglich, dass wir in der Zwischenzeit neue Ineffizienzen hinzugefügt haben (z. B. die Sache mit den Megastrukturen). Außerdem ist ein Spielstand von 3.4, insbesondere wegen der KI, nicht sehr gut mit einem Spielstand von 3.5 vergleichbar, da sich die KI bei der Erstellung dieses Spielstands anders verhalten hat (andererseits kann man einen Spielstand von 3.5 nicht in 3.4 laden, da er mit ziemlicher Sicherheit abstürzen wird). Außerdem kann es sein, dass in einem bestimmten Spielstand eine bestimmte Sache vor sich geht, die zu einer Verzögerung führt (z.B. das bereits erwähnte Problem mit den Raumschiffen, das ansonsten kein Problem zu sein schien). Und manchmal sind Computer einfach launisch und verwenden ihre Ressourcen für andere Dinge als für das Spiel. Als ich das letzte Mal Tests auf der Grundlage von 3.4-Speicherständen durchführte, war es jedoch mehr als 30 % schneller. In meiner letzten Kampagne im späten Spiel ist es nicht gerade schnell (das späte Spiel wird nie so schnell sein wie das frühe Spiel - im frühen Spiel ist so wenig los, dass die Leistung in erster Linie davon abhängt, wie schnell die Frames gerendert werden), aber es fühlt sich definitiv weniger langsam an. Aber ich bin gespannt, was die Leute denken, und ob sie meinen, dass mehr Aufwand nötig ist.
Modding
Finally, as per tradition, modding. There’s a few cool additions we made. The biggest of the lot is inline script: basically, you can specify “inline_script = my_script” somewhere else in the game. (Works in most places, but not all). Then the game will look for a file called “my_script” in common/inline_script, and paste the contents of that file in where you specified it should be used.
This lets you reuse script so you have to do less copy-pasting, which is a blessing. There are no particular performance concerns with it, although if used on a particularly large scale it could affect startup time and potentially memory usage. (Unfortunately, I have not tested what a “particularly large scale” would be. Certainly hundreds of usages would be fine. It would probably make things slower once you get into the hundreds of thousands).
The second big thing for modders is the script profiler. It’s now available to the public using the console command “script_profiler”. Use once to start profiling, and again to finish and print the results. So now you can find out exactly why your mod is causing performance issues. Although its coverage of script is more like 90% than 100%, and it doesn’t really cover UI issues, so it’s good, but won’t be useful in absolutely all cases.
Aside from this, here’s some highlights:
- You can now use @ in event targets. So “save_event_target_as = something@root”. Although be warned, it doesn’t handle dot scoping very well and probably won’t do what you want it to do if you try something like something@root.owner.
- You can stick in a custom_tooltip for planetary features now. So they can have custom effects that are displayed in nice ways.
- Fixed some issues that stopped you from making a Situation with an end value not equal to 100. Now you can extend them to your heart’s content, or rather to the maximum bounds of our fixed points.
- Added country_naval_capacity_contribution_from_subjects_mult and country_naval_capacity_contribution_to_overlord_mult modifiers, which add a percentage of the subjects' naval capacity to the overlord, without reducing the naval capacity of the subject. Note that these modifiers are not intended to be negative.
- Added effect to set a leader immortal, as well as a trigger to check if the leader is immortal
- Added has_forbidden_jobs trigger which checks if a planet has a deprioritized job of a certain type
- Added script list for owned_nonprimary_starbase, since owned_starbase only returns primary starbases (so no orbital rings)
- Added width and density values to asteroid belts allowing you greater control if not declared default is set to 1.
- check_economic_production_modifier_for_job now correctly factors in triggered pop modifiers from traits (specifically worker/specialist/slave ones). It also should be slightly faster
- Fixed starbase module on_finished/aborted/queued/unqueued
- Habitability ceiling and floor modifiers can now be applied directly to a planet (not just to a species)
- modify_species now correctly lets you specify multiple add_trait or remove_trait entries
- Allowed you to use script values in loc by defining them as a value in a scripted loc entry
- Added effect to enable possibility to set/update settings of the fleet after its creation.
(Anmerkung des Übersetzers: Da das Thema Modding hier im Forum keine Rolle spielt habe ich mir die Übersetzung gespart.)
Was steht als Nächstes an?
Toxoids und „Fornax“ werden nächsten Dienstag veröffentlicht, und danach sollten wir zu unserem regulären Tagebuch-Zeitplan zurückkehren.
Stellaris Entwicklungstagebuch #267 - 3.5 'Fornax' Patch Notes, KI, Performance und Modding
-
-
So, fertig.
Bitte genau durchlesen, kommende Woche schreiben wir eine Klausur zum neuen Patch und dem DLC und wehe Ihr habt nicht gelernt. 
Es kann sein, nein, wie ich Paradox kenne, wird es kommende Woche nochmals einen Beitrag mit Patchnotes geben. Wenn sie die Änderungen nicht extra angeben werde ich es mir verkneifen die nochmals zu übersetzen.
