UFR goes down to 117bhp with a 50% air-intake restriction. You should be able to give them any performance you need between XFG and unrestricted UFR, and now there are tyre options to play with too
A very low turnout this week (as is often the way after an incompatible update) and unfortunately in the second half the numbers dropped too low to continue - the event was called after round 4.
Up until that point there were still thrills and spills though - three drivers were in the running early on, but only one could keep the consistency.
Congratulations for the win go MRc's **TimDC** with 111 points of a possible 120, and 7 wins along the way.
2nd this week was PiranMOTO's **Jam 616**, 16 points short and with 2 wins.
3rd this week is PiranMOTO's **Jon 606** - his first podium this season.
Congratulations for the win go again to RD2, this time taking a record-equalling 12 race wins (shared with Sam) on his way to a record-breaking 194 points out of a possible 210.
This is his 8th DD Event win, yet another new record! We are going to have to call in reinforcements...
2nd this week is OK's Rauno and 3rd is MRc's TimDC - the pair separated only by Rauno's 3 extra points and Tim's 1 extra win.
In the meantime, drop this little beauty into your LFS/data/dds folder for a thicker smoke that's not too thick. Or there's a few more versions out there too, now you know which filename to search for
A little low on numbers this week, but that didn't stop the action! Another close-fought battle that lasted until the end and ended with a margin of just 3 points!
Congratulations for the win go to **RD2**, taking 9 race wins on his way to an amazing 181 points of a possible 210. More congratulations are in order: this is also his 7th DD Event win, equalling Sam and sharing the PiranMOTO record for most event wins!
2nd this week is MRc's **TimDC**, missing out by only 3 points and taking 8 race wins on the way there.
3rd place goes to PiranMOTO's own **Jam 616**, taking one of just four wins that TimDC and RD2 left for the rest of us.
On that general theme, I saw a suggestion today in discord that a minimum clutch time be set that matches the auto-clutch time. I don't know about that kind of thing so I can't tell if it's a good idea or not, but if it is a reasonable suggestion and do-able, I may never have to listen to the button clutch argument ever again. On that basis I thought it was worth a mention
Another fight to the death this week, as our two recent win-streak champions took the battle right to the last race.
Coming out on top this week is MRc's **TimDC**, returning to the top step for the fourth time and taking 8 wins on the way. Is this the first step in a new streak?
2nd this week is OK's **Rauno**, finishing just 8 points behind Tim with 4 wins along the way.
3rd place this week goes to **Sardjon** - his first time on the podium - drawing on points with Jam but taking 3rd place due to his 2 race wins as a tiebreaker.
Special mention for RD2 and MRc's Michal - both were in the running for a podium until having to leave early.
There's also a spare byte in MCI->CompCar (although it is the last one), might it be better in there also/instead for situations where laps aren't being completed?
I'm currently playing around with a little insim toy for drifters using MCI data from the host - it draws a trail of chalk lines, each aligned with the car - and it's sometimes falling victim to the optimisations of packet rate. When there's little/no control input change, the time between updates drops to what looks like about 1.5 seconds.
If I'm understanding it correctly, because I'm connecting the insim to DCON (ie, no physics), all the data reported in the MCI packet is a position/heading/speed/time type prediction. Clients can cope with this gap because their predictions come from running the physics with no input change.
I've attached a very quick replay and screenshot of driving in a circle, half the time with no control input change and half with a constant, gentle jiggling of the throttle. (The 'jaggies' are 6 to 8 elements long, at 200ms MCI interval)
I don't know if it's worth having a shorter maximum time between packets than the clients need, for the sake of host MCI data? Or if the DCON prediction could be improved by adding a value for rate of change of heading? Or if it's even worth refining, given that you do have to hold pretty still to trigger it
An amazing meet this week, with frantic races that were both raced and fought hard in good spirits - *the essence of DD* - ending with a close battle between the top two positions across the last 3 races.
Still on top this week is OK's **Rauno**, taking the PiranMOTO DD win-streak record to *four* - congratulations!
2nd place goes to MRc's **TimDC**, returning to push Rauno hard all the way to the end, claiming 5 wins on the way and missing out by just 6 points.
3rd place this week goes to **Jam 616**, snatching the final step of the podium in the final race by just 2 points.
edit: Special mention for Flying ET and Uber: both being part of the epic 6-way battle for the lead throughout the early part of the event (along with RedBot), and eventually missing out on the podium by less points than a single race win.