The cornering forces will generally drown all but the largest bumps, so it's pretty normal that you don't feel any rumble during cornering (in LFS). It is however important to set up the wheel pretty much exactly as described in the wiki/manual, since this gives you the best feedback. Note that for example having 105% FF in LFS and 40% in the profiler is completely different (worse) than having 105% in the profiler and 40% in LFS. Also having the centring spring or damping enabled is horrible and should be avoided at all costs.
The infamous rally pack was originally planned (or rather, considered) by the devs and Victor prematurely spilled the beans on that in an interview. However, it turned out that they didn't really have the resources after all, so all that is left now is the rally pack in-joke and the invaluable lesson for Victor to keep ones trap shut about development plans unless you know 100% you can do it (i.e. it's already done but not released yet).
Then maybe you should ask whoever posted those pictures on how to do it. They probably have an extra addon written using OutGauge to send the RPM data to the wheel.
Indeed, it is unfortunately not possible to directly send steering/pedal input to LFS without a virtual HID in between.
Depends, if you need the actual speed, you can get it with OutSim and use the "Vel" vector's length as speed in m/s. Or align it with the car's heading/pitch/roll and use the Y axis if you strictly need the forward speed only.
If an inaccurate speed reading is enough, then you can get this information with OutGauge. Keep in mind that this will really give you the value of the speedo, not the actual car speed. The gauge value is inaccurate due to the needle lag, tyre diameter differences (due to wear and/or tyre pressure) and wheelspin.
I think you need to be a bit more precise with what data you actually need to read and "set." OutGauge is really only useful for getting the gauge (rpm, speed, pedal state) data, but not the steer amount.
Reading the G25 axes itself is not really a problem and can be easily achieved with DirectInput. As for overriding the steering input, you'll have to use a virtual HID (as I guess mouse steer or keyboard steer is not an acceptable alternative). However you don't really have to write that yourself, as there's already PPJoy that creates virtual joystick devices. These devices are usually meant as controller adapters (so that you can for example connect console controllers to your COM port and use them or similar), but there's also an IOCTL controlled virtual device that you can simply access programmatically.
Yes, surely losing a race because the RNG hates you is tons of fun.
Random failure is a really bad way to handle situations like this, especially on top of normal problems like an unstable internet connection. If anything, then such failure must be simulated sensibly, so you have in some way control over how high the chances of failure are, like attaching a sort of "stress meter" to each part and only after extended abuse should such failures get possible to happen. If my left front tyre fails while in otherwise pristine condition wear and heat wise, then I'd like to be able to think back and know that it did because I aggressively rammed it over the curbs the last 20 laps. Complete randomness is just awful and really serves no purpose.
I don't think the tyre physics are being rewritten for Rockingham, but rather for the VWS that simply showed by example how the current physics couldn't reproduce real-life behaviour satisfactorily, even with (or maybe especially because of) the stability aids the VWS has.
The dark grey can be easily reproduced either by image manipulation (like in my image), or by actually having a user with custom name "Scawen" leave the server after those admin messages had been dispatched.
I don't have much C++ experience at all, but back when I tried to (and finally also succeeded in) getting the Jagged Alliance 2 sources to compile on VS2005, it was a huge pain in the butt to set everything up. There were a few type differences that VS wanted to have explicitly defined, which was relatively easy to fix and kinda understandable, but the random missing references, the need for special compiler flags and the completely cryptic and unhelpful linker errors made this endeavour quite an exercise in patience. And even after I got it running, debugging was kind of a bad joke.
I'm not sure what the point of this little anecdote was, but I guess "I had similar experiences and I feel with you" comes close. Naturally, I wouldn't touch C++ with a ten foot pole after that experience, and for what I do it is never the best choice of programming language anyway. Can't really see the point of using it for such high level stuff as InSim at all, but that's probably just me . Of course, if you (want to) work for a company that is stuck on C++ due to history (or maybe even has valid reasons to use it), then it can't be helped.
(Edit: Please ignore my ramblings, this is a C++ questions thread, not a "C++ vs. other languages" one. It's sometimes just kinda amusing to see how much time you have to waste on trivial functionality)