I guess it's to do with the way that the messages are now displayed from the server rather than locally, so it doesn't make it into the local history buffer?
Dygear: Have you tried any other DX8 games? As DX10+ is completely separate to DX9 and below, it's possible that the Intel driver has broken something old that LFS uses.
I don't know how Intel's driver availability is, but is it possible to revert to an older driver version to see if it still crashes?
Having the in-game driver do any functions other than steering never works without looking weird.
Animations for pushing buttons and changing gear can only happen after you actually do it, which IMO is much worse than not having the animations in the first place.
As you can see, what I said bar the last sentence is what we have been told (or basic maths), not speculation.
I could have speculated on other/specific reasons for their delay and other things, but I chose not to.
I even sat on the fence as to whether Eric has been working on other tracks or not. There haven't been any announcements or hints (other than "Westhill updates" whatever that means) so I'm not going to try to guess.
LFS ceasing to be indie would IMO be the worst thing that could happen to LFS. Sure, it would probably sell a hell of a lot more in the short term (mostly because of marketing) and while I'm sure quantity of content would increase with more people working on it, quality of the program would unlikely be any better, if not worse.
LFS exists because it's indie and is as good as it is because it's indie. Publishers have a nasty habit of rushing buggy code through, overworking employees and, especially more recently, throwing developers out to dry. Publishers are in it for the money first and the game later - indies on the whole are the opposite.
I've always wondered about that one.
It does make sense to not show a message if a player is /spec'd by an InSim program, because it's easy to automatically show a custom message.
However, if it's a manual /spec by an admin, it can be confusing as there can be no automatic message. It can also be tricky to keep track of it in replays, as InSim messages aren't recorded.
It's not a big deal, but slightly annoying sometimes.
While we're on the subject of autocross objects, it would be really useful to have a no entry sign (like the keep left/right ones). That'd make it a lot easier to navigate some of the more complicated autocross layouts, especially as chalk arrows can be hard to spot sometimes.
The VWS was originally (and still is) intended to be S1 & S2 content.
Both the VWS and S3 content (Rockingham and the Mystery Car initially) are waiting on the tyre physics for various reasons.
Making Rockingham S1/S2 would mean that the initial S3 licence would have even less content (that's assuming Eric hasn't completed any more tracks by that point, but either way would mean less S3 content). Having Rockingham at S1/S2 would be nice, but wouldn't make much business sense.
I've never tried using a prefix on a client InSim app, but I guess this is what's happening:
If the server's prefix is the same as yours, you get an MSO_PREFIX
If the server's prefix is different (or it doesn't use one) you get an MSO_USER and your prefixed message is shown to other players
If you want to send hidden messages to a client InSim, you probably should to use /O <message>, which will send an MSO_O
The automatic gearbox already knows where the optimal shift point is - as does the shift light on the cars that have it.
AFAIK, the only thing that affects the optimal shift RPM is the torque curve and ratios.
Ratios are a known quantity, as is the effect of the restrictor on the torque curve - assuming there's anything more complicated than just a constant % reduction in torque. Either way, LFS needs to know what the effect is to be able to output the torque in the physics engine.
I dunno if there's an equation to work it out or whether you have to run through each RPM value per gear, but VHPA can calculate all gears and graphs in close to realtime, so it can't be too complex.
The speed you can reach in a gear @ max RPM is pretty useless information on the whole TBH.
In most cars, if you're changing gear at the rev limiter, you're being inefficient and in the highest gear you should never reach the limiter.
What would actually be useful is optimal shift RPM and speed.
Top speed would also be nice, but would be much harder to calculate as it needs to take into account friction (which is affected by drag, tyre compound, pressure, camber, toe etc) - the VHPA needs to do a full simulation to work that out afaik.
Unfortunately, all this data takes up space so it'd probably need quite a bit of shuffling to fit it in. VHPA is a very good solution for now, even though it is a little inconvenient if all you're changing is ratios.
Also, the ideal racing line isn't necessarily what you'd calculate mathematically - it usually is for simple corners, especially when not laterally grip limited, but more complex corners or close sequences of corners can be very different.
It often also varies depending on the car. For example, the different drive configurations (RWD/4WD/FWD) of the TBO cars mean that one corner have very different fastest lines for the different cars, even though they have similar performance.
The ignition button doesn't actually turn off the car, only the engine, so there is no full off state in LFS where the entire dash would be off. All dash lights and gauges work at all times, regardless of the state of ignition/rpm/whatever.
Unfortunately, the LFSManual entry is fairly useless unless you want to use Python.
All of the information you need is in LFS/docs/InSim.txt (at the end).
The structs & enums in that document are all C/C++, so you can just copy paste them as Arduino also uses C/C++. You may need to check the types though - I don't know if the type lengths are different for the Arduino than 32/64bit PC.
Turbo boost is properly simulated and reported through OutGauge, with both +ve and -ve pressure.
Oil pressure (based mostly on RPM iirc) and Engine temp are faked ingame, but not simulated. I had assumed they'd work in OutGauge as well, but they appear not to.
Oil temp isn't simulated or faked at all afaik.
If you just want to show the temp & oil pressure dials doing *something* and not really bothered what, you could use the pedal input info.
The specific multiple monitor feature that was removed (as a built-in Windows feature) since Vista is where multiple displays behave as if they're the same screen - meaning fullscreen games etc will span across both displays.
In Vista/7/8, the displays used in extended mode still behave mostly independently - the start menu, task bar & full screen applications load by default only on the primary display and maximised applications will only be on a single display, not both simultaneously.
To get the old feature back on Vista/7/8, you have to use hardware (TH2G), software (SoftTH, but that only works for fullscreen 3d programs afaik) or a 3rd party driver feature like Eyefinity.
TBH, I think Vista got way more bad press than it deserved.
Most of the initial problems were caused firstly by the change in driver model, which meant that hardware manufacturers had to get off there arses and update drivers - something that many were incapable/slow at doing. Secondly, they removed a lot of the 'hacky' ways of doing things, which meant that a lot of programs that weren't written properly in the first place had problems. Finally there was all that "Vista capable" crap with PC OEMs - that one probably has equal blame between MS and the OEMs.
Vista with SP2 wasn't actually much different from the early W7 versions. There are a few retarded things about it and some inefficiencies, but it runs a lot better than it did originally.
Windows 7 fixed many of the strange design choices, improves UAC and has improved stability and efficiency - basically just tweaks and a few features over Vista. W7 is better than Vista overall but there's not actually a huge difference between the two.
Something that I think was forgotten by most people who still loudly hate on Vista is how much of a dog the almighty XP was when it first came out. It had a heavily criticised UI, consumer driver/software compatibility problems and was more of a resource hog and more unstable than Win2k. Sound familiar?
XP only really became usable after SP1 and only got good after the big changes made in SP2.
Yeah, that's what I figured for the 10-20ms readings, although I thought the 30ms was a bit high. I guess it's just an obscure combination of timing and maybe CPU load.
The multiple screen feature was indeed removed by Vista, but modern AMD and nVidia graphics cards can do it themselves. AMD's Eyefinity supports up to 6 screens per card and I believe nVidia has some kind of equivalent.
Windows 7 is actually a very solid OS. There are a fair few improvements over XP - its 64bit implementation especially, plus better stability - although it does use more RAM (less than Vista though). Saying that, with 8GB RAM costing less than £30, who cares.
Underneath, Windows 8 is basically Windows 7 with some performance improvements and a few other tweaks.
The new tablet ("don't call it Metro"*) interface is the start menu and nothing more. The desktop still exists as it was, other than the start menu, so the only time you need to access the tablet interface is when opening programs and shutting down. It is a bit clunky to use with a mouse though, but a hell of a lot better than it was in the Developer Preview.
Frankly that's no real hardship, as since Vista most people use the start menu only to begin typing the name of a program then select it from the list of the results - that behaviour hasn't changed.
I haven't properly played with W8 on real hardware yet - only in a VM - so I can't really say what it's like to use on the long term.
I've been using W7 every day for over 3 years now and I personally prefer it to XP. It's certainly much more stable; the only thing that's ever crashed it for me is when the occasional broken version of Flash takes out the graphics driver.
*They got sued over the Metro name for Trademark infringement or something
Just tested this on my machine - localhost dedicated server, same version as client, Win7 64bit
B9: 0.01-0.02s; mostly 0.02 about 80% of the time
B11: 10-20ms; mostly 0.01 >90% of the time
I haven't seen more than 20ms to a localhost server, although I did see 30ms (B9, Wine) or so to a LAN server sometimes, which is a little strange as real ping time is ~400µs.
B11 LAN server seems fairly solid at 10ms (>80% of the time), never above 20ms while on track.
Reported latency to Internet servers seems to be about OK in B11, mostly 40-50ms (max 60) to a server with real 36±1ms ping.
In my experience, it is usually the client's load times that cause the disconnects on track change, although IIRC occasionally people with very bad connections do get taken out by others who are loading slowly.