Sizable New rFactor 2 Update Available Now

[Paul Jeffrey]

Studio 397 have released a major new update for rFactor 2 - addressing many of the issues recently encountered with the simulation.

Having been in a bit of strife with the title following the recent 24h of Le Mans virtual event red flag, Studio 397 have redoubled their efforts to hunt down and eliminate some of the long standing bugs present within the simulation. With plenty of enhancements and changes having taken place within rFactor 2, many of the more long running issues appear to have been brought further into the limelight in recent months, and it is exciting to see these acknowledged and actioned by the development team - hopefully adding up to a much more robust playing experience now and in the future.

Check out the release article from Studio 397 below:

Releasing a new rFactor 2 build is typically something we do with a classic bulleted changelog, but this time we felt it deserved a bit more than that.

During our recent rF24 event, technical issues cropped up that left us no alternative but to red flag the race. We decided to immediately regroup and redirect our priorities towards dissecting and fixing what turned out to be long standing issues. It was not a simple task, but we rolled up our collective sleeves and dug in. With a lot of help of the participating teams, we analyzed all the problems and for the first time were able to reproduce most of them. Their cause turned out to be very specific edge cases in ‘rejoins’ and ‘driver swaps’ so we proceeded by focusing on trying to break these features in as many different ways as possible.

So of course, much of the findings relied on intense and focused testing over the past weeks. Having to go back and test multiple scenarios repeatedly and working to find fixes and workarounds required a well-thought-out approach with a solid understanding of the issues from all involved, both on the testing side and the development side. This intense focus has given us an insight into the many ways things can go wrong in the heat of racing. Thankfully, we also had the massive support of the rFactor 2 community through post-race feedback and stories, as well as logging – this was invaluable and an enormous push to help find the root cause of many of these issues people have in online events. As a team, we meticulously went over each of these reports and looked for any specific details that could point us in the right direction.

Car Selection and Upgrades
One of the main areas we focused on was issues related to rejoining after getting disconnected during a session, for example when the network connection goes down for a moment. rFactor 2 has always allowed for a driver to rejoin a race after a computer crash or network issue, but in some cases on rejoining the server, the driver would end up with a DNF (Did not finish), a DQ (disqualification) or their name would show at the bottom of the list as simply ‘pending an open session’. Of course, these outcomes are incorrect and the question for us was: what triggers these scenarios? Our research and testing quickly showed that, in most cases, these issues were related to rejoining and either a) picking a totally different car from the car selection, b) picking the right car with the wrong livery from the car selection, or c) picking the right car and livery but with a different upgrade package.

You might ask, “Why is this a problem, I always pick the correct options”? Whilst that might be true in 99% of the cases, it’s the 1% that hurts us here in the end. It’s hard to be sure a team of multiple drivers always chooses the correct options. Making a mistake, it turns out, causes problems for more people than the driver rejoining, so we needed to make sure this could no longer happen.

To tackle this problem, we first looked at the core code of the rejoin process to make sure all options regarding car and upgrades are inherited and stay with each driver, regardless of disconnections or previous driver swaps. This means when you join with car A and upgrade X, it will be logged in a more robust way that prevents the driver history getting lost. Next, we worked on making this process more user friendly, so that it’s actually impossible to make a mistake on rejoin. We enhanced the network protocol to communicate to your client what car, livery and upgrades were used before, so we can choose the right car for you. For example, if you join with a ‘BMW M8 GTE’ with the ‘Le Mans package’ and ‘my-team-livery’, and you have a network issue during the race and are booted, instead of seeing the whole list of cars, team liveries, and upgrades on rejoin, you only see your BMW M8 GTE, and the option to change upgrade package is no longer available. You simply get your car back!

This brings us to another important point and side effect of rejoin errors. Rejoining with the wrong car or upgrade would often cause lags and freezes for all other drivers already on the server as everyone was forced to load a different car in real-time while on track (instead of the car that got parked in the garage when you disconnected).

“AI Take Over” and Driver Names Stuck in the Pit Menu
A recurring issue we’ve seen is when a driver swap takes place, the AI would suddenly take over the car without warning.

This was caused by trying to hand over the car to a team mate that was no longer a passenger or even on the server at the moment of the pit stop. By default rFactor 2 was then configured to let the AI take over. This turned out to be a bad idea and we altered the code to no longer do this. This means that from now on, if the driver taking over is no longer present, you will retain the car at the end of the pit stop. This will allow you to keep racing and retry a driver swap with your team mate without AI taking over and ruining your race.

When selecting a driver in the pit menu, names of any passengers would stay stuck in the list and would be select-able regardless of whether they had left the server or stopped riding with you. This meant you select your team mate in the pit menu, they leave the server or stop riding with you, but their name stays in the pit menu and can be selected. This caused multiple issues: On disconnection/rejoin you would often end up with a DNF, and if a name of a driver was selected that was no longer riding or had left the server, the AI would take over. We’ve fixed this issue by simply removing any drivers from the pit menu list that are no longer riding with you (as should have been the case all along).

Disconnection/Rejoin with Passenger(s)
Disconnections while another driver is riding along, either waiting on a driver swap or having just completed one, would end in a DNF on rejoin. For example, you’re driving on track, your team mate is riding with you and you get a disconnection. On rejoin, you’re not able to race again and your team mate’s name is now showing in the list as a driver with a DNF. We fixed this by making sure that on disconnect/rejoin only the current driver retains the car, all other teammates simply stay registered as ‘passengers’ and are not considered a driver until an actual driver swap takes place.

Pit Menu Parameters Locked After Rejoin
Yet another issue we looked at and were able to fix was the sudden inability to toggle pit menu options after rejoining. This was particularly a problem if you experienced a disconnect with very little fuel and could not request more fuel in the subsequent pit stop, ultimately you would run out of fuel and end the race with a DNF. All allowed in-car pit menu options should now be open to selection on rejoin.

Steam Integration Improvements
As part of our ongoing profiling process based on logs sent to us by users, we have also discovered that the “real-time” API functions that Steam provides could cause small hiccups. We technically solved that by internalizing the original plugin and making sure we execute such functions on a background thread so they can never interfere with our physics loop. This change is done both client and server-side and it means you will no longer see a SteamPlugin.DLL in your plugins folder (and we’ve made sure that if it is still there by accident, it gets ignored from this build onwards).

Faster Loading Times
Last but not least, we also spent some time profiling and optimizing the track and car loading process. Internal tests have shown improvements in the range of 30-50%, which should help people in general. Faster loading obviously also means you can rejoin quicker, losing less time overall.

What’s next?
Build 1114 is the first of two scheduled releases to address the issues we found. We decided to split the process in two, concentrating on the major bugs first and then addressing the smaller ones. We thought it was important to get an update into everybody’s hands as quickly as possible, but only after making sure we could not break this build anymore. As always we encourage people to update both their dedicated servers and clients and report any issues. We are heavily committed to getting this right and continue to improve the online experience in rFactor 2. We expect to have an update on those issues next month, but again, we’ll take as much time as we need to ensure these minor issues are also completely gone.

rFactor 2 is a racing simulation exclusively available for PC.

For more news from the world of rFactor 2, check out the RaceDepartment rFactor 2 sub forum and join in with the community discussion. If you like racing in a clean and fun environment online, why not check out the RaceDepartment rFactor 2 Racing Club? Get yourself in on the action!

Like what we do at RaceDepartment? Follow us on Social Media!


 ​

 

[Case_]

If I understood correctly you have 100% ffb in profiler and then you set each car in game at 0.76?
Wouldn't it be easier and same result if you just set up profiler at 76% and leave in game multiplier as is at 1.00?

You are not achieving the same result by doing that. If you lower the game to 0.76 (for example), you are getting rid of most of the clipping, because the rF2 cars (at least the official S397 ones) generally clip a lot with the multiplier set to 1.00, and around 0.75 seems to be the sweet spot for them. You then set the wheel to whatever FFB strength you want (within its capabilities) and have an FFB that is as heavy (or light) as you like, but still free of clipping.

If you keep the game on 1.00 and then lower the FFB strength on the wheel, you will have an FFB that still includes all of the clipping, it just feels lighter in your hands. So far from what is generally considered ideal.

One thing people often don't understand correctly is that the in-game FFB settings and the wheel's FFB strength are not really interchangeable the way you suggest. The in-game settings are responsible for the "shape" of the FFB signal - you set the dynamic range of the FFB signal in the game and create the FFB you want to have. (And this is also more or less wheel indpendent, BTW.) Then, using the wheel's gain, you simply adjust how "loud" you want the end result to be. You should not be able to introduce further clipping on your wheel by adjusting its strength up to what it allows you to, provided its drivers are calibrated properly.

 

[CrimsonEminence]

If you keep the game on 1.00 and then lower the FFB strength on the wheel, you will have an FFB that still includes all of the clipping, it just feels lighter in your hands. So far from what is generally considered ideal.

I call it "software clipping" (don't know, how accurate this is) and it's one of the main reasons, i always change the ingame value and not the profiler one.

 

[Case_]

Yes, it tends to be called that, while the clipping you would potentially get on the wheel itself if you were able to exceed its capability (again, very unlikely at least with the standard consumer wheels, as the wheel's drivers should be calibrated well enough to prevent that from ever happening) is often called "hardware clipping".

 

[CrimsonEminence]

while the clipping you would potentially get on the wheel itself if you were able to exceed its capability (again, very unlikely at least with the standard consumer wheels, as the wheel's drivers should be calibrated well enough to prevent that from ever happening) is often called "hardware clipping".

Yes and also no, you can definetly get a G27 to clip by hardware reasons, when you send a signal (a fast corner with high downforce with ingame at 76% and LGS profiler value of 125% or so[dunno the exact amount of "overdrive" in the driver right now] for example) which is strong enough at peak, to have no really nuanced feel, just force. Even, if the game is delivering all of its detail clearly.

The motors aren't that strong in this wheel, so at a certain point it ends up, clipping by limitations of the wheel itself, because it can't deliver the difference between max steering force and nuanced details with slightly higher peak forces, anymore, because the motor isn't capable to deliver even more. ^^

 

[Case_]

Well, if you're running the wheel at 125 %, then I guess you might get hardware clipping.

I always forget Logitech doesn't care about their hardware and allows the user to just set the gain to whatever they like, even well beyond 100 %. So I guess I should correct myself to "it's very unlikely with the standard consumer wheels, unless you're a Logitech user who knows no fear"

 

[CrimsonEminence]

Well, if you're running the wheel at 125 %, then I guess you might get hardware clipping.

I always forget Logitech doesn't care about their hardware and allows the user to just set the gain to whatever they like, even well beyond 100 %. So I guess I should correct myself to "it's very unlikely with the standard consumer wheels, unless you're a Logitech user who knows no fear"

You can get slightly more potential out of the G27 with sometimes setting sliiightly higher values on profiler gain, and then tweaking fitting ingame values, but it isn't worth the time, because it is turning out to be that much of a compromise, especially by using several sims, instead of one. So leaving it on 100%, tweaking ingame values(which of course also interact with the wheel hard-&software capabilities) and having fun, is the most uncomplicated and safest way and you will probably don't even notice the difference in normal use, to some "overdriven" setting.

EDIT: Spring and Damper value belongs to 0% of course. NOTHING from this should be coming from the driver itself, even when the game "overrides" this setting. There you can also possibly cause some hardware clipping and loss of definition with some games.

 

[danraz3r]

I hope each update gets a better RF2 but ....

the unique thing i know when we have an announcement about rf2 update is that we are gonna have a good laugthing popcorn times readig the comment section . Thanks guys!

 

[Case_]

Spring and Damper value belongs to 0% of course. NOTHING from this should be coming from the driver itself, even when the game "overrides" this setting. There you can also possibly cause some hardware clipping and loss of definition with some games.

Spring and damper belong to default values, of course. The game doesn't "override" anything, because there's nothing to override to begin with. It either uses those forces or not. If it does not, it has precisely 0 impact on the overall FFB feel or "definition".

And, for the record, rF2 doesn't use those forces.

I just don't understand why so many people have this misconception about spring and damper settings in their wheel's control panel caused by subscribing to well over a decade old concept at this point. Spring and damper are not something that affects the FFB as long as you don't bring those sliders to 0 immediately. They're not laid on top of the game's FFB by the driver, they're simply optional additional tools for the game developer to use if he so wishes.

Fun fact: Logitech themselves even removed spring and damper settings from their drivers for the newer wheels completely. The G29/920 wheels are always running the equivalent of what would be full spring and damper on the older wheels.

 

[Stephen O'Sullivan]

All these posts about FFB tend to confirm what I've been saying for a long time about racing sims: most do a terrible job in explaining how to configure their wheel and game FFB settings so as to extract the maximum detail and driving feel.

Sim developers are rightfully proud of the physics and FFB interpretation that they provide, yet far too many simracers are not sure if they are getting the full benefit of that work. After all this time, rF2 still doesn't have a FFB meter. What is the point of trying to prevent a wheel from clipping when there is no objective measurement of saturated FFB?

The process of configuring FFB wheels for a sim needs to be refreshed. If developers can offer career modes, car setup pages, etc., surely they can devote resources to helping a new user with the most important aspect of their purchase?

/rant

 

[CrimsonEminence]

It either uses those forces or not. If it does not, it has precisely 0 impact on the overall FFB feel or "definition".

"Does not use" fits better than "override", yup.

BUT

i can assure you, that particularly some older games are using especially dampening, if turned on in the LGS profiler, and it is not very desirable with a lower tier FFB wheel.

Also AC uses the damper, when the car stands still and moving the wheel then causes unbelieveable noises and behaviour from the G27, you definetly don't want that...

Leaving dampening and spring on 0% works absolutely fine and is getting rid of some "phenomena".

 

[Case_]

 

[CrimsonEminence]

The G29/920 wheels are always running the equivalent of what would be full spring and damper on the older wheels.

Then they will probably get the rattly overdampened behaviour, when standing still in AC, without being able, to change it.^^ Or aren't they?

Fun Fact: I do Sim Racing for a while now (also using motorized wheels since 1998, where FFB wasn't more, than rattling) and if you think, there is no difference, between slider off or at 100% at these settings when the game doesn't use it...well...okay, you're right for newer games, that aren't using these forces, but like i've said, i'm not just using rF2^^ (I mean by that, i'm one of these old fashioned people, who are still thinking in older standards)

 

[dajdosta]

You are not achieving the same result by doing that. If you lower the game to 0.76 (for example), you are getting rid of most of the clipping, because the rF2 cars (at least the official S397 ones) generally clip a lot with the multiplier set to 1.00, and around 0.75 seems to be the sweet spot for them. You then set the wheel to whatever FFB strength you want (within its capabilities) and have an FFB that is as heavy (or light) as you like, but still free of clipping.

If you keep the game on 1.00 and then lower the FFB strength on the wheel, you will have an FFB that still includes all of the clipping, it just feels lighter in your hands. So far from what is generally considered ideal.

One thing people often don't understand correctly is that the in-game FFB settings and the wheel's FFB strength are not really interchangeable the way you suggest. The in-game settings are responsible for the "shape" of the FFB signal - you set the dynamic range of the FFB signal in the game and create the FFB you want to have. (And this is also more or less wheel indpendent, BTW.) Then, using the wheel's gain, you simply adjust how "loud" you want the end result to be. You should not be able to introduce further clipping on your wheel by adjusting its strength up to what it allows you to, provided its drivers are calibrated properly.

You are claiming that official S397 cars generally clip a lot with the in-game multiplier set to 1.00 regardless of wheel driver settings?
That would mean there is a clipping already in rf2 ffb output at games default multiplier so what you are saying is that rf2 somehow chooses this magical non-default number 0.75 and decides it will output raw linear signal for this multiplier value but at default value of 1.00 it decides to do post-processing which results in clipping which means loss of information.
That doesn't make any sense.
Are you trying to say that ffb multiplier is not really a simple multiplier (as its name suggests)?
That is a bold claim and did you do any measurements to backup this theory?

 

[Alex72]

Curious what kind of AI problems? I find the AI to be very competitive. It's all in the settings.

Where I've heard most have problems is offline races in the first couple laps but I don't do a lot of offline races. Mostly practice sessions. That said, I have not experienced what other have described. I also don't know what their settings were for the symptoms they described.

This is what I use based on lots of reading at the S397 forums and lots of testing.
Damage Multiplier - 100%
AI Strength - 100%
* With some 3rd party mods or for more challenge 110% or 120%
** Haven't tried more than 120% as I'm just not that fast.

AI Aggression - 29%
* Much higher than 33% and they seem to get a bit goofy

AI Limiter - 0%

Its AI slipstream people asking about. AI is really nice but lacks slipstream. More options for overtaking by the AI which would be nice.

 

[davehenrie]

The AI will also stop trying to pass a slower car when the faster car is on an in-lap. So if the Senna catches a GT3 just past the start finish line at Le Mans, the Senna will stay locked in behind the GT3 for the entire lap, losing huge gobs of time.
The AI have trouble deciding whether to use rain tires, especially if you cut the practice, qualifying, and warm-up sessions short.
The new PBR graphics have caused repeated updates that have broken many completed skins.
The latest update focused on lag caused issues with multiplayer, but many online leagues have noted an increase in online issues.
I could probably write paragraphs, but there are numerous online and offline issues that remain to be fixed. CURRENTLY S397 focuses on ONLINE improvements, so AI difficulties will apparently have to wait til they feel comfortable with the competition system, UI and online technical upgrades.

 

[Jens Roos]

You are claiming that official S397 cars generally clip a lot with the in-game multiplier set to 1.00 regardless of wheel driver settings?

Not your statement (and this have been discussed in another thread), but I would say it's just a FFB multiplier from an normalized FFB output. Looking in Motec, the actual output is -100 to 100, with many decimals:

(S397 Aston Martin GT3)

Above with somewhere around 0.5 multiplier and a 20Nm DD wheel (I use everything from 0.4 to 1.2 depending on mod). So using 1.0 on a wheel with less force would clip per default, but using 0.5 on wheel with less force would cause light FFB in general.

AC don't have FFB output to Motec, but I would say the global FFB and car dependent FFB gain have the same behavior. There I use 0.4 global and around 0.9 in-car, this will output around 35% FFB which is where the rF2 output is around as well, similar values in AMS.

But I would say, if you use x0.5 in-game and x2.0 at your wheel (if possible) would deliver same result as x1 and x1, the wheel can't output more than 100%. It's just multipliers. If you peak 100% output in-game or at the wheel makes no difference, you are just crunching numbers.

 

[John-Eric Saxén]

You are claiming that official S397 cars generally clip a lot with the in-game multiplier set to 1.00 regardless of wheel driver settings?

Yes, clipping is a phenomenon with every sim, with rF2 some cars exhibit it more, some less and wheel drivers have nothing to do with it. There used to be an easy plugin to monitor this, now it doesn't work since plugins that draw to screen are not compatible anymore with DX11. Anyway, the FFB isn't tuned such that it would never clip with 1.0 coefficient. The default coefficient is usually some kind of compromise with allowing a "strong" FFB (not a big fan of this) and having acceptably low occurrence of clipping and it is also tuned per-car, so one car with 1.0 can have different amounts of clipping than another car with 1.0. But clipping will definitely happen at 1.0 on most cars, for example if you hit the wall at 300 km/h or at entry of a high-speed corner with some bumps.

 

[dajdosta]

Not your statement (and this have been discussed in another thread), but I would say it's just a FFB multiplier from an normalized FFB output. Looking in Motec, the actual output is -100 to 100, with many decimals:
View attachment 321984
(S397 Aston Martin GT3)

Above with somewhere around 0.5 multiplier and a 20Nm DD wheel (I use everything from 0.4 to 1.2 depending on mod). So using 1.0 on a wheel with less force would clip per default, but using 0.5 on wheel with less force would cause light FFB in general.

AC don't have FFB output to Motec, but I would say the global FFB and car dependent FFB gain have the same behavior. There I use 0.4 global and around 0.9 in-car, this will output around 35% FFB which is where the rF2 output is around as well, similar values in AMS.

But I would say, if you use x0.5 in-game and x2.0 at your wheel (if possible) would deliver same result as x1 and x1, the wheel can't output more than 100%. It's just multipliers. If you peak 100% output in-game or at the wheel makes no difference, you are just crunching numbers.

That graph alone doesn't say much.
We would need to see comparison with exact same driving but with ffb multi 1.00.
What people are claiming here is that game never ouputs more than 100% ffb and instead clips it to some predefined max level? If that is the case then how does a sim decide what is "100 ffb" and why doesn't it just send out full signal and let the wheel drivers do the clipping job (if needed)? I am sure wheels have protection.
I would like to see motec output with software clipping. Until then I am not convinced.

 

[Jens Roos]

I would like to see motec output with software clipping. Until then I am not convinced.

Output never goes more than 100%, but I can change to 1.0 in above combination and reduce the wheel. Then in-game clipping should be visible.

 

[dajdosta]

If that how all sims do it then I guess developers decided that majority of players have weak wheels so average signal should be high and everything above 100% will probably be a noise their wheels so let's clip it on our side as John-Eric Saxén explained.
But what about capable DD wheels that could use full signal?
I guess those players need to lower ffb multi significantly, now I understand why you set global multiplier to 0.4.
I've never used those ffb clip apps and until now I thought they measure hardware clipping but no they are showing game ffb output, right?