You can now set how far AI units will go to get into a vehicle. The default is 50 meters.
Flyers will now only land at "land hints" that are ready to be placed in the editor. This will allow us to guarantee that flyers land safely. You should place the hints in fairly open areas, to allow the flyers some room for error. The direction of the hint is important - it tells the flyer which direction to land in. So, for example, if the hint direction points to the right then the flyer will approach the landing spot from the left. Bear in mind that the flyers need a safe landing approach distance of say 50-100 meters. I'm relying on you to make sure this approach path is safe ;-)
Also, the landing hints take an optional command post parameter. If you don't set this in the editor, then the hint is associated with the nearest command post, so you should rarely need to set it manually. The AI uses this data in the following way: if a flyer spots a non-owned command post that has a landing hint associated with it, the flyer will land, the AI soldier will jump out of the vehicle and try to acquire the command post. Transports also use the landing hints. They will land at friendly command posts to pick up soldiers, then fly and land at enemy command posts to deploy the soldiers. You can place multiple land hints around the same command post to give the AI several places to land.
By the way, like I mentioned above, flyers now need these landing hints in order to land at command posts, so until you have added these to your maps flyers will not be landing L
You can still use regular MoveTension, and that sets all directions to the same value.
Here's a brief description on how to make the AI defenders stay in defensive positions.
Place snipe hints at the defensive positions. Make sure the direction of the hint faces the forward-facing direction for the defender. Set the mode of the hint to "Defend". Don't use the MetaNode property.
In the lua script, add the following: SetDefenderSnipeRange(170)
I've added functionality to the AI so that when a command post is taken, any nearby units (within 60m) from the original owning team will try to immediately reacquire it. Previously, an enemy soldier could take a CP and any nearby original team's soldiers would just keep running away towards other CPs.
I've added a new parameter to the ODFs called AISizeType. This is basically the size category that the soldier/vehicle will use when referencing the connectivity graph and new barrier system. Example:
In rep_inf_assault.odf:
AISizeType = "SOLDIER"
Your choices for this are SOLDIER, HOVER, SMALL, MEDIUM, and HUGE, which are the same flags that are set in the editor when creating the barriers or the path planning graph.
If there isn't a tag in the ODF file (none have them right now), it defaults to SOLDIER.
I put some timers in the AI code to help optimize the connectivity graph. Each time a path is requested in the game, I time it, and then I show those on the screen by connectivity graph connection. This way you can see which legs are slow and should be optimized. The end result of this should be that the AI guys aren't standing around any more.
By optimizing I mean mostly adding more nodes so the connections in that area are shorter, but this could also mean messing with the barriers (tighten them around objects, etc...)
There are three different commands for this in the game (type in the console, no quotes):
"pathcost tot"
"pathcost ave"
"pathcost max"
(also "pathcost sum", explained below)
(also just "pathcost", which will turn it off)
They all (first 3) show the same information, just sorted on the different columns (I'd suggest "pathcost tot"). Type one, and you get a whole bunch of numbers on the screen. The top section deals with the individual connections, which is where you look to figure out which connections to optimize. The columns are:
Cnt - how many times this connection has been requested.
Ave - the average time taken to calculate this connection once.
Tot - the percent of all pathfinding time spent on this connection.
Max - the max time taken for one calc.
Conn - the connection name in the editor (C16 = Connection16)
So the useful information you can get out of this: the total ("tot") column shows where most of the effort of the pathfinding is going. Ideally these should be pretty consistent (and below 10). If one connection is at 35% and all the rest are below 7%, either that one leg is really slow, or a lot of people are requesting it (or both). But either way it's a good one to optimize. Look at the ave column, if that's higher than the rest (say its 0.025, the rest are 0.008) than you know that the leg is just too slow, so try to shorten it (break it into two). If the ave column is fine (<0.010), but the count column is big, then then leg is fast but its getting a lot of use, so it may be worth optimizing anyway.
Also there is a special connection in the list called "none", which is where it times paths that aren't on the graph. If the ave time for this is bad, than there are probably parts of the world not covered by nodes. I'm working on a way to make this clearer.
There are two more sections at the bottom of the screen. The first is the path queue time. This is essentially the delay from when a path is requested to when it is processed (this is less important than the section below). The first column is the number of paths requested, the second is the average queue time, and the third is the max. There are two rows, the first is the total for the entire game, and the second is only for the last 10 seconds. In an ideal world the second number (ave time) of both rows should be under 5 seconds.
The third section is the idle time of the AI players. This is the actual time that AI guys are standing around doing nothing waiting for a path. This is different than the section above since AI guys will calculate their next path while running, so they only stand around waiting (idle) if its not done yet when they stop. This section is obviously the key number that you're trying to reduce. When its 0, nobody is ever standing around. This is good. The columns for this are the same as the section above, being: count, ave, and max, and split between total game time and last 10 seconds.
You can get only the second two sections to display by typing "pathcost sum", which is better if you're trying to see the game too.
You will notice that some of the lines turn red. For the connection list, this means that you should look at this leg to consider optimizing it. For the bottom sections, this means the wait times are too much. If you can get the bottom lines to be green all the time then you've probably optimized enough.
Even if some of the top lines are red, you really only need to work on optimizing a connectivity graph if the idle time (last two lines) is red, otherwise everything is ok.
Ok example time.
Load Naboo2 and type "pathcost tot" in the console. Watch it for a minute or so until the game gets started and the numbers even out. There will be two red lines in the connection list. The first is probably "none" with around 30% in the tot column. Look at the ave column for this its 0.001, which is fine. The reason that its getting so much total time is because there are 1500+ hits in the cnt column. So ignore this one.
The other red line is C44, which is getting a bunch of hits (200+), and has an ave time of 0.006 sec. Both of these are ok numbers, but together they're using 18% (tot column) of all pathing time. If you load up naboo2 in the editor you'll see that Connection44 goes through some buildings and has a whole lot of barriers in the way. So this would be the first connection to look at if you were trying to optimize it.
But fortunately if you look at the bottom two sections, you'll see that the queue time is probably around 2 seconds, and the idle time is around 1 second. Both of these are very good numbers, and mean that an AI guy will usually wait around for only a second. So you really don't need to optimize anything on this level.
Example two. Yavin.
The AI guys used to stand around a lot on yavin, mostly because they were waiting for paths. It was really slow because of all the trees and stairs that they had to path through.
I went through yavin and optimized it, to see if this process would really work. It does. I got the idle time down from 30+ seconds to about 5 on the ps2. This is probably as good as its gonna get without clearing some of the trees out.
If you want to see the numbers when they're slow, go into sourcesafe and get the yavin1.BAR and yavin1.PLN from before this morning. The slow legs are shown very clearly. In the new graph I shortened some of the problem legs, then where it was still slow I made the barriers tighter around the trees and objects (to give more room for the paths). There is probably some more work that could be done, but the AI guys move around a lot better even now.
A few new AI console commands that may come in handy when building levels:
As always you have to turn on AI mode first by typing "aimode 1" or setting it on the command line with "/ai".
"ai.showobstacles 1"
This shows the barriers in the world as before (green boxes), but it also shows them expanded by the player's radius (blue boxes), so you know exactly where a player will fit. If two blue boxes are overlapping, the player will not path between them. It expands by the radius of whatever vehicle you're in as well, so if you get in an ATST, the blue boxes will expand to the size that an ATST can path through.
"ai.notext 1"
This turns off all the white text that follows around the guys when AI mode is on, so you can see other things.
You can also set this on the command line with "/ainotext".
"ai.showallpaths 1"
This will show the paths of every AI player in the world (red lines), so you can get an idea of where everybody is going. (if the lines go through solid objects, it's probably a good sign you're missing some barriers)
"ai.showconnectivitygraph 1"
Shows the connectivity graph in the world as yellow cylinders/lines.
Using the SetMaxFlyHeight(30) in the lua, you can now set the max height for jet- and dark-troopers.
Try "showflyerheights" to view the height in the game.
Change it with "ai.aimaxflyheight".