The skid etc sounds are missing because whoever coverted the car for rFactor forgot to include all of the sounds in the upload. The easiest way to fix the problem is to copy the sound files from the M3 Challenge GameData\Sounds folder to your rFactor GameData\Sounds folder. The only files you need to copy over are the WAV files in that top level folder. The ones in the BMW subfolder were already included in the conversion.
Once you copy the files over, it becomes much easier to sense what the car is doing. Amazing really how a few sound cues can affect your driving.
I didn't like the car at all in M3 Challenge but I'm actually having a lot of fun with it in GTR2 using LFS's FXO settings. The car is nice and smooth and predictable and can be easily drifted through corners yet it still has enough power to keep things interesting. It's a really pleasant surprise because I didn't think GTR2 was capable of such subtle dynamics.
Also, out of curiousity I wanted to see how an LFS like car would handle in an ISI game so I modified the M3 physics in GTR2 to use some settings taken from the FXO Turbo. I know, I know, they're two totally different kind of cars but this was just an experiment. Surprisingly, the changes made the car handle less like a pregnant hippo and more like a sporty coupe. The modified spring rates, ARB settings, ride heights, differential settings, tyre pressures etc are not at all realistic for an M3 but the car's a lot more fun to throw around the track now.
You put your photoshop file gauges file in the file folder to make the guages in your photoshop file gauges file show up as gauges in the game. Make sure that you do NOT put the photoshop gauges file in the file folder without first putting the gauges file in the correct photoshop file folder with respect to the gauges files otherwise the photoshop gauges files will NOT show up as gauges, files or folders in the game.
Someone has ported the car to GTR2. It feels much better to me in GTR2 even using the default setup.
Also, whereas in M3 Challenge you can't change the setup of the car and the game stops working if you edit certain of the physics files, in GTR2 you can tweak the setup in to improve handling and the physics files can be edited too. Increasing the stiffness of the front and rear ARBs really brings the car to life.
Congratulations atledreier! So glad to hear that mother and child are doing well. My wife and I are expecting our first in a few weeks and we're in that stage where we're feeling a strange mix of excitement, apprehension, euphoria, anticipation and fear.
Meh, it's the typical ISI/SimBin/Blimey feel. If you like that sort of thing, you'll probably enjoy it. If you don't, you won't.
I'm disappointed, frankly. I expected Blimey!'s first release as an independent outfit to be much better than this tired old crap. It's like they're not even trying any more. A mod that is officially sanctioned by BMW, for which the developers presumably had access to the full range of BMW technical specs and to BMW engineers for more obscure data should be a hell of a lot better than this.
Thankfully, they have left the physics and player files open and at first glance these don't seem to be significantly different from the GTR2/rFactor files so it may be possible to improve the existing settings within the M3 Challenge framework itself or re-use some of the content in a mod for either GTR2 or rFactor.
The colour of the ambient and directional light for each track in rFactor is specified in it's GDB file, located in GameData\Locations\<TRACKNAME>\<POSSIBLE SUB-FOLDER>. Open the track's GDB file in a text editor and replace the lines which begin with Sunrise, Day, Sunset and Night with the following:
Make a backup of the GDB before making the changes so you can revert back to the old settings if wanted.
I find these settings are much more natural looking than the defaults for most tracks. However, you may need to tweak the RGB colour values to suit your own preferences.
Unfortunately, this approach requires you to make the same edits to each track and variant and the changes will also cause mismatches if you try to use the modified tracks online.
Thanks for the pointer to Uzzi's new Road Atlanta earlier in the thread guys. A few minor issues aside, which will hopefully be fixed in the final release, it's excellent.
Heh, I'm the same way. I was just coming around to the idea that rFactor can actually be quite good after playing around with the C6 and the Caterhams. Then the PCC 2007 mod was released. It's gorgeous to look at but the dynamics are kak and inevitably, of course, it's being praised to the moon.
Self-aligning torque in rFactor is derived from lateral force and mechanical and pneumatic trail. The pneumatic trail at any point in time is generated parametrically using the current load on the tyre, the PneumaticTrail value specified in the TBC file (which specifies the peak pneumatic trail by load) and the current slip angle.
Todd, how does pneumatic trail vary with the longitudinal forces acting on the tyre? None of the definitions of pneumatic trail I have come across mention longitudinal forces yet surely they must have some effect? I've come across an informal and very brief mention that pneumatic trail decreases with vehicle speed but haven't seen any formal definitions that include (directly) a longitudinal force component. Any pointers to papers etc would be very much appreciated.
Add the new Nordschleife 2007 by Team rf-nordschleife.de to the list of rFactor track mods that are keepers. I've only spent an hour with it so far but this is the first representation of the Nordschleife I've seen that actually feels like a real place. And joy, curves are actually curves, not just connected straight line segments and the resolution of the track surface mesh is fine enough that the track actually seems to flow and undulate over the terrain. Very nice.
In the controller.ini file located in rFactor\UserData\<USERNAME>, make sure 'Fixed Rate Inputs' is set to "1". This puts the controller input processing into a separate thread which polls the controller at a fixed rate of 100Hz and should improve the steering latency you describe.
That's only a benefit if the controller input processing and graphics processing occur in the same loop. This approach has all sorts of problems, including the potential for input lag you mentioned. A more sensible approach is to decouple the controller input processing, graphics processing and physics processing from one another, put each in a separate thread and have the controller input and physics threads each run at whatever frequency is deemed appropriate. Using this approach, fluctuations in the graphics frame rate do not affect the controller and physics processing which will continue to run in the background at a constant* frequency.
* or to be more accurate, a near constant frequency. In non-realtime systems, there will always be some variability in time steps even when interrupts are supposed to be generated every x milliseconds.
and I've made edits to most of these, including some TDF changes to reduce some track surface undulations per Niels' post above and changes to the lighting in the GDB files to reduce the oversaturated cartoony look that rFactor suffers from.
Varano is my track of choice, OLDRing has a good variety of corners and some nice bumpy areas in braking zones to keep things interesting, Goldenport is so well done that I load it up occasionally to admire the craftsmanship even though it's not a great driving track and Virtua_LM_LeMans is simply a work of art even though the track surface modeling takes away some of the driving fun. Toban and Mills are surprisingly well done considering the relatively poor quality of the content created by ISI in house.
A longitudinal component is implicit in the idea of a slip angle. With no longitudinal component to the velocity vector, the slip angle is basically undefined and every definition that depends on slip angle breaks down. However, that's not really what you're getting at.
I haven't seen any definitions of pneumatic trail or self-aligning torque (or, for that matter, lateral force) that include a longitudinal parameter. Whether this is because they are truly independent of longitudinal forces or whether the standard definitions only apply within normal operating conditions and break down at the edge cases (e.g. the well-known problems with low-speed behaviour in various sims), I don't know.
Yes, that's true for a lightly loaded tyre. However, as load increases (e.g. under heavy braking or hard cornering i.e. in race conditions), the fall off is generally quite steep and SAT can even, in some cases, become negative. Here's a graph from some engineers at Hankook showing this:
If I were a betting man, I'd wager that the differences between netKar PRO and LFS are down to the way in which each models pneumatic trail. Pneumatic trail is distance between the centre of the wheel and the pressure centre of the tyre's contact patch and represents the location where lateral force acting on the tyre is applied. Since this location is offset from the wheel centre, when lateral force is applied to the tyre it generates a torque which causes the wheel to self-align (as long as pneumatic trail is behind the centre of the wheel). This is the self-aligning torque we have been discussing. Due to the dynamics of the contact patch, pneumatic trail varies with slip angle and load as shown in the following graph taken from the same paper I cited above:
Now, if LFS holds pneumatic trail constant, then LFS's SAT v slip angle curves will have the same shape as its lateral force v slip angle curves. If this is the case, and since it's generally accepted that the LFS lateral force curves do not exhibit much post-peak fall off, then LFS SAT curves will also not exhibit much post-peak fall off. This seems to be consistent with LFS's "force leveling off" behaviour described above.