RSX / RCX & REX Files {Scripting}

If you move the "wait $response" so it comes in between calculating the new ff and applying it (above send cmd), then it'd delay the response time a bit. Right now it just limits the update frequency (about 5/second)
 
I'm a bit uncertain how these scripts work.

I assumed a wait anywhere in the while loop would mean the same end result, since the while loop is run every frame that is painted?

Or will it calculate the value on one frame, then you can wait say 10 frames, and write the calculated value to the console, all within that one while loop?


This is where the scope of these scripts is a mystery to me still. It's not very clear what is best practice yet for different things. Ie, it'd be better running this per physics step, not per paint?!


Ideally I'd want to simply read Nm every physics step, and then use it to move the friction value up and down like an SMD camera moves around under accelerative forces (kinda damp the system with a few coefficients) That way the friction value is always getting updated, but it's not responding to big changes in single steps which it still does now a little bit. That way the force feedback will feel ultra smooth and damped and just, err, really nice :D


Still can't wait for having some control over brakes and throttle so we can do better ABS and TCS systems, and fake some turbo lag, and maybe even fake brake fade etc :D
Such simple concepts that we can implement in scripts very easily, then when they are refined enough Ruud can just drop the syntax logic into Racer properly.

Hmmm

Dave
 
Okay, when you put an 'interrupt', it stops execution, waits for the next frame, and continues then. paint/physics just changes whether it's doing this every frame or every 1ms. If there's a "wait" in the script, it waits that amount of time ignoring new frames.

As far as I know, it only runs the script from the top when you load the script, and when it reaches the end of the script file. If you have a "while 1" loop, it'll never hit the end, cause it's stuck in the loop forever.

I can't really test ff adjustments cause I don't have a wheel right now...

Implementing SMD in a script would be fairly straightforward, you store distance and speed, and every physics update you adjust the speed (-k*distance*time step for the spring), damp it (rho*speed for a linear damper, with rho<1 - adjusting for time step, which is slightly more complicated here), then adjust the distance according to the speed (speed*time step). Pretty straightforward discretization of the actual integral that applies.

Not sure the physics step is necessary for force feedback, as I don't think it updates at 1000Hz. You might want to implement it there, then include a 'wait' so it's going at say 100Hz instead. Or leave it in the paint step, but not have an interrupt - just wait 10ms on every loop round.
 
The thing is, physics runs at a fixed speed, the paint steps don't due to FPS speed changes?! This is best in physics surely?


Still not sure why while 1 loop matters, or the interrupt. That just means the code inside the while loop runs forever. Once inside then that is all I should care about? Are you saying that any paint or physics script will run every frame without that anyway?
I'm just basing this off bits of code I've seen posted up here etc. There are no official documents or guides on how all this works, hence me still wondering if what you are saying is 100% right, or just how you have managed to get it working?

It'd be nice for a few 'best practice to do X Y or Z' scripts from Ruud and Mitch... right now we just have snippets that don't tie up too well for a non-programmer like me :)



Sounds like a wait command is fairly useful then. I guess the script is then ignored, and only returned to at the line AFTER the wait command, after the specified time. Quite cool. It will indeed be best before sending the command to the console for a really basic damping system.

Where it is now, it's more like just a stepped response to Nm, rather than a lagged response which is what I was more after.



So really all I need to do is this?

//Focus on the car used by the script owner
rcar $car=get scriptowner car

string $cmd
float $nm
float $ff_friction

int $weight = 5250
int $residual = 500
int $max_mz = 14
int $response = 200

$nm = sqrt(pow (get $car nm) to 2)

$ff_friction = $weight - ((($weight-$residual)/$max_mz) * $nm)

wait $response

$cmd = "ff friction " + ($ff_friction)
send $cmd to console

??

Hmmm

Thanks

Dave
 
Yeah, in terms of practices, anything that affects car physics should probably run on the physics update, while anything that's visual should run on the paint update.

So, cause the wing raising on braking is (for now) all visual, it goes in paint. If it could adjust the car's wing physically to match, thus increasing downforce and drag, that part should most likely be in the physics step, while moving the generic object would stay in paint.

A script will run indefinitely without the wait 1 + interrupt, but it'll have to initialize variables every time it's run. It's like it implicitly has a loop around it with interrupt at the end. I think the variable initialization is a decent reason to prefer the while 1 / interrupt structure - it reduces the number of commands, and thus should make the script less heavy on execution.

You can also run scripts from oncar.rex, and those should only be executed once (when the car's loaded).

The way you wrote it looks like it would work out okay.
 
Hmmm,

I guess the while1/interrupt is ok for this then. I guess to run on physics steps I do "scripts\physics" folder?

I can streamline the script lots by combining it into just a few lines and removing the variables, but for now it made sense for user tweakability... once you have good values you like it's rather easy to make the bulk of the code just one line :D

Dave
 
Hmmm, running it in the physics folder makes it nice and smooth with a pause of about 75 steps or so (pause in-between the Nm check and the console command as per Stereo's suggestion)... it's much better in physics than paint!

I'm gonna try streamline the script more so it's really easy to set up for users to get the overall weight how they like it, but hopefully allowing it to retain the car authors tuning with regard to weight change and feel balance!


After playing GT5 and liking how the cars FF feels, this is the closest Racer has ever felt imo... better yet, it's possibly more realistic because Racer has nicer Mz to work with, which means it's feeling pretty good to my hands anyway :D

Yay!


Now all we need is the ability to influence some car.ini parameters like max_torque and brake_factors (so in essence being able to manage TCS/ABS and such systems more faithfully per car), and also wing coefficients (active aero spoilers ala Veyron etc :D )

Endless possibilities, just need more things to be able to tweak at :D

Dave


EDIT!

Ooooo, forgot to re-run list scriptfuncs and scripttypes, looks like throttle and other adjustments are in. I think I've just wet myself ;)

Now you won't see me for a few days while I write some ESP haha :D

Dave
 
Mmmm, nice, we also have per-wheel braking factor adjustment (good for multi-channel abs for example), and torque factor (engine), and power_gearing value, so we should be able to adjust our 4wd cars with some interesting characteristics now!


I'm just tinkering with a turbo and I'm making my brain hurt haha.

Having a truly independent system that feeds off external values is actually fairly complex if you want nice behaviour. Just tinkering with a system where you have baseline torque due to request (off-boost), and then the extra torque is allowed to be factored in as the 'turbo' system is spun up from it's zero state to max speed, which feeds off throttle position so far, and spins down using a constant.

I might need to use a nice method to describe the baseline torque vs rpm, so at idle rpm the torque response is normal, but as you get where the real car begins to boost, the baseline torque drops off... hmmmm


All fun and interesting!
 
Fairly straightforward turbo script - I've got it set up to kick in around 3500rpm WOT (if you're accelerating more slowly the turbo waits longer). Before that, as is displayed, it uses 0.5 of maxtorque so the car will be slower than usual. Once the turbo gets to ~16k units (everything's just made up anyway) it'll be at normal torque.

Tweaking $turboinertia affects how fast it spools up - lower is quicker.
scripts/paint/turbo.rsx (should really be a physics script, in paint so the numbers can be displayed)
Code:
rcar $car = get local car
// variables to use on the car
float $throttle = 0
float $maxtorque = 1
float $rpm = 0
// variables to use on the turbo
float $turborpm = 0
float $pressure = $basepressure
float $exhaustforce = 0
//---- the rest are constants
// atmosphere is around 15 psi, right?
float $basepressure = 15
// fudge factor to determine how fast it spins up.  Higher = slower.
float $turboinertia = 1
// static fric. to get the turbo spinning.  If exhaust pressure is lower than this, turbo stays at 0 rpm.
float $staticfric = 3.5
// how much air the turbo naturally pushes per rpm (subtract from exhaust pressure when spinning)
float $turbofactor = 0.0006
// how much extra intake pressure is generated per rpm
float $compressorfactor = 0.001
// what's the max pressure it can put out? Assume above this it just goes to a wastegate or something.
float $maxpressure = 30
while 1
{
  set $car maxtorque factor 0.5
  $throttle = get $car throttle
  $maxtorque = get $car maxtorque factor
  $rpm = get $car rpm
  // calculate exhaust force coming from the engine
  $exhaustforce = (0.1 + $throttle) * $rpm * $pressure * 0.001 / $basepressure
  // find power compared to turbo velocity
  $exhaustforce = ($exhaustforce - $staticfric) - ($turborpm * $turbofactor)
  $turborpm = $turborpm + ($exhaustforce * interval / $turboinertia)
  if $turborpm < 0
  {
    $turborpm = 0
  }
  $pressure = $basepressure + ($turborpm * $compressorfactor)
  if $pressure > $maxpressure
  {
    $pressure = $maxpressure
  }
  else if $pressure < $basepressure
  {
    $pressure = $basepressure
  }
  $maxtorque = $pressure / $maxpressure
  set $car maxtorque factor $maxtorque
  paint "Throttle" at float[2]{20,10}
  paint $throttle at float[2]{100,10}
  paint "Max Torq." at float[2]{20,30}
  paint $maxtorque at float[2]{100,30}
  paint "RPM" at float[2]{20,50}
  paint $rpm at float[2]{100,50}
  paint "Turbo RPM" at float[2]{20,90}
  paint $turborpm at float[2]{100,90}
  interrupt
}
I made it do less than 100% of maxtorque so that the clutch won't slip on tuned cars.
It's really only a lot of lines cause everything is variable. Plus all the paints, so you can get an idea what's going on.

What it needs next is a way to play a sound, tuned to the turbo rpm variable. Of course, a boost gauge needle, hooked up to $pressure, would be about as good.


I've assumed that the throttle directly controls what percent of air intake happens. So 50% throttle is half as much air (thus half the pressure) on the exhaust. I suspect the actual formula for throttle -> airflow is more complicated.
 
Looks pretty nice so far. Fairly similar to what I was doing.

The key value really is the one you have defined near the start though

while 1
{
set $car maxtorque factor 0.5

Ideally you want to have that factor a variable too. That is the torque factor at min boost, and you move to 1.0 at max boost.

That figure is in a sense the responsiveness of the engine off-boost. A 1000bhp Skyline might need 0.3 for that factor, so until it gets some boost it's cutting out loads of torque.
A car like a 135i BMW that runs quite mild boost for only 270 > 300bhp vs the same family engine from NA > turbo, might have the torque factor at 0.8 for example, so 80% of the torque is always there, 20% comes with some lag...


So imo, you need to define that as a variable for users to tune.


The second problem is that the turbo is quite independent of engine rpm. A higher gear and slower progression through the revs usually gives boost sooner and at lower rpm. I think rpm are tempting to use in there, but are probably best left out altogether.

The last issue is that when you define your torque curve, you have a low-rpm torque gap where the turbo can't ever get fast enough in real life. The problem is your 'script' turbo is cutting torque all over, so the low-end will feel even more laggy while in real life it might not be at all.
So we need a way to compensate for that too. We could do with saying something like the initial max torque factor is adjusted by engine rpm and a pair of variables which it interpolates between, say for a 1000bhp Skyline a curve might build up from 3000rpm and hit peak at 4500rpm, so you would have max torque factor at 1 from 0-3000rpm, and then from 3000-4500rpm have it change to the new factor of say 0.3, so it gets laggy.


Personally I think it's too complicated. Mine looks a bit like that now, but the reason I have too many variables is I'm chasing around problems which are generated by the above issues. Those above issues are more real ways to get a realistic turbo behaviour.


I'm aiming for a list a bit like this for user inputs.

spinup (rate it spins up)
spindown (rate it spins down)
boost (the value that moves around and defines how much instant torque you get)
boost threshold (where boost starts being added)
peak boost (where boost stops building up)

In theory that should be enough.

You can grab the turbo max speed as a notional amount from 1-boost... then you can just use spinup/spindown values in the appropriate magnitude range to work with the kinds of values that gives you (between 0 and 1)

I realised last night that having min/max speed defined, and spinup/spindown, just resulted in values that could all be worked up and down with the same end result.

Ie, half spinup, half spindown and half the max speed and it was the same for all intents and purposes. Max speed seems to be pointless to set by another user input variable. The magnitude of the variables is kinda irrelevant, what seems to matter is that they are 'tangible' variables that make sense wrt the real system :)


Looks like you were thinking the same things as me hehe, but the issue last night for me was the lag was all over, and on high boost engines (ie, not much torque at full throttle off boost vs on boost like a 1000bhp skyline) the low-rpm part of the torque curve was horrible... you do need a way to turn off the turbo effects there.
The only alternative is to add torque back in, BUT, that is dodgy because it's not how the system works irl. Imo, as you deviate from real behaviour logic, the further from reality it will react.


Hmmm

Dave
 
Oh, as per sounds. It would be nice to add a sound maybe. But for now, the fact that you don't get an instant sharp change when going full throttle between the acc/decc sound sets is nice.
Now if you tune the sounds a bit more realistically (ideally would be dB system with auto gain control, but hey ho), for a turbo motor they are quite loud on boost acc vs off-boost dec, and sound quite different.
It's pretty nice now going full throttle and having a soft sound change and build-up in volume with the boost! If you set the turbo whooshy noise right, it works ok.
I guess long-term a turbo sound would be best though, but it'd have to be programmed into Racer etc...

On to another thought, in theory if you alter the throttle rather than max_torque, you can then have a gauge for that, ranging from $boost > 1... no way to gauge max_torque variable though hehe :)


Dave
 
I disagree Dave, you shall think the other way, we're trying to simulate things, that really means 'faking' behaviors, the same for turbo. Since I do know some about turbo cars, (had a GT MK1 @ 180HP/950kg 1,3 bars custom dump valve, custom chip re-programmation etc..) they basically behave accordingly to the rpm. Sure, the quicker you go in higher rpm ranges, the less turbo output you'll get at some point. That's what defines a turbo model & a lot of varieties of models exist. I would just try to think how to make it simple & somewhat realistic enough.

About sounds, sure the scandalous 'pschhhhh' is a must & should be implemented (should be do-able , been testing sounds/images via scripts) & mix them accordingly. Also, most people forget, there's the 'wastegate' sound which also does a really particular sound, that happens just after releasing the throttle when fully pressed.

I'll give a shot to Stereo code & let you guys know, I think we should merge the best ideas/codes together & work from there. :rolleyes:

Cool stuff ya doing !
 
I disagree Dave, you shall think the other way, we're trying to simulate things, that really means 'faking' behaviors, the same for turbo. Since I do know some about turbo cars, (had a GT MK1 @ 180HP/950kg 1,3 bars custom dump valve, custom chip re-programmation etc..) they basically behave accordingly to the rpm. Sure, the quicker you go in higher rpm ranges, the less turbo output you'll get at some point. That's what defines a turbo model & a lot of varieties of models exist. I would just try to think how to make it simple & somewhat realistic enough.

I know what you mean.

I've been tuning cars with turbo engines for about four years now, so have read lots of books and considered the fake vs sim thing quite a bit against my on-road results, dyno results, boost logging etc etc...

Here is my code so far... (probably quite similar to Stereo's by now, and my last one, just added the min/peakrpm's and the comp variable (0 = uber boosted (probably no use), 1 is essentially an NA engine)
The values for spool and friction feel ok where they are, but fine tweak to get things perfect.

rcar $car=get scriptowner car

float $rpm
float $request
float $maxtorque
float $boost
float $maxthrottle = 1
float $speed = 0

float $comp = 0.65
float $spool = 2.5
float $friction = 1.5
float $minrpm = 1500
float $peakrpm = 2500

while 1
{
$request = get $car throttle
$rpm = get $car rpm

//stops turbo spinning backwards (friction will be 0 at 0 speed, so it'll stop slowing down)
//or spinning on forever (artifical limit to simulate wastegate or running out of efficiency etc)
if $speed > 1000
{
$speed = 1000
}
else if $speed < 0
{
$speed = 0
}
else
{
$speed = $speed + ($request * $spool) - $friction
}

//boost/turbo are inactive until min-rpm (boost threshold)
//boost/turbo are fully active by peakrpm, linearly interpolates adding boost between minrpm and peakrpm
if $rpm < $minrpm
{
$boost = 1
}
else if $rpm > $peakrpm
{
$boost = $comp
}
else
{
$boost = $comp * (($rpm - $minrpm) / ($peakrpm - $minrpm))
}

$maxtorque = ($request * $boost) + (($maxthrottle - $boost) * $request * ($speed/1000))

set $car throttle $maxtorque

paint ($speed) at float[2]{650,125}
paint ($boost) at float[2]{650,100}
paint ($maxtorque) at float[2]{650,50}

interrupt
}

My main issue is this line needs 'inverting' as it were...

$boost = $comp * (($rpm - $minrpm) / ($peakrpm - $minrpm))

As you pass 1500rpm, I want the boost value to be 1 (from the sub 1500rpm part), and as you move towards 2500rpm, I want the value to move towards the $comp value (0.65)... so it's blending between the two values between the two rpm parts. That way it's lag-free and torquey etc off-boost, but as you build to peakrpm you get into the meat of the boost where lag will be largest.

Quite simple really, just that is where I have got to tonight.




I considered using rpm too, but since the compressor and turbine demands are fairly linear, it's almost like rpm cancel out. Double the rpm and you double the gas flow to get the same boost, and you roughly double the exhaust energy to run the compressor near twice as fast. It essentially cancels out here. Adding it in just to cancel itself out seems pointless.

Note I'm using the throttle value, not sure why vs max_torque value. Just seems better when considering awd, where you need to factor the max_torque and power_gearing values, and don't want two scripts fighting over the same value.
Also, having max_torque = 0 had some weird issues for me with the engine returning to idle.

Hmmmm...



As per wastegate sound, the wastegate is activated different ways on different cars. Some don't have them. Some do, but they won't open on a throttle lift, while some mega-boost cars will open the wastegate on throttle lift because they generate so much boost even before the wastegate is open, that a lift of the throttle can spike boost before the dump valve activates, and so open the wastegate (open to air type maybe), which is that loud chatter I think.


But it's getting too complex. Best to just get 90% of the way there with 10% effort kinda thing.

I personally don't care too much for absolute details here, it's just adding a good deal of the sensation/effect to immerse you more. Having throttle lag instantly makes it feel like a turbo. That is probably enough. My steering script is rather basic, but it's enough in the confines of my g-free environment and living room PC desk, to immerse that bit more :D



Longer term we want all these scripts really well written so we can share variables around other scripts. Ie, you might want an intercooler script that gets cold/hot and adjusts boost values a bit... for example :D
So the turbo script can be left alone, and you just set up an intercooler that gets hot after so much use, and trims the boost variable from there.


Just want to get that off > on boost rpm thing the right way around, then I'm happy with that for now for a project car or two. Then it's back onto the Lambo for some nice awd variable torque split action hehe :D

Dave
 
The last issue is that when you define your torque curve, you have a low-rpm torque gap where the turbo can't ever get fast enough in real life. The problem is your 'script' turbo is cutting torque all over, so the low-end will feel even more laggy while in real life it might not be at all.
So we need a way to compensate for that too. We could do with saying something like the initial max torque factor is adjusted by engine rpm and a pair of variables which it interpolates between, say for a 1000bhp Skyline a curve might build up from 3000rpm and hit peak at 4500rpm, so you would have max torque factor at 1 from 0-3000rpm, and then from 3000-4500rpm have it change to the new factor of say 0.3, so it gets laggy.

Different philosophy of how to define the torque curve perhaps.

With mine the assumption is that the torque curve shows power at maximum boost pressure. If you use the curve straight from a dyno, then it's like you said - 1.0 up to 3000rpm, then drop to some fraction of that once part of the power is due to the turbo. If you want to leave the torque curve as measured by a machine, your way works.

The third option would be to assume the whole torque curve is for the NA engine - and add on max_torque above 1.0, plus possibly dipping below 1.0 when the turbo's not spun up, since it'll introduce some backpressure and other obstructions to airflow. That's kinda the reason I went with so many "realistic" variables - it's easy to slot in a wastegate/blow-off valve when the turbo is overpressurizing, that acts as expected (drop boost amount without lowering the turbo speed). Or include launch control that misfires to spin up the turbo at lower RPMs.

I left in the max_torque=0.5 by accident - the actual amount is defined by ($pressure/$maxpressure) at all times, ignoring that value. Since in that case min pressure was 15 and max was 30, it ends up being 0.5 anyway - rising to 1.0 when pressure is equal to 30. If the pressure difference were smaller (eg. 15 to 20) then it would go from 0.75 to 1.0 instead.
 
Both of your codes contains missing/non-existing functions, so "no default" compilation.

Stereo code looks good from the generated values I can see, that's behave quite nicely in-game. Dave's one would need some more love, I suppose waiting some more days & we will get a better scripting system with all kind of getters & setters which would ease our work.

Sounds needs to be implemented, some new Racer sounds functions/objects/attributes could be useful in that case...
 
Maybe because mine resides inside my car folder ? I was suspecting that kind of answer, I'll try the other way + with new newer version.

EDIT :


My bad Stereo, looks cool hiyaaa, new stuff, I've just generate the docs !
I'll give a deeper look, cool stuff, I'm wondering why Ruud didn't included in the log list ?

Now I see why...

Thx Ruud/Mitch :D
 
Different philosophy of how to define the torque curve perhaps.

With mine the assumption is that the torque curve shows power at maximum boost pressure. If you use the curve straight from a dyno, then it's like you said - 1.0 up to 3000rpm, then drop to some fraction of that once part of the power is due to the turbo. If you want to leave the torque curve as measured by a machine, your way works.

The third option would be to assume the whole torque curve is for the NA engine - and add on max_torque above 1.0, plus possibly dipping below 1.0 when the turbo's not spun up, since it'll introduce some backpressure and other obstructions to airflow. That's kinda the reason I went with so many "realistic" variables - it's easy to slot in a wastegate/blow-off valve when the turbo is overpressurizing, that acts as expected (drop boost amount without lowering the turbo speed). Or include launch control that misfires to spin up the turbo at lower RPMs.

I left in the max_torque=0.5 by accident - the actual amount is defined by ($pressure/$maxpressure) at all times, ignoring that value. Since in that case min pressure was 15 and max was 30, it ends up being 0.5 anyway - rising to 1.0 when pressure is equal to 30. If the pressure difference were smaller (eg. 15 to 20) then it would go from 0.75 to 1.0 instead.


I want to avoid as many real values as possible, and just concentrate on what is ultimately the resolved down system to the core components that are observable.

We probably think a lot of these turbo properties impact the torque curve in known ways, but that is misleading.
The end result of a turbo's impact on the engine is more to do with the engine fuelling than the turbo itself.

Very little about knowing the config of the turbo wastegate and things, will impact the final result on the car. There are theoretical outcomes, but the final one is all about tuning in the ECU (on modern cars)


I'm sticking to the idea that the torque curve we have is the full-boost curve from start to finish, and simply move from a fraction of that curve to that curve as an independent engine system spins up and down... using the min/peak rpm to trim out the point where the turbo is out of it's boost threshold (ie, the dip at low rpm)

Will be cool to see the pro's and con's of duplicating realistic behaviour using two scripts that have gone down different paths during development (though I do think in time they will resolve to something very similar anyway :D )

Dave
 
There's plenty methods of 'virtualizing/faking' a good turbo, for example, we could now take the new heat feature & calculate the turbo performance, as it gets warmer, they will develop less torque. Sure, bigger inter-coolers means better stability & more efficiency, so that's also somewhat related to the heat discussion. All those variables could be plugged into Racer scripts, some would be faked iterating thru fake ranges, I suppose.

Also, setting a dump valve as a boolean/float value & scripting some attributes could also lead to a slight increase of perf in higher rpms & better/quicker gear transitions. The real thing is actually feel the turbo on G25/G27 steering wheels :rolleyes:, typically (in reality) they react 'violently' from a certain min rpm to a max rpm non-linearly. Outside of this range, nothing should happen.

Another thing, is the huge depressure that happens when releasing the throttle after been at its engine/turbo max rpm. So, it's like an instant & quick engine braking occurring.

For the sounds, mixing it correctly to the scripted turbo attributes/variables values & we done ?

Idk exactly, I think Ruud prepares a new turbo system from what I can see in racer.nl.
 
You can do loads of stuff really. Main issue is what is the player going to notice.

Racers engine right now is just two curves, a friction and a throttle input that scales the curves. It's simple as anything, yet no one is saying we can now re-write the engine with a realistic system so we can have carbs, exhausts, fancy air filters etc...
The truth is that the simple system that reproduces the required result is all we need :D

Going further is fun of course, so no harm in playing!


I'm not sure how the current 'rumble' works for engine outputs, but it'd be cool to code the current torque output to follow a sinusoidal curve that averages out over the number of cylinders, so a V12 can feel really smooth, yet a 2 cylinder car at low rpm will have that cool surgey behaviour... hehe...

Loads to tinker with.

Has anyone tried the gear change settings yet? Does it do a sudden shift into the new gear, or does it trigger a shift as if you had used a button?

Automatic gearbox anyone? That will be a challenge and a half :D

Dave
 

Latest News

Online or Offline racing?

  • 100% online racing

    Votes: 92 7.7%
  • 75% online 25% offline

    Votes: 125 10.5%
  • 50% online 50% offline

    Votes: 171 14.3%
  • 25% online 75% offline

    Votes: 335 28.1%
  • 100% offline racing

    Votes: 465 39.0%
  • Something else, explain in comment

    Votes: 4 0.3%
Back
Top