Quote from scipy :

Listen flower, I understand english references well enough to know that obtuse means ur calling me thick/stupid/slow/<insert synonym>.

As far as clutching goes, it makes no ****ing difference weather gears are in neutral, in lower gear or next (higher) gear if the clutch is depressed, since rpm climbs because you're keeping the foot on the throttle. Your thinking on longitudinal G increases because engine picked up some revs and was being pulled back by the clutch on re-engagement also shows a lack of testing and knowledge on your part. While this is true to some extent, the amount of slip that was occurring even before the slip had any affect on temperature wasn't in the optimum range for acceleration. In fact, a much better result is gained when the engine bounces off the revlimiter quickly and is re-engaged with the clutch with less slip - especially since the main advantage of buttonclutch is removal of the full engagement clutch period.

Personally I interpreted his phrase "deliberately obtuse" to mean something entirely different to stupid - more like someone who understands the point perfectly well but holds a different opinion and is determined to feign lack of understanding of the point... A dictionary will let you down on some things; this is one of them.

But back to the actual subject:
Reading this I'm reminded that while hotlapping in an FBM I saw something perverse last year. I hate hate hate lifting in that damn car, so I compared laps in which I used a wheel button mapped to clutch for upshifts against laps where I lifted (and against other LFSW laps where people lifted, using Victor's online analyser). Much to my surprise, the laps where I lifted were quicker - less speed lost on the shifts. I didn't bugger about with a macro or changing button rates so maybe a slow clutch response was the main problem. (This makes what I did rather different to "button clutch" I guess.)
But I had fully expected the clutched shifts to be "quicker" overall. My reasoning was that the engine power was being converted into excess engine speed for just about the whole clutching duration (at least when I didn't hit the limiter) and then, when the clutch was released, some decent fraction of that excess energy should have been converted promptly back into extra vehicle speed via increased torque to the wheels. (I reckon the actual energy split between clutch heating and extra speed would depend on the torque carried by the clutch while slipping - I never got around to attempting to estimate that, but I guess it could be estimated pretty accurately from the replay by using the time taken for the revs to drop back.)[Damn, no, this is crap; the wasted energy (i.e. clutch heating) is purely related to the excess speed ratio; ignore the bit in italics! I am also of course entirely ignoring the variation of engine torque with speed which may be another dumb mistake...]
Aaaanyway, clearly this wasn't the case. So I assumed that either it was cos my clutch was slower (disengaged engine for much longer) than the lift, OR cos the LFS physics isn't being very faithful to reality in this case.
But Scipy seems to be suggesting here that accurate physics wouldn't produce the result I expected, in which case I'm puzzled and would like to know more - e.g. pointer to a post in which this is explained better?

Last edited by Neilser, Sat 4 Jun 2011, 17:45. Reason : correcting loser mistake

Quote from sermilan :

...button clutch can wait until then.

Agreed.

Any official position on killing the button-clutch exploit with an incompatible patch?

Quote from pik_d :

... read his posts and you'll understand (maybe).

Indeed, and since this is a test patch, I guess that if somebody has a very good reason for reinstating pitstops in hotlaps, they might come back...

Quote from Scawen :

There's a front and rear tyre warmer setting in the Tyres section in the Garage.

Quote from pik_d :

Edit2: The replays even tell you what lap the fastest lap was done on, so you can pretty easily figure out how far to skip ahead in the replay. I really think the people complaining are worried that someone will spend an hour scrubbing tires (this happens in real life doesn't it? Just not the same way) and "steal" their WR, but aren't willing to put in the time to take it back under the same legitimate conditions. As JPeace says, hopefully the new tire physics will be more realistic (really worn tires = slower) so this won't even be an issue then, but it's just as "bad" as people using unrealistic setups to go faster, and everyone does that too.

Firstly, using a slider to move a long way into a replay still takes time, as (sadly) it seems that the SPR files don't have any checkpoints - on my PC skipping a long way into a replay can take tens of seconds. Not nice if you want to watch a particular corner a few times. But that's a side issue. The worn tyres thing is just massively obnoxious, legal and all as it is. To have to do that to match times with somebody is simply not fun. To have a set that's a bit crazy doesn't waste 20 minutes of my time, even if it's unrealistic (which setup aspects are unrealistic btw?).

Quote from J@tko :

Exactly. You've got a much smaller surface area so less friction. It's just like if you're on ice - give yourself a push on ice skates and you'll go miles, but if you're on trainers then you won't go very far at all. Hence also why higher tyre pressure = bigger top speed - the higher pressure opposes the mass of the car on the tyre thus it keeps its shape better, making it thinner giving you a higher top speed

Mmm, drifting off topic here but a quick reply (let's start another thread if you disagree with me ) is that while high pressure means less rolling resistance (less deformation), less tread thickness does not mean less surface area or friction. Contact patch area is more or less entirely decided by tyre pressure. I guess the most likely candidate (since Scawen sadly didn't answer this bit :shy is that it's just plain unphysical; another flaw in the old tyre physics.

Edit:
* Ah, I see in a recent post that Scawen implies it is indeed a physics flaw
* I don't feel really strongly about removing pitstops or having time limits btw - the point has already been made that the problem will sort itself out once the tyre physics is updated.

Last edited by Neilser, Sun 29 May 2011, 18:13.

My comments, as someone who has done quite a few hotlaps (mostly to figure out why I'm so slow)...

Heating tyres: excellent idea. Individual temps are still totally realistic (ignoring the teleport to start position of course) but differing temps between inside and outside of tyre are not (think what a blanket would do).

Layout: start position = excellent idea (Westhill comes to mind). Objects other than start position on uploadable laps: I think not a good idea (agreeing with the points made above by others really).

Tyres below ambient: why not? (Have you never seen a fridge? )

Invalidation of existing hotlaps with contact: tricky problem. Might be good to ask the question more widely. I guess it would depend on how many "fair" hotlaps vs. "unfair" hotlaps get wiped out.

And a question for Scawen: why do "thin" tyres enable higher speeds? I've wondered for ages but never done all the testing I imagined I might I was guessing lower rolling resistance as one of a few possibilities... (Or maybe it's entirely non-physical of course.)

And many thanks Scawen for doing this - yes, the boring hotlaps are not only boring to watch but boring to make. I guess we're all hoping that the new tyre physics might eliminate the "thin tyres are faster" issue as well

Quote from Bokujishin :

Yeah I know it happened before too, but not that often I think.
It had never happened when hitting an incoming XRT before, and now I'm literally sinking into the ground

Well, if you think you've found something undesirable that behaves differently to Z28, Scawen may care, but I imagine he'll need an SPR to debug it...

I can't see an update to K31R mentioned above, so...
Have just tried it (yes, IGTC playtime, ROFL) and checkpoint 3 is back to front.
Tweaked version attached...

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 )