rFactor2 – Update augustus 2019 – Build 1114

Het uitbrengen van een nieuwe rFactor 2-build is typisch iets dat ze doen met een klassiek bullet changelog, maar deze keer vonden ze dat het iets meer verdiende.

Tijdens ons recente rF24-evenement doken er technische problemen op die ons geen ander alternatief lieten dan de rode vlag te zwaaien. We hebben besloten onze prioriteiten onmiddellijk te hergroeperen en te heroriënteren op het ontleden en fixen van problemen die al lang bestonden. Het was geen eenvoudige taak, maar we hebben onze collectieve mouwen opgerold en ons zelf ingegraven. Met veel hulp van de deelnemende teams hebben we alle problemen geanalyseerd en voor het eerst de meeste problemen kunnen reproduceren. De oorzaak bleken zeer specifieke randgevallen te zijn in ‘rejoins’ en ‘driver swaps’, dus gingen we door met het herstellen van deze functies op zoveel mogelijk verschillende manieren.

Natuurlijk vertrouwden veel van de bevindingen op intense en gerichte testen in de afgelopen weken. Om herhaaldelijk meerdere scenario’s te moeten testen en te werken aan oplossingen en oplossingen was een goed doordachte aanpak nodig met een goed begrip van de problemen van alle betrokkenen, zowel aan de testkant als aan de ontwikkelingskant. Deze intense focus heeft ons inzicht gegeven in de vele manieren waarop dingen mis kunnen gaan tijdens het racen. Gelukkig hadden we ook de enorme steun van de rFactor 2-gemeenschap die via feedback en verhalen na de race en de logboekregistraties. Dit was van onschatbare waarde en een enorme duw om de oorzaak van veel van deze problemen te vinden die mensen hebben bij online evenementen. Als team hebben we elk van deze rapporten zorgvuldig doorgenomen en gezocht naar specifieke details die ons in de goede richting konden wijzen.

Autoselectie en upgrades
Een van de belangrijkste gebieden waar we ons op concentreerden, waren problemen in verband met opnieuw joinen na een verbroken verbinding tijdens een sessie, bijvoorbeeld wanneer de netwerkverbinding even verbroken is. rFactor 2 heeft een bestuurder altijd toegestaan ​​om opnieuw deel te nemen aan een race na een computercrash of netwerkprobleem, maar in sommige gevallen bij het opnieuw aanmelden bij de server, zou de bestuurder eindigen met een DNF (niet afgemaakt), een DQ (diskwalificatie) of hun naam wordt onderaan de lijst weergegeven als ‘in afwachting van een open sessie’. Natuurlijk zijn deze resultaten onjuist en de vraag voor ons was: wat veroorzaakt deze scenario’s? Onze onderzoeken en testen toonden al snel aan dat, in de meeste gevallen, deze problemen verband hielden met opnieuw samenkomen en ofwel: a) een totaal andere auto kiezen dan de autoselectie, b) de juiste auto met de verkeerde kleur kiezen uit de autoselectie, of c) het kiezen van de juiste auto en kleurstelling maar met een ander upgradepakket.

U vraagt ​​zich misschien af: “Waarom is dit een probleem, ik kies altijd de juiste opties”? Hoewel dat in 99% van de gevallen waar kan zijn, is het de 1% die ons hier uiteindelijk pijn doet. Het is moeilijk om er zeker van te zijn dat een team van meerdere chauffeurs altijd de juiste opties kiest. Het maken van een fout, zo blijkt, veroorzaakt problemen voor meer mensen dan de bestuurder die zich rejoind, dus moesten we ervoor zorgen dat dit niet meer kon gebeuren.

Om dit probleem aan te pakken, hebben we eerst gekeken naar de kerncode van het opnieuw aanmelden om ervoor te zorgen dat alle opties met betrekking tot auto en upgrades zijn geërfd en bij elke bestuurder blijven, ongeacht verbroken verbindingen of eerdere ruilprogramma’s. Dit betekent dat wanneer u meedoet met auto A en upgrade X, deze robuuster wordt vastgelegd en voorkomt dat de geschiedenis van de bestuurder verloren gaat. Vervolgens hebben we eraan gewerkt om dit proces gebruiksvriendelijker te maken, zodat het eigenlijk onmogelijk is om opnieuw een fout te maken. We hebben het netwerkprotocol verbeterd om aan uw klant te communiceren welke auto, livery en upgrades eerder werden gebruikt, zodat we de juiste auto voor u kunnen kiezen. Als je bijvoorbeeld meedoet met een ‘BMW M8 GTE’ met het ‘Le Mans-pakket’ en ‘mijn-team-livery’, en je hebt een netwerkprobleem tijdens de race en je opnieuw aanmeld, in plaats van de hele lijst met auto’s te zien, teamkleuren en upgrades bij opnieuw aanmelden, zie je alleen je BMW M8 GTE en is de optie om het upgradepakket te wijzigen niet langer beschikbaar. Je krijgt gewoon je auto terug!

Dit brengt ons bij een ander belangrijk punt en neveneffect van het opnieuw aanmelden. Teruggaan met de verkeerde auto of upgrade veroorzaakt vaak vertraging en bevriezing voor alle andere bestuurders die al op de server staan, omdat iedereen gedwongen werd een andere auto in realtime te laden terwijl je op de baan was (in plaats van de auto die in de garage geparkeerd stond toen je verbinding verbroken).

“AI Take Over” en namen van chauffeurs vast in het Pit-menu
Een terugkerend probleem dat we hebben gezien, is dat wanneer een bestuurderswisseling plaatsvindt, de AI plotseling de auto zonder waarschuwing overneemt. Dit werd veroorzaakt door te proberen de auto over te dragen aan een teamgenoot die niet langer een passagier was of zelfs op de server stond op het moment van de pitstop. Standaard werd rFactor 2 vervolgens geconfigureerd om de AI het over te laten nemen. Dit bleek een slecht idee en we hebben de code aangepast om dit niet meer te doen. Dit betekent dat als de bestuurder die het overneemt niet langer aanwezig is, u de auto aan het einde van de pitstop zult behouden. Hiermee kun je blijven racen en een coureurswisseling met je teamgenoot proberen zonder dat AI je race overneemt en verpest. Wanneer u een bestuurder in het pitmenu selecteert, blijven de namen van eventuele passagiers in de lijst staan ​​en kunnen ze worden geselecteerd, ongeacht of ze de server hebben verlaten of met u zijn gestopt. Dit betekent dat je je teamgenoot in het pitmenu selecteert, ze de server verlaten of stoppen met je mee te rijden, maar hun naam blijft in het pitmenu en kan worden geselecteerd. Dit veroorzaakte meerdere problemen: bij verbreken/opnieuw aanmelden zou je vaak eindigen met een DNF, en als een naam van een bestuurder werd geselecteerd die niet meer reed of de server had verlaten, zou de AI het overnemen. We hebben dit probleem opgelost door eenvoudigweg alle stuurprogramma’s uit de pitmenulijst te verwijderen die niet meer met je meerijden (zoals altijd al het geval had moeten zijn).

Verbinding verbroken/opnieuw deelnemen met passagier(s)
Onderbrekingen terwijl een andere bestuurder aan het rijden is, ofwel wachtend op een bestuurdersruil of er net een heeft voltooid, zou eindigen in een DNF bij terugkeer. Je rijdt bijvoorbeeld op het goede spoor, je teamgenoot rijdt met je mee en je krijgt een verbroken verbinding. Als je weer lid wordt, kun je niet opnieuw racen en de naam van je teamgenoot wordt nu in de lijst weergegeven als een coureur met een DNF. We hebben dit opgelost door ervoor te zorgen dat bij het loskoppelen / opnieuw deelnemen alleen de huidige bestuurder de auto behoudt, alle andere teamgenoten gewoon geregistreerd blijven als ‘passagiers’ en niet als bestuurder worden beschouwd totdat er een daadwerkelijke ruil van de bestuurder plaatsvindt.

Pit-menuparameters vergrendeld na opnieuw deelnemen
Nog een ander probleem dat we hebben bekeken en konden oplossen, was het plotselinge onvermogen om pitmenu-opties te wisselen na het terugkeren. Dit was vooral een probleem als je een ontkoppeling met heel weinig brandstof had en niet meer brandstof kon aanvragen in de volgende pitstop, uiteindelijk zou je brandstof opraken en de race eindigen met een DNF. Alle toegestane in-car pit menu-opties moeten nu open staan ​​voor selectie bij opnieuw aanmelden.

Steam-integratieverbeteringen
Als onderdeel van ons doorlopende profileringproces op basis van logboeken die door gebruikers naar ons zijn verzonden, hebben we ook ontdekt dat de “real-time” API-functies die Steam biedt, kleine hik kunnen veroorzaken. We hebben dit technisch opgelost door de originele plug-in te internaliseren en ervoor te zorgen dat we dergelijke functies op een achtergrondthread uitvoeren, zodat ze nooit onze fysische lus kunnen verstoren. Deze wijziging wordt zowel op de client als op de server gedaan en het betekent dat je geen SteamPlugin.DLL meer in je map met plug-ins ziet (en we hebben ervoor gezorgd dat als het er nog steeds per ongeluk is, het vanaf deze build wordt genegeerd).

Snellere laadtijden
Last but not least hebben we ook wat tijd besteed aan het profileren en optimaliseren van het laad- en laadproces. Interne tests hebben verbeteringen aangetoond in het bereik van 30-50%, wat mensen in het algemeen zou moeten helpen. Sneller laden betekent uiteraard ook dat u sneller kunt deelnemen, waardoor u in het algemeen minder tijd verliest.

Wat is het volgende?
Build 1114 is de eerste van twee geplande releases om de gevonden problemen aan te pakken. We besloten het proces in tweeën te splitsen, waarbij we ons eerst op de grote bugs concentreerden en vervolgens op de kleinere bugs. We vonden het belangrijk om zo snel mogelijk een update in handen van iedereen te krijgen, maar pas nadat we ervoor hadden gezorgd dat we deze build niet meer konden breken. Zoals altijd moedigen we mensen aan om zowel hun toegewijde servers als hun clients bij te werken en problemen te melden. We doen er alles aan om dit goed te doen en blijven de online ervaring in rFactor 2 verbeteren. We verwachten volgende maand een update over deze problemen, maar nogmaals, we zullen zoveel tijd nemen als nodig is om ervoor te zorgen dat deze kleine problemen ook helemaal weg.