There are probably a number of factors - these two I suspect are main ones:

1. IIRC, Scawen mentioned that with the current tyre physics, tyres that don't have much load on them - the inside ones when going round corners, regardless of how stiff the suspension is - don't have enough grip. This means that the scrubbing effect of the inside wheel going at a different speed to the surface won't affect it as much as it should, and so the disadvantages of the locked diff are reduced.

2. LFS hasn't got helical diffs. The best (mechanical) diff for racing is helical type (Quaife etc) as it supplies the most torque to the wheel with the most grip. All other non-locking LSDs in LFS reduce the spinning of the unloaded wheel, but don't stop it. This means power is wasted (and tyre heat+wear produced) spinning up the wheel with least grip. This is made worse by 1. above.


I also suspect that there is a problem with the implementation of the clutch-pack (unless I misunderstand how clutch-packs work, which is a reasonable possibility) which may or may not affect its behaviour when cornering. If the car gets stuck in a gravel trap and one of the drive wheels is hardly touching the ground, this wheel will spin away merrily while the loaded wheel doesn't move at all. The only way to move the loaded wheel is to keep modulating throttle whilst pumping the clutch. I don't get how that should be possible when the diff is set to have reasonably high locking under power and a high preload torque.

All Z25+ servers use UDP now instead of TCP for connections - something's probably blocking/dropping UDP packets.

Quote from eVo_BR :

Quote from chucknorris :

Am I the only one who sees "leonkill" as both the "buyer's" old lfsname and the From Line of the "seller's" email?

There is no way of detecting them automatically (unless Scawen adds some checks).
There are visual signs, some more reliable than others, but they can only be spotted manually.

Quote from boycey10802002 :

The hard thing about you learning outgauge right now is that all of the documentation seems to have disappeared from the internet.

All the OutGauge documentation you'll need is at the bottom of /your_lfs_directory/docs/insim.txt

Quote from blackbird04217 :

I like staying on track, which takes ~50% of my CPU. If I was to send a /end command (which is possible) I would then need to enter the track each time. Then I would be forced to - wait for lights each time I am doing a test, or to make it so the AI driver comes from pitlane...

I suppose the alternative could be a specially designed AutoX layout.

Put LFS in a window (shift+f4) then minimise it. Doing this puts LFS' usage from ~15% to 0% on my PC.

That presumably turns off some physics calculation, along with whatever CPU the graphics need.

Quote from Bob Smith :

While true, this also means the tyre should also warm faster when generating heat (given the same energy input to the system).

In my own tyre heating model I have found that temperatures simply swing more as the tread wears, and if anything the average temperature continues to increase as the heat conducts deeper in to the carcass, sidewalls, and pressurised air, meaning less heat can be lost from the tread into these areas.

I don't see why the LFS model would differ from my own in this regard.

Good point (I hadn't actually thought it through that much, mostly repeating what had already been said on the forum )

I would have thought that the primary loss of heat would be into the external air (+ track) rather than the internals anyway, as the temperature difference would be greater. Been a few years since I did any kind of thermal physics, so I can't be sure.

Thinking about it properly, I would expect less heat generation from the tread itself as the tyre wears, as there is less rubber to move around. I don't know how much of a significant impact this would make, if any, though.

The tyres cool down after a few laps due to tyre wear - the tread thickness reduces, so becomes less insulating. In other words, the tread can't hold as much heat, so the tyres cool down quicker.

For longer races, it's fairly common practise to let the tyres overheat a bit for the first few laps, till they wear enough to cool down a bit. They usually manage to keep the temperature fairly constant after that, providing you're driving fast enough and the pressures + camber are correct.

As they get very thin, they start loosing heat even faster and then get too cold.


Regarding F1 this year, in most races the harder compound tyres are perfectly capable of lasting the whole race. They've often been described as being able to 'run all day'.
However, the recent races where they've degraded too quickly is mostly down to them overheating - either because the track is so slippery they're sliding all over the place and generating a lot of heat from friction, or because the ambient temperature is very hot.
The reason F1 tyres (and most racing tyres) degrade so much is because as they get very hot, the rubber starts to melt and they start graining very quickly.

Unfortunately, graining isn't simulated (yet?) in LFS, so the tyres don't compare very well to certain racing series (sprint tyres) or conditions.

As far as I've been able to tell, it depends on the specific packet(s) and type(s).

A car can disappear for a long time and not lose connection - this is some or all position (UDP protocol) packets getting lost.

Regarding timeouts and lost connections, I think it depends on how the TCP connection fails (there are different TCP fail states as far as I know).
'Lost connection' sounds like a TCP/socket error where the connection is broken and the server gets a fail message somewhere.
'Timeout' is presumably where no traffic at all has happened on the TCP connection for a while (10 seconds in the case of LFS, I believe) and it gets closed.


It's been a while since I've delved into UDP/TCP and, of course, I don't know for sure how LFS' connections work, so it's largely speculation. I'm sure someone will correct me on some of it

Would this not be a bug with the nVidia drivers, rather than LFS?

Pitlane duration could also be estimated (lag permitting) by InSim applications.

Edit: LFS even sends InSim packets when a car enters and exits the pitlane, so this should be fairly simple to implement.

Well, I've never cracked windows and I've seen the problem before quite a few times on various versions, as I said above.
I don't have the problem in Vista on my laptop or W7 on my PC afaik.

I believe it would also be important to explain why and how they cause problems with the physics in said proposed sticky.

Most of the people who I've caught using them had no idea that they cause any issues at all and a good few of them wouldn't use them online if they knew.

I've seen this problem sometimes with pretty much every windows version since 95.

It doesn't happen on every install and I've never found out the exact cause, but it's probably driver related.

You CAN have it installed and unlocked on 2 computers, you just can't use them online at the same time.

You can also run LFS on 2 operating systems/installs provided that you have 2 separate installs of LFS.

Problems can happen if 2 OSs try to use the same *.xyz files, as that's where the unlock info is stored AFAIK.

Probably the easiest way of doing it is to allow all UDP ports to your machine(s) and run a firewall with application based rules on each machine.

Personally, I've never had any problems with router based firewalls blocking LFS, and software firewalls seem to do the trick when it comes to dropping packets bound for dis-allowed applications.

Drive smoothly. Move the wheel too fast and it'll kill you.

You can already do this for Ctrl+ and Alt+ function keys using LFS scripts. From docs/commands.txt

It wouldn't do it automatically and it won't work with F1-F8 as far as I know, but it's a start.

If the server is on your PC, connect using 127.0.0.1
If the server is on your LAN behind a NAT router (most consumer routers), connect using its LAN IP (192.168.x.x 10.x.x.x etc)
If the server is outside your LAN, connect using the server list.

It might be easier to use sc.exe, which should be included with Windows.

I'm not sure off the syntax offhand, but the file's help or google will probably help you.

Quote from DavidTiger :

Don't you have a normal Alt key??

Yes, but with one hand I can only get to F9 at a stretch and only F8 if I use my left hand. When driving with anything other than keyboard, taking both hands off the controller is very likely to cause unwanted steering input.


I hadn't considered the repercussions of simply making Alt Gr = Alt, but it does seem wrong that it gets interpreted as Ctrl rather than either Alt or nothing when used with F keys. When used with a standard letter that doesn't have an option for the modifier, it often doesn't do anything at all (text input on some other apps).

Many other programs, particularly games, interpret the Alt Gr key as a kind of 'Right Alt' which can vary its use depending on the key combination. I'm not sure what interpretation would be best for LFS, or even if it's worth changing, but having Alt Gr + F* do nothing or assume Alt + F* would be more logical than pressing the Ctrl + equivalent.

This is a fairly minor bug, but it's been bugging me recently (no pun intended).

The "Alt Gr" key seems to be interpreted by lfs as Ctrl instead of Alt. When I try to use the Alt Gr key to do the Alt + F7-12 binds with one hand, LFS runs the Ctrl + F equivalent.

Quote from JBiturbo :

as i recall, the Scirroco and the tyre physics are being anounced since august of 2008! And by that time, the Scirroco model was already designed and prety much perfect.

Yes, the Scirocco was announced mid-2008, but the tyre physics update wasn't announced until much later.

The VW was almost ready to go in Dec. 2008, which is why we got the pre-release announcement. However, there were some problems found with the handling, so release was delayed until the infamous "early 2009" to let Scawen sort out the problems.

It turned out that the problems were actually caused by errors in the tyre physics model, so Scawen quietly started research and work on a new model. He didn't announce that he was working on the tyre physics until August 2009 after he knew that the new model was an improvement over the current one.

I'm pretty sure that the 3D model + textures etc for the VWS will have been finished long ago, but the ESP system will need to be (re)written once Scawen has finished the new tyre physics.


Thus concludes a summary of what I understand has gone on with the VWS/Physics announcements. I may have forgotten some things and/or got it a bit wrong, but I doubt it's far off.

Setting the deviceIDright/left to -1 for the unused monitor is supposed to work.
I think I got it working like that with v1.08 I think, but it wasn't reliable. YMMV

People also slate BT Wholesale.

Most problems with ISPs and/or bad quality connections are down to congestion. BT Wholesale (any non-LLU '8 meg' service) is usually oversubscribed and as such can't handle the traffic going through it.
Cable isn't immune to this either - the connection is still shared, but with people on your street, as well as people in the same town or on the backhaul. Traffic management and silly daily download limits still apply to VM cable (unless you fork out for the top-tier package). Location and who set up the connection in the first place (NTL/Telewest/Blueyonder) dictates how many people it's shared with and if it affects download. Sometimes the download isn't shared locally, but the upload usually is.

LLU ADSL however depends entirely on the ISP as to what the contention ratio is and therefore how likely congestion is. ISPs do exist that provide 1:1 contention (ie you have your connection speed 'allocated' and not shared with anyone else) at competitive prices. With such ISPs, the only problem you'll have - unless you have a poor quality line (BT's fault) - is if some muppet breaks a fibre link somewhere.


It's all swings and roundabouts - VM is generally fine if you have the top tier package. LLU ADSL is usually fairly good, but that will depend on the ISP. The poor sods who are stuck with non-LLU '8 meg, my arse' packages because they happen to live somewhere without cable/LLU have to lump it unfortunately.

Another thing to point out with the '8 meg' packages is that they've started to falsely blame line quality for not being able to get the full speed. BT now reckon that the line where I am atm can only handle up to 6mbit. I know for a fact it can do over 7.5mbit, because it did when the 8bit service was first enabled at this exchange. Now they have a lot more people using it here, the connection (not the line) just can't get that fast anymore.