This mornings developments went fairly well I actually found a bit more code to cleanup and wrapping up that task, I actually made acouple admin commands to change car and track. Now typing !car xfg will cause the driver to spectate, pit, select the car, select his setup, rejoin the race and restart. This was something I previously did manually. He can also change tracks, although I suspect that one could use a little work as I currently wait for 10 seconds for track to load and having had LFS on my surface connected to the server I know some track loads took longer, which will cause that to fail. (Not to mention AIRS still has a bug that -something- is a little odd during track reload, I found a few possibilities during code cleanup that I fixed, but it seems to still have a lingering issue.
This evening so far I've modified his downshifting behavior, so he no longer gets on the throttle after/while downshifting. He will blip the throttle though. The results are not as conclusive as I thought the would be. I didn't expect massive gains, but during the first test, (not shown) it started looking pretty clear that he was indeed faster, nearly a tenth faster than his fastest lap in a previous run. But he had an issue, I guess a potential edge case in detecting which phase he is in caused him to miss a braking point completely.
Before, downshifting with poor throttle usage
After, downshifting with no throttle usage
Here you can see the before and after effects of the changes. In the displayed graph the green, red, blue lines represent throttle, brake and clutch usages respectively. (Orange is steering) While the first test looked great, you can see the results in these images show the times are pretty much identical so the change is minute enough not to matter.
I'm going to attempt to change his threshold braking behavior next. This is currently what it looks like as he gets near the desired entry speed of the corner:
You can see that he is braking hard for quite a bit of time, but for about the same length of time he starts easing off the brake and has a really long tail. The new behavior should have him brake harder longer than ease off, probably a fair bit quicker. I've got to let him train some more on the track though since I can't run the test in the exact same manner, if I did the lap times would get slower to prove it worked (since he wouldn't modify braking distance to match the new braking behavior). But in allowing him to just modify his braking distance, without being fully trained at a track how am I to know if his improvements were just there all along? So he is now training at FE2 with XRG.
This is the new braking chart, (may be for a different corner), but you can notice he hits the brakes a bit quicker, harder and doesn't let the trail off quite the same way. I was a bit silly and didn't save the test run data for his previous training run, but he did manage to do a lap that was 0.64 seconds faster than his old PB, whether that was just all corner memories lining up well or because of the new braking is hard to say. But I think from the graph it should be better.
This evening so far I've modified his downshifting behavior, so he no longer gets on the throttle after/while downshifting. He will blip the throttle though. The results are not as conclusive as I thought the would be. I didn't expect massive gains, but during the first test, (not shown) it started looking pretty clear that he was indeed faster, nearly a tenth faster than his fastest lap in a previous run. But he had an issue, I guess a potential edge case in detecting which phase he is in caused him to miss a braking point completely.
Before, downshifting with poor throttle usage
After, downshifting with no throttle usage
Here you can see the before and after effects of the changes. In the displayed graph the green, red, blue lines represent throttle, brake and clutch usages respectively. (Orange is steering) While the first test looked great, you can see the results in these images show the times are pretty much identical so the change is minute enough not to matter.
I'm going to attempt to change his threshold braking behavior next. This is currently what it looks like as he gets near the desired entry speed of the corner:
You can see that he is braking hard for quite a bit of time, but for about the same length of time he starts easing off the brake and has a really long tail. The new behavior should have him brake harder longer than ease off, probably a fair bit quicker. I've got to let him train some more on the track though since I can't run the test in the exact same manner, if I did the lap times would get slower to prove it worked (since he wouldn't modify braking distance to match the new braking behavior). But in allowing him to just modify his braking distance, without being fully trained at a track how am I to know if his improvements were just there all along? So he is now training at FE2 with XRG.
This is the new braking chart, (may be for a different corner), but you can notice he hits the brakes a bit quicker, harder and doesn't let the trail off quite the same way. I was a bit silly and didn't save the test run data for his previous training run, but he did manage to do a lap that was 0.64 seconds faster than his old PB, whether that was just all corner memories lining up well or because of the new braking is hard to say. But I think from the graph it should be better.
Last edited by blackbird04217, .
I was going to make a nice image with all the tracks, well some/most of them, to compare the old corner detection with the new. I even started going through the trouble of starting to capture these pictures before I realized they were inaccurate due to the, as if this won't be confusing, detecting what color to use at a specific point on the track. This is because the corner points are defined as distances around the racing line, and the color points are not. I spent a bit of time trying to fix it but honestly, it wasn't worth the effort in the end.
I could color the wrong spots in manually if I saved the images again, this time with the corner lines. But I probably won't as it would be time consuming and add little value besides being able to look back at the measured change.
If you have followed the project long enough you may remember that there was a time that I did not load the track information from the LFS PTH files and instead used a custom made layout to define the left and right edge of the track. This method was error prone, to say the least, but it did have some advantages. For instance the custom made layout could define the edge for dangerous or safe curbing better than the PTH files seem to, however the PTH files were much easier, less time consuming and simply work at all tracks.
I remind you of this because going forward there will no longer be a way to make the custom layouts to define track edges. ALL tracks will use whatever LFS supplied in the PTH files which is not always optimal but it simplifies some code, quite a bit actually.
Major code cleanup project has begun. So obviously I dropped processing the track edge information from layout files, but I've also found a few unused test algorithms for various things. Corner detection algorithm v1 has now been thrown away as well, since it is clear v2 is better overall; more simple, less edge cases and generally better corners detected. Altogether so far I've dropped 2850 lines of code and a handful of files. Keep in mind should I ever need any of it, I can use source control to get it back, but that is unlikely. It does feel scary and weird to delete all that code from the code base, even with source control That was about 10% of the total code.
Moving forward
-------------------------------------
Now that CDv2 is finally complete I think I might start digging into some behavioral changes, starting first with the way driving memories are stored, saved and loaded. I would really like the driver to keep track of the driving memories for each corner that led to the best elapsed time through the corner, and the best exit speed out of the corner. This might make it easier, or more reliable, to test personal bests after learning the track for awhile.
This morning I actually had another idea for CDv2 which I may consider adding. It could fix the issue at BL1 with the right/left turns at end of sector two by separating into two corners instead of one. I'm not sure yet if I will actually implement it, but essentially it would take a final pass over the color data looking for turns that go both left and right, then seeing if a straight section exists that is worth splitting. I do need to be careful, because FE1 chicane should be a single turn.
Another driving behavior idea I've been watching recently is the tendency to let off the brakes early. Say the driver is coming down a long straight at 100mph, and enters a braking zone for a corner with desired speed of 40mph. He will start braking hard for a bit, but as he gets down to 50mph he will start releasing the brakes and this extends his braking distance fairly significantly. He will still need to transition off brakes smoothly, but should threshold brake all the way to desired speed.
It would be very nice to get the driver to be better with higher powered rear-wheel drive vehicles. He is pretty good at XRG and XRT, even LX4 is usually okay. But some others have too much power and snappiness to them, so when coming out of the turn he should be a little more cautious before just slamming the pedal to the floor.
While I'm at it, driver logic v2 was written fairly quickly, and if you remember at first it failed to prove as interesting as I had expected, but finally got that worked out. With this I was a little silly and have recently had the brilliant idea that IF the driver goes beyond the limit in a particular corner, he shall immediately start going slower.
And finally going forward I would really like to find a way to get the driver to drive more precisely. Which will definitely be challenging, and it will very likely slow him down but at the same time make some tracks less of an issue by keeping him ON TRACK. (Like AS2).
EDIT: Forgot to mention that I'd like to revisit the prediction algorithm. Currently it is unused because it was not consistent or reliable. I'd like to figure out what might be causing that, and I think perhaps a longer time span may actually help make it more reliable.
Watching Jared run laps at BL1R in the LX6 I'm realizing his downshifting needs work. As in, he blips the throttle fairly well, but then after engaging the desired gear it appears he gets on throttle quickly while releasing the clutch. Like you would for up-shifting, this is potentially upsetting the car balance, but more importantly increasing time it takes to stop, if even by tiny amounts.
That would be all I have for this report. Stay tuned and come say hello on the testing server. I'm letting him train at various combinations and in most cases he is beating old personal best times.
I could color the wrong spots in manually if I saved the images again, this time with the corner lines. But I probably won't as it would be time consuming and add little value besides being able to look back at the measured change.
If you have followed the project long enough you may remember that there was a time that I did not load the track information from the LFS PTH files and instead used a custom made layout to define the left and right edge of the track. This method was error prone, to say the least, but it did have some advantages. For instance the custom made layout could define the edge for dangerous or safe curbing better than the PTH files seem to, however the PTH files were much easier, less time consuming and simply work at all tracks.
I remind you of this because going forward there will no longer be a way to make the custom layouts to define track edges. ALL tracks will use whatever LFS supplied in the PTH files which is not always optimal but it simplifies some code, quite a bit actually.
Major code cleanup project has begun. So obviously I dropped processing the track edge information from layout files, but I've also found a few unused test algorithms for various things. Corner detection algorithm v1 has now been thrown away as well, since it is clear v2 is better overall; more simple, less edge cases and generally better corners detected. Altogether so far I've dropped 2850 lines of code and a handful of files. Keep in mind should I ever need any of it, I can use source control to get it back, but that is unlikely. It does feel scary and weird to delete all that code from the code base, even with source control That was about 10% of the total code.
Moving forward
-------------------------------------
Now that CDv2 is finally complete I think I might start digging into some behavioral changes, starting first with the way driving memories are stored, saved and loaded. I would really like the driver to keep track of the driving memories for each corner that led to the best elapsed time through the corner, and the best exit speed out of the corner. This might make it easier, or more reliable, to test personal bests after learning the track for awhile.
This morning I actually had another idea for CDv2 which I may consider adding. It could fix the issue at BL1 with the right/left turns at end of sector two by separating into two corners instead of one. I'm not sure yet if I will actually implement it, but essentially it would take a final pass over the color data looking for turns that go both left and right, then seeing if a straight section exists that is worth splitting. I do need to be careful, because FE1 chicane should be a single turn.
Another driving behavior idea I've been watching recently is the tendency to let off the brakes early. Say the driver is coming down a long straight at 100mph, and enters a braking zone for a corner with desired speed of 40mph. He will start braking hard for a bit, but as he gets down to 50mph he will start releasing the brakes and this extends his braking distance fairly significantly. He will still need to transition off brakes smoothly, but should threshold brake all the way to desired speed.
It would be very nice to get the driver to be better with higher powered rear-wheel drive vehicles. He is pretty good at XRG and XRT, even LX4 is usually okay. But some others have too much power and snappiness to them, so when coming out of the turn he should be a little more cautious before just slamming the pedal to the floor.
While I'm at it, driver logic v2 was written fairly quickly, and if you remember at first it failed to prove as interesting as I had expected, but finally got that worked out. With this I was a little silly and have recently had the brilliant idea that IF the driver goes beyond the limit in a particular corner, he shall immediately start going slower.
And finally going forward I would really like to find a way to get the driver to drive more precisely. Which will definitely be challenging, and it will very likely slow him down but at the same time make some tracks less of an issue by keeping him ON TRACK. (Like AS2).
EDIT: Forgot to mention that I'd like to revisit the prediction algorithm. Currently it is unused because it was not consistent or reliable. I'd like to figure out what might be causing that, and I think perhaps a longer time span may actually help make it more reliable.
Watching Jared run laps at BL1R in the LX6 I'm realizing his downshifting needs work. As in, he blips the throttle fairly well, but then after engaging the desired gear it appears he gets on throttle quickly while releasing the clutch. Like you would for up-shifting, this is potentially upsetting the car balance, but more importantly increasing time it takes to stop, if even by tiny amounts.
That would be all I have for this report. Stay tuned and come say hello on the testing server. I'm letting him train at various combinations and in most cases he is beating old personal best times.
Last edited by blackbird04217, .
Before deleting the code for the old Corner Detection algorithm, I figured I will gather some pictorial evidence of what changed. Here is a quick shot of BL1 changes, before (CDv1) on the left.
Last edited by blackbird04217, .
Still too early to tell, but the driver was a teeny bit faster at FE1 with a bad racing line. Because FE1 and a few other tracks had custom layouts instead of PTH files. When I was testing the CDv2 apparently it was no longer loading the layout for FE1 (and others), so all the tracks were using the PTH files for defining left/right edges, thus the algorithm got configured with PTH files.
What this meant is that the line through the chicane actually became more S like than it was previously, which is slower, and the sharp corner at the back winds up too sharp so the driver hits the curb and rises on two wheels loosing speed. However, because CDv2 split corners better the driver is still actually faster and could, I believe, hit a 56:2x if things went right.
I knew Westhill didn't have a layout file so started testing there next, but the driver had only done 78 laps, with who knows what fuel load. That said after 78 laps on CDv1 he had a PB of 2:25.77, with splits 57.10 and 1:28.28. After only 20 laps, learning from 0, he has managed to get down to a 2:18.30 and I'm sure still loosing time.
That definitely points to good things ahead! Unfortunately all the tracks I had tested on seem like they had layout paths, and the racing line can change that much. I have thoughts on racing line v2, but I have other things I want to tackle first, like a new "driving memory" system that allows him to keep memories of the best elapsed time through a corner, best exit speed etc, which I will work on once I get some code cleaned up.
Will be deleting the old corner detection logic (will always exist in source control) and all the testing hackery that I did to tune corner detection v2.
Can definitely tell I caught the bug again and hope to work on this for a bit to come now that I finally got beyond CDv2. Lets go test some other tracks!
EDIT: A few more data points.
Looks like at AS2 he can drive a bit better. I know AS2 was once a layout track, but even with PTH file he had issues braking for last turn as he would go wide into grass. It looks like this still happens in XRT but after doing many more laps than previously and his best time was improved a lot.
I've also given him some laps at BL1, but that also was a layout track (I believe it used the layout) that is now using the PTH file. Even so the old corner detection combined first turn and chicane as one corner, and this now splits into 3 corners. The driver gained 2 seconds in sector 1 with the XRT. [u]Unfortunately[u] the racing line changed a fair bit (maybe using the standard amount of iterations for racing line) and the line now uses a bit too much curbing in sector 2 which he loses all the time gained, and the more time lost in sector 3, I think also because of curbs.
What is super unfortunate is I don't have a real good test of old and new corner detection versions because of the path file mess. I would have continued to use the layout, but anyone that saw the live stream saw that blew up in my face. The layout edges were bumpy enough that most of the track was declared turning.
I could flip back to the old Corner Detector to run some tests and I am thinking about doing that to get actual data but I think it has already proven to be better overall, even if BL1 with XRT wasn't doing better. (It wasn't doing that much worse, and maybe with a long run with full fuel would help).
EDIT 2: For the first time ever the driver can go on KY1 because of corner logic changes. Will take him a long time to lift the corner speeds to reasonable levels, but given the difference to other tracks, I'm wondering what happens there!
What this meant is that the line through the chicane actually became more S like than it was previously, which is slower, and the sharp corner at the back winds up too sharp so the driver hits the curb and rises on two wheels loosing speed. However, because CDv2 split corners better the driver is still actually faster and could, I believe, hit a 56:2x if things went right.
I knew Westhill didn't have a layout file so started testing there next, but the driver had only done 78 laps, with who knows what fuel load. That said after 78 laps on CDv1 he had a PB of 2:25.77, with splits 57.10 and 1:28.28. After only 20 laps, learning from 0, he has managed to get down to a 2:18.30 and I'm sure still loosing time.
That definitely points to good things ahead! Unfortunately all the tracks I had tested on seem like they had layout paths, and the racing line can change that much. I have thoughts on racing line v2, but I have other things I want to tackle first, like a new "driving memory" system that allows him to keep memories of the best elapsed time through a corner, best exit speed etc, which I will work on once I get some code cleaned up.
Will be deleting the old corner detection logic (will always exist in source control) and all the testing hackery that I did to tune corner detection v2.
Can definitely tell I caught the bug again and hope to work on this for a bit to come now that I finally got beyond CDv2. Lets go test some other tracks!
EDIT: A few more data points.
Looks like at AS2 he can drive a bit better. I know AS2 was once a layout track, but even with PTH file he had issues braking for last turn as he would go wide into grass. It looks like this still happens in XRT but after doing many more laps than previously and his best time was improved a lot.
I've also given him some laps at BL1, but that also was a layout track (I believe it used the layout) that is now using the PTH file. Even so the old corner detection combined first turn and chicane as one corner, and this now splits into 3 corners. The driver gained 2 seconds in sector 1 with the XRT. [u]Unfortunately[u] the racing line changed a fair bit (maybe using the standard amount of iterations for racing line) and the line now uses a bit too much curbing in sector 2 which he loses all the time gained, and the more time lost in sector 3, I think also because of curbs.
What is super unfortunate is I don't have a real good test of old and new corner detection versions because of the path file mess. I would have continued to use the layout, but anyone that saw the live stream saw that blew up in my face. The layout edges were bumpy enough that most of the track was declared turning.
I could flip back to the old Corner Detector to run some tests and I am thinking about doing that to get actual data but I think it has already proven to be better overall, even if BL1 with XRT wasn't doing better. (It wasn't doing that much worse, and maybe with a long run with full fuel would help).
EDIT 2: For the first time ever the driver can go on KY1 because of corner logic changes. Will take him a long time to lift the corner speeds to reasonable levels, but given the difference to other tracks, I'm wondering what happens there!
Last edited by blackbird04217, .
Yup, P2 is working, I shall try staying with the patches a bit better, especially when the notes include improvements to something I had issue with! Thanks and keep at it!
Yesterday I was able to change the way the driver detects the phase of the corner he is in. This is one of the changes needed to fix the braking before preceding corner issues. It took a while to get it working as I intended since it works in a VERY different way, and the track I was testing at, AS1, luckily had an edge case that I got to solve all at the same time.
Then I went to test the brake point before the preceding corner issue, since I had a test case there already setup. And the issue continued. I had some other stuff to do so I paused that and went on.
Moments after setting it down I realized that the code I wrote was actually just a replacement of finding his current corner phase, not anything that would properly deal with the brake point issue. No wonder why it didn't work! A few hours later when I finally got back to the project I spent the rest of the day working on detecting the brake point issue. Most of it streamed live on www.livecoding.tv/timbeaudet, but it was really just me fumbling around. I did find and solve an interesting edge case when connecting AIRS to a copy of LiveForSpeed when there is NO cars on track.
Then I went to bed, but couldn't sleep because that issue just kept lingering. Unsolved. Haunting me. Taunting me! As I slipped into the state a bit beyond being awake and just a bit before actually sleeping, it hit me like a freight train. I had been trying to make as few changes as possible, but I've had a better method of tracking this phase in mind. It was the perfect solution to both problems, and actually doesn't change all that much logically. (Still the minor change of actually detecting the BP before preceding corner issue, but that is a needed change)
I went back to the computer and slammed some keys around, and BAM, first test worked flawlessly with the same old normal behavior. I added a tiny bit more and two tests later, the same time the SpaceX rocket landed on it's platform, it finally worked. It finally stayed in T1 braking even after getting into T5 Apex and T5 Exit. The coincidence in timing was amazing because just as I got super excited that it FINALLY worked the way I wanted it to work, the SpaceX team/crowd watching started cheering and screaming with joy.
That was all me.
----
This morning I plan on wrapping up a handful of things, I would like to make it so he can track both that he is in T5 Apex/Exit -and- the T1 Braking. It shouldn't be terribly hard, and might not be super important but it is related to the small change(s) I want to make to his learning behavior so that he can actually modify the T1 Braking point distance. This change is one that is required for testing CDv2 accurately, and unfortunately is -actually- likely to change the behavior enough that the tests I ran won't be 100% accurate that any laptime changes were due to the Corner Detection v2 changes.
Sorry if that barely made sense I rewrote it a few times and it came out a bit thick.
At NOON my time, (12:00pm EST), I will do my best to attempt running Jared using CDv2 for the very first time. I will do this live on stream and you can also join the party on the server. There will be no other cars driving on track during this particular test.
What this means for you:
Come Join/Watch the LiveStream at 12:00pm EST or 4:00pm UTC
Then I went to test the brake point before the preceding corner issue, since I had a test case there already setup. And the issue continued. I had some other stuff to do so I paused that and went on.
Moments after setting it down I realized that the code I wrote was actually just a replacement of finding his current corner phase, not anything that would properly deal with the brake point issue. No wonder why it didn't work! A few hours later when I finally got back to the project I spent the rest of the day working on detecting the brake point issue. Most of it streamed live on www.livecoding.tv/timbeaudet, but it was really just me fumbling around. I did find and solve an interesting edge case when connecting AIRS to a copy of LiveForSpeed when there is NO cars on track.
Then I went to bed, but couldn't sleep because that issue just kept lingering. Unsolved. Haunting me. Taunting me! As I slipped into the state a bit beyond being awake and just a bit before actually sleeping, it hit me like a freight train. I had been trying to make as few changes as possible, but I've had a better method of tracking this phase in mind. It was the perfect solution to both problems, and actually doesn't change all that much logically. (Still the minor change of actually detecting the BP before preceding corner issue, but that is a needed change)
I went back to the computer and slammed some keys around, and BAM, first test worked flawlessly with the same old normal behavior. I added a tiny bit more and two tests later, the same time the SpaceX rocket landed on it's platform, it finally worked. It finally stayed in T1 braking even after getting into T5 Apex and T5 Exit. The coincidence in timing was amazing because just as I got super excited that it FINALLY worked the way I wanted it to work, the SpaceX team/crowd watching started cheering and screaming with joy.
That was all me.
----
This morning I plan on wrapping up a handful of things, I would like to make it so he can track both that he is in T5 Apex/Exit -and- the T1 Braking. It shouldn't be terribly hard, and might not be super important but it is related to the small change(s) I want to make to his learning behavior so that he can actually modify the T1 Braking point distance. This change is one that is required for testing CDv2 accurately, and unfortunately is -actually- likely to change the behavior enough that the tests I ran won't be 100% accurate that any laptime changes were due to the Corner Detection v2 changes.
Sorry if that barely made sense I rewrote it a few times and it came out a bit thick.
At NOON my time, (12:00pm EST), I will do my best to attempt running Jared using CDv2 for the very first time. I will do this live on stream and you can also join the party on the server. There will be no other cars driving on track during this particular test.
What this means for you:
Come Join/Watch the LiveStream at 12:00pm EST or 4:00pm UTC
Could not set up FF steer device
I have posted this in Test Patch as well, but it might be a general issue.
I had to contact Logitech about my G27 because of calibration issues and they "upgraded" me to a G29. However when I try using it in LFS I can't get FFB to work. LFS reports:
"CreateEffect failed (0 axes)"
"Could not setup FF steer device"
I've tried using both device 1 and 2 for the FF device and the G29 is listed first on the controller list so I'd expect 1 to be the proper device, but doesn't work.
The FFB of the G29 works as expected in iRacing.
I had to contact Logitech about my G27 because of calibration issues and they "upgraded" me to a G29. However when I try using it in LFS I can't get FFB to work. LFS reports:
"CreateEffect failed (0 axes)"
"Could not setup FF steer device"
I've tried using both device 1 and 2 for the FF device and the G29 is listed first on the controller list so I'd expect 1 to be the proper device, but doesn't work.
The FFB of the G29 works as expected in iRacing.
I'm going to post this in issues as well, since I am actually NOT on the test patch but am using 0.6P so it might be unrelated to test patch.
I had to contact Logitech about my G27 because of calibration issues and they "upgraded" me to a G29. However when I try using it in LFS I can't get FFB to work. LFS reports:
"CreateEffect failed (0 axes)"
"Could not setup FF steer device"
I've tried using both device 1 and 2 for the FF device and the G29 is listed first on the controller list so I'd expect 1 to be the proper device, but doesn't work.
-----------------------
Also, I came back after running LFS for a very long time and everything was running just fine on the track. Rendering as expected. I then ended the race, (or went to pits?), and got to see the attached view. Again this was 0.6P and unfortunately I don't have any information on how/why it happened, just fyi. I'll keep an eye out.
----
EDIT: If possible I have a few feature requests:
- A command to add an AI car of set difficulty, might be tricky now that there is /ai name, but I'd really like the ability to: "/ai easy /ai hard" or even use a number.
- In the back of my head I was digging into making a realtime telemetry tool, it sure would be nice if OutGaugePack had included steering wheel angle, but I suspect that is a PAIN to change since it would effect others using it by changing size.
- Any chance of an InSim message, or a command to print the locally used setup? I know you can see it on F12, but that doesn't help my AIRS driver safety check that it used the correct setup. To be fair I understand if that would be a waste of your time since I'm probably the only one to find this useful. I had hoped that it was in Display2[] on OutGuagePack but no such luck.
I had to contact Logitech about my G27 because of calibration issues and they "upgraded" me to a G29. However when I try using it in LFS I can't get FFB to work. LFS reports:
"CreateEffect failed (0 axes)"
"Could not setup FF steer device"
I've tried using both device 1 and 2 for the FF device and the G29 is listed first on the controller list so I'd expect 1 to be the proper device, but doesn't work.
-----------------------
Also, I came back after running LFS for a very long time and everything was running just fine on the track. Rendering as expected. I then ended the race, (or went to pits?), and got to see the attached view. Again this was 0.6P and unfortunately I don't have any information on how/why it happened, just fyi. I'll keep an eye out.
----
EDIT: If possible I have a few feature requests:
- A command to add an AI car of set difficulty, might be tricky now that there is /ai name, but I'd really like the ability to: "/ai easy /ai hard" or even use a number.
- In the back of my head I was digging into making a realtime telemetry tool, it sure would be nice if OutGaugePack had included steering wheel angle, but I suspect that is a PAIN to change since it would effect others using it by changing size.
- Any chance of an InSim message, or a command to print the locally used setup? I know you can see it on F12, but that doesn't help my AIRS driver safety check that it used the correct setup. To be fair I understand if that would be a waste of your time since I'm probably the only one to find this useful. I had hoped that it was in Display2[] on OutGuagePack but no such luck.
Last edited by blackbird04217, .
Well well well, this is starting to get interesting. I spent about 2 hours tuning the various settings attempting to come up with the best "all around" Corner Detection v2 algorithm that I can. I may still tune it some more, or change/add to it as I see fit however, I have technically computed the Braking, Entry, Apex and Exit points for the tracks in a different way.
The apex is computed slightly better than before, or at least, slightly differently. It walks backwards from exit along the racing line and waits until the corner starts to open back up, meaning it finds the from exit walking backwards the tightest radius of the line. Unfortunately this isn't perfect, especially for left/right chicane like turns, or those that have an racing line near exit that is practically straight due to the next turn. But it works.
It also gives me a new idea, but it would require behavior changes and I'm attempting to hold off on those, (as much as possible anyway since some changes are necessary), until after I get Corner Detection v2 with some test runs for comparison.
So why haven't I started the test runs if the algorithm is mostly done?!
Well, because unfortunately some of the braking points are intersecting or before previous corners. The driver currently detects his corner phase ONLY when crossing one of the lines, so this actually isn't a trivial change, and unfortunately will change his behavior at least a little and I was trying not to do that so we could prove the improvements were caused by CDv2. While making these changes I will make every effort to keep the behavior as identical as I can to what it is now, however, the braking logic for the turn further up the road may, or may not, override the current phase of the corner he may be in at the moment and that is essentially changing behavior.
His memory modifications and such will all remain the same, for now, however I am seriously looking to getting CDv2 tested and hopefully everyone else is as well! The debug visuals for most tracks look very promising. BlackWood remains similar to CDv1, although CDv2 is a bit better for sector 1. I am worried the driver will fail at South City Classic because there is an issue detecting the chicane as a corner. Just the way the path file is, the turn is tight but so short it gets dropped as noise. I have an idea for this, I just haven't figured out if I want to continue modifying CDv2 or not. (Really I don't want to as I want to get it tested already, but it might be worth doing it right since I probably won't iterate it for awhile).
Well, I'm off for the night. I'll get back to it in the morning.
----
EDIT: Later that night, continued working. Fixed the South City Classic issue by NOT removing gaps if a high angle was found. Didn't effect any other tracks, so hopefully that was worth it... But I may be able to do the same for keeping gaps that are straight enough as well, and that might help at blackwood and potentially others, though, I'm not doing that one tonight, because it is time for bed!
The apex is computed slightly better than before, or at least, slightly differently. It walks backwards from exit along the racing line and waits until the corner starts to open back up, meaning it finds the from exit walking backwards the tightest radius of the line. Unfortunately this isn't perfect, especially for left/right chicane like turns, or those that have an racing line near exit that is practically straight due to the next turn. But it works.
It also gives me a new idea, but it would require behavior changes and I'm attempting to hold off on those, (as much as possible anyway since some changes are necessary), until after I get Corner Detection v2 with some test runs for comparison.
So why haven't I started the test runs if the algorithm is mostly done?!
Well, because unfortunately some of the braking points are intersecting or before previous corners. The driver currently detects his corner phase ONLY when crossing one of the lines, so this actually isn't a trivial change, and unfortunately will change his behavior at least a little and I was trying not to do that so we could prove the improvements were caused by CDv2. While making these changes I will make every effort to keep the behavior as identical as I can to what it is now, however, the braking logic for the turn further up the road may, or may not, override the current phase of the corner he may be in at the moment and that is essentially changing behavior.
His memory modifications and such will all remain the same, for now, however I am seriously looking to getting CDv2 tested and hopefully everyone else is as well! The debug visuals for most tracks look very promising. BlackWood remains similar to CDv1, although CDv2 is a bit better for sector 1. I am worried the driver will fail at South City Classic because there is an issue detecting the chicane as a corner. Just the way the path file is, the turn is tight but so short it gets dropped as noise. I have an idea for this, I just haven't figured out if I want to continue modifying CDv2 or not. (Really I don't want to as I want to get it tested already, but it might be worth doing it right since I probably won't iterate it for awhile).
Well, I'm off for the night. I'll get back to it in the morning.
----
EDIT: Later that night, continued working. Fixed the South City Classic issue by NOT removing gaps if a high angle was found. Didn't effect any other tracks, so hopefully that was worth it... But I may be able to do the same for keeping gaps that are straight enough as well, and that might help at blackwood and potentially others, though, I'm not doing that one tonight, because it is time for bed!
Last edited by blackbird04217, .
Last night, this morning, and this afternoon has been quite busy for the AIRS project. I've been trying to run tests as constantly as possible, and some cars were failing pretty bad. It wasn't until I revisited the tried and true combo of XRG at FE1 that I realized what was happening. The "Modify at Apex" learning algorithm is faster, as I proved with data above, but it is less reliable. At FE1 the sharp right hand turn on the back stretch can cause issues, because after apex the corner tightens up enough that while getting on to the throttle the driver can slide.
Using the "Modify at Exit" approach this slide stays within reasonable limits, since the driver will keep the entry speed slower if a slide had occurred even between apex and exit in this mode. When using "Modify at Apex" the driver pays no attention to slip 'n slide behavior between apex and exit, so it gets worse, and worse, and whoops the car just spun. So while faster, it will definitely need behavior tuning after apex.
----
Last night I was working on a tool to visual the track corners as detected by the new corner detection. Surprising over the last few days I've had some break-through thoughts regarding the algorithm including a completely different way of looking at it. This was mostly triggered by my attempt to gather information. Instead of finding the first node less than a threshold, I instead mark each node that I think should be straight or corner, this has had some great results. The values still need some tuning but so far it is pretty promising.*
I also made a small menu tool that is so much easier to use than pressing random letters/numbers. Literally had about every letter and number used for increment/decrement these settings, so this debug menu tool simplified it a lot. On top of that I saved the basic track info for several tracks and created a way to quick load them for faster comparisons. I'm still trying to make the Corner Detection v2 combine small gaps, so say a small straight in a corner, or a small corner in a straight. To remove tiny errors within the detection that shouldn't bet there.
*There is one catch though, I will need to modify the drivers behaviors to protect against the braking point being before the exit of the corner preceding. The corners will definitely be much closer and the possibility for this to happen is definite. I will try to make as few changes to the behavior as possible, but this is actually a challenging problem to solve.
I plan to live stream tomorrow morning (approx. 11am UTC, give or take an hour) and it may be trying to find the "best fit" values for Corner Detection v2, which would theoretically be the final bit that needs to be done. Of which instead of using center line, or racing line to determine the corners, it seems like using left/right edges work even better!
Using the "Modify at Exit" approach this slide stays within reasonable limits, since the driver will keep the entry speed slower if a slide had occurred even between apex and exit in this mode. When using "Modify at Apex" the driver pays no attention to slip 'n slide behavior between apex and exit, so it gets worse, and worse, and whoops the car just spun. So while faster, it will definitely need behavior tuning after apex.
----
Last night I was working on a tool to visual the track corners as detected by the new corner detection. Surprising over the last few days I've had some break-through thoughts regarding the algorithm including a completely different way of looking at it. This was mostly triggered by my attempt to gather information. Instead of finding the first node less than a threshold, I instead mark each node that I think should be straight or corner, this has had some great results. The values still need some tuning but so far it is pretty promising.*
I also made a small menu tool that is so much easier to use than pressing random letters/numbers. Literally had about every letter and number used for increment/decrement these settings, so this debug menu tool simplified it a lot. On top of that I saved the basic track info for several tracks and created a way to quick load them for faster comparisons. I'm still trying to make the Corner Detection v2 combine small gaps, so say a small straight in a corner, or a small corner in a straight. To remove tiny errors within the detection that shouldn't bet there.
*There is one catch though, I will need to modify the drivers behaviors to protect against the braking point being before the exit of the corner preceding. The corners will definitely be much closer and the possibility for this to happen is definite. I will try to make as few changes to the behavior as possible, but this is actually a challenging problem to solve.
I plan to live stream tomorrow morning (approx. 11am UTC, give or take an hour) and it may be trying to find the "best fit" values for Corner Detection v2, which would theoretically be the final bit that needs to be done. Of which instead of using center line, or racing line to determine the corners, it seems like using left/right edges work even better!
Last edited by blackbird04217, .
Does anyone know if it is possible to link to the race results page (the one that shows the graphs above) for a given driver and given race?
I suspect it is impossible but this would make my life so much easier and more organized if that is indeed possible.
EDIT: This was actually possible, for the most part, by clicking on the small finish-line flag at the top left of the Online Race Results title bar and copying the link target. It doesn't link to the graph, but it is one click away.
I suspect it is impossible but this would make my life so much easier and more organized if that is indeed possible.
EDIT: This was actually possible, for the most part, by clicking on the small finish-line flag at the top left of the Online Race Results title bar and copying the link target. It doesn't link to the graph, but it is one click away.
Last edited by blackbird04217, .
It has been a week, and I've run the driver a bit and he definitely still needs a lot of help. For instance at Aston National (AS3) he does pretty good in XRG, but putting him in the XRT will cause him to go too wide, getting onto grass and spinning. FO8 has too much power and after the second hairpin he will apply too much throttle and spin, or mess up his learning algorithm.
This issue got me thinking, what if he modified his corner speed memory at corner APEX instead of corner EXIT. The thought being that after apex the driver is essentially trying to accelerate out of the corner, and in the case of FO8 at the second hairpin this action is what caused the corner speed to get lower and lower. A quick code change and the testing showed it improved his corner speed, but still failed to exit because of wheel spin.
I'm not going to tackle the changes to his cornering behavior after apex, so that won't get fixed, but I am going to collect data before moving forward. I've been theorizing for awhile now that a new corner detection algorithm will help improve his lap times. The only way to know if that is correct is to know what lap times the current algorithm is doing. So I will run 3 tests of about an hour in length (less if fuel limited) at a few different tracks and in several different cars using the current corner detection algorithm and the modify driving memory at exit, then repeat the tests 3 more times for modifying the driving memory at apex.
Modify at Apex Test 1
Modify at Apex Test 2
Modify at Exit Test 1
Modify at Exit Test 2
I've actually already run 2 of each for AS3/LX6 comparing apex vs exit memory modifications but that wasn't part of this bigger test I'm performing. The results are here, and unfortunately I'm confused by the second modify at exit test, which you can see starts with a faster lap than the others and the first few laps look drastically different, which makes me wonder if I had not cleared his memories completely at that start like I thought. You can also notice that in modify at exit test 1 the final lap was way slower, Jared wound up popping the front-left tire which previous test runs showed happened at lap 30. It seems to happen anywhere from lap 24-30 at random. This is likely caused from the car setup not locking the drive wheels first, and that is the only way for the driver to know the wheels are locked.
I'm hoping by the time I run all these tests, I will have Corner Detection v2 algorithm ready to use. And I will NOT be making any changes to his setup or driving behaviors during this time. The only change will be the corners get detected given the left/right edge of track, center line and racing line that he currently uses.
This issue got me thinking, what if he modified his corner speed memory at corner APEX instead of corner EXIT. The thought being that after apex the driver is essentially trying to accelerate out of the corner, and in the case of FO8 at the second hairpin this action is what caused the corner speed to get lower and lower. A quick code change and the testing showed it improved his corner speed, but still failed to exit because of wheel spin.
I'm not going to tackle the changes to his cornering behavior after apex, so that won't get fixed, but I am going to collect data before moving forward. I've been theorizing for awhile now that a new corner detection algorithm will help improve his lap times. The only way to know if that is correct is to know what lap times the current algorithm is doing. So I will run 3 tests of about an hour in length (less if fuel limited) at a few different tracks and in several different cars using the current corner detection algorithm and the modify driving memory at exit, then repeat the tests 3 more times for modifying the driving memory at apex.
Modify at Apex Test 1
Modify at Apex Test 2
Modify at Exit Test 1
Modify at Exit Test 2
I've actually already run 2 of each for AS3/LX6 comparing apex vs exit memory modifications but that wasn't part of this bigger test I'm performing. The results are here, and unfortunately I'm confused by the second modify at exit test, which you can see starts with a faster lap than the others and the first few laps look drastically different, which makes me wonder if I had not cleared his memories completely at that start like I thought. You can also notice that in modify at exit test 1 the final lap was way slower, Jared wound up popping the front-left tire which previous test runs showed happened at lap 30. It seems to happen anywhere from lap 24-30 at random. This is likely caused from the car setup not locking the drive wheels first, and that is the only way for the driver to know the wheels are locked.
I'm hoping by the time I run all these tests, I will have Corner Detection v2 algorithm ready to use. And I will NOT be making any changes to his setup or driving behaviors during this time. The only change will be the corners get detected given the left/right edge of track, center line and racing line that he currently uses.
Would an uninterruptible power supply help with that potential problem? My power flickers here and I've seen the lights drop while my rig and network remained connected because of the UPS.
Otherwise, I can't think of one beyond creating an application to listen for InSim messages to/from your server, but that might be overkill for your needs.
Otherwise, I can't think of one beyond creating an application to listen for InSim messages to/from your server, but that might be overkill for your needs.
It seems live I have indeed started working on the project again, and yesterday a few hours were spent fumbling around, on www.livecoding.tv/timbeaudet stream even, attempting to figure out a better way to detect those corners. I didn't really figure it out during that stream.
I then proceeded to clean up some of the code, which will make it easier to collect information about multiple tracks, including the ability now to zoom in and move that 2D track representation around to look at where corners are detected. I'm hoping with better tools I will get a better Corner Detection v2 algorithm developed.
I also found while testing that I had accidentally set the driver on the wrong setup. In general it is useful to always use the same setup so that any changes in his behavior or laptimes are due to, for the most part, actions I've taken by modifying code. With this I wonder if there is a way to get the current setup name from the local player.. I know I can see it on F12 screen, but I am hoping it could be displayed as text to the user, like a chat message, or, through InSim, which I found no options for. This could be useful so I could make the driver refuse to drive, or at least warn about unexpected setups.
This morning, so far, has been spent attempting to make the AIRS application a bit more friendly to disconnects. I've now made it so that if LFS is not running when I start AIRS it will show that it is disconnected from the racing sim. I can even press a button to attempt to connect again. However if it is connected and I abruptly kill LFS, the AIRS application can lock up with network issues. I'll be in good shape if I can fix that. Also among these changes, I've made it possible to go from the TrackDebugState into the RacingState, but that was minor., and useful.
After the abtupt kill issues, I've got a little more code cleanup to perform, hoping to remove lots of old code-rot from this 6+ year project, and then I've even got a few ideas for that new corner detection algorithm.
I then proceeded to clean up some of the code, which will make it easier to collect information about multiple tracks, including the ability now to zoom in and move that 2D track representation around to look at where corners are detected. I'm hoping with better tools I will get a better Corner Detection v2 algorithm developed.
I also found while testing that I had accidentally set the driver on the wrong setup. In general it is useful to always use the same setup so that any changes in his behavior or laptimes are due to, for the most part, actions I've taken by modifying code. With this I wonder if there is a way to get the current setup name from the local player.. I know I can see it on F12 screen, but I am hoping it could be displayed as text to the user, like a chat message, or, through InSim, which I found no options for. This could be useful so I could make the driver refuse to drive, or at least warn about unexpected setups.
This morning, so far, has been spent attempting to make the AIRS application a bit more friendly to disconnects. I've now made it so that if LFS is not running when I start AIRS it will show that it is disconnected from the racing sim. I can even press a button to attempt to connect again. However if it is connected and I abruptly kill LFS, the AIRS application can lock up with network issues. I'll be in good shape if I can fix that. Also among these changes, I've made it possible to go from the TrackDebugState into the RacingState, but that was minor., and useful.
After the abtupt kill issues, I've got a little more code cleanup to perform, hoping to remove lots of old code-rot from this 6+ year project, and then I've even got a few ideas for that new corner detection algorithm.
This thread is turning out to be an insane document of my thought process while I dig deeper into this AI project in non-traditional ways.
I got the driver running again and this morning I even made the WaitingOnGridAction multi-threaded so that the framerate didn't drop and the driver could keep the rpm's to a decent launch level.
I can't say I'll be making big updates to the project, but I've tossed the driver on XY3 for a bit and I really need to finish the new corner detection stuff because for these long tracks, or long sweeping corners, it is pretty painful. That will require a lot of "trial and error" which tends to zap my energy if results are not visible.
Along with that change I need to modify how the corner information is stored and accessed, along with how the driver modifies "memories" of the corner, what entry speed was safe, when to brake, etc. I really would like to see him have multiple memories to work from. And these memories need protection so the driver doesn't try increasing speeds above the cars potential in the area, or move a braking point before the exit of the preceding corner. This was causing Jared, the driver, to fail in some cases.
If I can manage to get that far there is also another thing related to the learning that needs some serious tweaking and that will also be a fair bit of trial and error unfortunately. This would be the limit detection algorithms and when the driver decides the car was pushed TOO HARD or not hard enough. Currently if he slips for even a moment above a threshold it triggers the "backoff" behavior and will go slower the next lap. But I've noticed that doesn't necessarily mean he went beyond the limit enough to back off.
There are tons of other things to address also;
- massive code clean up required
- better spin recovery, which is currently still pretty awful
- handling cold tires, especially on slicks
- auto save/load of memories for a track (vs manual)
So if I do get some momentum going for the project first priorities are:
- Some code cleanup (also helps getting refamiliar with codebase)
- Finalizing the new corner detection algorithm
- Restructuring the driving memories/corner access
... Protecting against brake before preceding corner exit
... Auto/save load driving memories
... Store driving memories for best lap, safe lap, etc
- New logic (more aggressive) for using limit detection for learning.
I think with those changes, he might actually be reasonably quick. Even the new corner detection algorithm could lower his lap times on some tracks drastically, although probably wouldn't help much at FE1, where the initial corner detection algorithm was based on/suited for.
I got the driver running again and this morning I even made the WaitingOnGridAction multi-threaded so that the framerate didn't drop and the driver could keep the rpm's to a decent launch level.
I can't say I'll be making big updates to the project, but I've tossed the driver on XY3 for a bit and I really need to finish the new corner detection stuff because for these long tracks, or long sweeping corners, it is pretty painful. That will require a lot of "trial and error" which tends to zap my energy if results are not visible.
Along with that change I need to modify how the corner information is stored and accessed, along with how the driver modifies "memories" of the corner, what entry speed was safe, when to brake, etc. I really would like to see him have multiple memories to work from. And these memories need protection so the driver doesn't try increasing speeds above the cars potential in the area, or move a braking point before the exit of the preceding corner. This was causing Jared, the driver, to fail in some cases.
If I can manage to get that far there is also another thing related to the learning that needs some serious tweaking and that will also be a fair bit of trial and error unfortunately. This would be the limit detection algorithms and when the driver decides the car was pushed TOO HARD or not hard enough. Currently if he slips for even a moment above a threshold it triggers the "backoff" behavior and will go slower the next lap. But I've noticed that doesn't necessarily mean he went beyond the limit enough to back off.
There are tons of other things to address also;
- massive code clean up required
- better spin recovery, which is currently still pretty awful
- handling cold tires, especially on slicks
- auto save/load of memories for a track (vs manual)
So if I do get some momentum going for the project first priorities are:
- Some code cleanup (also helps getting refamiliar with codebase)
- Finalizing the new corner detection algorithm
- Restructuring the driving memories/corner access
... Protecting against brake before preceding corner exit
... Auto/save load driving memories
... Store driving memories for best lap, safe lap, etc
- New logic (more aggressive) for using limit detection for learning.
I think with those changes, he might actually be reasonably quick. Even the new corner detection algorithm could lower his lap times on some tracks drastically, although probably wouldn't help much at FE1, where the initial corner detection algorithm was based on/suited for.
Yup as Whiskey said I use vJoy to control a virtual steering wheel to control the player car, InSim, OutSim and OutGauge for information and some other file formats the LFS provides. I have not, nor will I, used any undocumented things within LFS.
For frameworks I use TurtleBrains, my own C++ game dev framework using OpenGL, InternalCombustion my own framework for the simplest of 3D rendering, and again my own networking implementation of TCP/UDP. If you sense a pattern, I don't really use much beyond my own stuff (Win32, OpenGL, WinSocks, etc) with the exception of vJoy.
vJoy was a bit of a pain to setup, especially at first, and for some reason I had some trouble using buttons 0 and 1, so I skip those altogether.
For frameworks I use TurtleBrains, my own C++ game dev framework using OpenGL, InternalCombustion my own framework for the simplest of 3D rendering, and again my own networking implementation of TCP/UDP. If you sense a pattern, I don't really use much beyond my own stuff (Win32, OpenGL, WinSocks, etc) with the exception of vJoy.
vJoy was a bit of a pain to setup, especially at first, and for some reason I had some trouble using buttons 0 and 1, so I skip those altogether.
It is stored in svn, the code isn't open source, at least not at this time and not sure it will be, but I can maybe look into making it a public read-only repository if you are that interested.
It is a giant mess though, as the nature of a project that has "on/off" activity for 6 years would be. It really does need a proper clean up.
It is a giant mess though, as the nature of a project that has "on/off" activity for 6 years would be. It really does need a proper clean up.
I am not sure if there is a better way, but checking the RPM from the OutGauge packets is how I determined if the car is on or off in my AI project and it has seemed to work reasonably well.
OutGauge will only work for the players car I believe, if not the players car it will be the car that is being spectated and in the in-car cameras. It is similar to using InSim but a bit different in that you set the OutGauge ip and port in the configuration file then LFS starts throwing OutGauge messages whenever possible.
Well, this sucks. Work has been quite busy and keeping me from the project. I do have a lot I still want to do, primarily with better corner detection and storing the memories for best elapsed time and exit speeds, but other projects (like other racing game/sim projects) are starting to occupy my mind, so I am pretty certain the AIRS project is back in a holding pattern.
I even tried watching the driver lap a bit while working as usually that provides inspiration to stick with ti, but it got me discouraged because the driver can't even get back to the track very well after a spin without me manually intervening to reset the car. Well, you all know I will be back around again, and it may not be that long of a break as there is progress to be made with the memories and corner detection, and I'd really like to try that new steering algorithm, but that didn't seem to work as smoothly as I had hoped, when does it ever?
Thanks everyone.
I even tried watching the driver lap a bit while working as usually that provides inspiration to stick with ti, but it got me discouraged because the driver can't even get back to the track very well after a spin without me manually intervening to reset the car. Well, you all know I will be back around again, and it may not be that long of a break as there is progress to be made with the memories and corner detection, and I'd really like to try that new steering algorithm, but that didn't seem to work as smoothly as I had hoped, when does it ever?
Thanks everyone.
For the regular visitors of the server you may have noticed it is down. This isn't because I've taken another break on the project, not just yet anyways, but rather because work has got quite busy and my free time has become quite limited. I could keep the server up with Jared running laps, but without anything specific to test there is no reason to have him running, and I was finding that I'd become distracted watching him run laps as I watched for things he could improve upon.
So for now the server is down and progress has slowed.
I did continue working on the corner detector with all the data collected, and so far I've been less than impressed. Detecting where track corners are is actually a bit difficult. Values that work okay for some corners, don't work so well for others. And with the way I'm getting the "radius" at a point, (admittedly not the most accurate), sometimes it triggers on a straight.
Take FE1 for instance, some of the start/finish straight has some bends in the center line points as the path widens/narrows, these bends create a low enough radius at those points that a corner gets detected, where the sharpest turn on the track actually has a section where the radius becomes 3km for the final portion just the way the center line points straighten out, despite the track STILL TURNING SHARPLY.
So this becomes quite tricky because the center line isn't smooth enough. I need to find a way to make it smoother, but ONLY on the straight areas. But there is a catch 22 since I need the radius to determine if an area is straight or not, for instance that sharp turn in FE1 should not have the straight section that it does.
Anyway, that is the latest update.
So for now the server is down and progress has slowed.
I did continue working on the corner detector with all the data collected, and so far I've been less than impressed. Detecting where track corners are is actually a bit difficult. Values that work okay for some corners, don't work so well for others. And with the way I'm getting the "radius" at a point, (admittedly not the most accurate), sometimes it triggers on a straight.
Take FE1 for instance, some of the start/finish straight has some bends in the center line points as the path widens/narrows, these bends create a low enough radius at those points that a corner gets detected, where the sharpest turn on the track actually has a section where the radius becomes 3km for the final portion just the way the center line points straighten out, despite the track STILL TURNING SHARPLY.
So this becomes quite tricky because the center line isn't smooth enough. I need to find a way to make it smoother, but ONLY on the straight areas. But there is a catch 22 since I need the radius to determine if an area is straight or not, for instance that sharp turn in FE1 should not have the straight section that it does.
Anyway, that is the latest update.
Just don't forget that a legitimate case of acceleration over the cars normal values would be during contacts. You might want to have a momentary timeout for the car when it hits an object/wall/car.
Unfortunately I've refactored and moved code around that will have effected the test times for the XRT at KY2 with regards to different steering system. Probably okay anyway since I got hung up on one detail and didn't think of an immediate solution so I've put that on hold. By moving this code though, I should be able to give the StartFromStop action the ability to steer the car, which should greatly improve his recover. (Initially that action held the steering wheel straight in hopes the car stayed on a desired path, we all know how well that works: It doesn't).
I have continued working on some debug tools for seeing what the corner computer is reporting back without performing my own track walk. Here is a shot for BL1 with the new TrackMap code, which at this point the code probably should be removed into it's own separate file. Currently grey represents straight areas (including braking zone) and orange represents from corner entry until corner apex. For very observant readers, you may notice the track width varies in the new shot, that is because I now use the left/right edge that I get back from the pth file. Visually, I like the constant width, which is probably why LFS uses that in it's track map.
Looking at this BL1 image you can see it does "okay" for some corners and then completely failed for that final turn complex where you drive past pitlane entry. That should be separate corners, but the current detector gets it all as one.
Trying to improve that with the new detection.
Currently fighting an issue with the display on AS5, looks like it might be more issues with detecting what corner/phase of the track the car is in.
EDIT: I have confirmed it is indeed some issue with the detecting corner/phase. Also, added colors for each phase of the corner, looks pretty neat!
I have continued working on some debug tools for seeing what the corner computer is reporting back without performing my own track walk. Here is a shot for BL1 with the new TrackMap code, which at this point the code probably should be removed into it's own separate file. Currently grey represents straight areas (including braking zone) and orange represents from corner entry until corner apex. For very observant readers, you may notice the track width varies in the new shot, that is because I now use the left/right edge that I get back from the pth file. Visually, I like the constant width, which is probably why LFS uses that in it's track map.
Looking at this BL1 image you can see it does "okay" for some corners and then completely failed for that final turn complex where you drive past pitlane entry. That should be separate corners, but the current detector gets it all as one.
Trying to improve that with the new detection.
Currently fighting an issue with the display on AS5, looks like it might be more issues with detecting what corner/phase of the track the car is in.
EDIT: I have confirmed it is indeed some issue with the detecting corner/phase. Also, added colors for each phase of the corner, looks pretty neat!
Last edited by blackbird04217, .
So the fixes from yesterday, regarding distance from racingline accuracy, did seem to help a bit more at KY2 than it did at WE1. I've let Jared train for about 110 laps or so and have now locked him in race mode so he is not learning at the moment. I am going to let him run at least 65 laps without training as a baseline, possibly even a few stints of that just because more data makes it more accurate statistically speaking. It looks like his laps will be in the mid 2:18's. After getting that data, I think tomorrow evening, maybe, I will implement the ideas I have for the new steering logic and, this would be the crucial part, nothing else. Then let him run again, with the identical memories and see if that change alone helps or hurts any.
It is very possible it hurts his laptimes initially because there are a few turns on KY2 where he slides away from his racing line, and the new steering logic will probably make him turn harder there in an attempt to follow the line more accurately. That said there is one or two corners where he actually cuts on his racing line, although that probably helps his laptimes also... The goal here is not to be faster, or slower, but to collect the data to see what effect the changes had. I suspect he will be slightly slower ...
But I also suspect he might get faster, at KY2 anyway, after I let him relearn his memories, after running the tests. The theory here is a few turns he is actually not near the limits of the car, but slows down on them because he gets too far away from the white line. Initially this was my attempt to help with "severe understeer" since I still don't have an understeer limit detector. That is on my wishlist, but I don't know how to do it with the information provided. Maybe by building some form of table that says at X speed and Y steering angle desiredYaw is Z. That seems rather fluidy though.
For tonight I am going to do some more data collection. Time consuming. Questionable whether it is worth it. Lets hope it is.
This weekend I may or may not work on the corner detection, I may instead rework the way the driver stores his memories and track a way to save the memories that had best exit speed and best elapsed time from corner entry to exit, and include in that a way to fix up his "brake before previous corner" issue. Or at least, if he does start braking before previous corner, he should probably remain in the brake zone. I think my first approach will be to make it so the brake zone must be within the range of the previous corner exit and the current corner entry. But with the new corner detection I worry a bit that some of the new straights will be too short, and I may need to go for the more complicated method.
EDIT: Looks like something wonky happened here when computing the racing line!! Woah.
EDIT 2: I've collected track data for acouple more tracks then started working on that visualization from last night again, it works, mostly for FE1, but it seems to have some bugs with BL1 (at the very least) so I can't trust the visualization quite yet. Still, pretty neat to see where the corners are being generated without flying around the entire track.
It is very possible it hurts his laptimes initially because there are a few turns on KY2 where he slides away from his racing line, and the new steering logic will probably make him turn harder there in an attempt to follow the line more accurately. That said there is one or two corners where he actually cuts on his racing line, although that probably helps his laptimes also... The goal here is not to be faster, or slower, but to collect the data to see what effect the changes had. I suspect he will be slightly slower ...
But I also suspect he might get faster, at KY2 anyway, after I let him relearn his memories, after running the tests. The theory here is a few turns he is actually not near the limits of the car, but slows down on them because he gets too far away from the white line. Initially this was my attempt to help with "severe understeer" since I still don't have an understeer limit detector. That is on my wishlist, but I don't know how to do it with the information provided. Maybe by building some form of table that says at X speed and Y steering angle desiredYaw is Z. That seems rather fluidy though.
For tonight I am going to do some more data collection. Time consuming. Questionable whether it is worth it. Lets hope it is.
This weekend I may or may not work on the corner detection, I may instead rework the way the driver stores his memories and track a way to save the memories that had best exit speed and best elapsed time from corner entry to exit, and include in that a way to fix up his "brake before previous corner" issue. Or at least, if he does start braking before previous corner, he should probably remain in the brake zone. I think my first approach will be to make it so the brake zone must be within the range of the previous corner exit and the current corner entry. But with the new corner detection I worry a bit that some of the new straights will be too short, and I may need to go for the more complicated method.
EDIT: Looks like something wonky happened here when computing the racing line!! Woah.
EDIT 2: I've collected track data for acouple more tracks then started working on that visualization from last night again, it works, mostly for FE1, but it seems to have some bugs with BL1 (at the very least) so I can't trust the visualization quite yet. Still, pretty neat to see where the corners are being generated without flying around the entire track.
Last edited by blackbird04217, .
Not much progress for today. Watched him fail to learn at WE1 like he was at KY2. Looking through the code it appears to be some issues with estimating the distance he gets away from the racing line, which seems to affect his desired corner speed. I tweaked it and seems okay for WE1 except for T3, which is a really long turn and I guess there is a point between two of the track nodes the spreads out. Have not retested KY2.
I did however go through WE1 and AS1 and collect a bunch of track data, see attached image, which took some time. I'd like to do at least a few more full tracks, BL1, KY2, FE2, but it is pretty time consuming and boring work and I'm only "hopeful" that doing this gives me ideas or shows me values to use. I can say this would be much easier to FEED the driver than it would be to compute during the track walk, but I'm trying to give the driver as little information as possible.
While writing this post I decided I'd proof of concept an idea I have for showing the corners and such a little easier than flying around the whole track, so in 2D space I render out the track at a constant width, (not the tracks actual width), and for kicks I added the racing line on it. My idea here, once I get the new corner detection ready, is to show what areas of the track is straight vs turn, which should be easier to debug than flying around the track, even though it does lose a little precision. (theoretically I could render out a larger copy).
Not bad for 20 minutes work, I essentially implemented a track map feature, it should even work for super large tracks, scaling down as needed, lets try. Indeed it works, although this shows the lost precision. Still color coded corner vs straight will be super clear and useful.
I did however go through WE1 and AS1 and collect a bunch of track data, see attached image, which took some time. I'd like to do at least a few more full tracks, BL1, KY2, FE2, but it is pretty time consuming and boring work and I'm only "hopeful" that doing this gives me ideas or shows me values to use. I can say this would be much easier to FEED the driver than it would be to compute during the track walk, but I'm trying to give the driver as little information as possible.
While writing this post I decided I'd proof of concept an idea I have for showing the corners and such a little easier than flying around the whole track, so in 2D space I render out the track at a constant width, (not the tracks actual width), and for kicks I added the racing line on it. My idea here, once I get the new corner detection ready, is to show what areas of the track is straight vs turn, which should be easier to debug than flying around the track, even though it does lose a little precision. (theoretically I could render out a larger copy).
Not bad for 20 minutes work, I essentially implemented a track map feature, it should even work for super large tracks, scaling down as needed, lets try. Indeed it works, although this shows the lost precision. Still color coded corner vs straight will be super clear and useful.
FGED GREDG RDFGDR GSFDG