R&D AI Improvements

[Vereist]

Taking a couple of wild-ass guesses here, for the instances of them showing up right on the periphery before warping away, the path visibility is probably using unit distances rather than the actual number of visible tiles there are, which won't necessarily be the same thing. There are a lot of instances of the distance stuff being multiplied by 64, which means that's probably the tile size in Unreal units. So, when it looks for things, it uses the actual vector distance, even though the actual visibility/movement/whatever uses the tile counts. If that's correct, I don't know that there's a fix. You could try dropping the SightRadius on player units by 1, since it wouldn't surprise me if they hard-coded the visible radius unit distance instead of getting it from the unit's tile sight radius.

 

Now, if they're actually walking across somewhere in the middle of your field of view instead of the edges, no idea.

 

And, unless I'm misreading / misunderstanding how this works, when it looks for a valid location with FindValidPathDestinationToward, it eventually fails out into just teleporting to whatever the nearest cover location is. So, if it's looking at the cost of pathing versus where it can actually navigate to using the navmesh, it's possible that every move cost be so high that it can't do anything aside from warp. And that's a situation that's likely to happen if you've got it surrounded in an open area, or you have so many enemies and friendlies taking up all the available cover slots. On the other hand, they explicitly aren't using A* in that function. Though that doesn't mean they aren't calculating pathing costs with something else like the overwatch/flanking LOS.

 

You could try artificially limiting its acceptable vector distance in the if(VSizeSq(m_kUnit.Location - kClosest.TileLocation) < VSizeSq(m_kUnit.Location -vDest)) line and see what happens there.

[Andeerz]

Any way to make all alien pods active by default? :)

[johnnylump]

Amineri proposed a solution to activate all pods by default in the other thread a while ago. I went ahead and researched and posted the hex change that would put her proposal into the code (in the "Turning on alien pods by default" thread). Let us know if it works!

Edited June 18, 2013 by johnnylump

[Amineri]

Realized I should probably drop this hex change into this thread as well.

 

The alien patrol distance in vanilla is set to a rather absurd 45 distance units (30 tiles). In comparison a standard sectoid or XCOM soldier has movement 12 (8 tiles).

 

The following hex will reduce the patrol distance from 45 to 20 (a bit less than a dash move)

 

In XComAlienPathHandler.InitTrippedPatrol

original:
m_fPathingDistancePerTurn = 45.0;
0F 01 7a 2F 00 00 1E 00 00 34 42 

new:
m_fPathingDistancePerTurn = 20.0;
0F 01 7a 2F 00 00 1E 00 00 A0 41 

I know that this affects aliens that begin patrolling because an XCOM soldier makes noise that an alien unit "hears", causing the unit to being patrolling.

 

I'm not 100% sure if it affects alien pods that start off a mission patrolling.

[johnnylump]

Have you noticed a significant difference in battles with this change in effect?

[Amineri]

Have you noticed a significant difference in battles with this change in effect?

 

I haven't tested it super-extensively, but it seems as though alien patrols no longer move in such crazy ways.

 

I kept seeing issues on the following map:

 

 

I've turned on the unit detailed descriptions so you can tell where the alien pods are.

 

My test scenario was to go right first, and clear out that pod, then move across the alley to the left.

I often found that a soldier would make enough noise and would cause the pod on the left to begin to patrol. Typical behavior would be that the patrol would move from the building on the left down to the bus stop at the lower right in a single turn, past the XCOM units that were stationed in the alley.

 

Reducing the tripped patrol distance seems to have removed this behavior.

 

Unfortunately there is just one patrol distance hard-wired, and it isn't a function of the unit's inherent move distance, but I figured patrols wouldn't always move at maximum speed.

[Amineri]

I found a coding bug that is preventing the AI from hardly ever using the Hunker Down ability.

 

The Defense priority for Hunker Down (the Ability is technically 38 = eAbility_TakeCover) is:

            case 38:
                fScore = float(Min(int(0.30), int(float(m_kUnit.m_arrEnemiesEngagedBy.Length) * 0.10)));
                break;

Note that int(0.30) is always zero. The second argument will also be zero unless there are 10+ enemies engaged. Regardless, the function is taking the Min, and one argument is always zero, meaning that the Hunker Down defense score is always zero.

 

The correct code should have been:

            case 38:
                fScore = FMin(0.30, float(m_kUnit.m_arrEnemiesEngagedBy.Length) * 0.10);
                break;

And yes, there is FMin operator for taking minimum for floats (0xF4), as opposed to the regular Min operator for ints (0xF9)

 

Nicely, the hex change is very simply and local:

XGAIAbilityDM.AI_DefenseScore

original:
fScore = float(Min(int(0.30), int(float(m_kUnit.m_arrEnemiesEngagedBy.Length) * 0.10)));
0F 00 03 89 00 00 38 3F F9 38 44 1E 9A 99 99 3E 38 44 AB 38 3F 36 19 01 B2 88 00 00 09 00 98 30 00 00 00 01 98 30 00 00 1E CD CC CC 3D 16 16 

new:
fScore = FMin(0.30, float(m_kUnit.m_arrEnemiesEngagedBy.Length) * 0.10);
0F 00 03 89 00 00 F4 1E 9A 99 99 3E AB 38 3F 36 19 01 B2 88 00 00 09 00 98 30 00 00 00 01 98 30 00 00 1E CD CC CC 3D 16 16 0B 0B 0B 0B 0B 0B 

This should result in aliens that can't move (or don't have a good spot to move to) and don't have a good shot (so the shot priority is low) should sometimes use Hunker Down. This is the only mechanic that adds Hunker Down priority (neither Offense nor Intangibles add priority to this skill), so before this priority would always end up at zero, and be trimmed as a non-option.

 

I'd love any feedback / interesting stories about Hunkering Down aliens with this hex change :D

[johnnylump]

I'd seen an alien hunker down exactly once before entering this code.

 

Now I'm seeing it, but not too often. The aliens are using it fairly intelligently ... typically when outnumbered, injured and under cover without a lot of other good options. Seen suppressed alien do it, too.

 

Trying to target them at range has given a 1 percent chance to hit ... I dealt with that in one case by rolling a SHIV up next to the sectoid and getting a 100% chance to hit.

 

So far I'd rate this an excellent fix; I've put it in the bug fixes thread, as well.

[Amineri]

Double post ... ~_~

Edited July 11, 2013 by Amineri

[Tycus]

I believe I have found out how squad tactics are implemented (and was really disappointed by that). In <XGAIAbilityDM> there is function <AddOrFilterTeamAttack>, that handles (overrides) basic unit tactics and it launches itself only in 2 cases: on team member being flanked (function PassesTeamAttackFlanker), and on team member being suppressed (PassesTeamAttackSuppress). In all other cases unless unit has some predefined behavior in XGAIBehavior_{alien_type} it tactics will be handled by general XGAIBehavior. (unless I have misread the code)

More to that, team attacks aren't being handled very well. It works by increasing targeting priority of enemy doing flanking/suppressing action... and then it usually assigns task of taking out threat to threatened unit itself (which is not very smart; actually, it is so bad, that it could be counted as AI exploit: try it - suppress alien and it will fire at suppressor every damn time). It usually happens because all other units may be "unavailable" for task.

In regards of suppression there is so many conditions (most of them are quite reasonable) that completely prevent using that tactic, and it is given incredibly low priority (compared to it usefulness). Also there is so many overrides that forcing alien units to "take the shot", so it is completely unsurprising for me, that some people don't know that all aliens with captureable weapons have suppress ability (but hardly ever using it).

 

Now I would like to add to goals of this thread:

1) Fix priorities, so unit will prioritise standard shot only at exposed/flanked target; in all other cases force to consider other options first (ie 'nades, suppress and overwatch);

2) Fix priority of suppression, so its score would depend on suppression value of a weapon;

3) Fix teamattack to correct response for suppression, ie suppress the suppressor;

4) Reinforce use of suppress on overwatching enemies;

5) Reinforce use of suppress on single enemy in sight;

Yes, I love suppression, and while playing aliens in multiplayer was using it quite a lot.

 

Also, I detected a few (possibly) bugs in individual behaviors of certain alien types, namely Muton Berserker not using its BullRush ability as second move (was using only as a first; i believe there is some coding oversight that prevents him from doing just that), also it is coded in such way that it will target only walls with this ability (ability itself works just as well on any type of destructible cover (obviously with exception of cars).

And I can confirm that suppressing units being immune to damage from AoE attacks, but not to AoE damage that comes from exploding cover (Bullrush failed to damage trooper, that was suppressing other muton; but other time trooper covering behind elerium power source was killed in its explosion, when suppressed (by this very trooper) outsider shot it and missed shot blow it up).