In case you don't know, it has always been like that. Even if you've allowed a car reset, AI drivers pretty much only reset if they know they can't move anywhere and situation allows resetting a car. This means that they only reset if they're flipped, taken a wrong route/out of bounds or, in case of vehicles with motorbike gearbox, they're stuck and can't move forward. Being stuck in a sand does not make AI driver reset their vehicle, unless you use Autocross objects to force them to a position where they will reset their car.
Same thing has happened at least previously if they've destroyed their clutch or stalled their engine. Not completely sure how they handle this kind of situation in a current test patch though.
Thank you all very much for the feedback and reports since Friday's test patch (D41).
Tankslacno, that must be the best presented patch report I have ever received!
I am fixing the things which are definite bugs, especially if they were introduced recently. Some things won't be fixed but I will look at all the reported issues and see what I can do in a short time.
NOTE: I seriously want to move away from AI, as soon as possible, to get back to finish and release the recent updates to the mods editor and system (the intermediate, incompatible patch with the existing physics and graphics). So I'm just trying to round off the most important issues.
GT4_PL thank you for the comparison videos. They are entertaining. I am pleased to see D41 taking more care, crashing less.
EDIT:
I see that sometimes in D41 the result can be not as good as D40, but there are other examples with a lot of crashing in D40, that doesn't take place in D41. Example, my test with 5 bikes followed by, UF1, XRT, FOX at SO Classic, in D40 the cars would hit the bikes a lot more.
I'm still convinced D41 is better, even if sometimes an AI holds back when we really know it should try to pass. Anyway, D40 was considering passes on *individual* cars ahead, then going if all possible passes were in agreement. Instead, D41 considers the cars ahead as a group, then decides "pass left / pass right / brake". It's a better method which is more predictable. Of course, AI can be improved so much, I could work on it for years or decades. But my main aim was to stop AI ramming and ignoring other cars and bikes.
Currently, AIs are significantly better. Thank you Scawen!
The 0:20 and 0:39 moments D40/41 AI did in GT4's video is the main issue that usually causes big traffic jams. When driving into tiny areas AIs seem to just merge into a single file instead of finding other track areas and leaving space for each other. This sometimes will lead to a situation where AIs are in front of others and has priority to pass according to motorsport rules but they will just decide to stop and wait for other to pass just because they are not on the generated racing line.
Just noticed another bug in this. And it's related to this test patch, because this test patch is first patch where we can see F11 / F12 windows in test drive mode. Basically, you can use most, if not all, commands in test drive mode.
Here's that bug: if you're test driving from a replay of a hot lap session and decide to type command /laps 1-1000 (or /hours 1-48) and you do that before you start your first timed lap, F12 window thinks there is a race going on (it states that race length is X laps), but there is not a lap counter (it never appears) and none of your timed laps counts towards your driven laps in that "race". In fact, it seems like none of your test drive laps will ever count.
However, if you do it after you've started your first timed lap, it does turn your test drive into a effective race session.
This bug only occurs on replays which were driven in hotlap mode. This does not occur in practice sessions (in those, using command does turn that test drive to a race regardless of where you type that command).
So, in order to reproduce this bug:
1) Start a hotlapping session and save SPR of it
2) Open that SPR and enter test drive mode
3) Type command /laps 1-1000 or /hours 1-48 before you start first timed lap on that test drive.
4) F12 window thinks this session is a race, but lap counter never appears and that race never ends.
2) Unrelated to this test patch, could be on purpose, but has potential issues
In theory, command /setlap has potential issues. And that is to do with the fact that the second parameter (lap amount) of that command cannot contain 4 or more characters. What does this mean? Well, it does bring up two potential issues:
Ones not so bad, that is you can "only" subtract up to 99 laps per command. Command /setlap [username] [-100] does not work, since that second parameter has more than 3 characters.
The second one is the one where this command can become an actual problem:
I know this doesn't happen that often, but if you're having an endurance race on a very short or oval track, where race length is in hours and it's clear that lap amount will exceed 1000, /setlap command becomes useless for player who reconnects after an unintended disconnection and has already driven over 1000 laps. Why? Because /setlap only works up to 999 if you're having a race where length is 1000 laps or it's a timed race. (If race length is less than 1000 laps, it works up to that race length.)
That is because technically that command does not add laps for user, it only sets the lap amount of that affected user to that.
And yes, I know it may sound nearly impossible to happen, but it actually isn't. Think about you're doing a 24 hour endurance race in a team on track/car combo where average length of a lap is about a minute. After 5 hours, you've already driven about 300 laps. If one team would manage to have that average page of 1 lap per minute for that whole race, /setlap would become useless for them after about 16 hours and 40 minutes of racing.
I was just wondering that since that number can already be negative which subtracts driven laps, could it be also possible to make + sign work on that parameter? For example /setlap [driver name] [+2] would add two more laps to driver's current lap amount. Or alternatively, could it be possible to make the maximum lap amount on that second parameter so high in timed races as well as qualifying and practice sessions that it couldn't be realistically achieved by simply racing?
In any case, it also may seem a bit confusing that LFS states an error that this command needs 2 parameters if your lap parameter is at least 1000 (or -100 or lower). It's a bit confusing because you already have typed two parameters to that command.
Good news is I've fixed a lot of the AI related issues reported in your pdf.
About the /setlap command, I can't reproduce this. I've started a time-based race (/hours 1) then I was able to use /setlap up to 6000 laps, which is the designed limit. I could use negative values also to -6000.
With /laps 1000 I was able to use commands like /setlap AI 3 1000 or /setlap AI 3 -1000.
EDIT: This is incorrect solution, but I left that so you can still download that attachement
I found reason why that happened to me and there is a bug.
When I tested it, my driver name was written in Japanese code page. As I typed that /setlap command (using Latin code page) and used that driver name, which was written in Japanese, in there, it restricted the character limit of that second parameter to 3. That's why I got an error "This command needs 2 parameters" when that second parameter had 4 or more characters.
When I switched to driver name "Tankslacno", it worked properly.
EDIT: It seems like it only happens, if you use special symbols shown in Japanese code page as your driver name. I've attached a screenshot of my driver name. If you create a driver name using those symbols, you should be able to reproduce this bug then.
Sorry for double posting but this doesn't seem to be a solution to this bug.
This same bug happens with every single driver name regardless of their code page, if last character of that name is having other color than default color. If last character is in default color, this /setlap command works properly (it doesn't matter are other characters having different color in that case).
Here's how to reproduce this:
1) Create a new driver name and while naming it, apply some other color to it (other than default) at least to the last character of that name.
2) Go to single player and set race length either in hours or 1000 laps
3) Open connection list and right click on your player name. This allows you to copy that name with those colors included
4) Type /setlap, paste that name with Ctrl+V and type lap parameter with 4-5 characters. You see that error "This command needs 2 parameters" on screen.
Weirdly, if you just type that name without using colors, you can use that /setlap command with no problems. But if your lap parameter contains at least 6 characters regardless of colors, you see that error happening. Reason why I encountered that problem initially was because it was written in Japanese and used white color so naturally I just copied it by right-clicking it on connection list.
If I had to guess why this is happening, is it because whenever you apply a color to a name, it does apply that color code (https://www.lfs.net/faq/39) which contains a number to it.
EDIT: Technically that is not the 100% solution, but it's close enough. You can still have that last character colored of your driver name even if you copy it with colors from the connection list. You just need to make sure that before you type that lap parameter, you change your text color to same one your last character of your driver's name has.
So if your last character of your driver name is in cyan and you want to copy it with colors when typing that /setlap command, you can still apply that command correctly, but before typing that lap parameter, you need to make sure that parameter is also written in cyan.
OK, here is another update for AI, Test Patch D42. You should find it a lot safer and better in the pit lane. Also overtakes from a lower speed are better judged (avoided if there is no chance to pass safely because there is not enough time to accelerate).
I still want to look at the max braking judgement calculation, to make it take account of brake balance.
AI:
Improved driving in pit lane when close behind other drivers
Overtaking decision from low speed now allows for acceleration
FIX: Choice of pit stop box was wrong (bug introduced in 0.7B)
FIX: Slow start / stuck in pit stop if max torque at very low rpm
FIX: Errors in fuel calculation related to "Refuelling allowed"
Game:
Reset is now possible during a pit stop if the state is "finished"
FIX: Auto shift *up* did not work if max power rpm above redline
Interface:
FIX: Wrong info was shown in new F11/F12 display in Test Drive mode
FIX: Crash if /track command was used while generating AI path info
Bug Report: Ai Using Hadraplan has interesting anomaly as it's like preventing to engine overheat when reaching over 90km/h, even if gear ratios allows to go actually faster. I wonder if this is same issue with any other vehicles. Speedometer only shows 90km/h as max, once AI reaches over 90, ( somewhere 92-93 ) on downhill, it starts not using full throttle anymore.
Intended?
EDIT: It is not that case... impossible... issue is somewhere else.
In VR mode, the sound and image stall extremely while the path for the (mod) AI is being generated. I noticed this the day before yesterday during a test race with the AI (12 AI vehicles - levels 3 - 5) with version D41. Perhaps this depend on used VR headset (but I don't think so).
BTW: With the N.400S GT mod (https://www.lfs.net/files/vehmods/F1A4EF), even at level 5 the AI is massively (>10s per round) slower than me (and I'm really not the best driver). Is this a "general" vehicle mod problem (to whatever extent) or perhaps related to the latest AI adjustments?
But regardless: Thank you very much for the many improvements in the AI! This makes it (again) much more fun with the AI. However, it would be desirable if the AI paths could also be generated directly in multiplayer mode.
It would be very hard and far beyond the scope of this test patch to make the AI generation work in a separate thread so it doesn't hang between updates while it iterates the path improvements. You should generate offline (and outside of VR) any AI paths you want to use. Maybe you could use a separate LFS instance.
About the speed of AI, it's not your fault but I'm getting a bit tired of explaining so many times, the AI's driving ability (handling of one car, nothing to do with the overtaking) is all specific to the tyre model in question and has already been improved to some extent in the development version, but I will not be working on that for the public version, as it would be pure wasted time.
Nothing about their speed has got worse in the test patches, as I haven't worked on that. But you could verify by starting an earlier exe, run a single AI and see if the lap times are the same. That's your job as a tester really. I assert that their lone car driving ability is not changed. You are welcome to prove me wrong.
it's a nice long awaited update, driving with AI isn't as frustrating as it once was
but there is still some cases where it's behaving very unsmartly
one of them, I believe it's quite simple to fix, is that they seem to not take care of clutch slip and when they get stuck they happily burn it and the car can't move anymore.
When it happens in a tight place, like pits, they will block every other AI behind them. Maybe they could spectate and DNF instead or manage it with lower throttle inputs when it begins to get hot for example.
I think the AI is good enough for now and probably that it's worth moving on to a general patch with graphics and physics, because everyone is waiting for this. Moreover, the AI update depends on physics in this patch.
The vastly improved ai is a nice treat scawen, I appreciate the work you put into it! Keep on keeping on. I know you mostly see wants and or complaints but wanted to throw ya some appreciation.
Pasci, can you tell me an example of a track where the N.400 GT seems so slow? There is one thing I am trying that is specific to the public version, and that is braking prediction. Late braking followed by wide cornering is spoiling too much AI driving. I wonder if this could be the cause of the N.400 GT problem.
AI is still going to be a lot slower than good drivers, but maybe I can stop them making an error like running really wide of their intended line.
I've had some success with this new braking calculation.
So here is a new question: Can anyone tell me an example where a particular car always runs wide on a particular corner?
Doesn't matter if it's a default car or a mod (though default cars are quicker to get to). One of the best ways to tell me which corner it is, if not easy to describe with words, is you go into free view mode and type "/cp". The camera position is pasted to your clipboard in a text format, so if you tell me the track and config and the /cp text I can get to the exact corner.
EDIT: With the new code, teeembo's Lotus 49 mod takes Aston Cadet reversed turn 1 much better (and a lot of other corners). I'm not convinced yet for all cars in all corners. I have some examples where the corner is taken worse with the new code. So I have to check quite a few examples to make sure it does a lot less harm than good.
Once again, I decided to create a PDF-document where I report my experiences and issues with this test patch.
This PDF has 6 pages and I've divided it into five parts:
1) Two issues I suddenly found out, one of them is related to this test patch cycle.
2) My experiences of these fixes presented in this test patch in general
3) My testing with your other fixes Scawen
4) One thing I realized as well when I was able to reproduce that bug when using /setlap command
5) General information about attached files
I've attached four SPR-files. Now, there is also a fifth SPR and one RAC-file which I've uploaded into Google Drive alongside those five other files in a ZIP-folder since that first one is too big file to simply attach it here and the second one is not permitted file type.
- Replay OOS Error happening - this is almost certainly related to this test patch, because I haven't experienced OOS Error for years now and it always happens when I playback replays where lot of different bikes are racing
- 1 other bug found when viewing mods - bikes in general, not sure can this happen on other type of vehicles
- My experiences to each of your AI update in D42
- My experiences with updated AI in general with this newest test patch
- 1 bug when using certain bike on a certain track, not sure have I accidentally corrupted this
- My testing experience to your other fixes
- Other information related to that /setlap bug I found yesterday
- General information of each file I've attached
Hi, thanks for the info although I probably won't try to fix many things in that pdf. For example, I'm not really worried about wobbly bikes or cars being blocked for a while if the car in front has a long pit stop. The importance level is just not high enough. My aim was only to improve the AI, not to solve every issue. Definitely want to make sure I didn't make anything worse though!
But about the replay OOS error, please can you tell me which versions you recorded the replay? Is it that you are getting the OOS, even if the replay is recorded in D42? Or was the replay recorded in an earlier version?
I remember fastest cars (GTR, FO8, BF1) having problems at South City Long and Town Course + Reverse with one particular corner. I'm talking about that corner close to chicane in Classic, it's that second to last corner when driving Town Course in normal direction. I've noticed that XR GTR especially seems like it can barely make that corner when using default-setups.
If I have to guess, since they are driving downhill, they have too much speed coming to that corner and sometimes get stuck to that wall when trying to make that corner (and if someone rams them from the behind, it just increases chance of that happening). Probably having wind from wrong direction and/or using soft tires makes it even easier to reproduce it.
Now this doesn't happen on every lap, but I remember GTR-cars basically having their race end there, with some of those having puncture on their front tyre.
But, in any case, it has resulted me doing this: if I want AI's to have endurance race with those cars, I basically have two options:
1) I let them race on one of those three tracks with no wind and pray they don't screw up or
2) I use SO4R as a track as there AI's don't have any problem, because they approach that corner with much less speed.
I saw that pit limiter light its already updated to flashing.
Is it possible to make when you turn your lights and press flashing button they still to can flash, because whey they are ON now they not flash, only when lights are OFF they can flash.
I recorded it in D42. I could possibly try recording it in previous test patch, where AI drivers can drive bikes, but I can't test it on official patch, because it seems to only happen when several AI's are driving with bikes.
On D42, I also did playback D41 replays, where I had 25 bikes racing and had no OOS errors whatsoever.
Only thing I could think is that is there a possibility that a certain mod could cause this? Why I'm thinking this as a reason? Because on those replays where that OOS error occurs, there are lot more of different bikes racing. When I had 25 AI's racing on D41, there were only 5 different bike types total racing. When I had 32 AI's racing on D42, there were total of 27 different bikes.
