Racer v0.8.34 released

[Ruud]

Racer v0.8.34 is out! Get it at http://www.racer.nl/download/racer0.8.34.7z (48Mb, note the 7z extension; you'll need 7-zip from http://www.7-zip.org ).

Enjoy!
Ruud

Changes:
- Bugfix: Director cam didn't work
- Bugfix: Rain didn't affect grip (snow did)
- ENet upgraded to v1.3.3 (small change to avoid unreliable packet regression, and disconnect fix)
- Added input limiters for Pacejka curves for slipangle/ratio/camber/load (see data/cars/default/car.ini)
(wheel<n>.pacejka.slipangle_min/max etc); see http://www.racer.nl/reference/pacejka.htm#inputsoutputs
- Bugfix: Replay was never painted; no camera was defined.
- Bugfix: particles in replays were not animated in reverse mode. Now they are (although not entirely correct)
- Turning AI on while offroad would cause a crash.
- Added ai.spring_factor in car.ini to add some magic forces to keep the car on track (use 'ai scale' for example
to add some speed to the AI line; check out 'ai save' and such).
- CurvEd import of ASCII txt and CSV added.
- CurvEd imports were buggy (zero) if more than 50 points were imported.
- Added textures.stub in racer.ini to optionally load a single texture for every loaded shader; useful
when testing mipmapping (if you're using mipmaps effectively, see http://www.racer.nl/tutorial/stub_textures.htm)
- Added data/images/texture_stub.dds as a default images for the feature above
- Added dev.fast_fade in racer.ini to allow quick fades while developing
- Added wheel roadnoise filtering to simulate rubber; see http://www.racer.nl/reference/wheels.htm
- Added ai.rc_factor in car.ini to be able to help AI if you give it a high grip_factor as well. See http://www.racer.nl/reference/carphys.htm#ai
- Added ai.cg_factor in car.ini to lower effective CG height to help AI drive faster through turns without flipping.
See also http://www.racer.nl/reference/carphys.htm#ai
- susp_implicit_integration now set to 0 for explicit physics. It seems stable for F1 cars with tire_damping,
and the implicit method creates buggy load values in the tires.
- Added ghost.update_if_loaded (defaults to true) to determine whether to update the ghost lap (if you're faster),
even if you've explicitly loaded one with ghost.load.
- Materials without names in DOF files used to get the exact texture name (ie 'body.tga'). The extension is now cut, so it'd become 'body').

 

[camsinny]

Correct me if I'm wrong Ruud, but the stuff in the car.ini does that exactly, only without a UI.

In FMOD you set samples, set a value (RPM) from which it autopitches, set a start and end value and an attack and decay. Exactly the same as a car.ini only you use the mouse for attack and decay and there's some menus you need to click.

The only difference is that FMOD uses a GUI, we use notepad... If you want grab the designer and fine tune stuff in there and just grab the values you pick. It's basically the same.

Saying that makes me want to experiment with skid sounds...hmmm...

Also, Raph, you can use NFS Shift sounds already if you want, just decomp the fsb. Had to look around a bit first but they're just wav files.

 

[Raphael Buthmann]

but .fsb banks are compressed and uses less memory =D . It's better to use fsb too ^^

 

[KS95]

I haven't tried this version yet, but...

I got my MS Sidewinder wheel plugged into my new computer, and it works with Racer brilliantly (amazing control changes in the recent versions - .32 .33) apart from one problem. I only get 7 or 8 fps between 0 and 17 km/h, but above that I get the full 30+fps. Ermmmm, why? lol. Is it fixable?

Also, if I use my MS Sidewinder... Joystick instead, it works fine with no issues

Thanks in advance.

 

[camsinny]

I'd say it'd be something to do with the stick_friction, that's only used up to about 5km/h or something...probably is referenced up to 17.

 

[KS95]

I thought so too, which is why it's at 0% (I don't even know what it does? lol) but that doesn't seem to help..

 

[camsinny]

It's probably that your wheel doesn't support it, so it's slowing down your computer...it's something ruud would have to look at

 

[Mr Whippy]

Movables still seem to cause mega FPS slow down on track start.

Reload track console command fixes it though.

Hmmmm... bit of an annoying 'feature'

Dave

 

[QuadCoreMax]

Movables still seem to cause mega FPS slow down on track start.

Reload track console command fixes it though.
Hmmmm... bit of an annoying 'feature'

The thing is you can't add too many of them, had yesterday 113 cones distributed manually on my new track & when debugging it, it wasn't that fps nice, so I've finally redone the whole with just ~ 35 cones. Done in Tracked 0.8.32.

What's the movables flags you're using for 0.8.34 ?


About fev/fsb why not, I'm in...
I usually extract all wav/mp3 files out of it & choose from there...

 

[Mr Whippy]

The thing is, type 'reload track', and the FPS suddenly rocket up to the same FPS as if the movables were not there.

I use 1024 for movables now.

It's just a loading issue, not a movable count issue, as far as I can tell.

Dave

 

[Mr Whippy]

Just a general feature request thrown in here quickly.

Right now there is no way to have a nice glass type material for a building. Glass needs a reflection map, but we only have access to one, the live envmap of the car. Thus it looks weird to have a building reflecting what the car is seeing.

Is there any chance at all that we can create our envmaps (use the one that is rendered once, or we generate via console command as we drive around the track and run it at certain places), then we can make ones specific for different locations and buildings.

Right now I'm really struggling to have glass look at all realistic on buildings, which is a major problem for almost any race circuit with glassy buildings!


The alternative is to not run live envmapping... then the buildings can use a fixed reflection map (nice), but the car reflections are then lame hehe


Thanks

Dave

 

[Alex Forbin]

Why not just use a standard spherical map for the buildings based on a one time render?

Alex Forbin

 

[Mr Whippy]

I'm easy, whatever the solution is.

We just need a way to be able to define envmaps for fixed locations... perhaps 'render once' at run-time or TOD change, and from a certain defined point in the track.

Ie,


;envmap for main straight buildings
envmap_fixed_01
{
x=200
y=50
z=-200
}

Then in track.shd

$envmap or whatever is replaced with $envmap_fixed_01 in those shaders that want to use the envmap of the main straight...


Hmmmm

Dave

 

[camsinny]

Or if we could just specify one of those texcube's...

 

[Mr Whippy]

Yeah, if we can output a HDR texcube and just reference it... only issue is it means no effective use of TOD features, as the lighting in them would be fixed...
Not a huge problem anyway. TOD is 'ok', but a fixed TOD still allows you to make the track so much better!

Dave

 

[QuadCoreMax]

I'm excited, did anyone saw on Racer.nl new coming features ?

Systems & Signals...

 

[KS95]

I can't find anything, hmm

Edit: I see, from what I understand of what's said, it looks interesting lol

 

[QuadCoreMax]

http://racer.nl/tutorial/system.htm

I love it, it's like all dreams coming true, none of the games have something similar...

+1 Ruud/Mitch !!

 

[boomer541]

New features sound good and are welcomed BUT, I, for one, would rather see the bugs fixed first! Things like the generic suspensions problem, replay problems, etc., need to be fixed for a stable, bug free version and then have new features.

Just my two cents, pence or yen.

 

[Cosmo°]

I'm with boomer on this one. Progress is always welcome, but for the sake of getting that final version out and people back into the swing of things, it'd be great to just polish up a few things and then concentrate on future content and features.

I'm getting a lot of overrun detection messages in this version, with a nearly identical behavior to the NaN errors in previous betas (it was freezes when making contact with the armcos on the old ring2002 for example, back then). It clearly seems to be related to the newton collisions and causes slowdowns and sometimes freezes/crashes as well.

Force reversal issues are persistent too. When driving into an obstacle (like a sidewalk kerb) and getting stuck because of the less than optimal wheel collision detection, vehicles tend to accelerate backwards after a little burnout, attempting to climb the obstacle, even with the clutch fully depressed.

Another thing I keep wondering about is the use of alpha_to_coverage=1. We need it on most transparency objects to get things like shadowing, vehicle headlight behavior and rendering through multiple fences/windows to work. At the same time it causes moving colour banding issues, dot patterns (see trees on Carlswood) and such. Are these things known? Any idea how we improve that situation?

When we use Racer's auxilliary tools, like tracked, or ini.exe for batch files - they screw up our file formating. It would be really nice if they could leave the easy to read, neatly organized layout others and I have been using for ages alone

 

[QuadCoreMax]

The dot patterns issue, if you merge your vertices, it should reduce that glitch.

Sure, Tracked should listen/record the whole & do a proper update only on updated objects. Idk once you know, it makes not much difference, if it doesn't work the 1 way, we make it work the other way !

For the transparency, not that I know, you don't need alpha_to_coverage 1, just using alphafunc param + the standard_vf shader & should be good.