Normally, IRL, if the driver who won gets a time penalty given, the race results and timings are calculated based on that driver not having had the penalty, as time penalties are often challenged. The penalty is then added afterwards.
IMO this would be the best way for LFS to handle it.
However in the case of your DTM example, I'm not sure how it could be calculated to be fair (especially if the driver with the penalty wasn't the leader).
Regarding %age of laps for classification, that would probably be best handled by InSim (using the data received as each person completes a lap to keep lapcounts throughout the race) as there are so many possible variations on classification rules.
I don't know if InSim sends a packet with the "<PLAYER> did not finish" messages. If it doesn't, that would be a nice feature to have, containing info about number of laps. That wouldn't include players who entered spectate to clear the track prior to the final lap though afaik.
IMO this would be the best way for LFS to handle it.
However in the case of your DTM example, I'm not sure how it could be calculated to be fair (especially if the driver with the penalty wasn't the leader).
Regarding %age of laps for classification, that would probably be best handled by InSim (using the data received as each person completes a lap to keep lapcounts throughout the race) as there are so many possible variations on classification rules.
I don't know if InSim sends a packet with the "<PLAYER> did not finish" messages. If it doesn't, that would be a nice feature to have, containing info about number of laps. That wouldn't include players who entered spectate to clear the track prior to the final lap though afaik.
Disable it and find out.
Running LFS as a Steam shortcut causes some stability issues on my machine, so I wouldn't be surprised if similar graphics hooks caused problems.
I've only had up to about 5 LFS crashes in over a year that probably weren't caused by 3rd party software.
Check out the OutSim section near the bottom of the lfs_folder/docs/insim.txt file.
You'll need to write some software to relieve the UDP packets sent by OutSim (once you enable it in cfg.txt) and translate that into whatever commands you need to control the hardware.
There's probably more information about OutSim in LFSManual.
You'll need to write some software to relieve the UDP packets sent by OutSim (once you enable it in cfg.txt) and translate that into whatever commands you need to control the hardware.
There's probably more information about OutSim in LFSManual.
Ah, the black art of diffs.
Locked diff - not good, but not too bad providing you don't want to go round tight corners and don't mind more wear. Typically fastest in LFS for very few laps.
Open diff - bad (the problem with the Vectra in the video a few posts back)
Viscous diff - simple, but not brilliant.
Clutch pack - the best LFS has, providing the settings are right. Getting said right settings is a pain. Commonly used as the centre diff in 4wd and drift cars.
Helical diff - (ie Quaife, the one used in the Focus RS) ideal mechanical racing diff as it gives the most torque to the wheel with the most grip. Unfortunately not (yet?) available in LFS.
Locked diff - not good, but not too bad providing you don't want to go round tight corners and don't mind more wear. Typically fastest in LFS for very few laps.
Open diff - bad (the problem with the Vectra in the video a few posts back)
Viscous diff - simple, but not brilliant.
Clutch pack - the best LFS has, providing the settings are right. Getting said right settings is a pain. Commonly used as the centre diff in 4wd and drift cars.
Helical diff - (ie Quaife, the one used in the Focus RS) ideal mechanical racing diff as it gives the most torque to the wheel with the most grip. Unfortunately not (yet?) available in LFS.
Simply put, less grip == more slide, so having rear tyres that have less grip would make it easier to start a drift.
Controlling it is just a matter of throttle control - and you need less throttle with slippery tyres, so you can cope with a less powerful car - it can be quite hard to get enough torque in the XRG to overcome the grip level of the normals and keep control, so less grip on the rear would make it easier. The normals have a rather fine gap where they're slippery enough for the XRG to easily break traction, but not so soapy they're uncontrollable.
Once they get really hot it can be very hard to hold the slide, but in my experience, you have to be well over 130 degrees in road supers for that to be a problem.
In cars with enough power to easily break the traction of the tyres (unlike XRG), it's usually easier to control the slide if the tyres have more grip.
Controlling it is just a matter of throttle control - and you need less throttle with slippery tyres, so you can cope with a less powerful car - it can be quite hard to get enough torque in the XRG to overcome the grip level of the normals and keep control, so less grip on the rear would make it easier. The normals have a rather fine gap where they're slippery enough for the XRG to easily break traction, but not so soapy they're uncontrollable.
Once they get really hot it can be very hard to hold the slide, but in my experience, you have to be well over 130 degrees in road supers for that to be a problem.
In cars with enough power to easily break the traction of the tyres (unlike XRG), it's usually easier to control the slide if the tyres have more grip.
You're correct regarding the road_supers, but I did test normals as well and there was a very noticeable difference between normals and hybrids.
Just did an 8 lap run at Aston Cadet in an XFG and the drawbacks of the hybrids are much reduced, so I see where you're coming from.
Presumably due to the lower weight, power and speed of the STD cars, it's a lot harder to get heat in the tyres, so you're going to be at optimum in the hybrids much earlier than normals (if ever). Hybrids at optimal do seem to grip better than cool normals - whether that's realistic or not, I don't know, but it wouldn't surprise me.
I did find that once the hybrids got to 70-80 or so the grip was a lot lower, but I couldn't get the normals that hot, even after a lot of excessive power understeer.
Seems like the differences are quite subtle on the STD cars, as they're not very hard on the tyres. How that would compare to real-world, I have no idea.
I've just done a test on KY2, 1 out lap, 1 flying lap, same rb4 setup but different compounds:
Road_Normals: Quite slippery in the out lap, so quite a lot of sliding. At the end of the hot lap, temps were almost ideal (50 degrees, bright green on hottest tyre).
Hybrids: Initially a bit more grip, so a much smoother out lap with little sliding, up to optimal (~50 degrees) just before the end of the out lap. By the end of the hot lap, temperatures were 80+ degrees, bright red and very little grip.
Road_Supers: Much more grip than either Normals or Hybrids, so a very smooth out lap. Optimal temperature (~60 degrees) throughout the hot lap.
In conclusion: Hybrids provide more initial grip than Road_Normals (probably due to a softer compound) but quickly get very hot and unusable. Possibly a little faster than Road_Normals over a single lap on a shorter/less harsh track, but they're far too hot to be of any use for longer runs. By the end of the 1 lap, Road_Normals offer significantly more grip due to the hybrids overheating.
Road_Supers (similar to those used in tarmac rallies and production car racing) consistently have much more grip than both Road_Normal and Hybrids.
That's pretty much the behaviour I'd expect tbh.
There are 2 main reasons why hybrid type tyres aren't used on tarmac rallies.
1. In rally, the top speed is very, very, rarely reached, so any added top speed of a low resistance tyre is irrelevant. However, the grip around corners is very important - road tyres have much more grip on tarmac than a low resistance tyre, so are faster in the corners where more time can be gained/lost.
2. Hybrids get hot on when sliding around on tarmac. Very hot. This reduces grip further and vastly reduces the life of the tyre. Tarmac tyres are much more durable on tarmac.
Last time I was running LFS on my old PC (8 year old hardware design, physically 7 years old - was mid-range when I bought it - I was getting minimum 30FPS at decent resolution (1440x900) and max graphics, just no AA.
I'd still be running that PC, had I not upgraded to cope with games and software released in the last 2-3 years or so, then mainly due to incompatibility (SSE2) rather than performance.
I can't see LFS ever needing expensive hardware for graphics - it just isn't necessary unless it's poorly optimised or excessively pretty and unrealistic looking. Luckily, Scawen seems to be incapable of releasing poorly optimised code and "LFS is not a screenshot generator".
CPU wise, LFS is more taxing, but my 3 year old - again mid-range - 1.6GHz laptop has enough grunt to handle a 32 car grid without breaking a sweat.
In fact, I recently bought a second hand computer for £100 that's perfectly capable of playing Crysis at high/very high settings. I for one don't buy into the expensive hardware excuse for one second.
It's remarkable how well LFS runs on old hardware considering how good the updated Blackwood and especially South City look. TBH, all LFS needs on the graphics front are some lighting and materials improvements, none of which should tax a vaguely modern graphics card that's above the bottom tier. Models with huge numbers of polys are just overkill for a racing sim IMO.
Oh, and newer DirectX versions usually mean that things run faster as the code has been optimised more.
I'd still be running that PC, had I not upgraded to cope with games and software released in the last 2-3 years or so, then mainly due to incompatibility (SSE2) rather than performance.
I can't see LFS ever needing expensive hardware for graphics - it just isn't necessary unless it's poorly optimised or excessively pretty and unrealistic looking. Luckily, Scawen seems to be incapable of releasing poorly optimised code and "LFS is not a screenshot generator".
CPU wise, LFS is more taxing, but my 3 year old - again mid-range - 1.6GHz laptop has enough grunt to handle a 32 car grid without breaking a sweat.
In fact, I recently bought a second hand computer for £100 that's perfectly capable of playing Crysis at high/very high settings. I for one don't buy into the expensive hardware excuse for one second.
It's remarkable how well LFS runs on old hardware considering how good the updated Blackwood and especially South City look. TBH, all LFS needs on the graphics front are some lighting and materials improvements, none of which should tax a vaguely modern graphics card that's above the bottom tier. Models with huge numbers of polys are just overkill for a racing sim IMO.
Oh, and newer DirectX versions usually mean that things run faster as the code has been optimised more.
Had that happen on our servers occasionally. I think it happens if a new client connection glitches in a specific way that isn't caught by the server so it never times out. Players in the server already aren't affected, but noone can join.
Only solution seems to be to restart the server.
Oh, and this should probably be in the bugs section.
Only solution seems to be to restart the server.
Oh, and this should probably be in the bugs section.
It comes up in S2 as well if you click the exit button in the main menu.
It can also happen if your car is hit while it's being repaired. I can't remember exactly what stage it starts spamming though.
The easiest way to find out is to make a small program to display the data received, and check them against the values given within LFS.
IIRC, Accel is m/s/s and Vel is m/s. There may be a multiplier (like 65536) but I don't think so.
IIRC, Accel is m/s/s and Vel is m/s. There may be a multiplier (like 65536) but I don't think so.
If it is possible, there should be a link in the "My online car skins" section of LFSWorld.net (if that section is available to demo users - if not, I doubt it's possible).
I don't see why it would be forbidden - I certainly haven't seen it written anywhere. The reason you have to pay for extra slots is to cover bandwidth costs of the extra downloads. If the other user is happy to use their allocation to host your skins, it makes no difference to the grand scheme of things.
Also, here's a pic.
Has already been posted a few times on this thread and is also still on the z28 info on lfs.net
FYI, LFS itself does not use SQL. Some 3rd party programs that connect to LFS do, however.
As has been said in this thread many times already, it has been kept open so that the things inevitably posted in here aren't spread over many new threads.
This way keeps the forum tidy.
They used to all have sequentials. They were changed to H-Pattern to introduce a bit of a disadvantage to help balance the classes, particularly the FZR. An H-Pattern dog box wouldn't give the disadvantage, so they may as well have kept the sequential in that case.
Originally, LFS stopped you getting out of gear unless the clutch was depressed, but it was changed to allow the box to go into neutral without pressing the clutch pedal.
This was largely done to stop people cheating by putting the physical shifter into the next position early, then briefly mashing the clutch at the right time to change gear much faster and more reliably.
Short of FFB shifters, I'm not sure how this issue could be solved.
I know that would add a little realism, but would there really be any situation in LFS where you would want to turn on the ignition and *not* the engine?
Currently LFS simulates all the ignition stages that matter (stalling keeps ignition on and you have to reset to start the engine; pushing while on turns it off; pushing while off turns it on.
In the past (right before engine stalling was implemented IIRC) the starter actually engaged with the engine for a little while, and it was possible to move the car with the starter. I'm not entirely sure why that was removed. Ed: I suppose it's possible that the starter hasn't got enough torque to move the car
c
main(){
while(!isS3outyet())
postcrap();
return(0);
}
If the clients are loosing connection from the server, wouldn't that mean that the problem is between the LFS server and the LFS client? Surely if it was an error with the InSim application, the InSim connection would be terminated, not a client's?
In which case, it would be an LFS error (as the previous WOULDBLOCK issue was that Scawen fixed a few years back IIRC) not an error in the InSim application itself. It may be triggered by a lot of packets being sent over InSim in a short period, and reducing the number/size of InSim packets would reduce the likelyhood of it occurring, but wouldn't solve the problem - nothing in an InSim application would for sure.
We also have this problem sometimes on our InSim enabled server. Usually it happens to the same few people, indicating a client-side bandwidth problem, but has occasionally disconnected a good proportion of the server's clients at the same time.
I suppose the way to find out if it's an InSim<->Server or Server<->Client problem would be to see if your InSim application's winsock actually receives a WOULDBLOCK error/message. If it doesn't, other than over MSO, then I would assume it's an LFS Server<->Client issue.
In which case, it would be an LFS error (as the previous WOULDBLOCK issue was that Scawen fixed a few years back IIRC) not an error in the InSim application itself. It may be triggered by a lot of packets being sent over InSim in a short period, and reducing the number/size of InSim packets would reduce the likelyhood of it occurring, but wouldn't solve the problem - nothing in an InSim application would for sure.
We also have this problem sometimes on our InSim enabled server. Usually it happens to the same few people, indicating a client-side bandwidth problem, but has occasionally disconnected a good proportion of the server's clients at the same time.
I suppose the way to find out if it's an InSim<->Server or Server<->Client problem would be to see if your InSim application's winsock actually receives a WOULDBLOCK error/message. If it doesn't, other than over MSO, then I would assume it's an LFS Server<->Client issue.
They appear to have been replaced by .trs files (data/knw/TRACK.trs)
As I understand it, (I'm sure you've read more about the problem than I have) TCP_WOULDBLOCK happens when there are too many packets 'happening' in a short period of time.
Are you still sending buttons with a fixed size? If so, each packet will take longer to send thus make it more likely for a packet collision/flood to happen. Reducing the size of the packet to the smallest size possible (by cropping off the unused portions of the text field) may reduce the likelihood of this happening.
It's not a proper solution, but it may help.
Edit: I've just read the 0.5 update to your library - the above is irrelevant with that version, feel free to ignore.
Are you still sending buttons with a fixed size? If so, each packet will take longer to send thus make it more likely for a packet collision/flood to happen. Reducing the size of the packet to the smallest size possible (by cropping off the unused portions of the text field) may reduce the likelihood of this happening.
It's not a proper solution, but it may help.
Edit: I've just read the 0.5 update to your library - the above is irrelevant with that version, feel free to ignore.
Last edited by Degats, .
Win7 (+vista) has an entirely different driver model to XP and most stability problems are caused by driver issues. Is your XP 32bit or 64bit?
Also, you could try a clean install of Win7 if you have a spare drive - no need to enter a key or activate as you only need it for testing.
Also, you could try a clean install of Win7 if you have a spare drive - no need to enter a key or activate as you only need it for testing.
I've taken steam away from the internet for a couple of weeks on my laptop and not had a problem - just make sure nothing's part-way through updating when you pull the plug.
Steam integration works already - you can add LFS as a non-steam shortcut and all the steam overlay stuff works fine. The only thing I've noticed when using it via steam is the occasional crash - most likely down to the graphics hooks and whatever version/hybrid version of DX LFS uses.
Steam integration works already - you can add LFS as a non-steam shortcut and all the steam overlay stuff works fine. The only thing I've noticed when using it via steam is the occasional crash - most likely down to the graphics hooks and whatever version/hybrid version of DX LFS uses.
FGED GREDG RDFGDR GSFDG