rFactor 2 | Neues Update mit Build 1114 veröffentlicht

Aston Martin Vantage GTE & McLaren Senna GTR veröffentlicht


Studio 397 hat ein neues, umfangreiches Update für seinen rFactor 2 Rennsimulator bereitgestellt. Nachdem der rFactor2 24h von Le Mans aufgrund einiger technischer Probleme gestoppt werden musste, begann das rFactor 2-Entwicklungsteam gründlich zu analysieren, was während des Ereignisses schief gelaufen war, und ergriff geeignete Maßnahmen zur Behebung der Probleme.


Infolgedessen haben sie nun einen neuen Update-Build für rFactor 2 bereitgestellt. Anstelle der allgemeineren Changelog-Liste entschied sich Studio 397, uns über das folgende Schreiben detailliertere Informationen über das letzte Update zu geben.


Zitat von studio397

Die Veröffentlichung eines neuen rFactor 2 Build ist typischerweise etwas, das wir mit einem klassischen, gegliederten Changelog machen, aber diesmal hatten wir das Gefühl, dass es etwas mehr als das verdient hätte.


Während unseres letzten rF24-Events tauchten technische Probleme auf, die uns keine andere Wahl ließen, als das Rennen rot zu markieren. Wir beschlossen, unsere Prioritäten sofort neu zu gruppieren und auf die Sezierung und Behebung von Problemen auszurichten, die sich als langjährige Probleme erwiesen haben. Es war keine einfache Aufgabe, aber wir rollten unsere gemeinsamen Ärmel hoch und gruben uns ein. Mit viel Unterstützung der teilnehmenden Teams haben wir alle Probleme analysiert und sind zum ersten Mal in der Lage, die meisten davon zu reproduzieren. Ihre Ursache erwies sich als sehr spezifische Kantenfälle bei "rejoins" und "driver swaps", so dass wir uns darauf konzentrierten, diese Funktionen auf möglichst viele verschiedene Arten zu brechen.


So basierten natürlich viele der Ergebnisse auf intensiven und zielgerichteten Tests in den letzten Wochen. Die Notwendigkeit, mehrere Szenarien wiederholt zu testen und nach Lösungen und Workarounds zu suchen, erforderte einen gut durchdachten Ansatz mit einem soliden Verständnis der Probleme aller Beteiligten, sowohl auf der Test- als auch auf der Entwicklungsseite. Dieser intensive Fokus hat uns einen Einblick in die vielen Möglichkeiten gegeben, wie in der Hitze des Rennsports Dinge schief gehen können. Glücklicherweise hatten wir auch die massive Unterstützung der rFactor 2-Community durch Feedback und Stories nach dem Rennen sowie Logging - das war von unschätzbarem Wert und ein enormer Schub, um die Ursache für viele dieser Probleme zu finden, die Menschen in Online-Veranstaltungen haben. Als Team sind wir jeden dieser Berichte sorgfältig durchgegangen und haben nach spezifischen Details gesucht, die uns in die richtige Richtung weisen könnten.


Fahrzeugauswahl und Upgrades


Einer der Hauptbereiche, auf die wir uns konzentrierten, waren Probleme im Zusammenhang mit dem Wiedereintritt nach dem Trennen der Verbindung während einer Sitzung, z.B. wenn die Netzwerkverbindung für einen Moment unterbrochen wird. rFactor 2 hat immer einem Fahrer erlaubt, nach einem Computerabsturz oder Netzwerkproblem wieder an einem Rennen teilzunehmen, aber in einigen Fällen würde der Fahrer bei einem Wiedereintritt in den Server mit einem DNF (Did not finish), einem DQ (Disqualifikation) oder seinem Namen am Ende der Liste als einfach "pending a open session" angezeigt. Natürlich sind diese Ergebnisse falsch und die Frage war für uns: Was löst diese Szenarien aus? Unsere Recherchen und Tests zeigten schnell, dass diese Probleme in den meisten Fällen mit der Wiederaufnahme zusammenhängen und entweder a) der Auswahl eines völlig anderen Autos aus der Fahrzeugauswahl, b) der Auswahl des richtigen Autos mit der falschen Lackierung aus der Fahrzeugauswahl oder c) der Auswahl des richtigen Autos und der Lackierung, aber mit einem anderen Upgrade-Paket.


Sie könnten fragen: "Warum ist das ein Problem, ich wähle immer die richtigen Optionen"? Das mag in 99% der Fälle zutreffen, aber es sind die 1%, die uns hier am Ende wehtun. Es ist schwer sicherzustellen, dass ein Team von mehreren Fahrern immer die richtigen Optionen wählt. Einen Fehler zu machen, stellt sich heraus, verursacht Probleme für mehr Menschen als der wiedereintretende Fahrer, also mussten wir sicherstellen, dass dies nicht mehr passieren konnte.


Um dieses Problem zu lösen, haben wir uns zunächst den Kerncode des Wiedereingliederungsprozesses angesehen, um sicherzustellen, dass alle Optionen in Bezug auf Auto und Upgrades vererbt werden und bei jedem Fahrer bleiben, unabhängig von Trennungen oder früheren Fahrertausch. Das bedeutet, dass, wenn Sie sich mit Auto A und Upgrade X verbinden, es auf eine robustere Weise protokolliert wird, die verhindert, dass die Fahrerhistorie verloren geht. Als nächstes haben wir daran gearbeitet, diesen Prozess benutzerfreundlicher zu gestalten, so dass es eigentlich unmöglich ist, einen Fehler beim Wiedereintritt zu machen. Wir haben das Netzwerkprotokoll verbessert, um Ihrem Kunden mitzuteilen, welches Fahrzeug, welche Ausstattung und welche Upgrades vorher verwendet wurden, damit wir das richtige Fahrzeug für Sie auswählen können. Wenn Sie beispielsweise mit einem BMW M8 GTE mit dem Le Mans-Paket und der Lieferung meines Teams zusammenarbeiten und während des Rennens ein Netzwerkproblem haben und gebootet werden, anstatt die gesamte Liste der Autos, Teamfarben und Upgrades beim Wiedereintritt zu sehen, sehen Sie nur Ihren BMW M8 GTE, und die Option zum Ändern des Upgrade-Pakets ist nicht mehr verfügbar. Sie bekommen Ihr Auto einfach zurück!


Dies bringt uns zu einem weiteren wichtigen Punkt und Nebeneffekt der Wiedervereinigung von Fehlern. Die Wiedereingliederung in das falsche Auto oder Upgrade führte oft zu Verzögerungen und Einfrieren für alle anderen Fahrer, die bereits auf dem Server waren, da jeder gezwungen war, ein anderes Auto in Echtzeit zu laden, während er auf der Strecke war (anstelle des Autos, das in der Garage geparkt wurde, wenn er die Verbindung unterbrach).




"AI Take Over" und Fahrernamen im Pit-Menü festgefahren


Ein wiederkehrendes Problem, das wir gesehen haben, ist, dass, wenn ein Fahrertausch stattfindet, die KI plötzlich ohne Vorwarnung das Auto übernehmen würde.


Dies wurde verursacht, indem man versuchte, das Auto an einen Teamkollegen zu übergeben, der zum Zeitpunkt des Boxenstopps nicht mehr Passagier oder gar auf dem Server war. Standardmäßig wurde rFactor 2 dann so konfiguriert, dass die KI die Arbeit übernimmt. Das stellte sich als schlechte Idee heraus und wir änderten den Code, um dies nicht mehr zu tun. Das bedeutet, dass Sie das Auto von nun an am Ende des Boxenstopps behalten, wenn der übernehmende Fahrer nicht mehr anwesend ist. Dies ermöglicht es dir, weiter zu fahren und einen Fahrertausch mit deinem Teamkollegen erneut zu versuchen, ohne dass die KI das Rennen übernimmt und ruiniert.


Bei der Auswahl eines Fahrers im Boxenmenü blieben die Namen der Fahrgäste in der Liste stecken und konnten ausgewählt werden - unabhängig davon, ob sie den Server verlassen oder nicht mehr mit Ihnen gefahren sind. Das bedeutet, dass du deinen Teamkollegen im Boxenmenü auswählst, er verlässt den Server oder hört auf, mit dir zu fahren, aber sein Name bleibt im Boxenmenü und kann ausgewählt werden. Dies führte zu mehreren Problemen: Beim Trennen/Wiedereinschalten kam es oft zu einem DNF, und wenn ein Name eines Fahrers ausgewählt wurde, der nicht mehr fährt oder den Server verlassen hatte, übernahm die KI. Wir haben dieses Problem behoben, indem wir einfach alle Fahrer aus der Pit-Menü-Liste entfernt haben, die nicht mehr mit dir fahren (wie es die ganze Zeit der Fall gewesen wäre).


Trennen/Wiederverbinden mit dem/den Mitfahrer/n


Trennungen, während ein anderer Fahrer mitfährt, entweder auf einen Fahrertausch wartet oder gerade einen abgeschlossen hat, würden beim Wiedereintritt in einen DNF münden. Zum Beispiel, wenn du auf der Strecke fährst, dein Teamkollege mit dir fährt und du eine Trennung bekommst. Bei der erneuten Teilnahme kannst du nicht mehr Rennen fahren und der Name deines Teamkollegen erscheint nun in der Liste als Fahrer mit einem DNF. Wir haben dies behoben, indem wir sichergestellt haben, dass beim Trennen/Wiedereinsteigen nur der aktuelle Fahrer das Auto behält, alle anderen Teammitglieder einfach als "Passagiere" registriert bleiben und nicht als Fahrer betrachtet werden, bis ein tatsächlicher Fahrertausch stattfindet.


Pit-Menüparameter, die nach dem Rejoin gesperrt sind


Ein weiteres Problem, das wir uns angesehen haben und das wir beheben konnten, war die plötzliche Unfähigkeit, die Menüoptionen der Boxen nach dem Wiedereintritt umzuschalten. Dies war besonders problematisch, wenn Sie eine Trennung mit sehr wenig Kraftstoff hatten und beim anschließenden Boxenstopp nicht mehr Kraftstoff anfordern konnten, letztendlich ging Ihnen der Kraftstoff aus und Sie beendeten das Rennen mit einem DNF. Alle zulässigen Pit-Menü-Optionen im Auto sollten nun bei erneuter Teilnahme zur Auswahl stehen.


Verbesserungen bei der Steam-Integration


Im Rahmen unseres laufenden Profiling-Prozesses, der auf Protokollen basiert, die uns von Anwendern zugesandt wurden, haben wir auch festgestellt, dass die "Echtzeit"-API-Funktionen von Steam kleine Probleme verursachen können. Wir haben das technisch gelöst, indem wir das Original-Plugin verinnerlicht und sichergestellt haben, dass wir solche Funktionen auf einem Hintergrund-Thread ausführen, damit sie unsere Physikschleife nie stören können. Diese Änderung wird sowohl client- als auch serverseitig vorgenommen und bedeutet, dass Sie keine SteamPlugin.DLL mehr in Ihrem Plugin-Ordner sehen werden (und wir haben sichergestellt, dass, wenn sie versehentlich noch vorhanden ist, sie ab diesem Build ignoriert wird).


Schnellere Ladezeiten


Last but not least haben wir auch einige Zeit damit verbracht, den Ladeprozess von Strecken und Autos zu optimieren. Interne Tests haben Verbesserungen im Bereich von 30-50% ergeben, was den Menschen im Allgemeinen helfen sollte. Schnelleres Laden bedeutet natürlich auch, dass Sie schneller wieder beitreten können und insgesamt weniger Zeit verlieren.


Was kommt als nächstes?


Build 1114 ist die erste von zwei geplanten Versionen, um die gefundenen Probleme zu beheben. Wir haben beschlossen, den Prozess in zwei Teile aufzuteilen, indem wir uns zuerst auf die großen Fehler konzentrierten und dann die kleineren. Wir dachten, es sei wichtig, ein Update so schnell wie möglich in die Hände aller zu bekommen, aber erst nachdem wir sichergestellt hatten, dass wir diesen Build nicht mehr brechen konnten. Wie immer empfehlen wir den Mitarbeitern, sowohl ihre dedizierten Server als auch ihre Clients zu aktualisieren und alle Probleme zu melden. Wir setzen uns intensiv dafür ein, dies richtig zu machen und das Online-Erlebnis in rFactor 2 weiter zu verbessern. Wir erwarten, dass wir nächsten Monat ein Update zu diesen Themen erhalten, aber auch hier werden wir uns so viel Zeit nehmen, wie wir brauchen, um sicherzustellen, dass auch diese kleinen Probleme vollständig beseitigt werden.