Racer v0.8.33 released

Ruud

RACER Developer
Things have been very busy, lots of things going on at the edges of Racer (not really core Racer), but here's an update finally. :)

Get it at http://www.racer.nl/download/racer0.8.33.zip (75Mb)

Known issues:
- The current replay should be re-recorded
- AI training is very alpha, it currently s*cks

Changes:
- Added 'gfx.show_traffic_lines' option to visualize track grid
- Added 'show traffic' and 'hide traffic' console commands
- Traffic improved to be usable
- Added 'gfx.bestline.source' which determines whether the bestline is derived from AI or the ghostlap
- Added log.buffer_time to be able to change the log buffer size
- RTD logging improved
- DXT3 dds format was flipped incorrectly (bad detection of DXT3 format)
- dbg_controls.throttle/brakes/clutch/steer now work again (if dbg_controls.update=0)
- Multiview camera were slightly off wrt eye position
- Added 'show log' and 'hide log' console commands to show live log details
- Cg dll's updated to v3.0.16
- Added log.database.dir for eternal logging of RTD telemetry files (customer)
- Added ghost.time_scale for slow-motion ghost laps (mostly for testing use)
- Changes in thread creation (handle leak fix)
- Added data/images/fadeout.tga where Racer fades to in menus and other situations
- Added 'show ailines' (and 'hide') to visualize AI lines
- Pressing Ctrl-F6 to drive an AI lap now accepts AI cars; they will try to train themselves.
Use 'ai learn save' to save the trained lap.
Let it run for quite a number of laps. See http://www.racer.nl/tutorial/newtrack.htm#default_ai
- Added 'ai reset' console command to reset AI velocities to 50 km/h (for AI training purposes)
- Added 'ai scale <v>' console command to scale AI velocities
- Experimental friction circle method added; #6. Is like #3, only without clamping max_slip_len (dbg_car.friction_circle_method). Doesn't seem too viable though.
- Per-wheel tweaking of 'max_slip_len'; an addition to the tire model to constrict large slip lookups
See http://www.racer.nl/reference/wheels.htm#combinedforces
 
The issues you had, same here...

After tweaking my ATI CCC, got after 2 secs loading into the game a crash.
CCC params (newest ATI drivers) :

Code:
Driver Packaging Version    8.85-110419a-118226C-ATI    
Catalyst™ Version    11.5    
Provider    AMD Technologies Inc.    
2D Driver Version    6.14.10.7193    
2D Driver File Path     System/CurrentControlSet/Control/Video/{B7DD40D0-281C-484D-869E-5D124F1C4BF8}/0000     
Direct3D Version    6.14.10.0833    
OpenGL Version    6.14.10.10750    
Catalyst™ Control Center Version    2011.0419.2158.37550    
AIW/VIVO WDM Driver Version    6.14.10.6238    
AIW/VIVO WDM SP Driver Version    6.14.10.6238
Racer Log

Code:
Wed Jun 01 15:52:05 (INFO): [racer/3068] Crash detected - attempting to  recover some data before displaying the crash dialog
Wed Jun 01 15:52:07 (FATAL): [racer/3068] Exception 0xC0000005, flags 0,  Address 0x01CDA021
(this dialog text is stored in QLOG.txt)

OS-Version: 5.1.2600 (Service Pack 3) 0x100-0x1

0x01CDA021 [atioglxx]: (filename not available): (function-name not  available)
0x016AE301 [atioglxx]: (filename not available): (function-name not  available)
My CCC 3D options :

Use custom settings => enable
HD AA => disabled
Adapative AA => disabled
HD Aniso => enabled
MipMapping => High Quality

Same settings works with 0.8.32...getting some 10-15% more fps.
I suspect those god damn drivers....I recently installed because of some 3D app issues....grrr

Reverting to defaults CCC options.
 
Another Bug?
Tried replay, ran ok, made video and had minor glitches when played back. Saved replay, tried to view replay from menu. BUG BUG!

The screen went all black, car sounds like it running but I can't see it or track. FPS 3000+. Nothing unusual in the Qlog, physics engine: v. 2.29.

Anyone else have this problem, er bug? The same occurs on ver 0.0832 and 0.0831. Only a replay on carlswood works.
 
Thanks for the new beta Ruud. Dave already mentioned the max_slip_len feature and my understanding of how it works is pretty much the same - now, I'm just wondering what the intended usage is. Thinking about it, we already have pretty good and distinctive control over the post-OSA/OSR region of the pacejka curves and we can also specify different sets per axle/wheel already.
I guess this max_slip_len feature is more convenient as a form of driving aid then. Certainly when testing it out, the impression was similar to what happens in simulation inspired games, where vehicles get some leeway but ultimately are hard or impossible to spin out. Is that what you were after or am I misunderstanding, misusing it this way?

AI and traffic features will have to be checked out still, from a couple of quick attempts on various tracks it seems a timelapse function could be nice to speed up the AI learning process a bit, similar to fast_time maybe?

Ctrl+G gear indicator now also shows speed and rpm - makes it a bit more difficult to get only the gear position information for me, when I'm relying on this feature on cars with (semi-) automatic transmissions and no HUD (which I think is the only reason to be using it in the first place).



A more general observation, you keep using regular .zip format for the releases, but a simply recompressing of the contained folder with 7-zip reduces the archive size down from 75MB to 45MB, so surely would be preferrable for both the server and some user sides :) That said, I'm always getting nice high speed connections from racer.nl, but not everybody downloads 75MB in a few seconds.

max_slip_len is a cap on the Pacejka lookups really. If you look at an actual .tir file for example you can see:

Code:
[VERTICAL]
VERTICAL_STIFFNESS       =  237644.6267      $typarr(  15)       $Tyre vertical stiffness
VERTICAL_DAMPING         =  500              $typarr(  16)       $Tyre vertical damping
BREFF                    =  3                $typarr(  11)       $Low load stiffness e.r.r.
DREFF                    =  0.045981         $typarr(  12)       $Peak value of e.r.r.
FREFF                    =  0.12114          $typarr(  13)       $High load stiffness e.r.r.
FNOMIN                   =  3619.8           $typarr(  14)       $Nominal wheel load
$----------------------------------------------------------------long_slip_range
[LONG_SLIP_RANGE]
KPUMIN                   =  -0.414743        $typarr(  23)       $Minimum valid wheel slip
KPUMAX                   =  0.40448          $typarr(  24)       $Maximum valid wheel slip
$---------------------------------------------------------------slip_angle_range
[SLIP_ANGLE_RANGE]
ALPMIN                   =  -0.31            $typarr(  25)       $Minimum valid slip angle
ALPMAX                   =  0.31             $typarr(  26)       $Maximum valid slip angle
$---------------------------------------------------------inclination_slip_range
[INCLINATION_ANGLE_RANGE]
CAMMIN                   =  -0.05            $typarr(  27)       $Minimum valid camber angle
CAMMAX                   =  0.05             $typarr(  28)       $Maximum valid camber angle
$-----------------------------------------------------------vertical_force_range
[VERTICAL_FORCE_RANGE]
FZMIN                    =  929.58           $typarr(  21)       $Minimum allowed wheel load
FZMAX                    =  7931.86          $typarr(  22)       $Maximum allowed wheel load

Here you see that the Pacejka curves (this is in an MF5.2 file) are very restricted in what their valid range is. So I don't agree that it's 'misusing', but rather capping of the curve inputs. It might need to be done like the TIR file; capping input SA and SR to a valid range. That's what max_slip_len does more or less, only in a different place. So the curves become unrealistic beyond certain input values, which is a reason why cars can get very oversteery. By capping the inputs a bit, you add some more tweaking to the tire response.

AI learning is very alpha; it now looks a grip again (I believe v0833 looked at being able to keep near the driving line, but that is dependent on steering control, so not a good qualifier). But it is adding faster/slower/faster chunks, so that's not good for smooth driving. Quite a difficult area. The fast_time equivalent you're looking for is 'realtime <x>'; I use it a lot for AI training tests, also for checking AI lines. I can drive around 'realtime 7' on my PC (Quadcore 3Ghz something) without things going too fast.

On zip, I always use the standard Win7 zip. I guess it s*cks then. ;-) 7z indeeds makes it 45Mb, whereas 7z compressing to .zip makes it 69Mb. Quite a difference, perhaps 7z is the way to go then!
 
Vsync was doing something like that for me as well, it seems like it aimed for fractions of the total possible frames that could be hit consistently (60 = 1:1, 20 = 1:3, 12 = 1:5). It would be nice if there was an intermediate mode where it would only enable vsync with fps >=60, and just go for maximum framerate below 60.

The nice thing about vsync is that you get rid of tearing. If you'd turn off vsync and do a software cap on framerate, you'd get tearing back, but probably constantly at around the same spot onscreen. I don't think I can turn on/off vsync at will while running (or can I, hm).
 
Ummm, just a wondering. MF5.2 has slip ranges in both lag/long.

Would it be possible to do that for pacejka89 too? Does it make sense to be able to limit the max slip ratio/angle that way, than limit the calculated total slip len?

That way you can force the circle to be more ellipse shaped etc!?

Not sure if we even need to or not, just that MF5.2 does it?!


All good stuff.

Dave
 
BUG?

Pretty sure that the rain grip reduction isn't working.

Yes, I've seen there is an entry in racer.ini, but just set rain=1 on a track and drive around. Doesn't seem slippy to me. Snow grip reduction is working, but not rain.

Been like this for a while now, but doesn't seem to have been picked up elsewhere. Anyone else finding rainy weather is still very grippy (as in dry grip levels)?

Dave

Fixed in v0.8.34. It hasn't worked since at least 2009, it seems, only with snow!
 
BUGS?

If you use 'reload track', the next time you try use the "C" key to change camera, Racer crashes (can post screen showing info if needed), are others getting this?

...
Also noticed if I use "wireframephys on", I can see all my cones are using a proxy convex mesh. Setting "shape" as 0 or 1 has no effect, or doesn't use a sphere or box bounding...

Reload & C fixed in v0.8.34.
The cones look like cones in the physics here; we're using this in our Zandvoort:
Code:
  cone_17_cone_01
  {
    file=cone_17_cone_01.dof
    flags=1024
    type=0
    trans_movable_to_zero=1
    rot_dyn
    {
      x=0.000000
      y=0.000000
      z=0.000000
      w=1.000000
    }
    offset_dyn
    {
      x=0.000000
      y=0.000000
      z=0.000000
    }
    group=0
  }
 
Ummm, just a wondering. MF5.2 has slip ranges in both lag/long.

Would it be possible to do that for pacejka89 too? Does it make sense to be able to limit the max slip ratio/angle that way, than limit the calculated total slip len?

That way you can force the circle to be more ellipse shaped etc!?

Not sure if we even need to or not, just that MF5.2 does it?!

It's not really the realm of MF itself; you just enforce limits to the inputs. It might be good though; our .tir files supply those limits and I do notice some curves go haywire when applying a lot of load, for example. It would work for both MF5.2 and Pac89.
 
Yipee, some fixes :D

The rain one sounds trivial, but it's handy for testing car handling when you know a given car behaves a certain way in the wet vs the dry.

Also, wet tracks with envmapped ground look pretty cool with appropriate shaders (just a shame that sometimes cones reflect in the puddles that are about 10x bigger than they are haha)

Thanks!

Dave
 
Talking about animated/skeletons objects like cones & stuff, couldn't we have a pickline which extends to the next 'pickline' that means having a big curve where we load the same dof in order to distribute it 'randomly' thru all picklines ?

The fact is, for now, we load animated/skin meshes/objects per 'pickline' (yellow line when holding Shift + LMB) which is unhandy in cases of bigger tracks.

Cool stuff the new joint attributes in Tracked & the according scripts !
 
Talking about animated/skeletons objects like cones & stuff, couldn't we have a pickline which extends to the next 'pickline' that means having a big curve where we load the same dof in order to distribute it 'randomly' thru all picklines ?

The fact is, for now, we load animated/skin meshes/objects per 'pickline' (yellow line when holding Shift + LMB) which is unhandy in cases of bigger tracks.

Cool stuff the new joint attributes in Tracked & the according scripts !

wat?
 

Latest News

What is the reason for your passion for sim racing?

  • Watching real motorsport

    Votes: 180 66.7%
  • Physics and mechanics

    Votes: 116 43.0%
  • Competition and adrenaline

    Votes: 125 46.3%
  • Practice for real racing

    Votes: 52 19.3%
  • Community and simracers

    Votes: 73 27.0%
Back
Top