Hmm. I should probably do some reading on NN's then, I've heard of them including mentioned once already in this thread; though my objective is not for an AI that 'learns'. Teaching the AI is not the idea here, and I don't see it fitting very well, however where you say that very human like output is achieved than I should at least give it a read over. Hopefully if it is useful it fits into the design of my AI already since I've spent some time on that.
Update: The AI now has true access to the gauge sensor. When waiting at the grid it will shift up into first, and step on the throttle. Also, it can now stay at a steady speed; which I have down to 10mph since I shouldn't exceed any limits there and not need to worry about 'driving at the limit'. So now the next step is to get the physical sensor and visual sensor to work for the driver to drive to a destination; and then it will be down to making a layout around FE1 so that I can try getting a car to drive around the track.
Update: The AI now has true access to the gauge sensor. When waiting at the grid it will shift up into first, and step on the throttle. Also, it can now stay at a steady speed; which I have down to 10mph since I shouldn't exceed any limits there and not need to worry about 'driving at the limit'. So now the next step is to get the physical sensor and visual sensor to work for the driver to drive to a destination; and then it will be down to making a layout around FE1 so that I can try getting a car to drive around the track.
Hmm, you bring up a good point about the hills, though my AI (as of now) is developed with little to no current information about hills in LFS. Think of it as flattening the track and just knowing where you should be - this could bring up issues in the future; bridges and other things, but I think it may be negligible for now.
Well Android you certainly brought up an area I hadn't been able to think of, though I don't know how one would go about implementing this. Really if it could be implemented it could _possibly_ give me some 'idea' of the tire states that I am looking for although I see some issues with attempting to implement this;
First we don't know wheel speed; although like you stated for driven wheels we can take a delayed guess since speedometer has built in delay. This could have an effect where the AI is driving along, hitting the throttle just fine and then thinks "I'm spinning my drive wheels" even though the issue has either been re corrected already or traction was gained.
Time 0; Car starts accelerating from 0 mph. (Throttle Input: 100%)
Time passes: Car hits some grass while accelerating causing excessive wheel spin. (Throttle Input: !00%)
Time passes: Car gets back on tarmac and wheel spin is sorted out. (Throttle Input: 100%)
Time passes: A sensor detects the wheel speed is greater than the car speed. The AI uses this to reduce throttle input. (Throttle Input 70%)
Time passes: Eventually the sensor tells the AI everything matches great. (Throttle Input: 100%)
So in this example the AI behaves a little wonky when it hits a small patch of grass. Off the top of my head I can't think of many other places where this comes into play, although I have a feeling more often than not the delayed speedometer reading would bite me. There would need to be information in the GripSensor that shouldn't be there; how much throttle/braking is going on. This would need to be there so the GripSensor can report accurately depending on slowing down/speeding up since the speedometer is delayed.
-----------------
This said, I might be getting ahead of myself. First thing that is required is to get the AI to go around the track. I wish I hadn't messed up my copy of LFS right now, as I want to run a test in the XFG to see what is the 'optimum' speed to drive Fernbay Club - WITHOUT going over the limits. Which is to say, what speed would you only need steering input and never need to worry about hitting the brakes? Once a car goes around a track successfully I think the project will stand in a much different position; because even then I can start adding my tests by reference points.
First we don't know wheel speed; although like you stated for driven wheels we can take a delayed guess since speedometer has built in delay. This could have an effect where the AI is driving along, hitting the throttle just fine and then thinks "I'm spinning my drive wheels" even though the issue has either been re corrected already or traction was gained.
Time 0; Car starts accelerating from 0 mph. (Throttle Input: 100%)
Time passes: Car hits some grass while accelerating causing excessive wheel spin. (Throttle Input: !00%)
Time passes: Car gets back on tarmac and wheel spin is sorted out. (Throttle Input: 100%)
Time passes: A sensor detects the wheel speed is greater than the car speed. The AI uses this to reduce throttle input. (Throttle Input 70%)
Time passes: Eventually the sensor tells the AI everything matches great. (Throttle Input: 100%)
So in this example the AI behaves a little wonky when it hits a small patch of grass. Off the top of my head I can't think of many other places where this comes into play, although I have a feeling more often than not the delayed speedometer reading would bite me. There would need to be information in the GripSensor that shouldn't be there; how much throttle/braking is going on. This would need to be there so the GripSensor can report accurately depending on slowing down/speeding up since the speedometer is delayed.
-----------------
This said, I might be getting ahead of myself. First thing that is required is to get the AI to go around the track. I wish I hadn't messed up my copy of LFS right now, as I want to run a test in the XFG to see what is the 'optimum' speed to drive Fernbay Club - WITHOUT going over the limits. Which is to say, what speed would you only need steering input and never need to worry about hitting the brakes? Once a car goes around a track successfully I think the project will stand in a much different position; because even then I can start adding my tests by reference points.
Yes the state tracking is a lot more memory and less flexible, which is why I was asking, that way if you were planning that route I'd have have given you a hint; of course assuming it was still early enough to do so. But looks like you have the more flexible way to do it already, and that is nice.
FlameCZE - NICE! Very nice. Thanks much.
FlameCZE - NICE! Very nice. Thanks much.
I was going to say that even automatic transmissions still have Neutral. And I know my first car (auto, unfortunately and I won't go back to one), you could even slam it from drive into park; passing through both neutral and reverse to do so. And when this happens the wheels lock up and STOP. I haven't been in this type of situation, though I've had my clutch pedal stick before and pop back up with small delay. But like stated, you can't do much in a panic state of mind; that said, how do you have time to make a 911 call and not think more clearly about the situation at hand?
It's hard to think that a cop, with any sort of vehicle training, would panic under such situations. And a half a mile is at least 15 seconds at 120mph, I don't know how long it takes for the car to stop but that call was certainly long enough to have thought of other ideas; especially when the operator mentioned the ignition. (Keyless or not I do believe there is a big "stop" button, though I don't know if it would help with much as the car has enough momentum to keep the engine firing.) I don't know, sad to see people lose lives, but it needs to happen; the population of 8billion (or whatever it is) is not effected if 25 people die. Sure the emotions of those friends and families are effected, but people die every day. It is a fact of life that will not go away; life == death.
EDIT: And where as it is "sad" that people lose their lives like this it is far more sad that the media points fingers, lawsuits fly and statements like Toyota knew this was a problem for two years and could have saved these people. Stating like it is Toyota's fault. That is sad.
It's hard to think that a cop, with any sort of vehicle training, would panic under such situations. And a half a mile is at least 15 seconds at 120mph, I don't know how long it takes for the car to stop but that call was certainly long enough to have thought of other ideas; especially when the operator mentioned the ignition. (Keyless or not I do believe there is a big "stop" button, though I don't know if it would help with much as the car has enough momentum to keep the engine firing.) I don't know, sad to see people lose lives, but it needs to happen; the population of 8billion (or whatever it is) is not effected if 25 people die. Sure the emotions of those friends and families are effected, but people die every day. It is a fact of life that will not go away; life == death.
EDIT: And where as it is "sad" that people lose their lives like this it is far more sad that the media points fingers, lawsuits fly and statements like Toyota knew this was a problem for two years and could have saved these people. Stating like it is Toyota's fault. That is sad.
Last edited by blackbird04217, .
@AndroidXP: I do believe that the AI need to know that information about each of the tires, as that is the information that keeps the AI driving at the limit and handling what happens when the AI is over the limit. This I think is key to getting the AI to be fast without knowing the exact physical constraints; although I will likely be proven wrong.
As far as getting the AI to drive around the track at 10mph, I am pretty sure this information it not required. And for braking, like you mentioned earlier just use cars with ABS systems for now, or even turn the brake aid on in LFS. However, that doesn't help when dealing with wheel spin like my current LX6 issue, and again back to my previous point about cornering at the limit. As far as only having four values; UNDER, NEAR, AT and OVER_LIMIT I think that it might need more; certainly not less; however this may be debatable at another time, since it might be important to know the actual percentage of the limit that the tire is at; example 0-100% 0-80% = Under Limit 80-95% = Near Limit, 95-100 = At Limit and > 100% is Over Limit.
@logitekg25: Yea, no wheel speed available; I am out of ideas at this moment but I am sure something will come up. As said to AndroidXP, if I wanted to have the car aim for a speed of ~10 to 15mph I believe I could get it to navigate a track, however that is obviously not very competitive...
On the otherhand, if a set was made that limited a car to drive 15mph because of gearing then it might be quite interesting, and thus competitive in a very _slow_ way. (Let the driver with the shortest overall line win).
As far as getting the AI to drive around the track at 10mph, I am pretty sure this information it not required. And for braking, like you mentioned earlier just use cars with ABS systems for now, or even turn the brake aid on in LFS. However, that doesn't help when dealing with wheel spin like my current LX6 issue, and again back to my previous point about cornering at the limit. As far as only having four values; UNDER, NEAR, AT and OVER_LIMIT I think that it might need more; certainly not less; however this may be debatable at another time, since it might be important to know the actual percentage of the limit that the tire is at; example 0-100% 0-80% = Under Limit 80-95% = Near Limit, 95-100 = At Limit and > 100% is Over Limit.
@logitekg25: Yea, no wheel speed available; I am out of ideas at this moment but I am sure something will come up. As said to AndroidXP, if I wanted to have the car aim for a speed of ~10 to 15mph I believe I could get it to navigate a track, however that is obviously not very competitive...
On the otherhand, if a set was made that limited a car to drive 15mph because of gearing then it might be quite interesting, and thus competitive in a very _slow_ way. (Let the driver with the shortest overall line win).
Even in Visual Basic you wouldn't be able to do that. I understood all the logic you were coming from, and that sndskid was used as an example as well. The only way this would work is if you had the source to the project, and could access the sound directly; regardless of syntax/language issues.
So your teacher was able to do this because he had some sort of Object named sndskid. At anytime in the code with that object you could check: if sndskid.isEnabled() then doSomething(); But since I don't, and won't ever have the LFS source code, then I can not detect their sound objects, and test in that sense.
It was worth mentioning, but hopefully you now understand how it works and its limitation.
----------------------
Back on topic; can anyone think of a way using position, direction, heading and angular velocity to detect _which_ tires are UNDER, NEAR, AT or OVER_LIMIT?? I don't think this is even possible, though I am still trying to get outside the box. Perhaps there is other bits of information that LFS has. Android and I have discussed oversteer/understeer using these, and in those specific cases it would be as simple as detecting oversteer and setting both rear tires to OVER_LIMIT. (Vice versa for understeer). However there are situations, like hard braking/accelerating, where the car is not understeering/oversteering but the tires are OVER_LIMIT and this (as of now) is what I am trying to detect using what LFS gives me; and as pointed out by both Android and myself, it may not have fool-proof solution.
EDIT2: If anyone does find a reasonable way I will be paying close attention here, and if shared would be extremely happy. Even if the code is in another language as long as I can understand what math is going on, and the theory behind it I would be willing to try it!
EDIT: Well said AndroidXP.
So your teacher was able to do this because he had some sort of Object named sndskid. At anytime in the code with that object you could check: if sndskid.isEnabled() then doSomething(); But since I don't, and won't ever have the LFS source code, then I can not detect their sound objects, and test in that sense.
It was worth mentioning, but hopefully you now understand how it works and its limitation.
----------------------
Back on topic; can anyone think of a way using position, direction, heading and angular velocity to detect _which_ tires are UNDER, NEAR, AT or OVER_LIMIT?? I don't think this is even possible, though I am still trying to get outside the box. Perhaps there is other bits of information that LFS has. Android and I have discussed oversteer/understeer using these, and in those specific cases it would be as simple as detecting oversteer and setting both rear tires to OVER_LIMIT. (Vice versa for understeer). However there are situations, like hard braking/accelerating, where the car is not understeering/oversteering but the tires are OVER_LIMIT and this (as of now) is what I am trying to detect using what LFS gives me; and as pointed out by both Android and myself, it may not have fool-proof solution.
EDIT2: If anyone does find a reasonable way I will be paying close attention here, and if shared would be extremely happy. Even if the code is in another language as long as I can understand what math is going on, and the theory behind it I would be willing to try it!
EDIT: Well said AndroidXP.
Last edited by blackbird04217, .
I don't have "sndskid" to check if it is enabled or not. I can't magically do things with sounds. Where as you are new to programming let this be a quick lesson you will learn shortly; you can only work within X constraints; not X+1. Meaning that I can only do so much with LFS, I am limited to InSim, OutSim, and OutGauge for detection of RaceRestarts, CarPosition, etc... I am limited by a layout file to read information for my reference points etc, and also limited by PPJoy for the virtual controller.
While I am making my AI work within tight limits, using LFS does tighten the limits a bit more; though it is worth continuing to try because of the physical accuracy in LFS and the potential. That said, sound processing as you are requesting would need to be done more like the following;
Get sound input from lineout or something that records the speaker output. Kinda like a microphone, but a different channel.
Use this raw sound data, and compare, using some tricky algorithm, to that of a skid sound, to detect which tire(s) and how much skidding is going on.
Then hand the AI that value through it's physical sensor; a value that a physics system could tell me. One that I can't currently get from LFS, although I am hoping to find a way to fake it well enough with the information LFS does give me.
While I am making my AI work within tight limits, using LFS does tighten the limits a bit more; though it is worth continuing to try because of the physical accuracy in LFS and the potential. That said, sound processing as you are requesting would need to be done more like the following;
Get sound input from lineout or something that records the speaker output. Kinda like a microphone, but a different channel.
Use this raw sound data, and compare, using some tricky algorithm, to that of a skid sound, to detect which tire(s) and how much skidding is going on.
Then hand the AI that value through it's physical sensor; a value that a physics system could tell me. One that I can't currently get from LFS, although I am hoping to find a way to fake it well enough with the information LFS does give me.
Yes I am completely sure I do not want to code something that detects sounds and then processes the sound to see if it is a tire squeal, if so which tire and how much grip is lost. A simple number from the physics department can go a long ways; and still keep it within the limits of my project.
Example; Why make this sound processor to detect engine speed, when the RPM value is easily given and available? Just use the value, perhaps add some inaccuracy as described above and the AI seems to 'hear' the engine even when the value comes from the car. The point of this project is not to work on sound processing and/or image processing.
Example; Why make this sound processor to detect engine speed, when the RPM value is easily given and available? Just use the value, perhaps add some inaccuracy as described above and the AI seems to 'hear' the engine even when the value comes from the car. The point of this project is not to work on sound processing and/or image processing.
No problem about the misunderstanding, especially since it is now understood! But I think now you see how using LFS is limiting to me in ways that I don't want it to be.
As for "Beginner" to "Pro" difficulty range I think that will be tweaked by changing the accuracy of the drivers estimations. Of course, this assumes I can even achieve some competitive level of driving, which as said; I have my doubts - but certainly have my hopes as well.
As for "Beginner" to "Pro" difficulty range I think that will be tweaked by changing the accuracy of the drivers estimations. Of course, this assumes I can even achieve some competitive level of driving, which as said; I have my doubts - but certainly have my hopes as well.
The thing is that the AI needs to get some information from the physical side, no matter how you look at it. As said I do not want to get exact values; but most importantly I do not want the AI to "physically move or control the car". That is my objective in detaching the AI from physics. There are things that must come from the physics side of a game/simulator in order to make the AI in the first place; being the amount of traction at each tire, the current position and orientation of the car. The cars velocity and angular rotation as well. All these physical things make up the "AIPhysicalSensor" which will tell the AIDriver what is currently happening to the car.
Like stated, I am not aiming to make sound detection, image processors or anything obscure - just taking a different approach on how racing AI is done, and I am aiming this approach at AI in Simulations vs AI in Games. Big difference as we know. The AI in games needs to be fun for the player, while the AI in the simulation does not aim to be fun to drive with. (If it is actually competitive for someone than GREAT but I don't have my hopes that high yet, especially for the LFS side of this that has been started.
EDIT: About the RPM and the sensors for the car information, this isn't to simulate a beginner vs experienced racer. The RPM from the GaugeSensor could be exactly as our ears are. Since it could have an inaccuracy to it +/- 200 RPM I would guess. (That is a range/accuracy of within 400rpm from hearing, while the driver could also look and get a better reading. Before I start adding a lot of inaccuracy to the project, I first need to get the AI to successfully navigate a track; even if they stay well below the limits.
Like stated, I am not aiming to make sound detection, image processors or anything obscure - just taking a different approach on how racing AI is done, and I am aiming this approach at AI in Simulations vs AI in Games. Big difference as we know. The AI in games needs to be fun for the player, while the AI in the simulation does not aim to be fun to drive with. (If it is actually competitive for someone than GREAT but I don't have my hopes that high yet, especially for the LFS side of this that has been started.
EDIT: About the RPM and the sensors for the car information, this isn't to simulate a beginner vs experienced racer. The RPM from the GaugeSensor could be exactly as our ears are. Since it could have an inaccuracy to it +/- 200 RPM I would guess. (That is a range/accuracy of within 400rpm from hearing, while the driver could also look and get a better reading. Before I start adding a lot of inaccuracy to the project, I first need to get the AI to successfully navigate a track; even if they stay well below the limits.
Last edited by blackbird04217, .
Thanks for the very kind offer, but I have a feeling it won't help my AI too much :P The values are what I am after. That sounds great, adding undo support for an editor _really_ helps the editing process! (Are you using a chain of commands to support undo/redo? or just keeping track of the last state and undo'ing to that state?)
Oh right, I remember reading that. Nice nice. Well I think we can all work together to find the object IDs of the common objects and make a big table of them for future use. I am not to this point in my project yet though I will of course be willing to pitch in on finding IDs because that seems like it will be a bit of a pain since the only way I can think of doing it (accurately) would be placing one object in a layout, reading the layout and matching the ID.
EDIT: Sorry for derailing the LYTe - Layout Editor thread. Please let the ObjectID discussion happen elsewhere since it isn't the objective of the layout editor.
EDIT: Sorry for derailing the LYTe - Layout Editor thread. Please let the ObjectID discussion happen elsewhere since it isn't the objective of the layout editor.
I know your working on a database for layouts but can I ask what use the object index values would be to that? Or are you working on more than just a database there FlameCZE?
I don't know why there is any sort of limitation for the button text, never ran into that. Although I didn't use this library I just made my own and it seems to work find sending that variable lengthed packet. If he had to choose a constant value why not choose the maximum?
About windows vs linux;
closesocket(s); in windows becomes close(s); in linux/unix
windows needs WSAStartup() and WSACleanup() calls at the start and end of the networking project where as linux would not.
Using blocking sockets would require a call to fcntl() instead of ioctlsocket(). There are probable a few other things I am noth thinking of. I have never written networking for linux/unix or other operating systems however I have read and remembered those bits of info - somehow...
About windows vs linux;
closesocket(s); in windows becomes close(s); in linux/unix
windows needs WSAStartup() and WSACleanup() calls at the start and end of the networking project where as linux would not.
Using blocking sockets would require a call to fcntl() instead of ioctlsocket(). There are probable a few other things I am noth thinking of. I have never written networking for linux/unix or other operating systems however I have read and remembered those bits of info - somehow...
Thanks much! That will be useful
By any chance do you have a list, or know all the object Index values per track? I understand they change depending on the track but when it comes to making my AI 'map' I will be using "blue cone" to place the driving line, "red cone" for left track edge, and other specific objects; which mean they will change from track to track. On the wiki-page it has some of the values but not all, and certainly not all for all tracks; the most complete listing was the autocross area which is what I am currently using to get basic functionality in my AI.
If you have this available it would be a great resource, I don't know how your editor would work without it really. Thanks either way it goes.
If you have this available it would be a great resource, I don't know how your editor would work without it really. Thanks either way it goes.
Nope, but even then I don't feel that resembles how a player gets lockup information. Where I do not need my AI to be 100% realistic in capturing the information it needs, I do want to stay as realistic as I can, and where I can't I want to keep it seemingly realistic. For instance; detecting exact traction of the tires is not realistic - but if I was giving the 'approximate' state (UNDER, AT, OVER LIMIT) then I consider this realistic even if the values did not come from sound/visuals as they would with the player.
I've been wondering if I could use G forces on the car; however it will likely not work very well. My idea was to track the amount of g force against the car during braking, if that force goes down the brakes are locked; so apply less brakes for a moment. However this has issues, the car could have been bumped by another, or other reasons which don't represent locked wheels but a decrease in force; also the force is not always X while braking, it changes a lot.
I've been wondering if I could use G forces on the car; however it will likely not work very well. My idea was to track the amount of g force against the car during braking, if that force goes down the brakes are locked; so apply less brakes for a moment. However this has issues, the car could have been bumped by another, or other reasons which don't represent locked wheels but a decrease in force; also the force is not always X while braking, it changes a lot.
Hmm thanks for that, I didn't consider that the speedometer might lag behind a bit - that will make things a little more challenging than they already are. Back on page 1 you can see that I wanted the AI to know the state of each tire; and that should have been enough to know in a context dependent environment. However with LFS I can't get the state of each tire; as far as UNDER, NEAR, AT, or OVER_LIMIT. With that information on each tire the AI can detect anything in a context dependent state.
Howerver LFS doesn't get this information; One can argue that a player doesn't receive this information but I think with sounds and feeling (including the visual slip angle feeling one gets from driving in simulations) the player can get all that information immediately. Which there was a way to do that for LFS as it is kinda needed - I think.
There are hundreds of things we know intuitively, which is hard to make an AI that knows and obeys all of those things...
CONTEXT SYMPTOM FIX
Braking A Tire > AT_LIMIT Less Brake Pressure
Acceleration A Drive Tire > AT_LIMIT Less Throttle Pressure
Turn+Brake Outside Front > AT_LIMIT Less brake, less turn
Turn+Accel(FWD) Outside Front > AT_LIMIT Less throttle
Turn+Accel(RWD) Outside Rear > AT_LIMIT Less throttle, slightly less turn for a moment
Turning Outside Front > AT_LIMIT Less turning force
Turning Outside Rear > AT_LIMIT Opposite lock, minimal thottle/off brakes (to shift weight towards rear)
Howerver LFS doesn't get this information; One can argue that a player doesn't receive this information but I think with sounds and feeling (including the visual slip angle feeling one gets from driving in simulations) the player can get all that information immediately. Which there was a way to do that for LFS as it is kinda needed - I think.
There are hundreds of things we know intuitively, which is hard to make an AI that knows and obeys all of those things...
_BUMP_
Anything coming from this idea?
Anything coming from this idea?
Okay, something that needs to be added to the prevention layer (when I get there) is the ability to detect when the drive wheels will/are spinning. The same will go for braking, I will need to detect if wheels are locked.
I have very little physical information about the car that is being driven and somehow I need to detect wheel speed - which is impossible, and also one of those things that the AI shouldn't need to know about. (A player doesn't measure the wheel speed when they are in the car - except perhaps by the tachometer/speedometer and judging of the reference points . . .).
Ok, after thinking about this for a while now I think I finally answered this in my post! I believe, since the AI knows the speed they are traveling - they can compare this to the speed of the speedometer; and see that they are applying too much throttle.
However the same is not true for locking the brakes; as there are other wheels not attached to the speedometer, or even only just one wheel is locked... A player gets this information from sound, and sight in some cars. I am not about to make a sound interpreter or image detection. So I've answered have the question. Any ideas to do this accurately with minimal data available?
I have very little physical information about the car that is being driven and somehow I need to detect wheel speed - which is impossible, and also one of those things that the AI shouldn't need to know about. (A player doesn't measure the wheel speed when they are in the car - except perhaps by the tachometer/speedometer and judging of the reference points . . .).
Ok, after thinking about this for a while now I think I finally answered this in my post! I believe, since the AI knows the speed they are traveling - they can compare this to the speed of the speedometer; and see that they are applying too much throttle.
However the same is not true for locking the brakes; as there are other wheels not attached to the speedometer, or even only just one wheel is locked... A player gets this information from sound, and sight in some cars. I am not about to make a sound interpreter or image detection. So I've answered have the question. Any ideas to do this accurately with minimal data available?
After looking at the picture I am pretty sure the Autocross Area in LFS is too small. That said, do you know the data format you phone(s) will give the GPS data? I need this information before I can try doing this, although as said I think the area might be too small.
Like others it depends on the situation. If I know I am at fault and I can let the other driver back without killing my race I will do so. If the accident caused the other to get badly damaged, or into a place where he can't catch up to me easily, then I will continue on driving and say sorry after / deal with it after. This happens in real-life as well, it is very situational. (Although as mentioned in real-life a crew is being updated as to what the officials dish for penalties or not.
From the administrative side, this is a huge issue with the Head-to-Head system. The type of knock-out racing can be greatly changed by a little contact. Even penalizing the person at fault after the race, the victim of the incident walks away with less points than they may have otherwise. There were some very controversial races in the last couple of seasons. To have real-time judging of these incidents would be the solution, however I don't feel comfortable judging something with that importance under time constraints. Maybe in the future this will be resolved; but as it is I like seeing the sportsmanship that exists in that league, however there are times when the competitor should have continued going, faulty or not.
I didn't vote because there isn't a correct answer in my mind it is a situational issue.
From the administrative side, this is a huge issue with the Head-to-Head system. The type of knock-out racing can be greatly changed by a little contact. Even penalizing the person at fault after the race, the victim of the incident walks away with less points than they may have otherwise. There were some very controversial races in the last couple of seasons. To have real-time judging of these incidents would be the solution, however I don't feel comfortable judging something with that importance under time constraints. Maybe in the future this will be resolved; but as it is I like seeing the sportsmanship that exists in that league, however there are times when the competitor should have continued going, faulty or not.
I didn't vote because there isn't a correct answer in my mind it is a situational issue.
Thanks, be sure to update me/this thread so I can help with this GPS thing, I'd like to play on some IRL autocross tracks. That and my AIRS project needs to know this as well!
FGED GREDG RDFGDR GSFDG