As promised, I will cover the other tTool features that were introduced as a part of the Build 1110 update.

For the custom_realtime.ini, the new batch test parameters (and their defaults) are as follows:

[CustomRealtimeTest]

RealRoadGroove=0.0 // 0.0-1.0, amount of rubber laid down.

RealRoadMarbles=0.0 // 0.0-1.0, amount of marbles laid down.

RealRoadWaterDepth=0.0 // 0.0-1.0. amount of water on surface.

RealRoadTemperatureK=298.15 // 265.15-350.15 ° Kelvin (yes this is actually shown as Celsius in the TTool UI)

TerrainDryFriction=1.0 // 0.1-2.0, base terrain friction. (Dry= in .tdf file)

TerrainDiffusiveAdhesion=1.0 // 0.0-1.0, manual hack to tinker with (remove) diffusive adhesion to help compare grip with/without these variables.

TerrainMicroRoughness=0.25 // 0.0-1.0 (micro+macro can’t exceed 1.0)

TerrainMacroRoughness=0.50 // 0.0-1.0 (micro+macro can’t exceed 1.0)

WeatherAmbientTemperatureK=298.15 // not sure of range, but it should be plenty for any normal racing context (air temperature)

WeatherTrackTemperatureK=303.15 // not sure of range, but it should be plenty for any normal racing context

Essentially, the above tests now allow us to test tyres under more conditions, helping to understand crossover points for compounds, and similarly, wet tyres. As well as allowing us to better visualise how additional track rubber and or surface water might influence overall grip levels. Finally, it also provides a means by which we can directly measure how a track surface type influence the grip and behaviour of a tyre. These are obviously important factors in influencing vehicle dynamics on different racing circuits. Finally, the parameters provide modders with a key tool to prepare for some future improvements we intend to bring to rFactor 2.

Also new are the .tgm [realtime] parameters:

GaugePressureExtrapolationRange=(50000,500000)

CarcassTemperatureExtrapolationRange=(1,999)

RotationSquaredExtrapolationRange=(90,90000)

Some time ago, we disabled lookup table extrapolation for ‘safety’. We did so, as we had experienced some unpleasantness with rF2 locking up when extrapolation would lead to some extremely stiff (or soft) values that could lead the entire software to freeze. Instead, those have now been unlocked with manually defined ranges (use with extreme caution!). It affords the possibility to build tables slightly shy of required ranges, or can more realistically, help to re-purpose an existing tyre with lookup table for vehicles that might have otherwise fallen outside the range due to a higher top speed, or pressure, or whatever. Note that it’s pretty safe to extrapolate small ranges, in general (that is sticking to within maybe 5-10% of the min/max ranges defined in the [QuasiStaticAnalysis] section of the .tgm). However, for ranges significantly outside those, you will want to regenerate lookup tables for a couple of reasons… Obviously, if you’re extrapolating a lot, you’re further deviating from recorded and established values, as well as risking potentially unstable values resulting from doing so. On the other hand, if the car spends all of 1 second per lap at some really high speed, it may actually be advantageous to record your highest speed in the QSA slightly under the absolute vmax and that extrapolation can actually make the tyre slightly more accurate overall in the greater scheme. So use this knowledge responsibly, you have been warned!

Finally, the last new parameter introduced with B1110 is the [realtime] parameter:

InclinationExtrapolation=1.0 // 0.0=no extrapolation, 1=extrapolate one step, 2=extrapolate two steps, etc.)

This is a fix for certain tyres with oddly shaped (usually very long and ‘patchy’) contact patches that arise from extrapolation of the inclinations. Some time ago, we recorded the contact patch in greater resolution, and extrapolation has often become more of a nuisance than an assistance. For the record, many of our tyres use 0.5 or even lower values now.

To mark the occasion, there are new versions of the 3 TGM spreadsheets on docs.studio-397.com. The TGM generator, which includes the latest variables. The QSA batch test generator, which reorganises the result columns for compatibility with B1110. And, the realtime batch test generator, which obviously makes use of the new features highlighted in this article. There are many, many other changes, and for the eager, full change-log’s are available within the spreadsheets. Again, to open them, you’ll want to use LibreOffice (ideally on the 5.4 branch as that’s what they have been built and tested against).

Happy tyre building!