Feels like it is just me here again! Even if it is I guess I'll keep talking.
Tonights developments progressed quite a bit! I started by allowing myself to send commands from my laptop / BlackBird account to the other machine, hoping that I'd be able to send "/press reset" or something similar and found that I was unable to do that, unfortunately. But it does let me send "/w pb" much easier than typing out "/ws fe1 xrg pb airs_artificial_driver" each time... I just need to look at the other screens to see the actual pb and it isn't easy to share.
I then worked on a config file for all the InSim/OutSim/VirtualController ports and IP addresses. Previously these were all hardcoded values and that worked out just fine, but if I want to try running AIRS on one machine and LFS on another I couldn't before without making a specific build. I've previously been too lazy to write the saving/loading config but now I've got it and won't need to do it again.
I also moved the interface around a bit and cleaned up the code from the other night with the corner detection. To add some more mess I decided to quickly add some "is at/near limit" buttons to the interface and really cruddy first attempt to detect if the car is at the limit for Oversteering, Understeering, Throttle or Braking conditions. It is working pretty well, though the values need some tweaking still.
Unfortunately these values will need to be tweaked per car / per setup, and that is one of those things I am really trying to avoid doing in this project. It is just really hard not to back yourself into one of those corners. For now Oversteering is calculated simply by checking directionOfCar vs directionOfMotion and as the angle increases it eventually crosses the threshold to be over the Oversteering limit.
Over throttle limit is determined by looking at the speedometer reading and the physical movement speed of the car, and if these are mismatched by some threshold, the car is considered over the throttle limit. Same for the braking actually, except in reverse. This does mean for the driver to detect the braking limits the setup will need to lock the drive wheels first, even if only slightly.
Understeering limits have not been implemented yet. This one is actually more tricky and I've yet to think of a good way to compute this limit. Sometimes you don't need to turn in very much to be understeering so "turning hard while going straight" isn't exactly the way to detect it.
All these can be seen with the new display, black / blue is under the limit. Green is nearing the limit but still under. Yellow is just under / at the limit and Red is over the limit by any amount. I think I'm getting closer to being able to start driving logic 2.0, had a lot of good thoughts about that today and I just need to finish the understeer limit detector then tweak the values - hopefully finding a way for the values to work for all cars ... Eesh.
Tonights developments progressed quite a bit! I started by allowing myself to send commands from my laptop / BlackBird account to the other machine, hoping that I'd be able to send "/press reset" or something similar and found that I was unable to do that, unfortunately. But it does let me send "/w pb" much easier than typing out "/ws fe1 xrg pb airs_artificial_driver" each time... I just need to look at the other screens to see the actual pb and it isn't easy to share.
I then worked on a config file for all the InSim/OutSim/VirtualController ports and IP addresses. Previously these were all hardcoded values and that worked out just fine, but if I want to try running AIRS on one machine and LFS on another I couldn't before without making a specific build. I've previously been too lazy to write the saving/loading config but now I've got it and won't need to do it again.
I also moved the interface around a bit and cleaned up the code from the other night with the corner detection. To add some more mess I decided to quickly add some "is at/near limit" buttons to the interface and really cruddy first attempt to detect if the car is at the limit for Oversteering, Understeering, Throttle or Braking conditions. It is working pretty well, though the values need some tweaking still.
Unfortunately these values will need to be tweaked per car / per setup, and that is one of those things I am really trying to avoid doing in this project. It is just really hard not to back yourself into one of those corners. For now Oversteering is calculated simply by checking directionOfCar vs directionOfMotion and as the angle increases it eventually crosses the threshold to be over the Oversteering limit.
Over throttle limit is determined by looking at the speedometer reading and the physical movement speed of the car, and if these are mismatched by some threshold, the car is considered over the throttle limit. Same for the braking actually, except in reverse. This does mean for the driver to detect the braking limits the setup will need to lock the drive wheels first, even if only slightly.
Understeering limits have not been implemented yet. This one is actually more tricky and I've yet to think of a good way to compute this limit. Sometimes you don't need to turn in very much to be understeering so "turning hard while going straight" isn't exactly the way to detect it.
All these can be seen with the new display, black / blue is under the limit. Green is nearing the limit but still under. Yellow is just under / at the limit and Red is over the limit by any amount. I think I'm getting closer to being able to start driving logic 2.0, had a lot of good thoughts about that today and I just need to finish the understeer limit detector then tweak the values - hopefully finding a way for the values to work for all cars ... Eesh.
I worked a bit more on this last night and actually got a handful of improvements. First I've refactored the race restarting portions, and now the driver can handle a player restarting the race much better than he was doing before.
I've also deleted a large portion of code that had become infected with code-rot, not being updated as things improved. That means the nice visualizers I created for showing how I computed the racing-line and several things when I was trying to create my own physical world have been deleted and stripped from the project. I can always get this back by using the source control, but it makes things easier to maintain.
I also modified how the InSim debug interface is working and it will now show the developer status. I can change this status myself by typing an insim command or by using the menubar that I have also just added to the AIRS application. This should give people that connect an idea of my whereabouts / availability.
But probably the BIGGEST change was some hackery, that I will need to clean up, to detect which corner, and what phase of that corner the driver is currently in. I had to mess around with this quite a bit before I finally figured out how to get things working. The primary problem was the distance the car can travel from "frame to frame" in the AIRS project. So I actually had to run the checks backward to get the furthest possible point and make it more accurate - this does mean that other points could be skipped, but the display on the server shows it correctly the best it can.
There is also a slight delay in the InSim Button updates that make it somewhat slower than AIRS actually catches it, but it has been running all night and is still going strong and accurate. I encourage you to join the server SRS:TestingGrounds and check it out for yourself.
The driver does NOT yet use this information in any way, so even though it is displayed, it doesn't change any logic for the driver, yet. Driving logic version 2 will use it though and this was one of the steps to getting there.
I've also deleted a large portion of code that had become infected with code-rot, not being updated as things improved. That means the nice visualizers I created for showing how I computed the racing-line and several things when I was trying to create my own physical world have been deleted and stripped from the project. I can always get this back by using the source control, but it makes things easier to maintain.
I also modified how the InSim debug interface is working and it will now show the developer status. I can change this status myself by typing an insim command or by using the menubar that I have also just added to the AIRS application. This should give people that connect an idea of my whereabouts / availability.
But probably the BIGGEST change was some hackery, that I will need to clean up, to detect which corner, and what phase of that corner the driver is currently in. I had to mess around with this quite a bit before I finally figured out how to get things working. The primary problem was the distance the car can travel from "frame to frame" in the AIRS project. So I actually had to run the checks backward to get the furthest possible point and make it more accurate - this does mean that other points could be skipped, but the display on the server shows it correctly the best it can.
There is also a slight delay in the InSim Button updates that make it somewhat slower than AIRS actually catches it, but it has been running all night and is still going strong and accurate. I encourage you to join the server SRS:TestingGrounds and check it out for yourself.
The driver does NOT yet use this information in any way, so even though it is displayed, it doesn't change any logic for the driver, yet. Driving logic version 2 will use it though and this was one of the steps to getting there.
It seems that there is still some form of issue with the AI driver getting confused about the location of his car. I haven't seen any issues there for a month or so when I first started up making the server public, but it did just need to be restarted because a player joined and the driver was confused.
Strange. I wasn't able to track it down but will keep my eyes open. I've been trying to think of ways to get the driver to feel the limits of the car in a given moment, in hopes to have a better algorithm for the new driving logic.
Also need the driver to understand restarts even better. The other day a player joined and restarted the race. The driver jumped the start and was spectated. Currently the driver does okay if he restarts the race, so now he just needs to understand when others do.
Strange. I wasn't able to track it down but will keep my eyes open. I've been trying to think of ways to get the driver to feel the limits of the car in a given moment, in hopes to have a better algorithm for the new driving logic.
Also need the driver to understand restarts even better. The other day a player joined and restarted the race. The driver jumped the start and was spectated. Currently the driver does okay if he restarts the race, so now he just needs to understand when others do.
But you haven't even asked for help. Does the code not compile? What doesn't work? What are you trying to do?
Well I can't give you all the code because I don't even know what is wrong. Nothing comes for free, it takes effort to do things. You haven't even taken the time and effort to explain the problem yet you are asking for someone to do it for you.
As for being a beginner with programming, I was once a beginner too. It was hard. It was hard for a really long time. But I learned by doing, not by having others do for me.
As for being a beginner with programming, I was once a beginner too. It was hard. It was hard for a really long time. But I learned by doing, not by having others do for me.
The code sample is a bit limited, I have no idea what the "Conn" object is, but I'm guessing it is the connection from one of the C# frameworks available.
This is a weird way to write an "if not", and had me confused for a bit. If that is even the intention in the first place. It would be better written:
Let us know what you are trying to do with the code, and what actually happens, and it will help us locate what is wrong.
if (Conn.AFKTick == 60 == false)
This is a weird way to write an "if not", and had me confused for a bit. If that is even the intention in the first place. It would be better written:
if (Conn.AFKTick != 60)
Let us know what you are trying to do with the code, and what actually happens, and it will help us locate what is wrong.
Now that family has left I've got the server running again, from time to time, and am working on making the driver better at restarting races so he can drive all night. He has driven successfully for 24 hours, about 4 to 5 restarts, but still seems to get hung up from time to time. And I've witnessed a few times when I come back to check on the driver that the AIRS application starts running extremely sluggish. Not entirely sure why that would happen all of a sudden, memory usage looked as expected, but he was down to 1fps at best - far too sluggish to drive the car.
Still planning how I will attack the new driver logic, there is a lot of things I have in mind, but the trick will be getting the driver to understand it! For instance, when entering a corner too hot, it would be best to straighten the wheel and go offline a bit to allow more braking before initiating a sharper turn. This is easy to understand as a human, but for the artificial driver, it is much more complicated than the current logic of "try to follow this line".
The thought I had was to have the racing line, and then have a "driving line" which gets modified in real-time by the driver. This would work great for multiple thoughts: passing lines, aggressive/defensive lines through a corner, pitting, and even modifying the line as described above when entering too fast. The trick here would be having the driver follow the line accurately!
If I go with the real-time modified "driving-line" I will need to make the driver be able to follow that line much more precisely than he currently does. If you haven't checked it out, the racing-line he computes and "follows" is shown on the server by a chalk-line. Watching him drive, you will notice he tends to fall off the outside edge of each turn. Sometimes more, sometimes less. This is also dependent of the car he is driving - in single seater cars the problem is much worse.
A while ago I tried a solution to aim the driving point to the left/right depending on how far away he currently was, which worked to some degree but also added more of a wiggle in straights so I removed that.
I may not go with the "driving-line" idea, as I am still thinking about the new driver logic, but currently it is a thought.
EDIT:
I went ahead and tried modifying the steering behavior to get a more accurate line, and by simply doubling steering angle change by 2 the XRG is now following the line almost, but not quite perfectly. I haven't yet tried other cars. What I can say already is WOW, what an improvement on lap times, IMMEDIATELY. The driver has only done 5 laps and he has already smashed his old PB by over a second. New PB is down to 1:00.00 exact, and bound to drop in the 59s shortly! (while writing this he has now dropped to 59.99!)
In the few laps I've watched, he now tends to stay on the inside of most corners, during entry and slides on the outside during exit. He is also on the outside of the back sweeping 'corner' that behaves like a straight. So my conclusion is that the faster he is driving, the bigger the multiplier will need to be. I will also assume that this is a value that will need to be tweaked for other cars, and I'm still pondering the best way to do that since I really don't want a table of values that I need to hand-tune to get the driver to go fast. I'm on the fence about this though, since to some degree it will be required.
He broke the minute barrier!!!
Still planning how I will attack the new driver logic, there is a lot of things I have in mind, but the trick will be getting the driver to understand it! For instance, when entering a corner too hot, it would be best to straighten the wheel and go offline a bit to allow more braking before initiating a sharper turn. This is easy to understand as a human, but for the artificial driver, it is much more complicated than the current logic of "try to follow this line".
The thought I had was to have the racing line, and then have a "driving line" which gets modified in real-time by the driver. This would work great for multiple thoughts: passing lines, aggressive/defensive lines through a corner, pitting, and even modifying the line as described above when entering too fast. The trick here would be having the driver follow the line accurately!
If I go with the real-time modified "driving-line" I will need to make the driver be able to follow that line much more precisely than he currently does. If you haven't checked it out, the racing-line he computes and "follows" is shown on the server by a chalk-line. Watching him drive, you will notice he tends to fall off the outside edge of each turn. Sometimes more, sometimes less. This is also dependent of the car he is driving - in single seater cars the problem is much worse.
A while ago I tried a solution to aim the driving point to the left/right depending on how far away he currently was, which worked to some degree but also added more of a wiggle in straights so I removed that.
I may not go with the "driving-line" idea, as I am still thinking about the new driver logic, but currently it is a thought.
EDIT:
I went ahead and tried modifying the steering behavior to get a more accurate line, and by simply doubling steering angle change by 2 the XRG is now following the line almost, but not quite perfectly. I haven't yet tried other cars. What I can say already is WOW, what an improvement on lap times, IMMEDIATELY. The driver has only done 5 laps and he has already smashed his old PB by over a second. New PB is down to 1:00.00 exact, and bound to drop in the 59s shortly! (while writing this he has now dropped to 59.99!)
In the few laps I've watched, he now tends to stay on the inside of most corners, during entry and slides on the outside during exit. He is also on the outside of the back sweeping 'corner' that behaves like a straight. So my conclusion is that the faster he is driving, the bigger the multiplier will need to be. I will also assume that this is a value that will need to be tweaked for other cars, and I'm still pondering the best way to do that since I really don't want a table of values that I need to hand-tune to get the driver to go fast. I'm on the fence about this though, since to some degree it will be required.
He broke the minute barrier!!!
Last edited by blackbird04217, .
Well last night I was able to get a little bit more work into the project. By unfortunately that will be it for a couple weeks. I should still have access to the forums should anyone have questions or if I have any breakthroughs. I took the server down since I won't be free enough. Overnight though I was able to make a few improvements to the airs application. First I added a quick way to add text information through insim buttons to the debug controller. It isn't very amazing feature wise, but it will get the job done. Minor issue is that I either turn it on for just me or for all users and the way it stand you can't turn it off via shift-I. But I don't think that is a giant problem for this server though.
The next improvement was with the driver restarting races. He would get glitchy after the first restart. I figured out why and have fixed this issue and a different crash issue that popped up today from some recent maintenance changes. Pesky bracket locations. Hehe
Finally I modified the downshifting point to be a little higher as one player suggested. I didn't really get to watch the driver after making this change, but it should stay in the power and better.
The next improvement was with the driver restarting races. He would get glitchy after the first restart. I figured out why and have fixed this issue and a different crash issue that popped up today from some recent maintenance changes. Pesky bracket locations. Hehe
Finally I modified the downshifting point to be a little higher as one player suggested. I didn't really get to watch the driver after making this change, but it should stay in the power and better.
Don't worry about the layout stuff, it isn't urgent at all and the PTH files might be working, although it seems every other track has minor "gotchyas" about one thing or another.
A good handful of people had joined the server while I was working, so I wasn't able to hangout much. Had work/life stuff to be done. I'm going to take the server down for a couple weeks until while family visits, but I will get it back up as soon as they leave and things calm down enough for me to continue working on the artificial driver.
When I get back to development I would like to build up a debugging screen in LFS with InSim buttons that show what state the driver is in and what information and when it starts coming together get that debug information shared with everyone that wants to see it. Two other priorities, before new driver logic, will be to properly handle race restarts and being spec'd and make sure that during multiple restarts the driver doesn't get glitchy.
When I get back to development I would like to build up a debugging screen in LFS with InSim buttons that show what state the driver is in and what information and when it starts coming together get that debug information shared with everyone that wants to see it. Two other priorities, before new driver logic, will be to properly handle race restarts and being spec'd and make sure that during multiple restarts the driver doesn't get glitchy.
That is hilarious! Good work on getting him into and out of pits! I would like to teach him how to pit but that is a bit of a challenge. I'm also trying to get him to understand the restarting of the race a bit better so he won't jump the start and get spectated. Sometimes it works, sometimes it doesn't.
I need him to be able to keep going around the track all night long, restart when he gets out of fuel, and continue some more. This is needed before I get the new driver logic written so that he can adjust the braking point and entry speed over a long period of time. Still not exactly sure how I will go about that portion.
I wanted to say he is running on the server now, his racing line is shown and I'll try to keep him going most of the day but since I am actually working (on real work stuff) I can't watch him or the server non-stop. So if you have some time and want to stop in, you are welcome to do so.
I guess he must have restarted the race and sometimes when he does this he gets in a funny state where his sensors are very glitchy. Somehow causing him to cut corners a LOT and even hit some tires. Unless you mean to say his current best was 1:01.14, in which that was the lap that possibly had him bumped with a BF1. Not sure if I can believe the time or not so for now I'll wait until he does it again.
I need him to be able to keep going around the track all night long, restart when he gets out of fuel, and continue some more. This is needed before I get the new driver logic written so that he can adjust the braking point and entry speed over a long period of time. Still not exactly sure how I will go about that portion.
I wanted to say he is running on the server now, his racing line is shown and I'll try to keep him going most of the day but since I am actually working (on real work stuff) I can't watch him or the server non-stop. So if you have some time and want to stop in, you are welcome to do so.
I guess he must have restarted the race and sometimes when he does this he gets in a funny state where his sensors are very glitchy. Somehow causing him to cut corners a LOT and even hit some tires. Unless you mean to say his current best was 1:01.14, in which that was the lap that possibly had him bumped with a BF1. Not sure if I can believe the time or not so for now I'll wait until he does it again.
I didn't get much done tonight, and I think this is the last night of development for a couple weeks for family coming in. I didn't get much, but I moved some things around to be easier to maintain in the future, deleted some unused bits of code and made it easier to add debug visuals to LFS. In doing so I added a chalk line along the racing line that the artificial driver computes and tries to follow. Next time you visit the server you will be able to see how far away from his own racing line he gets.
I also tried making it easier for the driver to start the car but that will remain to be seen if it works or not. The driver did an insane personal best today, but I think it may have been because of a big push from a BF1 driver at just the right time. 1:01.14, his old PB which is actually him and him alone was a 1:01.30 so I suspect there was a bump that played into that lap, or somehow he got major aero effects and or extreme circumstances...
Then again I was shocked when he got down to a 1:01.30. The logic has not changed since back when he was setting a 1:01.78, although recently I did change his set (after the 1:01.30) that did make him hit the 1:01.50s more consistently, so it is possible...
I also tried making it easier for the driver to start the car but that will remain to be seen if it works or not. The driver did an insane personal best today, but I think it may have been because of a big push from a BF1 driver at just the right time. 1:01.14, his old PB which is actually him and him alone was a 1:01.30 so I suspect there was a bump that played into that lap, or somehow he got major aero effects and or extreme circumstances...
Then again I was shocked when he got down to a 1:01.30. The logic has not changed since back when he was setting a 1:01.78, although recently I did change his set (after the 1:01.30) that did make him hit the 1:01.50s more consistently, so it is possible...
I've had some issues with the server and a handful of random users (unknown) that crashed the ai driver while I left him overnight. So to combat this, from time to time I may password the server and those that follow this thread and have a respect for the project will still be able to access it with the password: airs although usually when passworded I will probably not be around.
On occasion I may password it with a different password completely, but will try to limit this. Hopefully the public password above doesn't get abused. The other thought I had was to make the AIRS application spectate any users who try to join the track if they don't have prior approval, although I don't really want to do that because most people have been respectful of the AIRS project, and for this I thank all of you.
On occasion I may password it with a different password completely, but will try to limit this. Hopefully the public password above doesn't get abused. The other thought I had was to make the AIRS application spectate any users who try to join the track if they don't have prior approval, although I don't really want to do that because most people have been respectful of the AIRS project, and for this I thank all of you.
I don't really have much to show and tell this time around, but I have been busy working on the project for the past two nights. Mainly I am back to trying to get the artificial driver running on different tracks even though last week I had given up. It was quite interesting how this happened;
First I started adding a portion of code that would allow users that join my SRS:TestingGrounds server a chance to see some of the information from the driver in action, so with the new corner detection I decided to send some LFS layout objects (chalk lines) to show some of this information, and it works. If you ever join and see some lines on the track you will know what they are. (Red is braking point, White is entry, Blue is apex and Yellow is exit).
When I got this working I had found a bit of test/experimental code that I started writing a long time ago, but never really finished and completely forgotten about. The function was named "LoadPathTest()" which cleared out the left/right edge and loaded them from the path file instead. This actually works, sort of. At least for forward direction tracks. The path does indeed follow the track well, but in some situations the left/right is actually not where it should it be making the track a bit more narrow than it would be with a handmade layout.
After finding this I decided to try out SO1, and it did work, sort of. The driver slammed into the walls over and over again, particularly at the chicane. For this to work on reversed configs I just need to swap the order and sides, which wouldn't be terribly hard - if it ends up being worth it.
At this point I ran into some weird issue, the AI driver going down a straight would go no faster than 35-40mph, and tries zig-zagging like crazy. Still not sure what is causing it but after spending two or three hours looking at all code changes it seems to have always happened except in the FE1 data that was processed a long time ago, so I decided to make sure I didn't lose it. (The issue reproduced when I tried reprocessing FE1, even on the codebase back in June 2014, thanks again source control.)
Today I found part of the issue and when I processed the FE1 data again it still failed. But restarting with the already processed data got it working. So I tried with the other tracks and that seemed to help, it has always been a challenge to keep the processing of data (first time) and loading processed data (other times) completely in sync, but at least now I know where the problem is and I've started ignoring it for now even if it is annoying to restart the driver after processing the data.
Right now I'm trying to add some code to have the application tell players that the server is a testing ground for the airs_artificial_driver. Also been trying to clean up some of this codebase, because such surprises as the LoadPathTest() shouldn't be so surprising. Unfortunately there has been quite a lot of experimental hacking in the years I've been working on the project.
First I started adding a portion of code that would allow users that join my SRS:TestingGrounds server a chance to see some of the information from the driver in action, so with the new corner detection I decided to send some LFS layout objects (chalk lines) to show some of this information, and it works. If you ever join and see some lines on the track you will know what they are. (Red is braking point, White is entry, Blue is apex and Yellow is exit).
When I got this working I had found a bit of test/experimental code that I started writing a long time ago, but never really finished and completely forgotten about. The function was named "LoadPathTest()" which cleared out the left/right edge and loaded them from the path file instead. This actually works, sort of. At least for forward direction tracks. The path does indeed follow the track well, but in some situations the left/right is actually not where it should it be making the track a bit more narrow than it would be with a handmade layout.
After finding this I decided to try out SO1, and it did work, sort of. The driver slammed into the walls over and over again, particularly at the chicane. For this to work on reversed configs I just need to swap the order and sides, which wouldn't be terribly hard - if it ends up being worth it.
At this point I ran into some weird issue, the AI driver going down a straight would go no faster than 35-40mph, and tries zig-zagging like crazy. Still not sure what is causing it but after spending two or three hours looking at all code changes it seems to have always happened except in the FE1 data that was processed a long time ago, so I decided to make sure I didn't lose it. (The issue reproduced when I tried reprocessing FE1, even on the codebase back in June 2014, thanks again source control.)
Today I found part of the issue and when I processed the FE1 data again it still failed. But restarting with the already processed data got it working. So I tried with the other tracks and that seemed to help, it has always been a challenge to keep the processing of data (first time) and loading processed data (other times) completely in sync, but at least now I know where the problem is and I've started ignoring it for now even if it is annoying to restart the driver after processing the data.
Right now I'm trying to add some code to have the application tell players that the server is a testing ground for the airs_artificial_driver. Also been trying to clean up some of this codebase, because such surprises as the LoadPathTest() shouldn't be so surprising. Unfortunately there has been quite a lot of experimental hacking in the years I've been working on the project.
It is quite difficult to see this in a screenshot, and this shot was taken before the apex point was added, but I've got the driver to figure out the braking point, turn-in point apex and exit of the corners in FE1. It might need slight adjustment but it seems to work, for the most part. Some of the corners are connected, such as the final chicane and final turn all counts as a single turn to the algorithm because there was no straight section along the racing line for a long enough time.
If anyone even cares about the technical details, here is essentially what I did to figure out these points.
First I found the starting and ending node of the first corner. I defined a threshold angle of 2 degrees, and if a node along the racing line angled more than this amount to its previous and next nodes it would count as a corner. Simply finding the first of them gives the starting point of the first corner. The ending point of the first corner continued until I found multiple nodes together that were detected as straight, I think minimum distance was set to 50 meters.
From here I go from the end of the corner until I find the start of the next, then find the end of that one, and then the start of the next and then the end until the start of the next is the same point as the start of the first corner. Essentially finding the entry and exit positions of all the corners.
The braking is not perfect by any means, and it could be a little smarter so I may do so in the future, but currently it starts at each corners entry point and walks backward along the racing line 50 to 80 meters and plops down the braking point. The overall idea is to have the driver keep track of this point in his memory and modify it depending on how the car is behaving. If it was easy to reach the target entry speed, the brake point can be moved closer - etc. The initial placement could be smarter though, as I could check how long the straight before the corner is and make longer braking areas for longer straights - assuming here that the driver will be going faster on these straights than the shorter ones, needing more time to brake for target speed.
Finally the tricky bit, which I admit didn't work out quite as well as I was hoping for but such is life and I will let it be as it is until I find a better idea. The apex point of the corner. I realize some corners can have multiple apex points, but for the artificial driver I was going to have a single apex - even for chicanes. Essentially I'm using the apex point as the point in which it should be safe to start speeding out of the corner towards the exit.
With this loose definition it made sense, intuitively to me, to start at the exit point of the corner and work backwards along the racing line. While working backwards monitor the distance from the racing line to the INSIDE edge of the corner. At the exit the racing line should be near the outside of the track so as this distance decreases keep walking backwards. Once it increases, stop! Step forward slightly and that would be the apex.
This sounds reasonable in my head, but for turn one the exit is actually near that side of the corner because after T1 and before the chicane the track is constantly turning even though it is sort of a mini straight as far as racing is concerned. Otherwise, the chicane apex and far back turn worked flawlessly. The final turn apex looks a little later than one would expect, but not terrible for an automatic corner detector. I haven't yet run this on other tracks, but I am looking forward to getting the driver to understand the different sections of the track and change the driving logic to drive at the limit instead of how it is currently with drive by wire.
I've said it a few times but I've recently began running the artificial driver in other cars, just to get a feeling for differences, and boy are there many differences.
First it is IMPORTANT to realize that the current logic has been based fairly drastically on the XRG at FE1. Some of the variables that I KNOW are hardcoded for this combo are things including braking distances, speed in turns of certain angles (35-40mph) and various others. Actually just changing to a different setup in the XRG can make the artificial driver fail like a fish out of water. Seriously. This is one major reason I want to change the logic to be less hard coded and more "feeling of the limit" not to mention that is one of the underlying goals of this project.
So with the current, hardcoded and simple, driving logic I've been watching how it performs with other cars and trying to figure out the "whys". This way when I plan and write the new "at the limit" driving logic I can have ideas about what needs to change per car or even things to keep in mind.
So far in all my testing the airs_artificial_driver has been fastest in the FZ5 with a mid/high 55 something. You can check all times for the driver on LFS world, username: airs_artificial_driver. This time was set without ABS and a lot of locked tires. Current hardcoded logic just slams on the brakes and expects the car to have ABS for threshold braking. Interestingly in the FZ5 turning ABS on will cause a spin when braking on the back straight, the rear end gets loose and winds up in front so the driver prefers to kill the tires. I believe the FZ5 is so fast because it weighs a lot and takes a long time to slow down but still doesn't drive over the limit, too much, and has the power to really accelerate out still.
The FZR was quite amusing to watch as well, I'm not sure what the time was but this car makes it extremely clear the artificial driver has no concept of tire limits because it is excruciatingly slow through the turns at 35 to 40mph. I was practically screaming "go faster" during each turn because the slicks have much more grip available.
I also recently added sequential shifting to the shifting logic so I could try out the single seaters, and well, that was disappointing. Quite like the FZR the driver never got near the limit of the car. The BF1 brought up another very interesting problem I'll need to keep in mind - not all cars have the same steering setup. What I mean by this is the AI driver rarely turns the steering wheel to full lock, and in some tight turns the single seaters (particularly BF1) requires this because they have a limited range. Essentially the artificial driver plows the BF1 into the tire stack in the chicane because he didn't turn sharp enough. Amusing, yes. Fast - no.
Then there was the UF1 test, I figured this couldn't possibly end badly with a car so slow grandma can drive it. Well surprise surprise. The artificial driver doesn't shift properly. What I mean by this is because of some hardcoded logic the driver slowly shifts up to fourth gear about as expected, but then never downshifts. Instead stays in fourth gear the entire time. The problem with the hardcoded value is the tachometer reading never gets a certain percentage below the engine speed with max torque, so the downshift threshold is never reached. I'm sure he would down shift if the car was stopped for some reason, but he doesn't while driving. Yet another thing to keep an eye for. I may need to have different values for each car.
Finally I've put the driver in the LX4 and a new problem came shining through, clutch wear/temperature. As of now the artificial driver has been shifting with very VERY basic logic. Clutch in 100%, shift to gear, once gear is engaged, clutch out. This means the driving logic was controlling the throttle during the shift and generally meant for a full throttle, no lift, upshift. Which was working flawlessly for the XRG with a stronger clutch.
I have now changed the shifting mechanism a little bit so that it now controls the throttle while the driver is attempting to shift. It takes 30 to 50 milliseconds to fully press the clutch and release the throttle, then shift to gear and once engaged it will take 200 to 250 milliseconds to release the clutch and press the throttle. With one exception, if the engine speed drops near engine idle speed it will then press the throttle fully, this isn't perfect, but I found that otherwise he would stall when starting from a stop and shifting into first.
This change now has me wanting to do some heel-and-toe down-shifting. The driver isn't losing control, but a keen eye will notice the traction breaks away at the drive wheels during a down shift because the driver isn't very smooth. Also the shifting logic still needs to be modified slightly to detect up or down shift. The new logic with applying throttle will occur even on a downshift, something that is obviously not desired when attempting to brake for a corner. The driving logic will quickly correct it, but that is still ~0.1 seconds with more than half throttle while trying to stop the car.
It is quite neat to watch the different cars and learn these little things. For instance when testing the "at the limit" logic for acceleration the BF1 without traction control will prove very useful, possibly the same car would be useful for testing the braking threshold, but I suspect that the FZ5 might be better due to the tendency to get loose at the rear. Still not sure how I will detect "under, at or over the limit" for these different conditions, (braking, accelerating, turning), but hopefully I'll figure something out.
----
One last thing, this isn't specific to just car changes, for instance at BL1 the artificial driver had an issue in some cars not being able to stay on track at the end of the long straight. Although there is currently an issue with the track layout somewhere in the chicane. I wish creating tracks was easier, but I don't want to spend more time on making it easier, so for now I will stick with FE1.
First it is IMPORTANT to realize that the current logic has been based fairly drastically on the XRG at FE1. Some of the variables that I KNOW are hardcoded for this combo are things including braking distances, speed in turns of certain angles (35-40mph) and various others. Actually just changing to a different setup in the XRG can make the artificial driver fail like a fish out of water. Seriously. This is one major reason I want to change the logic to be less hard coded and more "feeling of the limit" not to mention that is one of the underlying goals of this project.
So with the current, hardcoded and simple, driving logic I've been watching how it performs with other cars and trying to figure out the "whys". This way when I plan and write the new "at the limit" driving logic I can have ideas about what needs to change per car or even things to keep in mind.
So far in all my testing the airs_artificial_driver has been fastest in the FZ5 with a mid/high 55 something. You can check all times for the driver on LFS world, username: airs_artificial_driver. This time was set without ABS and a lot of locked tires. Current hardcoded logic just slams on the brakes and expects the car to have ABS for threshold braking. Interestingly in the FZ5 turning ABS on will cause a spin when braking on the back straight, the rear end gets loose and winds up in front so the driver prefers to kill the tires. I believe the FZ5 is so fast because it weighs a lot and takes a long time to slow down but still doesn't drive over the limit, too much, and has the power to really accelerate out still.
The FZR was quite amusing to watch as well, I'm not sure what the time was but this car makes it extremely clear the artificial driver has no concept of tire limits because it is excruciatingly slow through the turns at 35 to 40mph. I was practically screaming "go faster" during each turn because the slicks have much more grip available.
I also recently added sequential shifting to the shifting logic so I could try out the single seaters, and well, that was disappointing. Quite like the FZR the driver never got near the limit of the car. The BF1 brought up another very interesting problem I'll need to keep in mind - not all cars have the same steering setup. What I mean by this is the AI driver rarely turns the steering wheel to full lock, and in some tight turns the single seaters (particularly BF1) requires this because they have a limited range. Essentially the artificial driver plows the BF1 into the tire stack in the chicane because he didn't turn sharp enough. Amusing, yes. Fast - no.
Then there was the UF1 test, I figured this couldn't possibly end badly with a car so slow grandma can drive it. Well surprise surprise. The artificial driver doesn't shift properly. What I mean by this is because of some hardcoded logic the driver slowly shifts up to fourth gear about as expected, but then never downshifts. Instead stays in fourth gear the entire time. The problem with the hardcoded value is the tachometer reading never gets a certain percentage below the engine speed with max torque, so the downshift threshold is never reached. I'm sure he would down shift if the car was stopped for some reason, but he doesn't while driving. Yet another thing to keep an eye for. I may need to have different values for each car.
Finally I've put the driver in the LX4 and a new problem came shining through, clutch wear/temperature. As of now the artificial driver has been shifting with very VERY basic logic. Clutch in 100%, shift to gear, once gear is engaged, clutch out. This means the driving logic was controlling the throttle during the shift and generally meant for a full throttle, no lift, upshift. Which was working flawlessly for the XRG with a stronger clutch.
I have now changed the shifting mechanism a little bit so that it now controls the throttle while the driver is attempting to shift. It takes 30 to 50 milliseconds to fully press the clutch and release the throttle, then shift to gear and once engaged it will take 200 to 250 milliseconds to release the clutch and press the throttle. With one exception, if the engine speed drops near engine idle speed it will then press the throttle fully, this isn't perfect, but I found that otherwise he would stall when starting from a stop and shifting into first.
This change now has me wanting to do some heel-and-toe down-shifting. The driver isn't losing control, but a keen eye will notice the traction breaks away at the drive wheels during a down shift because the driver isn't very smooth. Also the shifting logic still needs to be modified slightly to detect up or down shift. The new logic with applying throttle will occur even on a downshift, something that is obviously not desired when attempting to brake for a corner. The driving logic will quickly correct it, but that is still ~0.1 seconds with more than half throttle while trying to stop the car.
It is quite neat to watch the different cars and learn these little things. For instance when testing the "at the limit" logic for acceleration the BF1 without traction control will prove very useful, possibly the same car would be useful for testing the braking threshold, but I suspect that the FZ5 might be better due to the tendency to get loose at the rear. Still not sure how I will detect "under, at or over the limit" for these different conditions, (braking, accelerating, turning), but hopefully I'll figure something out.
----
One last thing, this isn't specific to just car changes, for instance at BL1 the artificial driver had an issue in some cars not being able to stay on track at the end of the long straight. Although there is currently an issue with the track layout somewhere in the chicane. I wish creating tracks was easier, but I don't want to spend more time on making it easier, so for now I will stick with FE1.
Last edited by blackbird04217, .
Gutholz let me get it tested right quick and get back to you with some more details. You might already have the fe1_airs_lr.lyt since you were on the server which you could use as reference, but essentially I placed cones approximately 15-30 meters apart or so (closer on the turns, further on the straights). With the new distance thing you will need to make sure the first cones are closer going the correct way around the track, I haven't yet tried using fe1 for fe1r yet, in theory it could work just changing the meaning of left and right edges but that remains untested.
Server is going up soon for a little bit of development tonight.
EDIT: From my experimenting with the dragstrip this "find the nearest" might not be so great. I admit though the drag strip is a very unusual case, and I wasn't using the return road correctly, but you can see here the nearest cone is jumping across to the return side.
It didn't take much to fix that particular issue, just add more cones that need to be deceivingly close together, but then another issue returned which is because of the hairpin like turns the algorithm for detecting the center line has an issue where it can't always find the edge. Lets put it this way: Making tracks for this AI Driver is still not as easy as I was hoping for. I've given up on this portion for now, sorry Gutholz I know you were looking to make a layout or or two and help out. If you feel up to it you can still try to, but I'd choose one that doesn't have very sharp turns because these give the AI some troubles, I need to work on a debugger for this but I don't want to at this moment in time.
He seems to be doing pretty good on AS1R so I'll run him there for a bit for a change of scenery.
Now for my next trick, since I'll stop playing with the tracks for the time being, I want to give the driver information about the track in a different way. For long time readers of the project you may remember I wanted to use reference points for driving much like a human would. If nobody noticed, I sort of didn't do that as completely as initially desired. (I used the left/right edge track reference points to create a racing line). Now I will take that racing line and create several points of interest for the driver to distinguish between straights and corners.
A straight will be defined as a section of the racing line where no two nodes exceed some threshold angle for some minimum distance where as a turn will be almost anything else.
Each turn will have several bits of information:
- A reference point for the entry of the turn.
- A reference point for the exit of the turn.
- A reference point for the brake point.
- At least one reference point for the apex*.
*The first left/right chicane in FE1 will likely be defined by this all as 1 turn but will have 2 apex reference points. Not entirely sure how the algorithm will determine each of the apex points at this time, or even if that is really needed. (The braking point, entrance and exit points are certainly needed though the driver should change behavior after passing the last apex since that should basically be the throttle out quickly point).
So enough talking let me start doing!
Server is going up soon for a little bit of development tonight.
EDIT: From my experimenting with the dragstrip this "find the nearest" might not be so great. I admit though the drag strip is a very unusual case, and I wasn't using the return road correctly, but you can see here the nearest cone is jumping across to the return side.
It didn't take much to fix that particular issue, just add more cones that need to be deceivingly close together, but then another issue returned which is because of the hairpin like turns the algorithm for detecting the center line has an issue where it can't always find the edge. Lets put it this way: Making tracks for this AI Driver is still not as easy as I was hoping for. I've given up on this portion for now, sorry Gutholz I know you were looking to make a layout or or two and help out. If you feel up to it you can still try to, but I'd choose one that doesn't have very sharp turns because these give the AI some troubles, I need to work on a debugger for this but I don't want to at this moment in time.
He seems to be doing pretty good on AS1R so I'll run him there for a bit for a change of scenery.
Now for my next trick, since I'll stop playing with the tracks for the time being, I want to give the driver information about the track in a different way. For long time readers of the project you may remember I wanted to use reference points for driving much like a human would. If nobody noticed, I sort of didn't do that as completely as initially desired. (I used the left/right edge track reference points to create a racing line). Now I will take that racing line and create several points of interest for the driver to distinguish between straights and corners.
A straight will be defined as a section of the racing line where no two nodes exceed some threshold angle for some minimum distance where as a turn will be almost anything else.
Each turn will have several bits of information:
- A reference point for the entry of the turn.
- A reference point for the exit of the turn.
- A reference point for the brake point.
- At least one reference point for the apex*.
*The first left/right chicane in FE1 will likely be defined by this all as 1 turn but will have 2 apex reference points. Not entirely sure how the algorithm will determine each of the apex points at this time, or even if that is really needed. (The braking point, entrance and exit points are certainly needed though the driver should change behavior after passing the last apex since that should basically be the throttle out quickly point).
So enough talking let me start doing!
Last edited by blackbird04217, .
Interesting, I've actually already got BL1 done, although during the test something did go wrong in the chicane area so I should be able to move reference points and fix that issue now. So that would is a grand idea dawesdust_12. If anyone else has suggestions I've actually got layouts started/made for: FE1, BL1, AS1R and I think AS2.
Also I tried a few different cars last night for fun, and it shows how little the artificial driver knows about driving at the limits. The current algorithm looks at several points on the racing line that are ahead of the driver to determine braking. The driver attempts to enter a turn at some speed (I think 40mph?) depending on how tight it turns. So watching him drive in the FZR was quite comical as he could go twice the speed around the turns. Hopefully the new algorithm will be better and adapt to other cars better: I'll have to remember to make the reference points change based on the car driven.
Also I tried a few different cars last night for fun, and it shows how little the artificial driver knows about driving at the limits. The current algorithm looks at several points on the racing line that are ahead of the driver to determine braking. The driver attempts to enter a turn at some speed (I think 40mph?) depending on how tight it turns. So watching him drive in the FZR was quite comical as he could go twice the speed around the turns. Hopefully the new algorithm will be better and adapt to other cars better: I'll have to remember to make the reference points change based on the car driven.
I spent the night removing a bunch of files from the codebase and ran into a few troubles with the new timer, but got it figured out so everything is working as it was before. Just before I started removing the files, I had the artificial driver running laps and he was on a streak, I'm not entirely sure what was different (no logic was changed, at all) but he was running faster than I had seen before, beating his 1:01.70 PB down to a 1:01.44! It was pretty neat to watch, but I always test with the same airs_driver setup and no wind. His fuel load changes from time to time, but I had not messed with it. He does randomly have better runs from time to time, probably latency and framerate helps a lot.
There is still plenty in the code base that does not need to be there, all the visualizer code is now useless and no longer functioning, but I have a hard time just deleting it because it took time to write and we neat to see. I guess I half think I'll want it in the future even though that would need effort to get working again. There are also other files like my deformable tire, point mass system and some basic physics that I added to the project back when I was swinging back and forth between writing my own physical world for the testing.
There is still a LOT of code that contributes to the racing line computation, all the communications/data collection with LFS and the many different states for the driver. But for those interested, the code base is currently at about 226 files and 38000 lines of code (including 7500 blank lines, 9000 lines of comments). I'd say at least 10% to 15% is not used in the way the project is working now.
With that out of the way, I also started working on tracking the time a bit better, and found the InSim packet TINY_GTH which allows me to get the time in LFS and I can then compare that to what time OutSim and OutGauge are stating. From the print out I see the latency of a full round message through InSim is about 30-80ms with spikes upto 150ms.
Both OutSim and Outgauge are typically 30-50ms behind that time I grab, which leads me to believe they are actually delayed by 50-90ms, but I could be wrong. I don't have a great way to show this information so it just spews through the debug console for now and isn't the easiest to actually watch and I'm taking the accuracy with a grain of salt.
I've also added a way to guess at the order of the reference points without requiring the cones to be added to a layout. I've still yet to test this currently, need to make a new track to do so, any suggestions? but if it works as expected maybe someone could help make layouts for driver to know how to drive at other locations, in any situation it should allow a reference point to be moved after if it is found to be problematic...
So tonight was a very productive night even though one of the items remains untested and not all the timing information has been displayed how I initially wanted.
There is still plenty in the code base that does not need to be there, all the visualizer code is now useless and no longer functioning, but I have a hard time just deleting it because it took time to write and we neat to see. I guess I half think I'll want it in the future even though that would need effort to get working again. There are also other files like my deformable tire, point mass system and some basic physics that I added to the project back when I was swinging back and forth between writing my own physical world for the testing.
There is still a LOT of code that contributes to the racing line computation, all the communications/data collection with LFS and the many different states for the driver. But for those interested, the code base is currently at about 226 files and 38000 lines of code (including 7500 blank lines, 9000 lines of comments). I'd say at least 10% to 15% is not used in the way the project is working now.
With that out of the way, I also started working on tracking the time a bit better, and found the InSim packet TINY_GTH which allows me to get the time in LFS and I can then compare that to what time OutSim and OutGauge are stating. From the print out I see the latency of a full round message through InSim is about 30-80ms with spikes upto 150ms.
Both OutSim and Outgauge are typically 30-50ms behind that time I grab, which leads me to believe they are actually delayed by 50-90ms, but I could be wrong. I don't have a great way to show this information so it just spews through the debug console for now and isn't the easiest to actually watch and I'm taking the accuracy with a grain of salt.
I've also added a way to guess at the order of the reference points without requiring the cones to be added to a layout. I've still yet to test this currently, need to make a new track to do so, any suggestions? but if it works as expected maybe someone could help make layouts for driver to know how to drive at other locations, in any situation it should allow a reference point to be moved after if it is found to be problematic...
So tonight was a very productive night even though one of the items remains untested and not all the timing information has been displayed how I initially wanted.
Yea I had already added the filter for the PLID of the artificial driver, so that issue won't pop up again.
Given the issues I saw with the prediction unit, the jumpiness in the AIRS display and a general curiosity I think my next plan of action will be to find a way to accurately determine the difference between the LFS World time and the AIRS world time*. I know there is a delay in the communications, and I assume this delay to be 50-100ms, but will try determining it and maybe finding a way to make the display run smoothly, even if it needs some form of client prediction**.
The refactoring is going pretty good, I just need to finish removing the old bits of code that have been replaced, and hope that the issue, with the first lap 10 meters to the left of the racing line, never appears again. It didn't appear to be an issue due to refactoring though, perhaps a change or two before it but again I went through each change in each file since the copy that worked and found nothing that would have changed that behavior, so it was a strange issue that has since disappeared.
I've also had some interest from someone that may want to try creating some more track layouts to get the driver working on different tracks, but to do that I'll need to modify some of that code again for improvements, probably something I should have done a long time ago anyway. This won't be that difficult, I just need to add an additional step that sorts the track edge reference points by nearest before processing them - although I may end up removing the curve code I wrote.***
So the overall list of things I want to do with the project:
1) Remove the old bits of code from the new refactoring job.
2) Get an accurate calculation of the LFS-AIRS time difference.
3) Improve the layout parsing to not be so strict about ordering.
4) Remove parts of the "to curve" in the layout parsing where it caused issued.
5) Process the track to create reference points where corners, straights and braking points are.
6) Detect if the car is accelerating or decelerating at the limit.
7) Detect if the car is understeering or oversteering.
8) Create a new driving state behavior that uses the braking point references and limit detection to modify the braking point.
Hopefully when I get these steps complete the driver will have a more clear sense of the information, (hopefully not so jumpy?), and with any luck with modifying brake points and driving at the limit of the cars capabilities should make the driver faster. I would really like to see a time in the 57 to 58 second range on FE1 with the XRG once the driver understands the limits of the car. I would be shocked and amazed if the times are in the 53 to 55 second range. This is not world record pace by any means, but currently the PB of airs_artificial_driver is 1:01.70
*I'm not entirely sure how to do this accurately as there are actually many parts to the problem including the network latency. I should be able to figure that out with the InSim ping packet, but that would be the InSim delay and not necessarily the OutSim packet which contains vital information about the location of the car, actually I think OutSim/OutGauge are the required packets for the driver to work, InSim being great for the other car locations and general state. Since I run the AIRS world in a fixed time step, my thought was to take the network latency, some InSim state information about LFS timing (need to look it up), and the time stamps in the OutSim/OutGauge packets, and with this information I should be able to determine how much time has passed since the information has been updated.
**Ultimately I am a bit confused why this didn't work previously since I have essentially added this to the OutSim packs that are used for the artificial drivers car, so it is apparent to me that something must be wrong, but I've taken several looks into it and it seems correct. I'll keep digging and if I can get a smooth display to work, that should, in theory, make the prediction unit also become smooth.
***The curve code was initially meant to make the placement of track edges easier by creating a curve that went through all the reference points. Initially this sounded like a great idea because it does mean that less cones need to be used to create the corners. In hindsight it is not working quite as expected in all scenarios, particularly when there is a long straight section. The problem here is that the curve code can, in some situations, create a weird curve along a straight that sort of doubles back on itself. I ran into this issue in particular when I was trying to make a layout for the dragstrip (to get the artificial driver launching on green lights better) but unless I places a lot of cones all the way along the straight these silly curves came into play. I don't think it should be too hard to remove.
Given the issues I saw with the prediction unit, the jumpiness in the AIRS display and a general curiosity I think my next plan of action will be to find a way to accurately determine the difference between the LFS World time and the AIRS world time*. I know there is a delay in the communications, and I assume this delay to be 50-100ms, but will try determining it and maybe finding a way to make the display run smoothly, even if it needs some form of client prediction**.
The refactoring is going pretty good, I just need to finish removing the old bits of code that have been replaced, and hope that the issue, with the first lap 10 meters to the left of the racing line, never appears again. It didn't appear to be an issue due to refactoring though, perhaps a change or two before it but again I went through each change in each file since the copy that worked and found nothing that would have changed that behavior, so it was a strange issue that has since disappeared.
I've also had some interest from someone that may want to try creating some more track layouts to get the driver working on different tracks, but to do that I'll need to modify some of that code again for improvements, probably something I should have done a long time ago anyway. This won't be that difficult, I just need to add an additional step that sorts the track edge reference points by nearest before processing them - although I may end up removing the curve code I wrote.***
So the overall list of things I want to do with the project:
1) Remove the old bits of code from the new refactoring job.
2) Get an accurate calculation of the LFS-AIRS time difference.
3) Improve the layout parsing to not be so strict about ordering.
4) Remove parts of the "to curve" in the layout parsing where it caused issued.
5) Process the track to create reference points where corners, straights and braking points are.
6) Detect if the car is accelerating or decelerating at the limit.
7) Detect if the car is understeering or oversteering.
8) Create a new driving state behavior that uses the braking point references and limit detection to modify the braking point.
Hopefully when I get these steps complete the driver will have a more clear sense of the information, (hopefully not so jumpy?), and with any luck with modifying brake points and driving at the limit of the cars capabilities should make the driver faster. I would really like to see a time in the 57 to 58 second range on FE1 with the XRG once the driver understands the limits of the car. I would be shocked and amazed if the times are in the 53 to 55 second range. This is not world record pace by any means, but currently the PB of airs_artificial_driver is 1:01.70
*I'm not entirely sure how to do this accurately as there are actually many parts to the problem including the network latency. I should be able to figure that out with the InSim ping packet, but that would be the InSim delay and not necessarily the OutSim packet which contains vital information about the location of the car, actually I think OutSim/OutGauge are the required packets for the driver to work, InSim being great for the other car locations and general state. Since I run the AIRS world in a fixed time step, my thought was to take the network latency, some InSim state information about LFS timing (need to look it up), and the time stamps in the OutSim/OutGauge packets, and with this information I should be able to determine how much time has passed since the information has been updated.
**Ultimately I am a bit confused why this didn't work previously since I have essentially added this to the OutSim packs that are used for the artificial drivers car, so it is apparent to me that something must be wrong, but I've taken several looks into it and it seems correct. I'll keep digging and if I can get a smooth display to work, that should, in theory, make the prediction unit also become smooth.
***The curve code was initially meant to make the placement of track edges easier by creating a curve that went through all the reference points. Initially this sounded like a great idea because it does mean that less cones need to be used to create the corners. In hindsight it is not working quite as expected in all scenarios, particularly when there is a long straight section. The problem here is that the curve code can, in some situations, create a weird curve along a straight that sort of doubles back on itself. I ran into this issue in particular when I was trying to make a layout for the dragstrip (to get the artificial driver launching on green lights better) but unless I places a lot of cones all the way along the straight these silly curves came into play. I don't think it should be too hard to remove.
This is working a lot better than not at all. It works great when I don't have to click inside to restart the race, reset the car or other issues. Thanks for the help guys!
After a little bit of trouble (from running another copy of LFS and forgetting to turn of OutSim and OutGauge messages) I think I fixed a few issues that I ran into with the detecting the artificial driver's car.
First I had previously been checking to see if it was player controlled, which worked great while I was doing this solo, it controls the only "player" car. But when other people joined the server and jumped in the session, this confused the artificial driver code, a lot. That was easy to solve.
When that wasn't confusing the driver there was a situation where the driver would constant try starting the car, even though the car was already turned on because he was getting the wrong OutGauge info. I'm not sure how that is, maybe it was based on the previous stuff, or during my tests because OutGauge was sending packets (from two copies of LFS) when I wasn't expecting it. This has also been addressed, so I think the AI driver will behave better with other players on the server now, but only time will tell.
First I had previously been checking to see if it was player controlled, which worked great while I was doing this solo, it controls the only "player" car. But when other people joined the server and jumped in the session, this confused the artificial driver code, a lot. That was easy to solve.
When that wasn't confusing the driver there was a situation where the driver would constant try starting the car, even though the car was already turned on because he was getting the wrong OutGauge info. I'm not sure how that is, maybe it was based on the previous stuff, or during my tests because OutGauge was sending packets (from two copies of LFS) when I wasn't expecting it. This has also been addressed, so I think the AI driver will behave better with other players on the server now, but only time will tell.
It may not always be up but there were a few visitors earlier today that came to check out the broken driver as I described above. Want to know the hilarious thing, it isn't broke anymore ... at least it isn't reproducing currently.
There is some very weird gremlin somewhere. Gutholz was on the server as I rebuilt from a previous commit (thanks source control) and still ran into the same issue. So I went back even further and finally got a build that worked flawlessly. I stopped using the newest build because a few others had joined, and why not show the less idiotic driver...
Well, during the last hour I've been looking through every file and change in the all the diffs from previous to current and the only thing I think could remotely have the effect I'm seeing is changing the number of memories from 25 to 10, and even that sounds extremely odd to be a cause but is the closest possibility.
All the other changes were involved with separating the virtual controller class so I could, eventually, run LFS and the VirtualController on a different PC than the AIRS Brain for performance reasons, and maybe even server stability? None of the other changes should cause the driver to remain almost exactly 10 meters to the left of the racing line he is trying to drive on. Actually the driver logic didn't even change, beyond adding or moving the "WaitForGreenLights" state which I can't see how that could relate.
So, I update to the latest revision (the one just before my refactoring, the one that Gutholz watch fail) and it works flawlessly. I run the version I have refactored... it works flawlessly. NOTHING CHANGED from the time I started seeing these issues until now except perhaps several restarts of LFS and AIRS... What the hell. These are not fun gremlins or problems to deal with, and I'll be happy if the driver never attempts to drive 10m to the left of the racing line.
Oh, and when he was driving 10m to the left, everything from my debug visuals shows that he knows he should be 10m to the right to get on line. It shows that the desired angle is greater than he was actually turning. Which at one point had me wondering about hitting some buttons that reinitialized controls to have caused the problem, except I even tried recalibrating them to offset that possibility. Honestly, I'm at a loss of what possibly could cause this behavior.
Now on to some more fun stuff: Forward Progress.
There is some very weird gremlin somewhere. Gutholz was on the server as I rebuilt from a previous commit (thanks source control) and still ran into the same issue. So I went back even further and finally got a build that worked flawlessly. I stopped using the newest build because a few others had joined, and why not show the less idiotic driver...
Well, during the last hour I've been looking through every file and change in the all the diffs from previous to current and the only thing I think could remotely have the effect I'm seeing is changing the number of memories from 25 to 10, and even that sounds extremely odd to be a cause but is the closest possibility.
All the other changes were involved with separating the virtual controller class so I could, eventually, run LFS and the VirtualController on a different PC than the AIRS Brain for performance reasons, and maybe even server stability? None of the other changes should cause the driver to remain almost exactly 10 meters to the left of the racing line he is trying to drive on. Actually the driver logic didn't even change, beyond adding or moving the "WaitForGreenLights" state which I can't see how that could relate.
So, I update to the latest revision (the one just before my refactoring, the one that Gutholz watch fail) and it works flawlessly. I run the version I have refactored... it works flawlessly. NOTHING CHANGED from the time I started seeing these issues until now except perhaps several restarts of LFS and AIRS... What the hell. These are not fun gremlins or problems to deal with, and I'll be happy if the driver never attempts to drive 10m to the left of the racing line.
Oh, and when he was driving 10m to the left, everything from my debug visuals shows that he knows he should be 10m to the right to get on line. It shows that the desired angle is greater than he was actually turning. Which at one point had me wondering about hitting some buttons that reinitialized controls to have caused the problem, except I even tried recalibrating them to offset that possibility. Honestly, I'm at a loss of what possibly could cause this behavior.
Now on to some more fun stuff: Forward Progress.
Ahh, I see. Well, in interesting news I have had no issues just calling SetCooperativeLevel() BACKGROUND | EXLCUSIVE on all devices, LFS works just normally.
I even managed, after watching @DANIEL-CRO's video a few times, to successfully control LFS when it did not have focus. However, it will still mess up my AI driver to lose control for the moment it takes to get it to work. Still, better than nothing so I will keep the injected DLL where it is.
I've also tried modifying the AIRS application to hijack the Window Procedure of LFS to intercept the "WM_KILLFOCUS" and "WM_ACTIVATE" messages to attempt to hijack and not let LFS think it is inactive- but this ultimately failed, I think because the LFS window class is created from a different process... Go figure. So I think I've got it working as well as it is going to work.
Essentially what I need to do when changing out is focus an application from the task bar, then click it again to give LFS the focus back, but before LFS gains full focus reclick the task bar a final time and if successful, LFS will still collect input.
I even managed, after watching @DANIEL-CRO's video a few times, to successfully control LFS when it did not have focus. However, it will still mess up my AI driver to lose control for the moment it takes to get it to work. Still, better than nothing so I will keep the injected DLL where it is.
I've also tried modifying the AIRS application to hijack the Window Procedure of LFS to intercept the "WM_KILLFOCUS" and "WM_ACTIVATE" messages to attempt to hijack and not let LFS think it is inactive- but this ultimately failed, I think because the LFS window class is created from a different process... Go figure. So I think I've got it working as well as it is going to work.
Essentially what I need to do when changing out is focus an application from the task bar, then click it again to give LFS the focus back, but before LFS gains full focus reclick the task bar a final time and if successful, LFS will still collect input.
It didn't seem to be crashing when I tried with exclusive and background, but only when I added the message box, so I assumed kicking LFS out of focus at that moment caused it to handle a message wrong. I will keep trying though. It would be really awesome to get it working so I won't give up just yet. Thanks for the information. I'm not quite sure what is happening in Step 3 though, although that may be because I should only need to worry about SetCooperativeLevel and not actually in CreateDevice, just check to make sure I'm dealing with the right device, I'll give it a go.
FGED GREDG RDFGDR GSFDG