Nope, that's incorrect! Victor is the "web guy" who maintains the forums and LFSWorld. Eric is the one who designs the tracks and (most of the) cars, with the tools and graphical capabilities that Scawen provides / codes into LFS.
There is no need to break compatibility to DX8 hardware right now, so why bother? LFS is not about being or becoming a multi-million $ cash cow, so as long as it provides enough dough to let the devs live their lives without requiring a "real" job it's working well enough. Besides that, due to being a niche product it is more beneficial to be compatible to as much hardware as possible to give lots of people the opportunity to use your product rather than trying to attract the graphics circlejerk crowd that mostly consist of people who aren't interested in simulators or realistic gameplay anyway.
And in case you haven't noticed from the-LFS-way-of-development™ yet, just because something can be done doesn't mean Scawen will do it. There is no acute need for a complete graphics overhaul (nothing is broken), so graphics improvements will continue to come as they do now. Slow and in small amounts.
@Tristan: what do you think about my "motions!" megapost in regards to accuracy? Is how I think someone drives actually happening for you too, or does that only work in a sim environment that is far less random than reality?
Hmm, sorta, yes. You can accomplish the task of using an arbitrary set of "strategies" or "decision maker processes" to compute a final result or behaviour very easily using OOP.
How did you come to that conclusion?
Whether you use WinXP or Win7 is completely irrelevant for how LFS looks or what DirectX version it uses. Win7 does not remove DX9 (and with that also DX8) compatibility.
Indeed, you are wrong.
1) DirectX or rather Direct3D is an API that allows you to communicate with the graphics card. Newer DirectX versions give you different/additional/more efficient ways to do that, however, how many polygons you can display is still determined by your graphics card, not DirectX version.
2) In LFS, the ground you drive on IS NOT the track you see. There are two separate meshes for each track. The first one is the one that gets rendered and you can therefore see on the screen, the second one is invisible and used for physics interactions. Because it is not rendered, it can be vastly more complex than the visible one without affecting performance.
Ever driven over kerbs? These are rendered perfectly flat, but when driving over them they're actually acting as if they were zig-zagged. There are also a few places in LFS where these two meshes are not perfectly aligned, allowing you to drive "below the floor" or "in the air" depending on how misaligned they are. Just go on the dragstrip and drive along the little path on the right side. If you go off into the grassy hills on the right of the path you can see what I mean.
Can't really say much about iRacing or netKar, but the aero model in LFS is still quite simple as far as I know. The wings are probably simulated well enough, but the ground effect is only simulated for race cars that have an undertray/diffusor and it isn't influenced by ride height at all. In a real car if you go very fast and get air under the car not only is the ground effect gone/diminished, but if you're unlucky your whole car can act as a wing which can flip you over - no such thing in LFS.
Non-downforce cars are also lacking the negative downforce (lift) at high speeds, though IIRC that's the case because Scawen doesn't have good reference data on just how much lift is actually produced for cars similar to LFS' ones, so he just set the lift to 0 instead of using wrong values.
This can be very easily extracted from RAF files (with RAFTyreExtract) and is in this case shown with MultiDim (that plots arbitrary data on a 2D pane). If someone told you this is incredibly complicated to do then they 1) had no idea whatsoever and 2) sound like the usual LFS "it's not implemented because it's too complicated" apologists.
1) The ideal shiftpoint is the RPM value where changing to the next gear will deliver more torque than the current gear does. This RPM value is different from gear to gear (shifting 1st to 2nd has a different ideal shiftpoint than 4th to 5th) and throttle position (though you're generally only interested in the WOT shiftpoints).
2) The ideal shiftpoint cannot be felt, heard, seen or otherwise humanly measured while driving the car. It needs to be externally calculated or measured from dyno charts.
3) Once you have calculated the ideal shift point(s), you can either set up a shiftlight to light up at the correct RPM value (or nearly correct RPM value, if it doesn't differentiate by gear), or you learn the value(s) and shift by looking at the RPM gauge or by knowing the engine pitch at the ideal-shiftpoint-RPM. This is what "shifting by ear" refers to and has nothing to do with figuring out the ideal shiftpoint per sé.
4) Hitting the ideal shift point accurately is generally grossly overrated and not terribly important for good laptimes at all, as Tristan has nicely pointed out.
5) The big deal about the LFS shiftlight is that it doesn't light up at a pre-set (and possibly inaccurate) RPM value, but dynamically performs the ideal shiftpoint calculation in realtime, even depending on throttle position. When the LFS shiftlight lights up, then that is the de-facto ideal shiftpoint. Not earlier, not later. It is not a simple redline warning. I don't know if such systems exist in real life, but if they do, they're probably only used in top-level racing. Maybe nobody actually bothers though, since as per point #4 hitting the ideal shiftpoint isn't as important anyway, especially if you factor in human reaction time on top of that.
Point #5 is also why not having dyno charts available was until now (or still is?) not a big deal. Dyno charts help figuring out the ideal shiftpoint - why bother with that when LFS already does the work for you?
So in summary, the shiftlight being gone is a concern because it told us the ideal shiftpoint, but it is not a big concern because the ideal shiftpoint isn't that important anyway.
Besides that, currently you can still use the automatic gearshift help to figure out the ideal shiftpoint RPM value. Yes, the automatic gearshift in LFS always shifts at the ideal shiftpoint. This behaviour is of course less than ideal, because in some situations you don't want to shift at the so called "ideal" shiftpoint.
E: @Dygear: I don't think he necessarily wants to write the best/fastest AI, but simply an AI that uses a more human-like approach of driving and decision making, no matter whether that will result in a more believable / competitive / human-like AI or not. My approach would certainly be a different one.
Warning, wall of text incoming!
I don't think the human mind does that at all. Downforce just makes the car more grippy, resulting in a different baseline knowledge (see below) of how to drive the car - having another car in front is a special condition that just translates into "watch out! less grip / more understeer" and you compensate for that by driving slower / braking earlier / finding a line that is not directly behind the car. Just how and how much you compensate for less grip comes down to how much experience you have with your car's behaviour in that situation.
How much grip a car has in absolute terms at a certain point is not really a concern for the driver anyway - you're never actively calculating grip during a race and deciding how fast you can possibly go through a corner. Rather, you have a baseline knowledge of what corner can be taken at which gear (= speed) using which motions (= braking motions, turn-in motions, throttle motions) under normal conditions. By motions I literally mean the motions you perform - they are stored in your muscle memory and can be accessed very quickly without requiring you to think.
This knowledge is built up by practice and slowly approaching the limits starting from a rough but safe initial guess (and learning from following competitors or watching replays, etc.). So what you end up with is a set of inputs + expected results that need to be started at a certain time.
Any special conditions are then accounted for afterwards, for example by having altered "baseline knowledge sets" for different but frequently occurring situations. Having less grip until the tyres are warmed up, approaching T1 after the race start, driving on a wet track or overtaking a competitor are probably situations that are worth learning a different set of motions for as they happen relatively often.
Conditions you don't have a learned set of motions for (due to them occurring very infrequently or if you simply don't have much experience yet) have to be compensated differently, either by educated guessing or pure guessing. These generally require you to actively use your brain and are thus much slower than if you had a stored set of motions ready for them.
The educated guess comes into play when you have specific pre-existing knowledge about the nature of the situation or you can link the situation to similar situations that you know how to handle. Say for example your rear tyres are overheated. Or dirty. Or your rear suspension is damaged. You might not exactly know what actually happened and you have no idea how much grip you have at the rear tyres (other than less than usual) so you can't simply "play back" the motions you're usually going through anymore, but you do know that using the throttle less aggressively and softening your steering inputs (less sharp and aggressive cornering) will probably help in this rear grip = lower situation. Just how much you have to alter your usual driving by these rules comes then down to trial & error, but basically you increase the strength/influence of the input alteration until your error-correction trigger rate (see below) goes down to an acceptable level, while constantly going back more and more to your usual unaltered behaviour to test if the special condition has improved or gone away.
A pure guess is, besides being the worst, a kind of guess you have to take when you have no reference or prior knowledge of how to handle a situation correctly. For the most part this is probably the simple reaction of reducing speed and/or taking evasive action. By gaining more experience you reduce the amount of situations where you have to resort to this kind of guessing.
During a race you also have a secondary set of motions ready, not used for specific parts of the track but for general error corrections. It's basically a set of triggers running in the background that auto-launch corrective motions in certain situations.
For example: trigger condition > error > actions to resolve
- Car turns unexpectedly/without steering input > oversteer > countersteer
- Front tyre screech under braking > front lockup > reduce brake strength temporarily
- Rear starts coming around under braking in RWD car > rear lockup > countersteer + apply throttle / reduce brake strength
- Car doesn't turn enough under braking > braking understeer > reduce brake strength and wheel turn
- Car doesn't turn enough under throttle > throttle understeer > reduce throttle and wheel turn
- Car turns too much under throttle > throttle oversteer > countersteer + reduce throttle
- etc.
Of course these are very general and might not be correct under all situations (= trigger condition not refined enough), but they simply represent the learned/automatic reactions to correct various errors that occur due to whatever reason. Of course these can also be more complex / abstract / meta-triggers, like "rate of oversteer corrections too high" (something wrong with rear wheels? overheated?) or "motion with high success rate starts failing too often" (something wrong with the car?), etc.
Basically I'd say for driving around a track you're using a set of learned and sometimes deliberate motions, using triggers (distance to-/position of a reference point can also be a trigger) to determine when to start or stop the motion.
Brakepoint
Start braking motion
Press brake pedal with certain speed/strength
Repeat heel-toe downshift motion with certain frequency till desired gear (speed) and/or turn in-point is reached
Turn-in point
Start turn-in motions
Release brake pedal with certain speed
Start turning the wheel till desired/sufficient angular momentum is acquired to hit the apex
Apex
Start exit-turn motions
Increase throttle with certain speed
Reduce wheel turn while maintaining sufficient angular momentum to reach corner exit
Corner exit
Start straight-line motions
Repeat gearchange motion every time the engine pitch reaches a certain point
Follow track till the next brakepoint is reached
All that while running keeping the error-correction motions, or at least a situation-appropriate subset, ready in the background.
I guess the point I'm trying to make is that you try to avoid as many active calculations - as much thinking - as possible and rather follow learned motions.
Or maybe an even simpler, more abstract process:
Wait for trigger
Start motion
Does it achieve desired result?
Yes: Goto 1, No: Continue
Do we have an error-trigger to correct the situation?
Yes: Goto 1/2, No: Continue
Start up brain
Can we make an educated guess from our general car-behaviour / situational knowledge?
Yes: Do it!
No: Slow down / evade
Well, at least that's how I'd say a human driver does the driving, roughly speaking. Making an AI work like that is a different story.
Just rotate your wheel fully left/right to make sure LFS uses the full steering range of your wheel after the calibration has been reset. Deadzones are really terrible for wheels and you shouldn't need to use them at all.
Well, without that it would be completely undrivable with keyboard controls. It's basically the same as LFS old keyboard stabilised controls, before they got rightfully nerfed.
Try finding new graphics drivers for your what I assume to be integrated graphics card. Right now it apparently reports to LFS (via DirectX) that it doesn't support antialiasing, hence LFS not displaying the option. Maybe newer GFX drivers enable this option, but I fear that even if they did your GFX chip wouldn't have enough performance to make good use of antiasliasing.
E: Though a quick Google search suggests that your GFX chip doesn't support antiasliasing at all :worried:
In Options > Controls > Axes / FF, click "recalibrate axes" and depress all pedals fully once. Is the bar to the right of "Slider 0" still maxing out before you actually reach the end of the throttle pedal's travel?
If so, check out if you have put the potentiometer of your throttle pedal back in correctly. It might be misaligned and therefore reporting 100% before actually reaching 100% pedal travel.
Also, as far as I am aware, the forum accounts aren't created until you first log in here, so you can be licensed without the forums showing you as such.
This is evidenced by the forum reporting 38450 members including demo racers, but the amount of total licensed racers alone is > 60000 from the last reported numbers.
Though it might make sense to implement that as bitflag instead, just in case for any hypothetical license model changes in the future where an S2-content license doesn't require an S1-content license anymore, for example.
So make it:
-1 doesn't exist
0 no license / demo
1 S1 license
2 S2 license
4 S3 license
A typical S2 user today would then report as 3 (S1 + S2 license).
Then again... just how likely is that to happen? So maybe not