Is there any particular reason you chose C++?

Whoa! I didn't even know domains had hands!

Rotate the wheel fully left and right once in LFS, to make sure it calibrates correctly and uses the full steering range. Regarding 900°, none of the cars in LFS actually have 900° steering - the maximum is 720° for the road cars. This is also why the recommended Logitech Profiler setup is set to 720° and not 900°.

However, if you want to force the cars in LFS to use 900° you can do that too. Simply set the "Wheel turn compensation" option in LFS to "0" - now all cars will use 900° steering, though the cockpit wheel animation speed will be slower than your real wheel.

Okay, your world and local space work exactly like LFS' world (the track) and local (the car) space, the only difference being that Z and Y is switched. Also, if you're spawned on the track, you're not guaranteed that the world and local space are aligned / equal. In fact, on the autocross track the car spawns facing "backwards" in world space.

Of course "forward" etc. are just labels for the axes so it doesn't really matter what you call them, but the "forward" in world space makes no physical/logical sense to me, since a world has no front or back. "Forward" just happens to be the Y (in your case Z) axis that is the one that points to the top of your screen if you use the top-down view of the map editor.

That said Z being the "forward" axis is not that foreign to me. When rendering for example, the screen coordinates are also XY (0,0 is top left there, though) whereas Z is the depth (hence the term Z-buffer ), pointing "forward," away from yourself who's sitting in front of the monitor. Just sayin'

But world space has no back/forward/left/right. These terms are all relative to an object, relative to your car. The world space is fixed, so North/South/East/West are more logical in my opinion. Your local space might have +Z always pointing forward, but relative to the track that might be anywhere. The aforementioned 75° would be lots of East (-X) and a little bit of North (Y/Z).

Maybe we just have a different meaning of world and local space though. I can't wrap my head around how +Z (+Y) is always forward in your world space. Or why your +Z would be LFS' -Y

Well, what do you see as "forward"? The Y in LFS is also positive for "forward," but more accurately you'd have to call it "North." Remember, the coordinates are aligned to the track, not to the car. Unless you align the velocity vector with the car's heading, the velocity vector will actually point wherever the car is travelling in relation to the track, instead of Y = forward axis of the car.

Note that on the autocross area you start facing exactly 180° backwards, so driving forwards will decrease the Y coordinate LFS reports.

E: Attached the image, hope you can read the values.
(E2: In my debug output the velocity is already aligned to the car's heading, so Y is always forward.)

Last edited by AndroidXP, Thu 28 Jan 2010, 23:17.

Sorry but that doesn't seem right. I'll draw a diagram as to how LFS coordinate system works.

E: Attached the diagram below (just imagine the Y = your Z). Your calculation would put the X positive and therefore on the right side, having the angle mirrored along the Y (Z) axis. I just want to make sure you use the correct values for calculation, so that the AI reaching its goal wasn't just a fluke.

Last edited by AndroidXP, Thu 28 Jan 2010, 23:04.

Ah of course, the heading is anticlockwise. You have to take X = -sin(val).

By the way, why are you normalizing the vector afterwards? As far as I understand it already comes out normalized (length = 1) due to the use of sin() and cos()?

E: :ices_rofl @ the driving skill

Last edited by AndroidXP, Thu 28 Jan 2010, 22:37.

The coordinates in LFS work this way:
X = left/right (or rather, West/East)
Y = forward/back (or rather, North/South)
Z = up/down

I think this is actually the more logical variant and maybe you should change your AI logic to work like this too. The reason for this is that your AI will mostly work on a 2D plane as far as I understood, so basically as if you're looking from a top-down view onto the car/track. This means that by far the most interactions / coordinates will be on the "track surface plane" which would be using X,Y coordinates in the LFS / traditional system. In your system most stuff would happen on the X,Z plane, which "feels" kinda weird in my opinion. Of course in the end it doesn't really matter, so use what you're most used to.

In regard to your conversion function, are you sure you're getting the heading as ushort? It's a float for me... wait, are you actually using OutSim (OutSimPack struct) or the InSim CompCar struct? You should be using the former, but it seems you're applying the maths required for the latter. In the OutSim packet the angles already come in radians, ranging from -180° to +180° (-Pi to +Pi).

Do you have a game-specific profile (in this case obviously LFS-specific) set to 720° maybe? If that's the case then you can change the global settings as much as you want, it will always load the LFS-specific settings once you start it up.

Quote from kazmer :

What about to measure how the car reacts to the control inputs?
If braking, then the ideal braking point is at the largest amount of -delta speed. So the max acceleration point is at the maximum +delta speed. If you loose grip, these would decrase dramatically

Unfortunately, it doesn't. Have a look at the G-meter while braking on the limit and while locking your wheels. The difference will be minimal - far too unreliable to draw conclusions from. Same goes for wheelspin.

Quote :

Could you post a link (or send it to my e-mail: kelemenlajos'snail'google.com) to the outsim documetation from LFS, i didn't find any

It's in your LFS directory in the "docs" folder, a file named InSim.txt (contains info about all LFS interfaces).

I think you're a bit pessimistic regarding the reachable speed Obviously this isn't a one-fits-all solution for sims other than LFS, but we do know that the tyres' optimal slip angle is somewhere between 6 to 10° and the optimal slip ratio is about 5 to 10%. All the AI would need to do is keep the car within those slip angles (rear tyres slip angle = car heading vs. velocity vector, front tyres slip angle = rear tyres slip angle + steering) and slip ratios (that we admittedly only more or less accurately know for the driven wheels) and go as fast as possible within those constraints.

Taking a corner could work like this roughly:

• AI accelerates on straight towards "rough brakepoint" (marked by placed track node)
  
• AI reaches "rough brakepoint," starts looking for brake reference points (placed by hand near visual markers)
  
• AI finds brake reference points in satisfactory constellation (distance, angle, etc.)
  
• AI's next target is now "turn in point"
  
• AI starts braking
  
• Brake error correction routines kick in necessary
  - This would normally have anti-lockup
  - Tries to keep the car pointed at / going towards the target while braking
  
• Turn in reference point constellation is reached
  
• AI releases brakes
  
• AI turns into corner, towards "apex point"
  
• Over-/understeer correction routines kick in as necessary
  - If the desired angular momentum (stored as metadata, or learned) cannot be reached within front tyre slip ratio constraints, perform anti-understeer actions depending on current car state.
  - If the desired angular momentum is exceeded or the slip angle of tyres is exceeded, perform anti-oversteer actions
  
• Apex reference point constellation is reached
  
• AI's next target is now "corner exit"
  
• AI starts accelerating
  
• Oversteer / anti-slip correction routines keep the car at the limit / from going full throttle
  
• Corner exit reference point constellation is reached
  
• AI's next target is now "rough brakepoint" of next corner
  
• Repeat
  

Of course there might be intermediate navigation points put somewhere to guide the car around the track for slight bends that don't require braking.

However, nowhere do you really need the tyre state itself - keeping it at the limit would work like:

• Apex reached, AI wants to go full throttle
  
• Grip sensor reports 6° slip angle and 2% slip ratio, so the tyre can't really give much more, throttle reduced to 25%
  
• time passes, AI wants to go full throttle
  
• Grip sensor reports 4° slip angle and 2% slip ratio, throttle reduced to 33%
  
• time passes, AI wants to go full throttle
  
• Grip sensor reports 3° slip angle and 3% slip ratio, throttle reduced to 50%
  
• time passes, AI wants to go full throttle
  
• Grip sensor reports 3° slip angle and 5% slip ratio, throttle reduced to 75%
  
• time passes, AI wants to go full throttle
  
• Grip sensor reports 6° slip angle and 10% slip ratio, the last throttle input was too much, too soon, throttle reduced to 50%
  
• ...
  

The throttle reduction could then be restrained further by also looking at the past actions and restricting the maximum throttle delta so it can't go to 100% immediately, even if it wanted.
So by knowing the current slip angles you can prevent the throttle from being unreasonably high (that's the "guess" you do on how much throttle can be applied on a certain slip angle/ratio without going overboard), while at the same time you can keep learning by increasing or reducing the guessed value depending on how often you overstepped your limit (which is passing a certain threshold value of slip angle/ratio that causes a little more aggressive fix-the-situation action to be taken).

Now I just hope that made at least some sense

Nope, it just gives you what the car gauges show (hence the name).

^ The problem is that we don't have the information of "wheel speed." Please have a look at the OutSim/OutGauge documentation so you know what information we can actually access


@blackbird:
Now maybe that's a stupid question, but do you really need that information? I mean, is your AI model already that set in stone that it actually requires the per-wheel grip state (even if it's just three possible states per wheel)?

The only real problem I can see is the one of wheel lockup under braking, but other than that the information available from OutSim and OutGauge should be enough to get the AI moving around a track trying to follow a line, just from a "my car points here but I want it to go there" point of view. If you really need it you could infer the tyre grip limit state from the current slip angle/ratio of a tyre that you can calculate from the car heading vs. velocity vector, steering angle and speedo vs. actual speed ratio. You basically "know" how much traction a tyre can provide (if not you simply measure it - externally) and the LFS<>AI interface then has to "guess" the tyre state by sort-of doing a mini tyre simulation.
Or wait, why not simply take the acceleration? The acceleration lets you calculate how much work the tyres do in total (vs speed and mass of the car), and the current car heading / steering lets you split up this total to the tyres with a bit of math magic. Then you just need to compare the (estimated) work done by the tyre to what you think it can do at max and set the state accordingly (though of course you'll never go beyond max to give you a definite "over limit" state). Or so. Well, I dunno, it's late, I should go to bed.

It's not about VB or C++, it's about knowing programming. The language just dictates the syntax - a good programmer can learn pretty much any programming language with little effort if he wants to. In the end it's all the same thing anyway, just with different comfort levels and gotchas.

VB is probably a good starting point for a newcomer as it's pretty easy to read and doesn't put all that many pitfalls in your way. If you want to do programming as more than a occasional hobby though, realise that the main goal should not be to learn language X, but to use language X as a tool to learn programming. Once you get a feel for how stuff works in the computer world, grasping the programming concepts gets much easier. Your remark "i thought you were tearing into lfs itself" shows that there still might be quite a way ahead of you, though . You can't just "tear into" LFS and access variables like you imagine, since that would require the actual source code. If you wanted to do that without the source code, the only way would be modifying the assembler code directly, but this is already very VERY low level stuff and doing anything more than changing some values in memory (like car horsepower) or skipping/redirecting function calls (most commonly used for skipping those nasty copy protection checks) would turn out rather complicated and daunting for even the simplest things.

Ok, enough off topic, back to AI.

Good god, you have no idea

There is no way to just detect when a sound file was played. All you got is the end result, the audio stream generated by LFS that is a combination of various potentially heavily distorted or completely artificial sound bits. Good luck matching the output to one specific sound file.

It's normal, and you can't really do anything about it.

That's why I said if it's a renaming issue, not overwrite issue.

If it's just a renaming issue then this the last modified date probably won't help.

Quote from yeager :

Of course I was in serious denial if I thought my comments would pass by without another thread decaying into debate.

So you're a troll then?


Nah, just kidding . I agree with you, but looking back at LFS history then it's clear regular status updates won't happen. They have been requested in various forms numerous times over the past years, but the devs apparently don't want to spend half a day a month to squeeze out a little story to keep the community in check.

I do kinda understand the problems such updates can bring, considering how almost anything they say is taken as pure gospel and promises. Even now where they already seem to go to ridiculous lengths to formulate anything they write in a way that makes it clear that nothing is set in stone, people often misunderstand, misread or completely ignore what is written and later cause a ruckus demanding to know why X wasn't Y even though the update clearly states why X isn't Y.

Still, I think regular updates would be the way to go, and instead of trying to untangle the mess that misunderstandings cause themselves, they could just wait and let the community members that are able to read and comprehend do the job for them.

But then again, what do I know about customer relationships, so there.

Yes, that's what I meant with "no foolproof solution." In theory the locked tyres produce a little less than maximum braking force, but that seems far too unreliable to depend on. Apart from the countless external factors, what if the car setup is simply too front biased, for example? Sure the fronts lock up, but the increase in brake strength also makes the rears work more, counteracting the traction loss of the fronts.

You know what, just stick to ABS enabled cars

I thought about this a bit yesterday and while the speedo-vs.-real-speed ratio = wheel slip was pretty obvious to figure out, detecting when wheels are locked is not. I can't really think of a foolproof solution to that at the moment

Maybe as a start it's enough to just assume that straightline braking will never lock up the wheels (set tuned so it doesn't happen) and any other lockup scenarios would be handled by detecting and alleviating "understeer during braking" situations.

Also a word on the wheel slip mentioned above, note that the speedo "lags" a bit, so while accelerating you'll detect a few % negative slip (actual speed faster than speedo), while decelerating will push it a bit into the positive slip region (actual speed slower than speedo). But if you account for that it can work quite well at detecting the slip ratio of the driven wheels

The main problem is usually that the areas in LFS are too small to hold the layout, though you might get lucky if the shape fits or the layout is small enough to begin with.

How do you plan to record the GPS data? Walk once along the inner, then along the outer side of the track? Does it even have an inner and outer side, or is it just cones placed at some points?

You could PM David 09 and offer to be his personal translator before he creates yet another thread that requires a linguistics degree to decipher what it's about