AI does not steer consistently

[Arthur-D]

Description

It seems that the different AI karts, while sharing the same AI code, steers quite differently in certain places. It is an issue because it's near impossible to tweak drivelines so the AI handles things correctly since they don't act the same. Video of the issue: https://youtu.be/PVZ5aTHR7lg and skip to 0:50 to see where I tried tweaking.

Short version: Kiki does consistently well, while the others don't. I did more tests and most karts do well there, so the drivelines are good enough, but some karts just don't follow them properly.

In the video, you will see that Kiki did well, while if you skip to 4:05 you will see Xue drive off the bridge for no discernible reason. Same at 5:05, and ditto with Sara the Wizard at 5:55. Then Xue does it again at 6:05 and 8:05. Sara the Wizard repeats the feat at 9:50. 10:35 is interesting because Adiumy has done terrible all the time, but for once the AI was not at fault, seems like the bridge is not well connected to the ground, so he jumps and falls off the bridge.

Drivelines in the particular spot I tried tweaking:

Steps to reproduce and configuration

supertuxkart --kart=kiki --ai=adiumy,sara_the_wizard,xue --track=greenvalley -N --profile-laps=10 STK release version: current git master

[qwertychouskie]

Does the AI try to prevent the center point or any point of the kart from going outside the drive quad? If it only checks the center point of the kart, that could easily cause the kart to run into a rock/off the bridge, as the kart is still considered to be within a valid drive quad.

[Mrxx99]

Also on 01:40 (https://youtu.be/PVZ5aTHR7lg?t=1m40s) the basketball skips over Kiki here (like in #3182)

[Arthur-D]

I worked around the issue in this particular place somewhat with driveline tweaking, but it's still a problem that the AI doesn't seem to care all that much about the driveline boundaries, and they do that to varying degrees.

[hiker]

For the record, here some comments I just made on irc: (10:56:57 AM) hiker: I am about to post there, can you look up the kart types, and maybe length of the karts? (10:57:15 AM) hiker: --kartsize-debug (10:57:22 AM) hiker: will print the size of all karts (10:57:46 AM) hiker: If our steering estimation (which depends on length of karts) is incorrect, that could explain it (10:57:56 AM) hiker: or the different steering for different kart classes (10:58:20 AM) hiker: Adiumy could be related as well (10:58:34 AM) hiker: Ideally all karts should (ignoring kart class) have the same turn radius (10:59:04 AM) hiker: Now the turn radius depends on length, so I am using some maths to compute what steering is needed for a given radius depending on kart size (10:59:17 AM) hiker: If that formula is just wrong, we have different steering behaviours (11:01:38 AM) hiker: You can try (11:01:50 AM) hiker: use an arena, and drive circles with different karts (11:02:01 AM) hiker: Hmm - you would need to print the coordinates to get the radius (11:02:22 AM) hiker: But just putting the shortest and longest kart into the same class, and just looking at the skid marks might give you an idea (11:02:25 AM) hiker: split screen or so

[Arthur-D]

[info ] main: wilber: width: 0.837411 length: 1.715575 height: 0.871927 mesh-buffer count 1 [info ] main: adiumy: width: 0.852141 length: 0.943786 height: 0.775698 mesh-buffer count 1

Wilber is the longest kart in the game, and Adiumy the shortest. As my video shows, even though I don't manage to start skidding in the exact same place, Adiumy has a much wider turn radius than Wilber, and might explain a lot of the AI steering disrepancies.

See https://youtu.be/PdfniPmahfc

[hiker]

The karts have a different classes (light vs medium), which affects speed, which in turn affects the turn radius. I admit I forgot that we adjust the turn radius depending on speed artificially. It gets a bit difficult to study this code, don't have time. Suggestion: 1) try putting the two karts into the same class 2) If you still see a difference, then in karts/kart_model.cpp::load(): m_wheel_base = fabsf(m_kart_model->getLength() - 20.25f); modify this to be a constant (e.g. 1.7155 - 20.25), independent of actual kart. See if this makes a difference then.

[Arthur-D]

1. With both in medium, Adiumy still had a much larger turn radius.
2. It appeared to be in karts/kart_properties.cpp and I changed line 315 to m_wheel_base = fabsf(21.7155 - 20.25); Using 1.7155 - 20.25 gave an extremely tight radius that actually seemed to make Adiumy unable to skid, so went with 21.7155 - 20.25 instead. With this, Adiumy suddenly had a noticeably tighter turn radius than Wilber, so still didn't manage to get them to turn the same.

In conclusion, either my testing has been flawed, or there's something wrong with the code.

[qwertychouskie]

Did you put Wilber into the Medium class?

<kart name              = "Wilber"
      version           = "3"
      model-file        = "wilber.spm"
      icon-file         = "wilbericon.png"
      minimap-icon-file = "wilbericon32.png"
      shadow-file       = "wilber_shadow.png"
      type              = "light"     ------------------------------> This is what needs to be changed to 'medium'
      groups            = "standard"
      rgb               = "1.00 0.42 0.00" >

[Arthur-D]

As said I did, I can double check later.

[Alayan-stk-2]

For reference, while I didn't see the latest comments before doing my trials, I did tests with a fixed wheel_base a few days ago.

Changing the wheel base to a fixed value did change the turn radius, but it didn't fixed the issue. Two serious flaws were highlighted when doing so : 1)The kart who previously had the biggest turn radius had now the smallest : there is some effect in the physics which seems to make karts with closer wheels have a shorter turn radius. 2)The max-steer computations were completely off : they said that the kart who had measurably the smallest turn radius had a smaller steer angle (i.e., a bigger turn radius) than the other one it was tested against.

For those experiments, I put the max speed of lights and mediums to be identical, so it didn't matter. No need to change the classes of the kart themselves as long as you make the classes themselves similar.

So basically, I independently did tests broadly similar to those of Arthur and got a similar issue (1) while the logging revealed another issue (2).

[qwertychouskie]

The turning radius issue is now fixed, this should be re-checked.