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.)

Quote from Neilser :

Things that are detectable in an SPR file with 10ms time resolution are not always detectable in an MPR file with much coarser - maybe 250ms? - resolution. I think this is at the heart of it (but am prepared to be wrong about that ). Thus even though the clutch behaviour may be identical on the client every time as you suggest pik_d, it probably won't look identical to the server or to the other clients.

(Also, I double-checked last night and the clutch pedal does "move" when using auto-clutch.)

If we/anyone can come up with a practical/reliable way to detect it, I'm sure it can be implemented in the future. (Clearly an LFS patch to eliminate the issue would be preferable though!)

If anyone is really convinced it can be reliably detected, I'm happy to have a go at helping to prove/disprove this, e.g. by having someone use it and someone else save an MPR file and then check it frame by frame through a bunch of shifts. However, I have a suspicion that precisely this type of test has already been carried out...

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.

Anyway, the point is we discussed this at length before, and even when we banned b/c, scripts were written to get around this.

I still think only around 6 -10 people in the whole league have used any kind of script, and I believe that the only reason most of these did it was to get nearer the times of 3 people (not mentioning names), who were already doing it. It had no affect whatsoever on 95% of the people taking part, as these people were much quicker than the rest of us anyway.

The bigger question for LFS in the future is that these scripts will work in leagues races etc, 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 jasonmatthews :

The bigger question for LFS in the future is that these scripts will work in leagues races etc, 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

And I'd be happy helping in anyway I can; be it making a replay sniffer, or what not.

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. Someone wise once said: "To earn respect, you have to show respect". You may argue that they would be on the top anyway, so what's the harm in letting them use these exploits? Well, they shouldn't, as it's wrong and as I said, shows lack of respect for those that plays it fair. And it's even worse in a situation like this, when there's money involved. I have no problem with my money going to people that plays fair, but I do have a problem with it going to people that "cheat".

What should have been done from the beginning, was to enforce the rules VERY strictly, and ONLY allow the use of autoclutch. Since autoclutch is universal for all controllers, everyone can use it, as opposed to clutch axis which only are available to those with clutch pedals (G25/27), it would be the most fair way. Anyone suspected of not using autoclutch, should then be banned from the competition.

A little note about the clutch axis - it can be set to really short travels, so it engages/disengages really quick. And that together with the flappy paddles essentially makes it the same as a BC macro. Anything other than CL (clutch axis) + SH (shifter) together makes no sense, and makes it questionable if it's legit or not. Unless it's common in real cars that have flappy paddles, that they use manual clutch when they shift?

As Jason said, it should be an easy thing to fix for the devs, and I sincerely hope it will be in the next patch.

Quote from arco :

What should have been done from the beginning, was to enforce the rules VERY strictly, and ONLY allow the use of autoclutch. Since autoclutch is universal for all controllers, everyone can use it, as opposed to clutch axis which only are available to those with clutch pedals (G25/27), it would be the most fair way. Anyone suspected of not using autoclutch, should then be banned from the competition.

I'd never have competed in this if that was the case; I won't drive without using my pedals properly - it just does not immerse me, which is the entire reason I play LFS.

I do agree with your first paragraph, especially the "To earn respect, you have to show respect".

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...

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.

Quote from jasonmatthews :

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

Because that wouldn't help at all. You already see the clutch with the bc exploit, making the shift longer would be going in the wrong direction.

Quote from Neilser :

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

That may be because the way LFS replays work is to record inputs, not the end result of the inputs.

Quote from Neilser :

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...

MPR data probably doesn't have enough data points for this to work.

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.

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...

Arco has posted how to set up the button clutch exploit here: http://www.lfsforum.net/showthread.php?p=866988#post866988

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?)

Yes I did.

Even after reading these posts few times, I'm still not sure what is meant by axisclutch and autoclutch (to name a couple). Comes from using keyboard to race for so long.

However, not sure if it helps, but LFSLapper allows you to set a number of controls which you may want to allow use of, or ban.


Where you see an asterisk (*) you can replace with either Y (allow) or N (disallow).

If disallowed, you're spectated before getting out of pits.

No idea what swapside means.

Edit: "swapside" means you can't change driver position (from left to right, or right to left).

The Live for Speed Hotlap League 2010 has now finished! The league has seen an incredible 592 people take part, with some great battles and amazing times set, almost always beating World Record times.

Congratulations go to Andrew Carey for taking the win, with a fantastic £108.57 in total prizes. 2nd place was Nick Catsburg (£20.88) and in 3rd, by just 1 point, was Magnus Bjorndal (£77.38). 4th place was taken by the unlucky CQ|Guru (£47.48) and 5th place by CQ|Dzban (£31.08). The rest of the cash prizes can be seen on the table on the left.

There were also server prizes for the most improved driver (Sparkee) and two lucky dips (K.MacDonald & ﾏﾑﾏ Matty).

Many thanks to 500 Servers for so generously donating so many server packages, and to all the racers taking part. I hope you all enjoyed it and we hope to run it again next year!

was good fun, this league has kept me motivated for lfs. thanks to the admins and everyone thats helped out.

Congratulations arrowkart for the win

Quote from arrowkart4 :

was good fun, this league has kept me motivated for lfs. thanks to the admins and everyone thats helped out.

+1

Congratulations go to Andrew Carey for taking the win, with a fantastic £108.57 in total prizes. 2nd place was Nick Catsburg (£20.88) and in 3rd, by just 1 point, was Magnus Bjorndal (£77.38). 4th place was taken by the unlucky CQ|Guru (£47.48) and 5th place by CQ|Dzban (£31.08). The rest of the cash prizes can be seen on the table on the left.

Second place got less than 3rd and 4th?

Quote from Mr.46 :

Second place got less than 3rd and 4th?

Maybe NickC passed on the "sever prize"?

I'm drastically slow - did all 20 combos but only managed to scrape into 45th

Oh yeah sorry

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