Firstly, close firefox while playing and see if that makes any difference.
The Intel X3100 will be the main culprit. Try reducing the resolution - it should increase framerates, but will look worse. It's a compromise you may need to take.
You won't have CCC/Catalyst as you have an Intel chip. CCC is for ATi graphics, so don't worry about that.
Also make sure the laptop is plugged into mains and is on high performance mode while playing LFS.
Sounds like you're clicking 'open' instead of 'save as' on the download dialog box (or IE's security settings are dangerous and just opens it without asking... if that's the case, check your security settings or get a better browser like Firefox, Opera or Chrome). Save it to somewhere sensible (Documents\Downloads or c:\Downloads etc), then open and extract the archive.
Files stored in temporary internet files get deleted when IE has finished with them, hence the name and is probaly whats causing the trouble.
Not so strange, really... LFS is a lot more CPU intensive than most other games due to the huge amount of physics calculation. Relatively small variations in background CPU usage can cause a big difference in LFS if the CPU is working hard to run LFS on its own. Most other games may show a few fps difference, but wouldn't be that noticable.
The fact that running LFS at a higher priority pretty much solves the problem would support the above.
After a bit of testing:
Doesn't happen in Z or Z10
Doesn't happen in single player with only my car
Doesn't happen on my new PC (phenom II 955, 4890) with a cleanish LFS install
It's probably caused when the graphics (and cpu?) are being stressed. In the case of my laptop, the graphics may be accessing more memory (it can use system memory as well as its dedicated, but I have no way of confirming this).
I've been having what I think is a similar problem recently while playing on my laptop, although I haven't noticed any HDD activity.
I'm not sure if it has anything to do with the test patches - I'll test with Z and Z10 later.
For me, the frame rate doesn't quite go down to 1fps - its usually 10-14 or so for a few seconds (It's normally 30-60 fps). Happens fairly regularly at certain points at Aston. I've installed parts of the realism pack that's been mentioned a few times recently, and I think that may be making it worse.
When the slowdowns happen, a lot of CPU is being used by a kernel process (red line in the usage graph) SYSTEM. Strange thing is, it's using the same core as LFS and not the other one...
As I said above, I'll see if I can glean some more info by testing it later with different versions etc, and maybe a clean install of LFS.
In fact, this is probably the cause of both problems. The auto box won't shift when the engine is on the limiter and the wheels are spinning. While accelerating round a corner - particularly in a fwd with soft suspension and a soft diff - the inside wheel is spinning, so as before, it won't shift.
This works for any controller with or without a profiler:
In options > controls, assign /press 7 /press 8 /press 9 and /press 0 to ctrl+ or alt+ binds
You can then assign controller buttons to those binds by clicking in the "wheel buttons" column.
This will use up 4 binds, but can be used on 3 using .lfs scripts to toggle on/off.
OutGauge is a protocol, in a similar way to InSim, but much simpler in that it only listens for packets from LFS. The only documentation is the very last section in the file %your_lfs_folder%/docs/insim.txt. If you're not using C/C++ this will have to be modified to suit whatever language you're writing the app in (all the ones mentioned on this thread use vb6.0 because its relatively simple to make a GUI).
If you only want to display text/numbers you can use the values recieved from LFS and convert the units as needed. Dials are somewhat more complicated...
There are 2 ways to make the dials themselves - the easy way, by inserting an image as a background, or the hard way (the way I did it) by using only GUI objects (circles, lines etc). The needles can either be lines or images. Both need to be rotated using trig and some 'gymnastics' as one of my lecturers would say.
The 'ticks' on the rev counter on mine are redrawn for each car to take into account for different rev ranges. The ticks for all the other dials are calculated and drawn when the program starts up.
It was mostly just me playing around with outgauge and has never been officially released. It's mostly there to spit out every piece of data that outGauge sends and adds a couple of funtions like top speed etc. It's more obvious what the gauges do once LFS has actually connected to it and things start happening, although a lot of the random looking numbers have no labels and are pretty obscure
Mine's made all the worse by the fact that it's 100% generated by VB (including the ticks on the rev counter which is why you can't see them ) so probably more things than should get refreshed all the time.
Yes, I know it's fugly, it's a hash job that looks really nasty until LFS connects to it
Are there any other known issues that affect only the test patches and not Z?
There's the front left tyre AA issue, but that's only visible on certain views+graphics settings so not that major.
Bugs unrelated to the test patch (ie ones that happen in Z as well) should be in the bug reporting section, not here.
Edit:
If any bugs you find in Z13 etc are reproducible, test it in Z as well. Then, only if it doesn't apply to Z but does in Z13, post it here
All of those except possibly the first link have been tuned to a greater or lesser extent for drifting.
Many modern road cars (especially ones with wide tyres) actually can't have their steering lock increased, as the tyre is very close (if not rubbing against) the well on full lock.
The only car I know of that actually has a stock steering lock of ~45 degrees is the London TXII
This probably isn't a simple fix as the handbrake is needed on grids with a steep gradient - ie Blackwood - to stop the car rolling down the hill.
Disabling the button to activate the handbrake might work, but it - or a small push on the brake - does need to be there for the starts.
LFS doesn't directly benefit from multi-core as it isn't multi-threaded. However, performance should be better on a multicore (assuming each individual core is similar to a single core comparison) as background tasks can use other cores without affecting LFS (much).
AFAIK, there's no significant difference with DX performance between XP and Vista.
However, on lower spec systems (mine included - 3200+ Athlon XP) gaming performance on Vista is often better than XP as it is better at manageing and prioritising threads thus giving the game more CPU time to work with. The difference is most obvious on CPU intensive games of course, such as LFS and TDU.
There are also differences between the graphics drivers for each OS, but your mileage will vary as far as that's concerned.
The FBM's tyres in LFS effectively come at a pre-warmed 65 degrees - not up to racing temps, but certainly not cold. It's probably best to think of them as lightly scrubbed and is probably the best way of treating fresh tyres in the absence of warm-up laps in LFS.
It would be interesting to have the option of brand new tyres when changed on a pit stop though.
It's probably a CPU issue - what CPU do you both have? Unlike most games, LFS taxes the the CPU much more than graphics or RAM. The price you pay for good physics.
@bully2100 If the CPU is the issue, rolling back to XP is likely to make it worse, as Vista has better thread management
Unfortunately, LFS's yellow flag detection is pretty useless for cruise servers as it could treat a car moving at the speed limit as being slow, and would also flag up cars stopped nowhere near the road. It also has no concept of 'wrong side'
Hmm regarding the pit limit, I imagine that the vast majority of cruise InSim applications currently use the penalty flag itself to determine speeding as it's simpler. Said program can then automatically clear it if needed.
However it's fairly simple to change the InSim app to detect the speed itself. The only potential issue is a delay (or difference in delay) in the detection if there is a lag spike. Another thought is MCI delay - as I understand it, MCI's are sent at intervals (often 1sec) but the pit speed penalty is instant. Whether that matters in the slightest, I have no idea.
I'm on the fence on that one, although it may (or may not) be useful to be removed for people using the cruise flag but without InSim for whatever reason.
Edit: Could perhaps be useful as a server side option? This could also give some servers (including racing) the option of changing the pit limit speed through InSim.
@ John5200: If you don't like slow laptimes reported on LFSW, do some fast laps without an AX layout
Personally, I can't think of any issues for cruise servers other than the flags thing.
Lap times/counts don't get in the way at all and as has been said, some servers have lap time/count records anyway. IMO it's not worth bothering to remove it and they do add value/a challenge to some.