Hi, I am having problems matching the roll stiffness of my in game vehicle to data I have a from a real car. The rear is too soft and the front is too stiff. I've double checked everything, and tried to fudge it but the adjustments I'd have to make to match to roll stiffness numbers are too great for my liking. Could this be down to how RF2 calculates roll centres coupled with short wishbones and lots of suspension travel that cause plenty of roll centre migration? On a different note if anyone has a link to a good guide for the visual side of car modding and where I can find rtrainer that would be greatly appreciated. Many thanks in advance for any assistance.

If you've worked the numbers to get the correct roll stiffness numbers, how do they compare to rates of what I presume are actual spring rates of the bar? I recall something about doubling vs what one would expect in the past (but also thought that was patched, may have been only with either diameter or spring based bar rates.) Motion ratio compensation? Things to double check, at least. rtrainer was replaced by the skip barber car which is in devmod.

Thank you for your reply. I end up going from about 5 N/mm to 15 N/mm at the rear and from about 20 N/mm down to 10 N/mm at the front. I've plotted the motion ratio graph from the game data and measured it on the car and they are identical. I've manipulated the motion ratios a little bit but I need to change them considerably (more than 10%) to match the roll stiffness.

Roll Center (RC) is a somewhat "abbreviated" form of Virtual Swing Axle (VSA) to derive Instantaneous Centers (IC). Instantaneous Centers in relation to the COM will alter Roll Rates in a non-linear manner depend on the positions of the IC at all 4 corners. It can be a bit confounding with short arms as the IC-COM coordinates sometimes change drastically with rise and droop of the suspension. Carroll Smith (RIP) wrote an excellent book "Tune to Win" in the late 70's that covered this, that inspired me to learn Basic Programming as it took an extraordinary number of calculations to plot IC's through various suspension heights, and wrote a program to analyze suspension geometry in the early 80's. On a Z80 processor it would take about 40 minutes to run on a car such as a Lola T492. Than enabled some predictable and exceptional improvements with only minor changes to pickup point relocation. This may help: http://white-smoke.wikifoundry.com/page/Suspension+Geometry As for whether rFactor2 includes IC in their algorithm, I can't say. My guess is they probably use more of the abbreviated form of RC as its pretty processor intensive for real time calculations.

@John R Denman I don't know if you've looked at pTool, but boiling the calculations down to the various centres (in itself a fairly contentious topic as far as how useful those calculations are in practical terms, for the more advanced analyses I've seen discussed) is really doing a disservice to the rF2 suspension modelling. It would be a simpler model/algorithm if it just calculated some instant centres at various positions or scenarios and then derived something about the car handling from that. The suspension links actually run in real time, at 2400Hz if pTool is any indicator (and we know the tyres do, so why not), with their movement constrained based on the relationship of various links (the game creates subsystems, similar to how we might see 2 arms forming a triangle with a rigid structure like the car body and say right, that outer point simply pivots around the inner ones, I can remove any other possibilities for it) and further constraints defined in the suspension system (and pTool, named Constraints funnily enough) that might make 2 arms rotate around each other in limited axes, for example. This all happens in real time with optional spring and damper rates also defined for each component, with 2 subbodies defined for any official car released in the last ~5-6 years (and most mod cars, I would suggest) with further chassis flex between those, and inertia impacting the forces put back through the suspension links (in realtime) and back the other way from the tyres through the suspension and impacting the body movement itself. It's a different proposition to coming up with response graphs for different applied forces (static, for example) and dynamic scenarios that your program would have produced (I've only done some limited range calculations in excel myself at this stage, aiming to keep my analysis to the level of my understanding so as to not make a right mess of things), because it 'only' needs to calculate the next position in realtime - which of course involves its own mathematical approaches. Centres are a good reference (especially for humans) and check point if you suspect something has been done wrong, but that's about it for rF2.

Thank you both. If I've read this correctly Lazza you're suggesting that Rf2 treats the issue of roll centres/axis as a force based problem and then all the calculations happen in real time? I know what I've looked at trying to calculate roll axis from forces and geometry it's a pretty complex process so this would be quite something if Rf2 does this all while the car is moving. This could also point to compliance being more of a factor than I had previously considered. Does anyone know of a way to increase the compliance in specific suspension arms and not others? I'd like to be able to introduce a substantial amount more flex into the outboard lower wishbone joint but don't know if this is possible.

I think this is question for @Michael Borda , but if you know how to get the chassis.ini in to ptool, you can play with all values in it in real time..