ZoomIm Rückblick auf den Juni war auch der Monat der die Halbzeit des Jahres markiert aus Sicht von Studio 397 ein Feuerwerk an Highlights für rFactor 2. Neben den virtuellen 24 Stunden von Le Mans, die aber nicht ganz glatt liefen - doch dazu später weiter unten mehr -, konnten die rF2-Piloten die neue kostenlose Strecke Portland ausprobieren, sich an der Überarbeitung des britischen Klassikers Silverstone sowie Verbesserungen bei dem neuen GTE-Wagen und der Physik aller Fahrzeuge erfreuen.
Im Juli wird das rFactor 2-Team an weiteren kleineren Überarbeitungen der GTE-Wagen arbeiten, Defaultfahrzeugabstimmungen vorbereiten die als idealer Ausgangspunkt für eigene Anpassungen dienen, Überarbeitungen der GT3-Fahrzeuge vornehmen und zwei Neuerungen vorbereiten, eine davon der Ferrari 488 GT3 in der 2020-Spezifikation und ein noch nicht angekündigter Rennwagen der sich schon im Betastatus befindet. Somit ist auch in der nächsten Zeit, nach einer kurzen Sommerpause, die Versorgung an Spielinhalten sichergestellt. Auch an der Benutzeroberfläche, den Overlays und neuen Wettbewerbssystem wird weiter über den Sommer gearbeitet. 
Zoom Großen Anteil am bisherigen Erfolg der PC-Rennsimulation haben auch die vielen Moddinggruppen und Einzelpersonen die mit ihren Erweiterungen rFactor 2 von Anfang verbessert und spielenswerter gemacht haben. Durch den technischen Umbau, vorangetrieben von Studio 397, ändert sich auch so einiges. Deshalb wird gerade die Veröffentlichung einer Dokumentation vorbereitet die die Modder dabei unterstützen soll das Beste aus den Updates unter der Haube herauszuholen.
Zu Beginn wird der Fokus dabei auf den Strecken liegen, später dann bei den Fahrzeugen. Neben Anleitungen werden Tools inklusive 3ds Max 2021-Plugins und ein unabhängiger Material-Editor und eine vollständige Beschreibung der Shader plus einige Tipps und Tricks bereitgestellt. Als Beispiel gibt es eine aktualisierte Version der Strecke Loch Drummond obendrauf, die alle möglichen Optionen der jüngsten Arbeiten an den Rennstrecken veranschaulicht. Alle Infos werden online im Developers-Guide unter https://docs.studio-397.com/developers-guide/ abrufbar sein.
Und nun zu den virtuellen 24 Stunden von Le Mans, an denen "insgesamt 200 Fahrer und viele Renningenieure und andere Unterstützer" beteiligt waren und die das Team um Marcel Offermans, Head of Studio 397, und die Partner trotz "einiger technischer Herausforderungen" insgesamt als Erfolg werten. 823 Millionen Onlinekontakte, verteilt über alle Kanäle, zeigen wie groß das Interesse in Zeiten der Coronavirus-Pandemie, in der der echte Motorsport ausgesetzt wurde, gewesen ist.
Zoom Virtueller Rennsport unterliegt, wie der reale Motorsport auch, dem Risiko, dass nicht immer alles problemlos funktioniert. Im Simracing spielen hierbei Software, Hardware und die Internetverbindung eine Rolle und einige Teilnehmer hatten während des Rennens damit Probleme. Was genau schief gelaufen ist und wie man dies am besten verhindern kann, ist Teil einer Untersuchung durch das rFactor 2-Entwicklungsteam. Zum Abschluss des Juni-Rückblicks und der Vorschau auf die nächste Zeit, folgt eine Beschreibung von Studio 397 wie man die beim Langstreckenrennen aufgetretenen Störungen identifizieren will und weshalb das keine triviale Sache ist.
"Vor einigen Wochen, nach dem 24-Stunden-Rennen, haben wir versprochen, regelmäßig über unsere Bemühungen zu informieren, die während dieses Rennens und einige Rennen zuvor aufgetretenen Probleme aufzuspüren und zu beheben. Tatsächlich haben wir diese Bemühungen nicht erst vor zwei Wochen begonnen, sondern es handelt sich um einen fortlaufenden Prozess. Bevor wir uns jedoch mit den spezifischen Problemen befassen, wollen wir zunächst etwas mehr über die Softwareentwicklung und die Behebung von Fehlern erklären.
Zunächst ein wenig Hintergrundwissen darüber wie wir Code entwickeln, welche Prozesse wir nutzen, um sicherzustellen, dass unser Code korrekt ist, sowie eine kurze Einführung darüber, welche Art von Fehlern im Code vorhanden sind und wie diese behoben werden können.
Jede Änderung, die wir an der Codebasis vornehmen, um einen Fehler zu beheben oder eine neue Funktion zu implementieren, wird isoliert entwickelt. Sobald der Entwickler, der daran arbeitet, sicher ist, dass die Änderung korrekt ist, wird er zwei Dinge tun: Zuerst werden mindestens zwei Kollegen gebeten die Änderungen zu überprüfen. Indem wir andere dazu bringen, sich den Code anzusehen, erkennen wir normalerweise Fehler, die der ursprüngliche Autor übersehen würde. Ich bin sicher, ihr kennt die Situation in der ihr selbst blind für eigene Rechtschreibfehler gewesen seid. Bei Code ist dies normalerweise nicht anders. Der zweite Schritt besteht darin, einen Build auf Steam zu erstellen, der von anderen getestet werden kann. Wenn die Änderung beide Prüfungen besteht, wird sie in das nächste Update integriert. Das geht an unsere Gruppe von Betatestern, die die Änderung erneut testen, um sicherzustellen, dass sie wie geplant funktioniert. Wenn dies erfolgreich ist, wird sie in das nächste öffentliche Update übernommen.
So gehen wir mit Veränderungen um. Doch was ist mit der umfangreichen Codebasis die wir bereits haben? Hier beginnt der Prozess damit, einen Fehler zu identifizieren und eine Reihe von Schritten zu finden, um ihn zu reproduzieren. Wenn wir es reproduzieren können, haben wir normalerweise kein Problem damit, das zugrunde liegende Problem zu beheben.
Es gibt zwei Arten von Fehlern im Code. Solche die auf Fehler in der Logik des Codes zurückzuführen sind. Einmal identifiziert, sind sie normalerweise leicht zu reproduzieren und zu reparieren. Der zweite Typ betrifft das Timing und das Threading, auch als Parallelitätsfehler bezeichnet. In den letzten Jahren treten diese häufiger auf, da Prozessoren immer mehr Kerne haben und viele Dinge gleichzeitig passieren. Das Reproduzieren dieser Art von Fehler ist normalerweise viel schwieriger, da die geringste Änderung des Ausführungszeitpunkts dazu führen kann, dass er erscheint oder verschwindet. Um diese Fehler zu finden, ist eine Kombination aus Glück, vielen Tests und in einigen Fällen strengen Codeüberprüfungen erforderlich. Angesichts der Tatsache, dass die rFactor 2-Codebasis aus Millionen von Codezeilen besteht (Zum Vergleich: Ein typischer Roman besteht aus etwa 15.000 Zeilen.), kann sich jeder sicherlich vorstellen, dass das Durchgehen des Codes von vorne nach hinten ein sehr zeitaufwändiger Prozess ist. Und vielleicht werfen Sie noch einen Blick auf das eigentliche Problem (Erinnert ihr euch noch an den Straßennamen, den der Hauptdarsteller auf Seite 34 überquerte?)
Nachdem wir unsere Vorgehensweise erklärt haben, kehren wir zum 24-Stunden-Rennen zurück. Unmittelbar nach dem Rennen haben wir begonnen, die verschiedenen Berichte zu analysieren und zu kategorisieren, und wir waren ziemlich bald davon überzeugt, dass es sich um ein oder mehrere Parallelitätsprobleme handelt. Diese zu reproduzieren würde schwierig werden. Wir haben ein Framework, mit dem wir vollautomatische Tests einrichten können. Unser erster Schritt bestand darin, die genauen Bedingungen dieses 24-Stunden-Rennens zu reproduzieren. Insbesondere haben wir begonnen, Testszenarien zu entwerfen, die den Berichten ähnelten. Zwei Wochen später sehen wir jetzt die ersten Ergebnisse dieser Tests mit einem reproduzierbaren Szenario das wir weiter untersuchen. Ich rechne damit, dass wir in der nächsten Roadmap mehr erklären können, aber die gute Nachricht ist, dass wir etwas gefunden haben.
Als Ergebnis der Suche haben wir auch einige vorläufige Ratschläge für diejenigen, die Langstreckenrennen veranstalten. Im Gegensatz zu dem was die meisten Serien machen - sicherzustellen dass der Ersatzfahrer kurz vor dem beabsichtigten Fahrerwechsel beitritt und danach die Verbindung beendet - ist es für den Moment wahrscheinlich besser, wenn alle Fahrer kurz vor dem Start dem Rennen beitreten und während der gesamten Veranstaltung mit dem Server verbunden bleiben. Unser Code kann theoretisch mit bis zu 104 Fahrern und zusätzlich 104 Zuschauern umgehen. Wenn eure Rennen also weniger haben, probiert diesen Rat aus, während wir fortfahren die Probleme aufzuspüren und zu beheben."
+ 04.07.2020 MK
News zum Thema
- rFactor 2: Radical SR3 XX, Build 1119 und Ausblick auf Neuerungen im Juni (06.06.20)
- rFactor 2: Ferrari 488 GTE, New York und Zandvoort-Update am Start (29.05.20)
- rFactor 2: Build 1118, Berlin E-Prix-Strecke - Detailinfos und Screenshots (23.05.20)
- rFactor 2: Le Mans-Spezialpaket und Ferrari sind gesetzt (21.05.20)
- rFactor 2: Zandvoort für alle Spieler kostenlos und On-board-Video (08.05.20)
