Bingo, ta!

Ah, nice one thanks! Hadn't found the newer thread when I searched
Will have to have a good look at both sets of source code to get a feel for how it's done, as at the mo I am a bit confused as to why the LEDs can be set with DirectInput (by using LFS's own handle for the wheel?) but yet this approach isn't appropriate for the range.

Hey...
Very happy to see someone has written a bit of code for this, even if it is hacky
I am planning to try it, now that I have a wheel with lots of turniness (my previous wheel had about 200 degrees ).

Am wondering just how godawful the SDK must be for you to have gone the long way around and implemented it the way you did... Did the API call not work properly/reliably?

(PS: am also planning to play with the LED mod too - do the lights flash beyond the shift point or just stay all lit up?)

I'm sure you're fully on the ball as usual
Perhaps it would be useful/necessary to only allow explicitly "allowed" hosts to be shown on the Airio Servers page? (Big headache to maintain though, so maybe not worth the pain.)

I'm still confused, EQ. Maybe my confusion is the same as some of the others who posted recently...

The way I see it: basically, if you want to prevent someone cheating in order to win the race, then some kind of generic "route checking" might be required, as the PTH file can't do this (because people can leave the path by just going wide on a corner by accident and speccing them for that would be a bit harsh ).
However if you want to stop people getting top times by cheating, then I believed the PTH file did that job perfectly.

Ah. Perhaps nobody spotted this yet?

Nah, brake bumps would slow you down

WOW. If I were a sig kind of person I'd have had multiple sig opportunities in the last few hours worth of this thread

Quote from Squelch :

Going back a bit further I found this from Scawen. I don't know if it still holds, but that is the principle I've been working on.
http://www.lfsforum.net/showthread.php?p=52917#post52917
Edit:
I can't find the post, but I also believe the pressure settings are for optimum, so by deduction, setting higher temps will give a slight over pressure.

Edit:
Found it, but it was the speculation thread.
http://www.lfsforum.net/showth ... imum+pressure#post1210485
Too much coffee and not enough sleep for me, so didn't quite absorb Bob's post which seems to dispel the myth.

Garage tyre pressures are cold/ambient.

Yikes, so you've managed to find some more recent posts in which both AndroidXP and Bob Smith have contradicted their statements from the posts I quoted earlier. OK, it's not a big deal I guess (and I have to say it's making me chuckle!) but I will PM them both if they don't reply here soon. I don't personally have any axe to grind, but I do think the correct answer is indeed "cold/ambient".

Hotlapping testing suggestion for Scawen: a possibly worthwhile tweak to the HLVC code would be to make it report *all* HLVC violations in each lap, not just the first. This would speed up 6A1 testing in places like SOx. Probably only needed until 6B. (If it's simpler, you could have a keypress to reset the HLVC status.)

Quote from AndroidXP :

It's exactly as it should be. A hotter tyre has a bit more air pressure, causing the tyre to bulge (making it more donut-shaped), resulting in more load on the middle section. The pressure setting in the garage is the tyre pressure at optimal heat, not at the heat the tyre starts out with.

Eh, this seems to be one of those points on which people keep getting mixed up. (Understandable.)
Take a look at http://www.lfsforum.net/showthread.php?p=783321#post783321 and http://www.lfsforum.net/showthread.php?p=596365#post596365 (linked from the first one).

Unless things have changed since 2007/8, the pressures which you set in the garage are the COLD pressures. (Once we're agreed on this, I suggest we delete/change the incorrect stuff to minimise the spread of disinformation )

Quote from Whiskey :

You'll need to speed LFS physics loop 10 times to get that. Otherwise, you'll get faked (rounded, aproximated) times, which is what many games do.

Actually I disagree.

While the physics loop frequency may be 100 Hz (or any other value; it's not important) it's always possible to interpolate between the positions that straddle any given checkpoint and thus produce a timestamp with higher precision.

(Edit: perhaps I should add that there's nothing at all fake about this. It's actually *less* fake than using the timestamp of the first position update which is beyond the checkpoint. That may not be what LFS does of course - I don't know.)

Quote from scipy :

This is silly. Add me on MSN and be educated.

Kind offer dude but sadly I'm not an MSN user... No matter - having figured out what was bothering me, I'm done. You may continue to believe a freely revving engine with fully open throttle is not delivering full power if you wish, no skin off my nose

Quote from scipy :

Then how is it unclear to you what I've said 2 posts ago?

You were quite clear, but just wrong
That's IMHO of course. Read on and I'll justify that.

Quote :

If you have an engine revving in neutral it's only going to produce enough power to cover it's inertia/friction/pumping losses. It is not making xyz hp @ 8000 rpm when you floor it in neutral - only when you try and stop it (like connect a resistance to it, then it'll be producing power - and only enough power to overcome that resistance, still not the full power).

I have no idea why you think that. I've just done some tests to verify that it isn't true in LFS. I don't believe it to be true in real cars either, but of course the engine management system *could* decide to reduce power when in neutral (my car's ECU doesn't even know that though) or if it spots the revs climbing very rapidly. One thing I did observe is that the FBM torque reduces dramatically quite a long way below the actual limiting rpm value when IN a gear (more than I'd expected) and even further below when the clutch is pressed (that's a bit weird and maybe fake?). I thought this was the reason for my original observation but it wasn't - explained below.

Quote :

...power "rapidly" goes into increasing rpm but it's not using anywhere near "maximum" power (meaning power it has at those rpm when on the dyno or accelerating the car and overcoming air resistance, rolling friction, inertia etc).

This assertion really confuses me. I think you'll agree it's wrong when I explain the test results.

Quote :

In fact, if you payed attention when driving a real car you could notice that even when you shift normally (lift off throttle, clutch in, cluctch out, throttle back on) but trying to make it a pretty quick shift, you will still get a little boost from the engine inertia.

Yeah, have (of course) noticed that. Every 17 year old probably finds that out when first allowed out alone

Quote :

Problem is that you took the FBM as an example.. where the limiter and the shift point are one and the same, so when you clutched on your flatshift.. where can the engine accelerate to? It will just keep bouncing off the revlimiter.

Yeah, I thought this might have been the problem all along. I had been aware of the limiter of course when I did the hotlaps last year, and thought I wasn't hitting it. But now I see the torque (clutch down) drops way below the limiter... However, that still wasn't it.

Quote :

Scawen modeled these transmissions correctly (as far as power/work/acceleration goes), there is no way you can gain acceleration by disconnecting the engine from the wheels and relying on increased rpm and subsequent slippage on re-engagement, over the dog-engagement gearbox.

This is exactly what I think my results below prove to be true in fact. Doesn't mean you'd want to do it in a long race of course. Or in the FBM as it goes.

Quote :

I think your main problem is not understanding how a dog-engagement gearbox really works. The shifts are very violent, in fact, more violent than a flatshift with a clutch.. but power delivery is nearly uninterrupted (in reality it is uninterrupted, the car will never go into opposite longitudinal G while accelerating), the components are very stressed but they're designed to survive.

They sound like a cool idea if a bit brutal. I guess the tyres and engine mounts take up most of the (brief) strain? Maybe the engines get torn off the mounts now and then?

Now the results to support my slanderous allegation that the one and only scipy has made a mistake
Today I did some acceleration tests on the drag strip in an FBM. Lots of 'em. More than it's fair or sensible to report in this thread so I'll be concise. (Need a new thread for more detail if anyone's masochist enough to care.)

The upshot: when changing some way below the redline (even as high as 8500) the time taken to accelerate to any given speed is significantly SHORTER with the clutched change than with the quick lift. Even when changing more or less at the redline (I was shooting for 9000) I only managed one run in which the quick lift got to a higher speed earlier than the clutched change; in the other runs that clutched change was marginally quicker. (My button rate has been set to 10 for this lot of tests btw.)

As you mentioned, the shift point being so close to the redline in the FBM means that it's a poor candidate for this, but perhaps the MRT has the same box? (And an amazingly high redline )

As a result of all of this, I now believe I understand my original problem btw: while the total time to accelerate to any given speed in the FBM when changing at roughly the redline may be just about identical whether you lift or use the clutch, the speed vs. time graph when clutching shows a slight drop and then a very rapid recovery - very brief deceleration while clutch down, then extra acceleration when it's released, "catching" up on the speed achieved by a "quick lift" change. But that means (by integrating the speed vs. time graph) that the distance covered in the clutched case is slightly smaller. D'oh! Quicker to get to a given speed need not mean quicker to cover a given distance...
(Apologies for length )

Quote from scipy :

Sry, don't wanna be dismissive but I'm not getting into energy/work/power discussion with you unless you are willing to go through thermodynamics 1 & 2, internal combustion engines intro and ICE construction first.

Luckily enough I'm a physicist so feel free to get techy when explaining. (Quite familiar with thermodynamics and engines.)

Quote from scipy :

There is no power to speak of if something isn't using it on the other end. When you rev the engine to 8500 rpm in neutral, it makes no significant power. It's better to have 50 % being used than having none during clutch full engagement period.

Eh? When the throttle's fully open at high rpm and you disengage the clutch, the engine is still producing full power unless you cut fuel or ignition. The power just goes into (rapidly) increasing the engine speed. It's still real power. And if you can at least partially convert it back into road speed it's also useful real power.

Ooo, unexpected bonus fixes:

Quote from Scawen :

Multiple object selection - press CTRL and click object button
Selection can be deleted, copied (O), moved (M), rotated (, / .)
Maximum qualifying time increased from 60 minutes to 240 minutes
TC Allowed Slip slider now goes up to 20% (previous maximum 10%)
On changing allowed cars disallowed cars will join the spectators
Exit from pits now results in a clean restart to hotlap position
New packet IS_PLC sets allowed cars for individual players

Fantastic (That disallowed=spec one will make cargame.nl S2 much better - GT2s constantly in/out of allowed cars...)

PS: I agree with Worry - the headlights are bright enough already!

Quote from scipy :

...when you lift 50 % of the power is still being transmitted to the wheels during the shift because only a small unloading of the transmission is needed

Ah, that's probably the key bit of missing info, ta

All the same, am still a wee bit puzzled about the "energy accounting" here. In the "quick 50% lift" case, the engine power output is reduced momentarily, but a negligible amount of that power goes to waste during the change. When the clutch is used, the engine+flywheel soaks up all of the (almost unchanging) engine power while the wheels aren't getting it, and if the engine speed hasn't risen much before the clutch is dropped again then the energy wasted in clutch heating should be "very small" (for some value of "very small"). So, hmm.....

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