FAForever
Implement DirectionsFromWithThreatThreshold into AI transport logic
Description of changes
This draft PR replaces the marker based system used to determine alternative landing zones for AI transports. The previous implementation caused problems on maps with dense marker numbers or where 3rd party AI replaced markers with there own, or maps with no default markers at all, it resulted in heavy sim speed drops when transports were used with high threat destinations. This is due to the threat validation being performed on the positions. For example if Uveso AI is enabled and generating markers you could have scenarios where 50+ markers were returned. We now removed the marker based validation and use the navmesh.
The new method uses a navutils function to generate alternative drop positions around the area taking into account air threat.
Testing method Must be tested against an AI scenario where it AI wants to perform transport drops to positions with enemy antiair threat. There is an example in the /lua/sim/navdebug/directionsfrom.lua file that shows how you could draw the results from this.
Known Issues I need to double check with Jip but I believe the radius is static which introduces a problem where smaller maps require a smaller radius but larger maps can support a larger radius. To try and find a happy medium I've used the property of IMAPSize * 4 to determine a transport drop radius. The reason for this is two fold. It will adjust the radius based on the map, so a smaller map will have a smaller radius, and a larger map a larger radius. With a max value of 164. It will guarantee (I think) that the positions that are returns will be outside the destinations imap block except in cases where the map is 40km and above. In those scenarios
5km IMAPSize = 32 10km IMAPSize = 32 20km IMAPSize = 64 40km IMAPSize = 128 other (80km) IMAPSize = 256
@Garanas Interested in your views on the approach here(usage of the directionsfrom function). Or if you've got any ideas to improve the results of the potential landing positions.
The weakness I see is that the radius while not static is only a single radius. So if it fails to find any drop spots its not going to extend its search. I started testing this with my own AI last night and will begin testing against the default this week. Once I'm happy I'll take it out of draft.
You could go with a relatively large radius, the (valid) points are naturally sorted by distance.
Testing has found an unrelated issue where as the transport will find a position that it can land but the air threat along the path to get there is too high. Any platoon functions using this will loop back and repeat the transport call causing excessive load.
This seems to be a problem brought about due to the code not supporting a pathing function that may reject calls due to the use of PathToWithThreatThreshold, which can return false if all possible paths are too dangerous. Where as the original pathing function would almost always return a result even if the path had high levels of threat.
The transports (and by extension all platoons that leverage that function) require a way to handle high threat paths. This issue is obvious on smaller maps where an enemy can completely lock down a large portion of the map. Or in the case of AntiAir when a group of fighters move across the map generating high air threat along a line of imap grid squares that will take time to decay and in the mean time block the path.
edit : I'll take this out of draft and look at the other issue in another PR given the potential scope and not wanting to have this get too far out of date.