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_]

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.

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?

I absolutely agree with you that what you've suggested makes no sense. I'm not even sure what you are trying to say and how did you arrive to those suggestions.

What I'm actually saying is much simpler than that and involves no magic or elaborate theories. I'm simply saying the FFB levels S397 have decided to set for their cars to correspond with a multiplier of 1.0 are a bit too high than I feel they should be, and setting the multiplier to around 0.75 simply lowers them to a level which I would consider to be more appropriate for a setting of 1.0. Bear in mind that 0.75 number is simply an average I arrived to based on my experience and based on how much clipping I generally want to see from a sim car. This number will still change depending on the specific car and also on track. And you *will* still get clipping at times, even when setting the multiplier around this value (one example that immediately comes to mind - try driving through the Esses at Watkins Glen without getting clipping, you'd have to lower the multiplier *a lot*). It's a bit of a balancing act (at least on the weaker consumer wheels, direct drive's sheer torque capability changes things considerably) to find a value that doesn't result in too much clipping outside of some extreme moments, and yet still have enough feel with the lighter forces (that, for example, is the reason why I tend to go a bit higher with the multiplier and tolerate a bit more clipping than I'd like with the M8 GTE).

It also has to be said that this is, to a large part, a decision that's not inherently right or wrong. I would like to see the multiplier to be set lower for the S397 cars (and certainly for other cars, with the Mak Group C mod being one of the worst examples which clip as soon as you look at them with their default FFB multiplier and settings), because I think there should be less clipping by default, but they have decided they want the defaults to be like this. I'm sure they had their reasons for that and didn't just choose the FFB level at random to be done with it.

And it also has to be said rF2 is certainly not alone here. AC and ACC, if you leave the in-game FFB level at 100%, will also clip quite a lot. Raceroom can be a hit or miss (and there are too many variables in Raceroom to influence that). AMS is probably the most consistent sim when it comes to FFB levels, but we also have no way of knowing as I'm not aware of any means of monitoring the FFB levels in AMS outside of our own hands (and experience with FFB settings and clipping). But it also definitely clips a fair bit at times as well, and it is by design, with the developers freely admitting that.

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?

Yes. There's no real feedback from the wheel (as in a way of measuring the wheel's actual response and output) to be able to monitor its real output using some kind of software and therefore be able to detect actual hardware clipping. You'd need a fairly elaborate setup. (Which, BTW, is incidentally also the reason why all the wheel measurements done using the Wheel Check utility you can find all over the internet are inherently flawed IMO, since they measure something else than what many people think they measure.)

 

[Emery]

I guess developers decided that majority of players have weak wheels […]
But what about capable DD wheels that could use full signal?

Yes, that is correct. rF2 has "Steering torque capability" in the controller.json. If your wheel can generate more than 8 Nm of torque, then setting this to the actual Nm your wheel can generate will scale the proper Nm.

As far as I know, no other sim has this capability, though I can imagine iRacing does.

 

[thepharcyde]

I have a TS-PC and 0.80 seems to be the sweet spot.

The default 1.0 is too high, not that I get clipping perse, but not true to life for what I think a race car is representative of.

To be able to set this holistic across all cars with one setting would be good.

 

[Emery]

The default 1.0 is too high, not that I get clipping perse, but not true to life for what I think a race car is representative of.

LOL... I can tell you've never driven a car on fat slicks without power steering! A TS-PC is no where close to reality in terms of required torque.

 

[Jens Roos]

Yes, that is correct. rF2 has "Steering torque capability" in the controller.json. If your wheel can generate more than 8 Nm of torque, then setting this to the actual Nm your wheel can generate will scale the proper Nm.

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

Well, that Nm setting in the controller file seems to have no impact on any output.
(on my wheel)

(wheel set to 100%, AM GT3, Brands Indy)

BLUE -> In-Game x0.48, Controller 20Nm, max 81%
BLACK -> In-Game x1.25, Controller 20Nm, heavy, noticeable flat FFB, max 100%
GREEN -> In-Game x1.25, Controller 5Nm, no difference to above , max 100%

Same test with default

BLUE -> In-Game x1.0, Controller 20Nm, max 100%, FFB feels ok, but goes flat sometime

So with In-Game at default, some clipping is going on, mostly when going over curbs.

But this however is very car dependent, I use over 1.0 on a few S397 cars and mods,
even if its much more common with <1.0 FFB gain.

 

[Emery]

@Jens Roos - Would you mind trying that with the DW-12 IndyCar?

 

[Jens Roos]

@Jens Roos - Would you mind trying that with the DW-12 IndyCar?

Sure, the gain or the controller change in Nm (but doubt that it's car dependent)?

 

[Emery]

Sure, the gain or the controller change in Nm (but doubt that it's car dependent)?

The Nm. I'm curious if S397 disabled the feature or if it is car dependent and we know the DW-12 had the feature at the time it came from ISI.

P.S. Thanks!

 

[davehenrie]

Anybody have a list of what wheels are capable of what levels of torque? the Nm #?

 

[EsxPaul]

Anybody have a list of what wheels are capable of what levels of torque? the Nm #?

I remember coming across this page a while back:
http://www.edracing.com/edr/Wheel-Torque.php

I'm not sure it's 100% accurate but it does give some ballpark figures.

 

[AyrtonForever]

since 1.1115 i have a problem with replays: i do 10 lap races that last about 20 minutes, but when i go to see the replays saved, these last only 2 o 3 minutes, maximum 4. is someone else experiencing this?

 

[dajdosta]

Yes. There's no real feedback from the wheel (as in a way of measuring the wheel's actual response and output) to be able to monitor its real output using some kind of software and therefore be able to detect actual hardware clipping. You'd need a fairly elaborate setup. (Which, BTW, is incidentally also the reason why all the wheel measurements done using the Wheel Check utility you can find all over the internet are inherently flawed IMO, since they measure something else than what many people think they measure.)

Feedback from the wheel would be ideal but is it really necessary? Resulting torque can be calculated, no?
Btw iirc I used Wheel Check for AC to create LUT and results were great.

 

[dajdosta]

Yes.

I absolutely agree with you that what you've suggested makes no sense. I'm not even sure what you are trying to say and how did you arrive to those suggestions.

Because at the time of writing I wasn't aware that something like software clipping exists. I thought why on earth would any application deliberately "clip itself" and output worse signal than it could!?!

But when thinking about it if multiple developers really have the same approach then there must be a good reason.
Maybe they decided that occasional clipping is better than sudden strong spikes.

 

[Case_]

Resulting torque can be calculated, no?

It certainly can, but there really is not much point. You know what the game is sending to the wheel already, and if you have no way to get feedback from the wheel, then calculating the exact torque doesn't really add anything. And as for if feedback from the wheel is really necessary - well, it would be nice to have that data at times. And it would certainly be a lot more useful than simply calculating the resulting torque

Btw iirc I used Wheel Check for AC to create LUT and results were great.

Yeah...you don't want to get me started on what I think about using Wheel Check and LUT, trust me.

I thought why on earth would any application deliberately "clip itself" and output worse signal than it could!?!

But when thinking about it if multiple developers really have the same approach then there must be a good reason.
Maybe they decided that occasional clipping is better than sudden strong spikes.

Again, setting FFB levels at least on the weaker consumer wheels is a balancing act. You need to "cram" a high dynamic range of forces into a relatively limited range of torque the wheel is capable of producing. If you lower the FFB output of the game to the point where you don't get any clipping at all, many cars will feel very "light" and you'll lose detail at the lower end of the torque range, because the weaker forces will be scaled down a lot. If you set the FFB levels so that the lower end forces are OK-ish, you *will* get a lot of clipping at the high end, because the calculated forces will exceed the range you have available. So you have to compromise and set a default that feels acceptable for the lower end forces, but doesn't clip too much at the higher end.

Obviously there might also be some dynamic range compression involved to make this easier, but that also has its pros and cons.

It's just not an easy task to set the FFB defaults in a way so you can get enough feedback at low speeds, but at the same time not get heavy clipping when going full blast through Eau Rouge (Raidillon, actually).

 

[Stephen O'Sullivan]

Again, setting FFB levels at least on the weaker consumer wheels is a balancing act. You need to "cram" a high dynamic range of forces into a relatively limited range of torque the wheel is capable of producing. If you lower the FFB output of the game to the point where you don't get any clipping at all, many cars will feel very "light" and you'll lose detail at the lower end of the torque range, because the weaker forces will be scaled down a lot. If you set the FFB levels so that the lower end forces are OK-ish, you *will* get a lot of clipping at the high end, because the calculated forces will exceed the range you have available. So you have to compromise and set a default that feels acceptable for the lower end forces, but doesn't clip too much at the higher end.

As an owner of a low-torque Driving Force GT, this is precisely why I think all sims should have a force feedback meter. The same applies even for much stronger consumer and direct drive wheels - it's all about harnessing the strength and sensitivity of the wheel to the sim's output range.

 

[Case_]

@Stephen O'Sullivan And I absolutely agree with you on that I think it's something that is absolutely essential to have in a sim (or even some simcade games, as much as I hate that term) if you want to set your wheel as best as you can.

I mean, I think AMS does a tremendous job of setting the FFB exactly right for all of the cars, but I would still like to have a way to monitor the FFB output even there.

Not to mention how much I'd love to have an FFB meter for Dirt Rally 2. If only to point out to a lot of the "FFB tweakers" what they are actually doing to their FFB

 

[CrimsonEminence]

I mean, I think AMS does a tremendous job of setting the FFB exactly right for all of the cars, but I would still like to have a way to monitor the FFB output even there.

You can feel clipping in AMS really well, because its FFB is so consistent with all cars.
You just need a modern Formula car with a track with fast downforce corners, then drive it through one of these and feel, if you get "road texture detail" while having a decent amount of steering input. If you feel nothing than force, then reduce the FFB strength.(74% is the sweet spot with my G27) I have the feeling, some cars are always set to get some clipping with RealFeel, but it could be Voodoo on my side. But it is possible to tweak it:

 

[Jens Roos]

The Nm. I'm curious if S397 disabled the feature or if it is car dependent and we know the DW-12 had the feature at the time it came from ISI.

DW-12, Indy 500

BLUE-> in-game x1.0, controller 20Nm
BLACK-> in-game x1.0, controller 5Nm
If not curbing to much, both peak around 70%, similar FFB at the wheel

So in my case, it makes no difference.

 

[Case_]

I don't think those shortcuts work in AMS.

And without any means of monitoring the actual FFB output, I would certainly advice to not even attempt changing anything, because the defaults by Reiza are very good IMO and any changes you make will just be guesswork, which is not how things should be done.

 

[CrimsonEminence]

I don't think those shortcuts work in AMS.

They do, i've used them, back when i had tried it with a MOMO Black.
You can even activate the speech synthesis for the real feel in the .ini.^^

And yes, every car has dedicated realfeel values, which are working very well^^