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.

Hmm, I'm out of ideas for solutions tbh, short of contacting sky/bt.

The 10 day thing is to determine the best sync speed for the line. This usually causes the connection to loose sync several times (would mean a complete disconnect for a minute or three), which is nothing like the problems you're describing.

From the attenuation figures you gave, the distance from the exchange is certainly not the problem. If you were to get ADSL2+, you should ideally get ~22mbit at 16dB, according to be - although the attenuation would be different with ADSL2+, so that won't be an accurate figure. You should certainly be able to get at least 5-6mbit on ADSL1.

The problem is like one or more of:
- congestion at the exchange
- problem with the line itself or its connection to the exchange
- problem with cabling between the line and the router/modem
- problem with the modem

1.3mbit actual and those latencies is unacceptable for an 'up to 8meg' ADSL connection when you're that close to the exchange. Call tech support is all I can really suggest for now.


ed: stick your phone number in the box at the top of this page to see what you should get with ADSL2+ (or ADSL1 if be isn't enabled on your exchange). There's a similar test in the broadband section of BT's site.

Last edited by Degats, Sun, 4 Apr 2010 20:03.

Packet loss is one of the problems (and will cause you to loose connection to any server sooner or later) although the high-ish ping and high jitter will make car-car interaction horrible.

If they don't have LLU at your exchange, you'll most likely be on ADSL1 (someone else may be able to confirm how sky broadband works when not LLU)

That download speed is fairly shocking - as teedot asked, how far away is your exchange? (If you don't know, look in your router status for something like 'downstream attenuation' - it'll be a number, most likely reported in dB. Failing that, PM me your post code and I'll look it up for you.)

I'm assuming as you're with sky, you also have a sky TV box? If so, chain two ADSL filters between the sky box and anything else - that trick is supposed to solve all sorts of problems on ADSL2+; it'll probably help with ADSL as well.

Another thing to try:
Plug a touch-tone phone directly into the master socket, dial 17070 and go to option 2.
This is known as the quiet line test - the connection should be absolutely silent - no hiss, pops or crackles.
If you hear anything, that would indicate a fault on the line - phone BT and mention the quiet line test.

Try speedtest.net and pingtest.net and post the results here.

Are you using an ADSL filter between the modem and the master socket?

How long did you run ping for? Try at least 100 to get a decent reading (ping -n 100 lfs.net)

What kind of ADSL (1/2/2+)? who is the ISP? Do you have problems connecting at all times of the day or only some?

Quote from AndRand :

Well, I dont know how LFS engine actually works - does it calculate equations on table of coefficients or does it make a table of "raw data" for given setup and then uses them in calculations (which I dont know to what extent applicable as coefficients are also dynamically changing (pressure, load and so on))?

As far as I'm aware, the current LFS model is purely mathematical. No tables, just equations.

There are several hosts that run using WINE on Linux with no problems. Mine included.

This isn't an LFS problem - upgrade WINE, check that UDP packets are passing through unheeded, make sure all the right ports are forwarded.

Quote from War :

Yes i tried to explain the same thing to them, but well they just don't understand... :doh:

Try telling them that S1/2/3 is just a level of content (as it is now) and not a program version (which is what it used to be)