That's a realism feature. In a real car the bitepoint of the clutch is not directly at the back of the fully depressed pedal but only after you release it a bit further, depending on how much the clutch is worn, too.

LFS simulates this by making the clutch 100% engaged at about 66% pedal travel.

Quote from menantoll :

Are you really that insecure in your own abilities that you want beginners not to be given a helping hand?

Quote from thisnameistaken :

Yes.

See that XRT in his avatar? It took him weeks to go long enough in a straight line without crashing to record that.

Countdown till this time gets beaten just to spite him, starting... now!

Also the big-ass impact that should've made this HLVC-invalid didn't look very nice.

The '4' line is definitely not wrong, generally speaking. It is meant as a tool to show newcomers what a racing line is, and how a good baseline looks on a specific track. It might seem inconceivable to a seasoned racer, but yes, people not familiar with motor racing tend to not know even such basic things as the ideal line. Sure, if you want to get competitive, that line is useless, but that line was not meant for replicating WRs in the first place.

Once you plan on doing online races, you shouldn't have to rely on this line at all. If you're still confused / not clear about how this basic principle of racing works then you're not fit for online competition, to put quite bluntly.

Does anyone know how to make it not have reversed force feedback on a G25?

It's one thing to model tyre flex, it's another to actually graphically display it. "Modelling it" also does not make a qualitative statement, so for all we know it could be a very simple or very advanced model.

S1 didn't have keys. It always used the same unlock system as it used now. The only difference back then was that the masterserver IP was hardcoded, which is why old versions cannot be unlocked anymore.

Quote :

Ok guys, for those that are interested which a few obviously are but not as many as I was thinking

Maybe the problem is that you started this thread too early. Personally I'm more interested in actual technical aspects (that you haven't worked out yet), not so much in the "general public" riff-raff.

So far all that was stated were a few quite obvious 'faults' of current AI implementations (half of which don't even apply to LFS) and your announcement that you want to use reference points instead of cheating to make the AI go round, all still very theoretical. I'd have preferred if you would've had at least a rudimentary look at the technical side of things before posting this, but oh well, let's see what you can come up with.

That you don't want to use LFS as tool for this is also kind of a bummer, since it would've given this project a little bit more... substance, though that might not be the word I'm looking for.


From a purely technical aspect I'd have to admit your choice of programming language would actually be the biggest hindrance for me. I guess with some effort I could start finding my way around C++ again, but alas, I am lazy and C# makes many basic and not so basic things a lot easier to deal with. AI programming / maths is hard enough, I'd rather not struggle with the language, too.

Quote from blackbird04217 :

Umm I missed a post earlier, just before tristancliffe's first. And it wouldn't work: I don't have line of site using the LFS data... There are hills and cars. The cars I could kinda work in.

But you can easily extrapolate that data from the track points you have (and you kinda have to have them). It would probably the job of the LFS <> AI interface to do this Z-culling for you, though. Just use each of the two opposing track points as height reference and you can work out the track contours from that. Not 100% accurate but in practice you're not going to encounter weird hills that obscure some points but not others all too often.

Quote :

But it was the last comment on reading the sound data of the tires that got me. You write me some code that opens the mic, records LFS at that moment in time, processes the data and gives me a value stating: UNDER LIMIT, NEAR LIMIT, AT LIMIT and OVER LIMIT from that : / Cause that's scary to me trying to get that info from LFS.

The remark about using actual sound output was just a jab at just how generic and realistic you want to go with this. What I'd actually do is read the tyre loads / slip angles / slip ratios and guess from there what sound the tyres would make, i.e. I give you a value of loudness and pitch. Your AI then decides from learned experience what values correspond to what "X LIMIT."

Quote :

I don't see how sharing it would be a benifit to anyone though as it wouldn't contol an AI driver.

How so? Set up a separate PC with the AI that joins you in a LAN game. Whoop, there is your "AI" driver.

Quote from blackbird04217 :

Its the programming side that is gonna make me wonder about following through.

You know, this might actually be where we differ. From that comment it seems you're thinking about this whole idea very abstractly, more from a conceptual point of view, whereas I tend to slip directly to concrete programmatic solutions (not saying that either is better, just that we apparently tackle this topic from a different point of view).

Last edited by AndroidXP, Thu, 3 Dec 2009 17:46.

Oh of course you do. But you also plot a certain line on the track that you know (from experience) is the best line to follow (Quote: "[...] distance from my line [...]"). By that I don't mean you visually imagine the ideal line as if you pressed '4' in LFS, but you subconsciously know this line and you follow it lap after lap to the best of your capabilities. Since you can't just visually plot the line with colours indicating when to brake/accelerate, you use reference points on the track to give you hints when to do what (brake, turn in, etc.). Extensive experience also lets you drive the track when you're off the line (due to an obstacle or driving error) and you know from the learned car behaviour what the most efficient path to return to the line is.

So you do have an internal line you know to follow, why can't the AI have one? If you do give the AI this line (since a human has it in his mind) then all you use the reference points for is storing the data of when to engage what input to make the car follow that line. Storing that abstractly as "start braking as soon as the cone leaves my field of view" or "the data on my ideal line says start braking now" is just substituting one way to encode data for another.

Heh, curing the cause. The symptom: the AI does not behave human. The cause: the AI is not human. The cure: make the AI human.

Making the AI behave more human-like by changing the way it acquires input is still curing the symptoms, not the cause.

Having access to abstract things like reference points of various natures is still "cheating," just a different form of cheating.

Quote from blackbird04217 :

On the LFS stuff. I could get the left side, right side info with almost as much work as making a quick environment myself I think.

Then you have your environment, but no physics, track or whatever that you can actually test your stuff on. Collecting these data points, however that is achieved, is also a really tiny amount of work compared to figuring out even the simplest algorithms for the AI to use and writing your own graphics/physics engine.

Using LFS also has the added benefit that if you succeed, you can share your AI as a program for others to actually use, even if it's not perfect.

Quote :

But I would be missing the important reference points of cones, and other trackside things like the billboard. It's hard to say what I mean, but I think these other reference points are more important then the track.

Then just place these reference points on your virtual map manually? It's just like overlaying a paper on the LFS track and manually marking wherever points of interest are. You don't have to actually have access to the polygons of the track to use certain objects as reference points which would require a completely own engine tailored for exactly this and going kinda beyond the presumingly abstract nature of your AI.

Quote :

It's also extremely important to know I want a line of sight on the reference points.

So? That's in no contradiction to what I suggest in regards to using LFS.

From my understanding you'd write:

The AI
- Has a field of view containing various reference points of whatever nature
- Has any additional input you see fit to use (speed, rpm, tyre sound - stuff you can see on the dashboard or hear)
- Has lots of complicated algorithms making sense of the reference points it sees
- Has a memory to store experiences ("no, braking 10m in front of the cone is not enough to make the corner!")

The LFS <> AI interface
- Has the virtual track map with all reference points (of whatever nature) stored in the LFS coordinate system
- Has an InSim component that gets the current car position on the virtual track map
- Uses the current car position, direction vector and field of view to compute what reference points are visible to The AI and feeds it this data in an abstract form (a "cone" is visible 10 metres ahead, 15° left and 6° down)
- Has an OutSim component that feeds the AI any additional info
- Has a rudimentary sound emulator to figure out what sounds the tyres would make at the moment (or actually intercept and analyse sound output?) to send to The AI. This is no harder than if you have to write your own physics engine/environment.


If you do it like that, then your AI is completely independent of what simulator you use, provided the physics are sufficiently similar (kinda the point when you want to make a realistic sim) and that you can write an interface that can feed the required data to your AI.

Quote from blackbird04217 :

Because I don't have the much needed reference points, and if I made them it would take tons of time - for what I am trying to achieve. I believe you can send commands to set an axis position, though I could be wrong. Either way, LFS would be a great platform tool to use, I wish Scawen would open a few possibilities to me, but it won't happen for security reasons.

What exactly are you missing? Again, assuming you use the same coordinate system as LFS:

1. Drive along the track outline and let your program automatically place track markers (your virtual marker consisting of a single coordinate on your virtual track map) every time you pass a track node. Do this for the outer and inner path of the track and you have your track marker cloud.
   
2. Make a simple InSim button interface that lets you spawn brake points, "go there" vector zones, etc. on the current position & direction. You do all this on your virtual track map so you don't need anything from LFS/InSim other than the current coordinate/vector.

Once you have this you use InSim to get your current position. You don't have to let the AI know this position, but just use it to calculate from your track map what reference points the AI is able to see. From there on you can do all your fancy abstract algorithms to figure out the rest. This is all the input your AI needs, as far as I understood (reference points at different places in the virtual field of view of the AI).

Quote from blackbird04217 :

Have you watch the super 'judgment' of an AI in LFS or 90% of the games? They turn-in, brake and accelerate at the same spots on the track, not making a mistake - (until you enter traffic which is not being talked about yet so irrelevant here).

Yes, but that's just the missing sensible application of Math.Random(). Once you have an AI that can perfectly follow a line to the best capabilities of the car, there is nothing hindering you from making that line less than perfect.

Using limited input and inaccurate knowledge to make the AI drive less than perfect just seems so... complicated for achieving a simple effect.

Quote from durbster :

I disagree. Best way is to accelerate as you arrive at the bump to lift the nose a bit. You can exaggerate this if you brake first too

But what's the benefit of that? Sure, your suspension might experience a slightly less sharp impact, but your passengers will have the added "fun" of sudden longitudinal de- and acceleration in addition to the bump. A constant speed seems to be far more sensible provided the speed bump design allows it (if they're too steep then you obviously have to slow down).

But what is "the same" input? You have to define what level of input you're talking about.

Input:
- I'm oversteering.
or
- The visually perceived angular momentum of the car is greater than anticipated from prior experience given my current input, combined with a weakened/reversed force feedback that is a result of the suspension geometry and aligning torque of the front wheels when the car points in a different direction than the direction of travel, combined with the increasing loudness and pitch of the sound that the tyres generate due to micro-vibrations of the rubber sliding and hopping on the track surface.


The former is the simple input that you, or your consciousness receives (if at all - when "in the zone" you tend to short-circuit your consciousness anyway and let the completely automatic subconscious do the driving), the latter is roughly the more deep-level input your subconscious uses to figure out the former in a sim environment.

Just to what level of "only human input" do you want to go, and, does it make sense or any difference in going to that level?

If all you want the AI to know is "you're oversteering," then there's no difference whether you come to that conclusion by doing it the complicated way of analysing how he track markers move related to how they should move, etc. or simply asking InSim what the car vector is in relation to the movement vector. One way just uses significantly more CPU cycles.

Somewhere you have to draw the line between simply knowing things and simulating the complex functioning of a human brain. As a driver I know where I am on the track, without consciously triangulating my position from known reference points all the time.

If you implement it like that, all you get is
1) a lot of wasted CPU time
2) an accurate position of your car
3) ??? some mystical benefit from calculating the position in a roundabout way

All you're going to use that "cheated" position would be to place it on your virtual track marker map, that will, as blackbird described, already consist of track bounds and "turn here" vector zones and whatever. These markers are also cheating if you put it like that. Why not make a visual recognition of what the track is? What a corner is? Why slowing down and turning the wheel will help you traverse this corner? You can go even more and more more basic and abstract until you end up with an AI that 100% simulates a human brain. I very much doubt this is the goal of this project

Anyway, this cheated position inside the cloud of track markers would then only be used to compute what track markers you can see, where they are in relation to your position and how to react to this information. In my opinion this is just an inefficient way to calculate a line through the corner that if you think is too perfect could alter with some Math.Random() here and there to get the same net outcome, but that's blackbird's decision

Quote from blackbird04217 :

• Catchup;
  
• AI Controlled Physics;
  

Thankfully these aren't the case with LFS anyway

Quote :

• AI Super Control;

A symptom of this is for example AI drivers that are hard to ram or spin out, since they'll immediately do the necessary counter steering as you hit them. However, that seems like just a matter of implementing proper AI handicaps and reaction times - hardly anything you need to write a whole new AI concept for.


That said, if you're still in search for a platform, why not use LFS? Of course, maybe that is too complex to deal with from the physics aspect, but it would already give you everything you need for this project.

1. Graphics / physics engine
   
2. Tracks & cars
   
3. InSim & OutGauge
   

The only thing you'd likely have to additionally invent is a virtual device that can emulate analogue steering, throttle, brake and clutch input. In worst case you could facilitate the mouse-steering mode in LFS, since manipulating the mouse cursor and emitting button clicks or key presses is easier from my experience.

Via InSim you can then get the actual position of the car (and whatever else variables you need and deem 'fair' to use) and map this to your internal track markers, using the same coordinate system LFS uses. Together with OutGauge (mainly used for "what does the RPM gauge say?") there's nothing hindering you from writing an add-on AI that can only use limited input.

Except that would yield worse results than just jamming the throttle with a stick and letting the force feedback do the steering.

Quote from logitekg25 :

i right clicked on it and said scan, and everyone seems to recomend it....except for people here

No it's just Shadow³ saying that. For reference I also have Avast, to put the "mine doesn't find anything" into contrast.

Mine doesn't find anything?

Of course, if you already had a trojan/virus before that, they do like to replicate themselves into other files/executables, so...

I kinda see what you're trying to do, but what's the point of it? It seems like an exercise that is doomed to fail. How is restricting the AI's input going to result in a more realistic (i.e., more human-like) AI?

Inducing driving errors by only giving the AI vague input will IMHO just result in an AI that can at best inconsistently traverse the track at not even close to competitive speeds, having increasingly worse performance the more abstract you make the calculations and the less you "cheat" by using existing data. So if you want to realistically simulate what a newbie driver is going to do you might have success with that, but if even achieving fast laptimes is going to be a major conceptual problem (that you seem to brush away very easily with the assumption the AI will be able to drive at the physical limit), just how are you going to create a realistic AI?

What is your goal with this? A mental exercise? Exploring AI concepts? Because it's surely not a realistically driving AI. My definition of that would be an AI that you could put in place of a human driver without anyone noticing for a good amount of time. Achieving that is extremely difficult. Artificially limiting your data input is not going to make that easier, more efficient or convincing than other concepts.

Or do you want to write an AI that manages to traverse a track with only the same input a human gets? Okay, wait, maybe I have misunderstood you and that is indeed what you're trying to do (re-reading your OP as I write this seems to indicate this)? If so then ignore half of what I said . I wish you good luck even though I still don't quite understand why you're doing this.


E: I see you posted in the meantime making things a bit more clear

Quote from anttt69 :

tbh i wouldn't recommend coming into ice cream.

Quote from AlienT. :

Are you ok there Ant? Just feeling a bit random at the moment mate?

It's probably sleep deprivation.

Quote from anttt69 :

Anyone know what the file mysleep.exe is in my iRacing folder?

Thank god iRacing found his missing sleep.

Just as info, for calibration alone it's often sufficient to turn the wheel fully in each direction to make LFS recognise the full available range.

You're not missing anything.

Just gave it another spin with the drift car and... gosh that's bad. I mean really bad. Seems like the tyres have been magically enchanted to lose most friction as soon as they're sliding sideways.

There is neither a Skyline nor a AE86 in LFS

To get your wheel working, first set it up like this:

1) http://en.lfsmanual.net/wiki/W ... tting_up_a_Logitech_Wheel

Then follow these steps for the ingame setup:

2) http://en.lfsmanual.net/wiki/Options#Setting_up_the_wheel