Racer v0.9.0 RC6 Released

[Ruud]

It's been too long... Now the new version is at www.racer.nl/dl_beta_win.htm

I'm working on stereoscopic rendering; with Quadro's this is relatively easy, on Geforce not so much, but I've read that driver 314.07 supports it suddenly out of the box?! There should be an Oculus Rift on its way soon (these next few months?) so that should be fun.

The changelist:

- Fixed Tracked white menu background
- Camera toggling (with the C key) had an extra mode that should not be there (this was an entity mode)
- Fixed bug in shadows_f.cg full screen shader.
- dbg_car.flip_tan option removed from racer.ini.
- Fixed audio pitch bending frequency to use the original frequency of the loaded sample, instead of the audio engine output frequency.
This could lead to incorrect pitch shifts for example with samples that were stored in 48kHz but played back at 44.1kHz.
- Added warnings for missing LOD models (which could cause disappearing models when generating the shadow maps)
- Modified scaling of racer.ini's dbg_controls.throttle/brakes/clutch/steer to use normalized values (0..1) rather than 0..1000
- Added filtering around wheel (tire) forces; a 2nd order Fz Pacejka input filter (fz_filter_frequency/fz_filter_damping)
and a 1st order Fy (lateral) Pacejka out filter (fy_filter_frequency). Both in data/cars/default/car.ini.
- Also added a 1st order Fx (longitudinal) Pacejka output filter (fx_filter_frequency).
These are useful when dealing with high-fidelity surface data (Lidar or high-frequency road artificial noise)
to prevent very spiky lat/lon accelerations (giving unrealistic grip loss).
- Added dev.opengl_checks to check lots of times for OpenGL errors.
- Added dev.run_first to be able to start a command (like a batch file) before starting Racer.
- Added audio options in car.ini; understeer_oversteer (experimental) and damper sounds. See http://www.racer.nl/tutorial/car_sounds.htm
- Added spline.ini option lines.lateral_divisions to tesselate the spline laterally. This highly improves cambered curves in the road. Values around 6-20.
- Fixed panorama_f.cg shader to light up the texture (would quickly become either black or whitish, never showing the texture image itself).
- Added rtd2ascii.exe tool to convert binary RTD (telemetry) files to ASCII.
- Added fmod() and abs() functions to Onyx, next to improved error/crash reporting.
- Onyx now requires all code to be defined in functions. For independent running of Onyx scripts (onyx_run.exe), you'll need to create a 'void main()' function.
- Added friction_circle_method 10 (similarity model/Marno Hopmans variant) which accepts per-wheel lyka and lxal tuning parameters.
(wheel<n>.pacejka.lyka and wheel<n>.pacejka.lxal). These define Fy influence on slipratio (ka=kappa=slipratio) and Fx influence
of Fx on slip angle (al=alpha=slip angle). Normally you'd use values lower than 1 (and larger than 0) for these lambdas.
- friction_circle_method can be overruled per-wheel (so per-car) under wheel<n>.friction_circle_method.
- Removed dbg_car.use_slip2fc option (obsolete).
- Revised the rendering path to be able to override the main FBO's size. This for surround rendering with split rendering for all 3 screens.
See also www.racer.nl/tutorial/surround_rendering.htm
Current issues: Z-buffer is shifted between split screens (screenCenter uses screenLeft's depth buffer).
- Added quad-buffered stereo support (see racer.ini:resolution.stereo.quad_buffered). nVidia Quadro only currently; 3D Vision may follow for Geforce cards.
See also www.racer.nl/tutorial/stereoscopic.htm
- Added 'vsync <n>' command to set vsync live.
- Autoexposure data/renderer/fullscreen_shaders_hdr/luminance_downsample_f.cg now detects NaN onscreen to avoid exposure spikes.
- nvidia_perf_path added in racer.ini, which needs to point to nVidia's PerfKit DLL. See http://www.racer.nl/tutorial/profiling.htm
- Motion blur taken out for the moment by default.

-----

RC5 Buglist:

- Gearbox shift times not working properly, step from 0 > 1 clutch position over the time rather than smooth linear transition.
- Water reflection not rendering, needs clarification on functionality.
- Qlog discrepancies (I'll let Boomer clarify those).
- Odd console readouts about tyre slip angles or something popping up (same goes for gearbox manual/auto setting, doesn't need to be console displayed imo)
- PerfSDK not working as advertised, broken?
- Multiplayer joining to IP's seems glitched, the person joining has their brake stuck on and are unable to shift
- The Multiplayer Lobby does not let you connect, and subsequently let you host, despite the right ports being forwarded. (Anyone else experiencing this bug?)
- The particles pop-out of existence at the end of their specified lifetime instead of fading away smoothly. It would be nice to have some better control over the fade-in and out over the lifetime of the particle since tiresmoke starts out thick and opaque then disperses and becomes more transparent over time, while gravel or dirt fades in a bit at first then eventually fades away.
- Smoke flickers in the reflections, as though it's missing every other frame.
- Replay bugs: No smoke effects, ghost car is left on track.
- The starter sound plays all the way to the end of the sample instead of stopping when you let off the starter.
- Ghost doesn't work on endless tracks.
- track special.ini: timeline.point_to_point=1, timeline.auto_return=0 - The auto_return setting doesn't seem to work here. I have a point to point track and the car resets 3000ms (3s) after crossing the finishing line, but I don't want it to.
- No reflection in the Racer garage when selecting a car.
- The unsprung weight apparently applies a downforce, try making a 150kg rear axle with the front suspension lighter and the car will act as though it has high downforce when jumping off of a ramp.
- If the wipers are set to rotate in opposite directions then the intermittent position does not rotate back and forth smoothly. It snaps back.
- In RC5c at least, the camera bug is still evident, and on Carlswood (spline based cameras) you can often get stuck so you can't get back to the in-car camera view which is really annoying! - Courtesy of Dave

-----


The Buglist (currently known specific to RC6):

• Try going in reverse, the front brakes appear to lock. After further examination it looks like in reverse the rear tires will lose traction completely if they spin at all. Alex Forbin
• Brakes on, car pointed downhill, car creeps forward and to right. Boomer541
• The physics are screwed up, just try to drive the Baja on the Cloverleaf Highway track and compare with ver090RC5. Try the Lambo also. Details & Details 2 Boomer541
• Problems with surfaces as the water in my Surfaces and sounds track makes the car float up/down. The water under the bridge flickers which appears to indicate a problem with textures. Boomer541
• Carlswood has flickers on the tirewall tops. Boomer541
• Cars wheels go above/below the surface and can make violent bounces. Boomer541
• There are NO skid marks generated. Boomer541
• Freezing my system, forcing a hard reset.The freezing even prevents qlog from leaving any hints as to what is going on. More info in post. Cosmo°
• Physics issues, see post. Chronus
• At night, everything has a red tint to it, can also be noticed during the day on the darker parts of the track or car. Harey (due to nVidia drivers?)
• Reverse doesn't work right, seems you have to slip the clutch to get it to go in reverse otherwise you just spin your tires and sit there. Harey
• Can't run strict=1, can't check car/track for errors!!! Boomer541 post
• When trying to use tracked to check key cameras the only yellow track section that appears is with the first camera (On carlswood). the p-key does nothing and the splines are different than on ver 090 RC3. Boomer541
• The three speed wipers Don't do three speeds. pos 1 - off, pos 2 - nothing (S/B intermitant.), pos 3 - normal sppe, pos 4- fast speed. Boomer541
• In a replay if you use the console you can't send a console command because the enter key has turned into a slow-mo toggle. This means as soon as you use the console in a replay, you are stuck and need to close Racer a 'messy' way. Ie, escape key no longer exits the race. Mr Whippy
• Multiplayer broken!

 

[Mr Whippy]

I'm back using RC5c and my Gallardo again and loving it...

Racer is good, but it when these changes occur to things as fundamental as tyres then they need some talking through or new documentation to really help us get a head-start on them.

There gets a point where the time invested to tweak some random parameters you don't really understand to try remove behaviours which might really be bugs gets too far.

For now I'm confident Ruud would do something to help us out if he had the time. Hopefully he'll get back into the 'tyre' zone again in a few weeks and maybe give us some guiding hints/explanations on the new tyres and coefficients etc

Dave

 

[luthobu]

Hmm. New thread, old topics, same arguments. We have been discussing content since
the old RSC days and have not moved even one step further. On the one hand, we all
welcome new content, but on the other, it has to be good. It is a race condition (pun
intended). Content cannot be good unless a creator has knowledge, and this knowledge
is acquired partly from the community. My first tracks were total crap. But they were
new, and I had visions. Along the years I have learned, I have improved and I have tried
to adjust to the ever changing Racer standards. But after a while you just get tired as
everything you aimed for is put to nothing with a new Racer release.

I would like to believe that I have given something back to Racer and the Racer community,
and not think that because I am not a pro I should not have done anything. IMNSHO
the willingness to create and share should be rewarded - for the effort itself - and not
be put down on behalf of a desire for industrial standard content. Free Racer calls for
free user content and what we get is what they, or we, give, us.

Take it or leave it, but don't put us down for trying.

(Edited: typos and bad grammar)

 

[boomer541]

Bug from bug list:

• The physics are screwed up, just try to drive the Baja on the Cloverleaf Highway track and compare with ver090RC5. Try the Lambo also. Boomer541

Not really a true bug but gave me fits when making a bridge or object with something under that the car can drive over which causes the car to bounce violently or sink into the top surface.

I was working on extending/adding to the "Factory Test Track" (FTT) with a tunnel, waterfall, and bridge over the main track. In ver 090 RC3 the bounce wasn't too bad but in ver 090 RC6 it was completely unaceptable.

The problem is with the bridges polygons under the bridge surface. The geometry flag for those objects was = 6 (Solid, supports car, ground) Making them a different object with flag=0 solves the problem.

So when making a track with bridges make sure the bridge supports are a different object with flag=0.

 

[Mr Whippy]

Well spotted Boomer.

Problem is that flags=0 means no newton mesh is generated for that object so if you want to be able to hit the supports of the bridge then you might need to let the cache build with flags=6 then set it back to 0.

What I'd really like is some kind of mesh/volume system for tracks so we can define DOF that are not rendered, but are there to crash into or use as a reference.

Ie, the current triggerline for reverb is nice, but it'd be better if you could define a volume that if you are in it sets the reverb instead...

As for collide, I guess the newton system could see them for generating it's collide mesh, but then Racer wouldn't actually use them at all for rendering or any other purpose?


Hmmm

Dave

 

[William Geuze]

When you only need to be able to collide with something, flags=2 is sufficient. Flags=6 means you will collide with it, and it is looking for a drivable surface and it's properties supplied in special.ini. If you don't flag the surface you want to collide with as a driving surface in the first place, you should have no errors driving across that bridge. As in TrackEd, the two seperate buttons already indicate that the collide and surface option are two separate things

You can very well use low poly collision meshes. Just apply a transparent material to it and set it to flags=2.

shader_invisible_walls~vf_standard_transparent
{
  layer0
  {
    map=invisible_walls.dds
    alpha_to_coverage=1
  }
}

I have a standard invisible_walls.dds which is 32*32, black rgb, black alpha (obviously )

 

[Mr Whippy]

Hmmm, I thought Ruud mentioned a while back that 2 and 4 were basically the same thing and we just used 6 globally for wheels/things to hit.

Since the car roof might hit somewhere wheels can hit, it makes sense that if you can drive on it, then you can collide with it.
Vice versa I'm not sure when that might be useful.

Maybe that is wrong though.


The latter solution works but it's going to cost in GPU time and start interfering with other transparrents and z-buffer depth etc.

I meant to mention it in my last post any way, but forgot by the end, but recently I've noticed 'empty' shaders in the Racer renderer folder. These are empty which is better for the purpose we are describing here... BUT, I fear the GPU may still be trying to render them as a batch (albeit a very fast batch )

Maybe that is the intended purpose of them, but I don't think Ruud ever clarified it



Dave

 

[William Geuze]

I'll try to explain some more then.

Anything with the collide flag (flag=2)can be driven on, but the wheels will not receive any surface information. This surface information is as you know defined in special.ini, where you can set road noise, grip levels, steering wheel noise, etc. For example, the canned effect for kerbs resides in there.

When you do supply the surface flag (flag=4) to an object, you do get your surface information, but the tires will not detect any collideable mesh beneath them and will fall through the mesh which, according to the tires, does not exist in it's own little world.

Not by coincidence, giving an object flag=6 is actually doing something like this:

flag=(flag=2)+(flag=4)

It's like the relation between a triangle and a polygon. Every triangle is a polygon, but not every polygon has to be a triangle.

Another example, guardrails and walls. These you want the tires and the collision mesh of the car to be aware of. However, it doesn't make any sense for the tires to look for surface information when touching the wall and maybe even for the physics engine to actually attempt driving onto the wall. This could potentially even lead to strange catapult stuff if you are unlucky

To test my explanation, take a car for a spin on a track and hit ctrl-3. The surface stat tab will pop up on your screen and in it, you will see the current active surface per tire, surf0, surf1. surf2, surf3. These will change as you 'touch' pieces of the mesh with different materials and their respective surface properties. For example newly laid slabs of tarmac, which you could give a slightly lower grip value in special.ini. When you then go into the geometry.ini and change all of your flags to 2, which is collide only, remove the cache folder, and repeat the same test, you will see the tires will not receive any surface values.

About the invisible walls messing up with the z-buffer, not in any way that I have seen, since they are not visible in the first place

 

[Alex Forbin]

Thanks for the clarification William, this really helps a lot.

Nice find on the flag=0 solution Boomer.

Alex Forbin

 

[boomer541]

I'll try the flag=2 tomorrow as today was spent updating my nVidia GTX 560 graphics card driver. Took all day with my dlow DSL 4 hours of downloading then testing Racer. Everything had a pink tint. Changed tod folder to a different set of curves, I've about 10 different ones and got good color with no pink tint.

Apparently scene color is dependant on driver as well as tod curves. Fun!

 

[William Geuze]

If you still have problems with it, just upload the track, will be easiest to see what is going on.

 

[Mr Whippy]

Cheers for that clarification William.

That is how we used to do it until the Newton stuff was introduced and from there and racer.nl docs it seemed to be 'ok' to just set 6 for anything you might hit/drive on in combo... I was sure Ruud said it made no difference by this point, but maybe it does again hehe


So right now it seems like we have:

flag 0 (empty)
flag 1 (sky)
flag 2 (newton meshed)
flag 4 (surface material *definitions* passed to wheels only)



Thus for most tracks we just want:

flag 0 (empty)

flag 1 (sky)

flag 2 (we have this just so we don't sink/crash through it, but it doesn't need a surface defined as wheels will never touch it or if they do it's not important by this point)

flag 6 (the main roads/grass/run-off areas where surface material definitions are important)



You have to remember us guys have been through a million transitions. Just pre-newton, iirc, the sky flag for example, of which there are many combos (at a time one was 24 iirc), was such that if you had it set to driveable/surface it was ok, but if you didn't then your car would float over your road and never sit down on it haha

That had a few of us baffled for a long time. Doing it technically wrong seemed to make it work. It made no difference in the end result but it was things like that which made flag setting a delicate matter


It's nice at this point that these things now finally just seem to work and not cause issues for the last few years, so this final clarification on what flag 4 actually does is very welcomed!


Thanks

Dave

 

[boomer541]

I've been using flag=72 or 0 for sky dof's and both work, Carlswood uses flag=0

Also a bunch of other numbers also worked dor sky dof's but it probably s/b 0 as that is used in the default track carlswood.

Thanks for all the good info and now we can majke good bridges. Did anyone try the baja on the cloverleaf track and watch it get launched?

 

[Mr Whippy]

Haha, maybe Sky is 0.

I've just checked and the sky has been about 5 different flag settings on Carlswood over the last 5 years or so... but formally we have never been told that sky has changed I don't think?!

73, 65, twenty something or other, 1, 0... haha...

What we could do with is a Racer.nl that is either updated with better info in these areas because currently the flag setting info is very limited.


All it has to be is a small table of flag and function, and then common uses as I noted above.

Then just a note in the change log that flag definitions have changed, check "URL"


Having to use TrackEd to hope it's setting the right flag values or to find out what values it sets so you know for sure, or having to hope that Carlswood flags are the correct ones to use at any given version release isn't ideal vs a bit of documentation


Cheers

Dave

 

[Mr Whippy]

About the invisible walls messing up with the z-buffer, not in any way that I have seen, since they are not visible in the first place

I still think if there were volumes we could simply flag in geometry.ini that would be seen for generating the newton collision mesh, but ignored for any other purpose, it'd be pretty useful.

That way you don't need empty shaders etc.

Applying a shader at all to something that never needs to be visible and only has a physics purpose for being present, or special effect (maybe a sound volume or something for audio etc), just seems really in-elegant.


Obviously it's the way it is but I think Ruud could improve this really easily by having Racer ignore a certain flag entry, and simply make it visible during the cache building of the newton mesh.

Simple... zero overall cost to the graphics pipeline.

Invisible polygons are still costly. Even just loading them into GPU ram (verts/tex coords, empty texture, batch etc) is cost and there need not be any at all!

Dave

 

[William Geuze]

It's common practice using the Unreal Engine as well though (One entire level was modelled as one low poly collision mesh, worked like a charm and was cheaper on the CPU for collision detection than a per object solution)

In principle I agree, on the other hand, we shouldn't have the need for invisible walls in the first place, I'd rather not use them and provide a visual cue.

 

[Mr Whippy]

In the end it's nice to a range of tools at your disposal, and an empty shader does the trick enough for now... but an even cheaper solution exists and that is simply dumping those empty shader dof after the cache is built

In theory I guess you could write an ini.exe batch to manage the process for newton cache rebuilding if you wanted... but a flag system would be a better way.

It just seems a natural and logical thing to do given the current system is so close to that end use.



I agree on the props system as well.

Ie, block a road off with a 'road closed' sign or a few barriers... but those don't usually go onto verges or pavements and a sneaky driver might drive around and into limbo hehe... that is where invisible walls might come in handy just to cover off the adventurous drivers who ignore the visual cues

I'm sure commercial games though use invisible barriers eventually, say a 10m vertical wall on top of all the armco so even if you get airborne your car will stop before it flies over it.
Many hours of time mis-spent trying to get out of the driving zones in GT3/4/5


Dave

 

[Mr Whippy]

Hmmmm more...

Just looking in the Content to Racer plugin that Thomas Kinet made, there is a flag setting box for 'invisible' but I can't set it to find out what the flag number is hehe.

I might have to pester Thomas and see if he'll spend a bit more time on this in his free time for us just to polish off a few edges.
It's such a fast exporter, really fast... just needs a few option boxes at export time

Dave

 

[luislucas]

Guys, I think I fixed the reversing problem, but I don't have the necessary experience to say if the driving dinamics got worse. So I went to racer.ini and changed:

Debug settings
...
skip
...
; Apply friction circle?
apply_friction_circle=1
; Method; 0=Genta (prefers longitudinal forces)
; 1=vector trim (equal mix of forces); much too simple
; 2=void (don't combine forces; should be testing only)
; 3=Gregor Veble's combined Pacejka (FC_SLIPVECTOR, very similar to Brian Beckman's Physics of Racing Series, chapter 25)
; 4=Cruden combined (not really useful yet)
; 5=none (for MF5.2 testing; automatically used if Pacejka model is set to Magic Formula 5.2)
; 6=Brian Beckman (=3 without factor limiting, see chapter 25; http://phors.locost7.info/phors25.htm)
; 7=Similarity method (~3 with adjusted scalings for Fx/Fy; no optimal SA/SR used), as in the Pacejka book, chapter 4.2.2 mostly, page 168
; 8=Magnus Gafvert, 2003/2004 (~7 with estimated peak Fx/Fy) which divides tire forces into adhesive and sliding (rotating sliding forces)
; 9=Cruden2013; separating adhesive and sliding
; 10=Similarity method (~7) with direct kappa/alpha friction circle (Marno Hopmans); no dividing by (1+kappa)
; 11=Brush model sliding direction (RvG 2013)
friction_circle_method=10
; Maximum slip length for combined slip calculations (5=understeery, 15=snap oversteers)
; This is a default value; tweak it by car (if not defined in its car.ini, this value is used)
max_slip_len=6.0
; Maximum tan(slipAngle); default is 0.75 (+/- 36 degrees), 20.0 (87 degrees) seems to work better
max_tan_sa=20.0
; Maximum brake reduction when wheels stop spinning - default=0.2
max_brake_reduction=0.1
; Adjust force direction when wheel starts locking?
wheel_lock_adjust=0
...
skip
...
; Maximum forces (to try to avoid sudden explosive physics)
max_force=260000 (attempt to stop the game from crashing when driving a heavy bus and hitting something fierce; in the future, this figure should be matched to the car's weight anyway)
max_torque=130000
...

I changed the friction circle method because it looked overly complicated for what it was, and the fps did jump quite a bit - but I'm not sure this is ideal.

 

[Mr Whippy]

Yep it's the new tyre mixing method that is broken.

I bet it's a simple fix though, probably a + or - missing somewhere.

The older tyre mixing systems are reliable, BUT, the default car.ini changes to some of the new and old legacy tyre model variables means that the old models don't seem to work at all well with those new values.


I'm just waiting for the probably very simple fix to this issue, and also a bit of clarification on what the new tyre variables do (and the re-activated or now important legacy ones (lat/long predit values)) until I start using the newer version.


Good work on having a play with things though, Racer needs testers to spot bugs etc

Dave

 

[luislucas]

Just to be clear, it's changing the wheel_lock_adjust from 1 to 0 that did the trick(perhaps because the new tyre calculation can deal with reverse/limit grip and the older didn't), not the change in friction circle method ... I just did that as an experiment of sorts, and it did feel less impredictable at the limit but I don't know that much in order to tell if that's the way it's supposed to feel.

Anyway, changing the forces didn't solve the problem; So I went to the QLOG (kinda fun to discover these things) and got this out:

...
Mon May 27 15:58:31 (INFO ): [racer] Pixfmt 2: 24 color bits, 0 depthbuffer bits (already changed to 24 and it works nicely), 0 stencil bits, 0 alpha, stereo: 0. [qxwindow.cpp:447 / EnableOpenGL]
Mon May 27 15:58:31 (ERR ): [racer] wglGetProcAddress(glProgramVertexLimitNV) failed [gllextmgr.cpp:143 / check_wglGetProcAddress]
Mon May 27 15:58:31 (INFO ): [racer] Render engine using Cg (1.50) [dgpushader.cpp:47 / DGPUShaderManager:GPUShaderManager]
Mon May 27 15:58:31 (INFO ): [racer] DGPUShaderManager::Init() Geometry shading is not supported on this card (ATI?). [dgpushader.cpp:139 / DGPUShaderManager::Init]
Mon May 27 15:58:31 (WARN ): [racer] DGPUShader:Load(data/renderer/shaders/dyn_standard_v.cg): The profile is not supported. [qerror.cpp:41 / QShowCGErrors]
Mon May 27 15:58:31 (INFO ): [racer] WorldRenderer: you have an ATI graphics card (ATI Technologies Inc.). Working around some long-term bugs. [renderer.cpp:575 / WorldRenderer::LoadSettings]
Mon May 27 15:58:32 (INFO ): [racer] Graphics card has support for 0 groups, 0 barriers [dframelock.cpp:371 / DFrameLock::GetFunctions]
Mon May 27 15:58:32 (INFO ): [racer] DFrameLock::SetVSync: vsync was set to 1 (verifying that it now is 1) [dframelock.cpp:177 / DFrameLock::SetVSync]
Mon May 27 15:58:32 (INFO ): [racer] Hardware capability: maxSwapGroups 0, maxSwapBarriers 0 [dframelock.cpp:440 / DFrameLock::JoinSwapGroup]
Mon May 27 15:58:32 (INFO ): [racer] Verify (from driver): actual swap group=0, barrier=0 [dframelock.cpp:463 / DFrameLock::JoinSwapGroup]
Mon May 27 15:58:32 (INFO ): [racer] Physics engine: NEWTON v2.34, architecture 2 [rmanager.cpp:1561 / RManager::Create]
Mon May 27 15:58:32 (INFO ): [racer] FMOD: modified software format is rate 48000, fmt 2, outChannels 2, inChannels 6, resampler 3, bits 16 [qsample.cpp:1297 / QSampleSetup]
Mon May 27 15:58:32 (INFO ): [racer] Controls: main control file is 'profile3.ini' [rcontrolengine.cpp:828 / RControllerEngine::OpenConfig]
Mon May 27 15:58:33 (INFO ): [racer] Safety changed to: SAFE [rcontrolengine.cpp:470 / RControllerEngine::StepInput]
...
skip
...
Mon May 27 15:59:44 (INFO ): [racer] Loading car 'mci-mc9-beta1.07' [rcar.cpp:977 / RCar::Load]
Mon May 27 15:59:44 (ERR ): [racer] wheel4.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1062 / RWheel::Load]
Mon May 27 15:59:44 (ERR ): [racer] wheel5.tire_model.damping_speed = 0.000000, but must be non-zero, like 0.15 (using 0.15) [rwheel.cpp:1062 / RWheel::Load]
Mon May 27 15:59:44 (WARN ): [racer] differentials.count=0; trying the (very) old differential.* path instead (please update your car.ini) [rdriveline.cpp:352 / RDriveLine::Load]
Mon May 27 15:59:44 (INFO ): [racer] 6-wheel cars are a special case; make sure wheel2/3 are at the full rear [rcar.cpp:2164 / RCar::CalcStaticProperties]
Mon May 27 15:59:44 (WARN ): [racer] Car 'MCI - MC9 Detroit Diesel 8V-71T / 8V-92 BETA 1.07' braking factor of all the wheels don't average out to 0.5 per wheel (now: 0.4667); brake balance is not correctly setup like this [rcar.cpp:1929 / RCar::Load]
Mon May 27 16:01:54 (ERR ): [racer] Torque with NaN attempted pass to physics engine - refused [prigidbody.cpp:1411 / PRigidBody:assForceAndTorqueToPhysicsEngine]
Mon May 27 16:01:54 (ERR ): [racer] Force with NaN attempted pass to physics engine - refused [prigidbody.cpp:1408 / PRigidBody:assForceAndTorqueToPhysicsEngine]
Mon May 27 16:01:54 (ERR ): [racer] Fy NaN detected in Pacejka; camber 1.#QNAN0, sideSlip 20.030279, slipPerc -8.736582, Fz 0.000000 [rpacejka.cpp:784 / RPacejka::Calculate]
Mon May 27 16:01:54 (ERR ): [racer] Mz NaN detected in Pacejka; camber 1.#QNAN0, sideSlip 20.030279, slipPerc -8.736582, Fz 0.000000 [rpacejka.cpp:788 / RPacejka::Calculate]
Mon May 27 16:01:54 (INFO ): [racer] Bad wheel 0 force 1.#QNAN0 1.#QNAN0 1.#QNAN0 [rbody.cpp:1429 / RBody::ApplyForces]
Mon May 27 16:01:54 (INFO ): [racer] forceRoadTC=0.000000 0.000000 -3964.931641 [rbody.cpp:1430 / RBody::ApplyForces]
Mon May 27 16:01:54 (INFO ): [racer] forwardWC=1.#QNAN0 1.#QNAN0 1.#QNAN0 [rbody.cpp:1431 / RBody::ApplyForces]
Mon May 27 16:01:54 (INFO ): [racer] sidePrjWC=1.#QNAN0 1.#QNAN0 1.#QNAN0 [rbody.cpp:1432 / RBody::ApplyForces]
Mon May 27 16:01:54 (INFO ): [racer] Going to crash, reason: wheel force NaN [qdebug.cpp:432 / QCrash]
Mon May 27 16:01:54 (INFO ): [racer] Crash detected - attempting to recover some data before displaying the crash dialog [main.cpp:97 / crashProc]
Mon May 27 16:02:07 (FATAL): [racer] Exception 0xC0000005, flags 0, Address 0x00418353
(this dialog text is stored in QLOG.txt)

So I guess the problem is that the suspension model exceeds it's limits due to the weight and the forces involved? As a sidenote, I was rather impressed that the game engine was robust enough to deal with the out of bonds track and car model and partially fix them/point out the problems, must have gone through LOTS of bugs. Btw, any help with optimizing the system configuration is also appreciated.

And I don't know if this was mentioned yet, but that feature that changes the pov angle according to the steering doesnt work at all, which is odd considering that the buttons that do the same work just fine. Changing those buttons to analog control doesn't work either.