Quote from Killer Beast :

I've found a bug on the ramps. Watch attached replay. Its on there at the start.

Damn, was gonna say that's the same bug that Z34 fixed, until I noticed that your replay is *from* Z34 :-/
(Edit: and it didn't go out of sync in Z33.....)

Quote from Scawen :

Thanks, that was useful.

I've done the lap ahead and behind colours now as well.

Wow, fantastic! That will make the open layouts fully usable now...

Is that about it for the "quick" patch and ensuing hiccups? We really should let you get back to that tyre physics
(And hopefully you're feeling all refreshed after the change of scenery for a couple of weeks!)

Quote from bunder9999 :

i don't see what the big deal is, f1's lights aren't predetermined either... if anything they should completely randomize the time between all-red and green. that way people can't try jumping the gun on race start.

That's precisely the point - on "normal" tracks the lights are somewhat unpredictable, but on autocross (and it seems now on open too) tracks they are perfectly predictable. (Whether it's a bug or a feature though... down to taste. I prefer unpredictable )

Nice one.
Just had a blast driving around a few open tracks
Can't wait to see some new race servers with open+layouts...

Mmm, just tried to find the server (after a long layoff from LFS) but seems not to be up...

Quote from Kid222 :

Hugs from Czech rep.! Such a dumb thing...

Another problem seems to be, that when i'm trying to get some people on TS for help in commentary, they hear themselves talking again from my source on TS, some sort of sound feedback.. Any idea what am i doing wrong there?

Sounds like you got it working then? Cool.

As for feedback, if you have speakers and a microphone, you'll get this. Shouldn't happen with headphones. If you can't use headphones, then you need to consider using push-to-talk so your mic isn't open all the time (or it'll just broadcast what it hears from your speakers...).

Quote from Kid222 :

*bamp* Anyone have any idea, how to possibly fix this? Still no solution on my side.

Could be a problem with your audio driver (what is it?) but wild and probably useless guess: try stereo mix BUT ensure that in your *playback* controls, the mic is not muted... (In other words, you'll hear yourself on your own speakers/headphones.)
GL.

Quote from Becky Rose :

Hi Neilser

You're right that it does need to be more than a byte, 256 options does allow for the possibility of recreating a similarly compatable setup. I'm not convinced 32 bytes are needed, 65536 possible combinations should be sufficiently daunting (2 bytes).

Hi Becky
Well, 2^16 would certainly be daunting to a human. But since it's easy to write a program to construct sets by tweaking values of certain parameters within reasonable ranges, this would be no obstacle to a brute-force approach.

Quote :

The maths to generate a sufficiently random checksum is of no real consequence, if the numbers come out too similar than all you do is use each field as a seed for a random number generation - then use those random numbers on a bitwise XOR and you've got yourself a totally random but consistent checksum.

Yup - if you get this bit "right" (md5 nearly got it right ) then there's no way other than brute force to go from the checksum to the original "plain" text, i.e the setup the person is using, or indeed from a setup to a subtly different one with the required checksum. But it could be done, and the only thing I can see that will stop this is if it's too hard to brute-force calculate the checksums (i.e. too many of them). If you simply make the checksum contain less information by shortening it, then many credible setups will exist which have the same checksum, preventing setup theft but allowing cheating (i.e. non-compliant setups).

I did some more tinkering, and saw some slightly inconsistent things. A patched version of LFS with newly added checksum behaviour could be altered to change any/all of this behaviour, but at present, some of the "floating point" fields behave quite differently from each other.
For example: if you drag the slider on ride height, the float that gets saved into the SET file will often have 7+ significant figures (e.g. 0.2671592), while if you just click the up/down arrows you get something with 3 significant figures (e.g. 0.256).
However, if you do the same things with bump damping, then both the slider and the arrows will give you the same precision - no more than 3 significant figures (e.g. 10700, for 10.7 Ns/mm).

You can get around this limitation for (I think) ALL of the float values by tweaking the file by hand with a hex editor, for example entering 10701.23 in the bump damping setting. This will load fine, and LFS will even save that value back to the set if you change a different value in the set. That way, you'd be able to use quite a lot of the bits in the 32 bit floating point mantissa to make it harder for someone to reverse engineer your set.
The same trick applies to some integer values where not all possible settings are used by the LFS setup editor (e.g. gear ratios). It would of course be a royal pain in the arse to have to do this by hand, but it would be trivial to write a setup obfuscator to modify the less significant bits of some appropriate setup parameters. (Still a bit of a pain though! )

I made a rough estimate, assuming you could obfuscate all float and integer fields to pretty much the max (so probably a little optimistic), and got a total of just over 500 bits worth of information for a FOX setup. (That's ignoring fields like the centre diff, which you might also get away with filling with junk.) This isn't bad for a 132 byte file (1056 bits). And I reckon 2^500 (roughly 10^150) is more sets than anyone could reasonably be expected to search for the correct checksum.
But that's not the whole story, because the set needs to be driveable. So the real range of credible values for bump damping for a FOX is probably quite a lot less - another rough estimate puts it at around 350 bits. This is still way more than enough to prevent a brute force attack.
But if we then weakened it by either or both of:
* splitting up the setup into pieces
* only using the up/down arrows to change settings
then the number of bits contributing to the checksum could be massively reduced.
Looking at your proposed split of setup checksums above, I'd guess that the most complex of them wouldn't have much more than 20 bits of genuine information going into them (regardless of checksum length) if no special measures were taken. This is only 10^6 setups to check, which would be trivial.

The basic idea is still totally viable though - this (long, sorry!) posting just shows it isn't trivial to prevent cheating and at the same time prevent setup theft.
I think (I'm not a crypto expert) that to "fix" it properly, Scawen would simply need to add extra info (let's call it junk DNA) to the setup file within each sub-area to be used for setup checksumming, and combine this with a cryptographically secure checksum (to prevent cheating). The logic about when to scramble the junk DNA would need a little thought, but it's late and my central heating has been off for nearly two hours and I'm bloody freezing, not to mention sleepy so I'll stop rambling now

OK, gotcha.
I thought that was what you meant by security but wanted to double-check before getting into the difficulties I can foresee... (Which you may have already considered of course )

The way I see it, you're torn between two slightly conflicting goals, which I can best demonstrate by extreme examples.
If you used a very small checksum, e.g. just 2 bits long, nobody could reverse-engineer the setup from that. BUT anyone who wanted to could trivially come up with an entirely different setup which matched that checksum, provided the algorithm to generate the checksum was known. (Just keep tweaking some fairly unimportant value(s) by small amounts until the checksum matched.)
Or... use a very long checksum, e.g. 128 bits, and it gets very difficult to find a different setup which has the same checksum - wonderful, nobody can cheat. BUT if the range of legal values in the fields used to generate the checksum is modest enough, then it becomes easy to reverse-engineer that portion of the set.
Now, having had a quick look at the setup file format, and a wee bit of testing to see what LFS actually saves (and loads, and resaves) into the wider fields (floating point and integer), I suspect that if you go for more or less the whole set in a single checksum you've probably got a good chance of making it work. Right off the top of my head I'd imagine you would need at least a 32-bit checksum, to avoid cheating, but I haven't attempted the arithmetic for this yet.

Quote from Becky Rose :

For reasons of security INSIM cannot send setup data, but i've noticed a few ideas, leagues and public servers rely on fixed setups. What if instead of setup data we could send a checksum?

I think I like this idea.
But what exactly do you mean by ""For reasons of security INSIM cannot send setup data"?

Yeah, restricted FO8 might offer some nice close racing even for RWD incompetents like me

Quote from Seb66 :

... I ran out of fuel anyway.. even though I added 2 more laps worth than I needed

Well that's pretty freaky - how on earth did you run out then?
Did you perforate the fuel cell?
Or maybe the damage changed your average revs?? Or just maybe wrong fuel setting?

Quote from Bmxtwins :

it still does it , it is fixed to the car's front axis no matter what... unlike regular chase which has smoothing options etc.

Funny enough, Boothy also told me to turn off the "acceleration shifts viewpoint" stuff, so I did, even though I thought they were all set to zero anyway. It made quite a large difference, which puzzled me (still a little bumpy but much less so). I went back and checked, and the head tilt was the only one which hadn't been zeroed. Doesn't make much sense as to why this should make such a huge difference but there it is...

Upshot: I reckon "custom-follow" might end up being usable after all

Lovely job!
I just used it to recreate the follow view but with a mirror. Unfortunately I can't use it on bumpy circuits as the camera movement drives me insane... shame.

Maybe it's fixed but a couple of days ago when I was there, Matti was setting low 44s and then I used his set and was going way quicker too (And then bmxtwins ruined it by pointing out that the restriction was too low!) Then I tried 20, 25, in-between values, higher values, everything above 20% was fine.
(edit: the penny should have dropped for me when I realised the peak speed through the chicane was up by 3-4kph with his set for both him and me compared to my own set - too much to be just down to improved handling...)

Quote from dekojester :

The one with the slightly wider final hairpin exit will be used. I'll upload it to the layouts thread shortly.

Hiya...
Just noticed that this post of yours is more recent than the update time on the layout thread post with all the files. Not really sure which is the final layout...? (I've now seen at least three )

Your REAL Name: Neil Conway
Your LFS Licence Name: neilser
Requested Car Number: 44
Your Country: Ireland
Your Team: Sonicrealms Racing

IIRC, SR team members weren't eligible for the servers

Yeah - enjoy it! Wish I could have joined you.

Quote from Becky Rose :

After 3 hours of solid sitting around drinking coffee my kitchen is half clean. The guys had better appreciate all this lethargy I'm putting in.

Fear not. Men are renowned for noticing and appreciating when women clean the house, change their hairstyles, buy new clothes....

My first LLSS event - great fun, thanks.

I just reviewed the replay of Q2 - I did indeed screw up a quick lap by Oscar Hardwick - sorry again Oscar. Was trying to get out of your way (just as I had done for the guy in front of you) but I totally failed on that score - misjudged how far back you were. My qually session had been a disaster but I had misunderstood the rules about using shift+s (as soon as I saw pik_d do it, I did it too)...

Cool, ta. Looks like it ought to work with my Logitech FF GP so will give it a try. (PS: did you use this to generate your bc exploit replay?)

Quote from jasonmatthews :

Fastest legit way is with button clutch or manual clutch with short travel. So as Arco pointed out, it might have been possible to stop this with making autoclutch compulsory, but even with autoclutch enabled, you can still use your clutch pedal to shift, so I really do not know of any way at all to stop this.

Hmm, but I thought the point of this discussion was that button clutch wasn't a legit way?

Quote from pik_d :

Also Neilser, I've attached another version of my clutching test, this time using the button clutch exploit. You can see the differences, especially that it will stall without any gas.

Yup, can see the difference - the clutch is always visible, so one can conclude that the shifts were not made using autoclutch...

I did some tests too.
In the first one I switched off autoclutch and just used button clutch with the max button rate (10). Several times the clutch showed up as only partially depressed, e.g. the change from 1st to 2nd at 10.67 seconds. (file mebctest_manypartialclutchbars.mpr)
In the second, I used axis clutch with very short travel (had to sacrifice my brake pedal for this test ). This also showed some partial clutch depressions, and for the 3rd to 4th shift at 27.04, the clutch apparently doesn't move at all. (file meaxisclutchtest.mpr) Bit disappointing, that.

I used 5 packets/sec by the way for both. Not certain what typical servers use (or the HL league), but it may matter.
NB: I didn't use any macros or Profiler tweaks for this (don't know how to).

So where are we going with this?
It would be ideal to allow axis clutch, if there's a way to distinguish between dodgy and non-dodgy manual clutch use, but maybe there isn't one?
But if the proposal is to only permit autoclutch (might make some people abandon ship) then you might say that if the clutch EVER shows up during a hotlap, the person has broken the rules... My second test suggests that most but not all axis-clutch changes (and maybe also true of bc changes) will show up in the MPR file. Provided the clutch pedal moves at least occasionally it would still incriminate them. But if there is a way to blip the clutch quickly enough that the MPR file never catches it, this approach is dead.
This sounds so simple that I realise I've probably entirely missed the point now, so I'll stop here for feedback...

Quote from pik_d :

Under what circumstances does it move? I did a quick test (attached) and you can only see it when it is constantly engaged. You can't see it when i shift, no matter if I flatshift or shift without load (eg, lifting to shift and save clutch). Compare that to the attached .spr (conducting the same exact procedure) and you see the differences.

and

Quote from CSF :

What you see when you shift is a clutch going up, but if you look at others cars with AC on, you don't get the clutch bar going up.

OK, thanks guys, I get it now. MPR files don't record auto-clutch activity (even your own!), SPR files do... Strange but true.

Quote from jasonmatthews :

[...] so if anyone can come up with a reliable way of detecting these scripts then it is worth discussing, and I am happy for us to discuss it here

Quote from arco :

What's most disappointing to me, is that these well known and already fast drivers, seems to have no problems with using these exploits. That to me tells me they have little respect for their fellow drivers.

Agreed. Bizarre, huh? But with at least one of the people, I already have first hand experience of an attitude problem. (I think perhaps cheats have no self-respect, but that's getting off-topic for this thread I guess.)

One idea occurred to me, but maybe it's a non-starter...
If a replay happens to show an upchange on a nice boring bit of the track (e.g. straight and level, not so unusual for high-speed upshifts) then we might be able to tell how long the shift took by comparing the speed for a few points before and after the change. If we then compare with a non-cheaty upshift...
Btw, this reminds me to ask - what is the fastest legit way to upshift? (Since that's what we need to compare it with...)
I know from playing with Victor's online analyser that speed dips (or at least pauses in acceleration) at each shift are very clear in SPR data. Not sure how true that is in MPR files but I think a discontinuity (or lack of one) ought to show up...

Quote from pik_d :

Under what circumstances does it move? I did a quick test (attached) and you can only see it when it is constantly engaged. You can't see it when i shift, no matter if I flatshift or shift without load (eg, lifting to shift and save clutch). Compare that to the attached .spr (conducting the same exact procedure) and you see the differences.

Wow, you're up early! Had the sun risen when you wrote this? Will check your replays and make some of my own when I am back at my LFS PC (hopefully tonight).

Quote from jasonmatthews :

What is stopping someone writing a script to put some longer shifts in to defeat this?

Indeed, and even some pseudo-random variation... (E.g. if the scripts are read from disk every time they are called, a helper app in the background could be constantly changing the delay value.)