For AI-"improvements", should I add a new option or use the existing "sneakyAI"?

[Yankes]

Civilians get drastically reduced score for that. (I shall also do that for the sniper, target-selection I just realized).

This should not be true for many mods, in some civilians could be bigger threat than xcom. Probably you should check if unit have weapon in hands or not.
This could be exploited by players but it could be consider a game mechanic ("drop weapon and run away").

[Xilmi]

The main issue with "best tile" comes up with with extended accuracy/no-LOS penalty options (not sure if you've tested those as well). There each tile might have a different accuracy to the target. Then it might become a difficult optimization problem which tile is "best" to move to

I've seen code for that in the original Method for that. There it calculates a score-modifier. I figure that this functionality would drastically change what is and what isn't a good overall strategy.

should you try to move to a tile, where the alien can itself see the enemy and remove the no-LOS penalty?

I thought it would be simple and an easily accessible variable how far an alien can see. But apparently you can't really tell without doing the entire visibility calculations that are done after moving. Especially when potential mods come into play. I didn't put too much effort into it, as without a massive accuracy-fall-off, having a line of fire and a dedicated spotter almost seems better than getting direct vision yourself, as that likely also exposes you to return-fire.

or at least that the unit does not unnecessarily move closer to the target and expose itself if doing so does not provide any real advantage.

You are right. Currently getting LoF on more targets increases the score. But this might exactly lead to the behavior of getting closer than it would have to and is a double-edged sword anyways due to also risking more return fire. So I guess I don't even need to do this. It's better to stay inside a house and look out of the window on one enemy than to run outside so you can see 3. So yeah. This is particularly good advice.

I should also look into how I can reserve TUs for the Alien and get a callback to think() before it's exceeded. That would save a lot of most likely unnecessary and expensive workarounds emulate the same thing.

It's basically fighting on 2 fronts: Making the behavior smart while also avoiding to have the aliens take too long for their turn.

[Xilmi]

This should not be true for many mods, in some civilians could be bigger threat than xcom. Probably you should check if unit have weapon in hands or not.
This could be exploited by players but it could be consider a game mechanic ("drop weapon and run away").

I think X-Com-units should always qualify as a threat. So exploit averted. But I could do the weapon-check on the neutrals.
Also: I didn't mean to ignore them, just de-prioritize them. If there's no X-Com-soldier but a civilian available to shoot at, it would still be done.

[psavola]

Actually, it seems as if the aliens are currently more interested in killing civilians than X-COM units, even if they have a chance. You might consider if you intentionally want to change this balance. You can in particular see this in terror missions (or in mods, custom missions where civilians might include units that fight on your side). In part the explanation might be that X-COM units are usually kept in better cover, and the AI keeps other units exposed, thus providing easier access to attack them. But I think I have numerous times also seen the aliens choose in their terror rage a harmless civilian as their target rather than an X-COM soldier.

As an additional potential way to make AI smarter and much more dangerous in certain contexts, the aliens might be aware of how their attacks affect various enemies. For example, there are aliens which cannot hurt tanks (in TFTD, for example tentaculats and hallucinoids) and a useful tactic is to push tanks to the front, so the aliens attack them (with little success). Such an alien could try to choose another target, instead of trying to attack with zero effect.

[Solarius Scorch]

AFAIK civilians use a simplified AI code, as thry only move once and not twice (like aliens do). I'm not 100% sure if it's true, but it sure looks like it. And also, they seem to start with 0 TU (as opposed to aliens).
If true, can these be disabled, so they move the same way as aliens? If not, can this be added please?

[Meridian]

Civilians use the same AI as aliens.
(Mind-controlled xcom also uses the same AI as aliens.)

Civilians also get 2 actions, same as aliens.
Civilians start with full TU, same as aliens.

[Solarius Scorch]

Civilians use the same AI as aliens.
(Mind-controlled xcom also uses the same AI as aliens.)

Civilians also get 2 actions, same as aliens.
Civilians start with full TU, same as aliens.

Thank you, I was misinformed, then.

In this case, I have no further requests for civilian/alien AI, other than healing.

[Xilmi]

Civilians use the same AI as aliens.

Good hint. I was wondering why they just stood there and did nothing. My AI simply didn't know what to do with them. So I needed to let them be controlled by regular AI instead.

I tried some different approaches yesterday, broke an important part of my code thinking I didn't need it and now am trying to find a more performant replacement.

First thing I tried was doing a lof-evaluation for the entire map. Well, no. It's way too slow.
I also realized that doing lof-calculations in both directions is not needed, as except for some fringe cases it usually should be the same both ways.

Then I wanted to make safety more valuable than being able to lof more than one opponent and divided the position-score by the number of lof from it. The advantage was that the aliens then took really neat covered positions.
The disadvantage was that the backup for the spotter was really shitty.

Then I wrote a really cheap (since no pathfinding is needed) way for hiding in cases where no lof can be obtained anyways. Using that same algorithm when TU's are too low to still fire as a means for hiding after shooting, this pretty much lead to the castle-defense-behavior that was described here earlier.
It works particularly well when fighting over buildings with windows.
I've seen two major disadvantages with it. For UFOs, especially with a narrow design like the large scout, it's not that great as they can't look outside and tend block each other and thus could be singled out.
The other one is that it makes the entire spotter/sniper-dynamic completely useless. It also allows me to safely run my units through open terrain as long as it's far enough from buildings.
Regardless of efficiency, it feels a bit too predictable and dull to fight against.

What I also tried was charging a unit that was already lofed by one of my units with everything. Charging a lofed unit is a lot saver than charging a hidden unit. Simply because we are pretty much guaranteed to get into firing-range on our turn, which allows to pelt it with everyone. And as opposed as to the single-spotter-approach, the loss of our spotter isn't as bad.

The big problem here is that my original approach to charging a unit was quite costly in terms of pathfinding. I had already removed that costly code as it was just ugly and if you pathfind directly on the unit you want to go to, it breaks once it gets into vision. And by breaks I mean it takes a really long time and then just has no result anyways because you obviously can't find a path to a tile that's blocked.

Workaround was to try and pathfind to tiles near the target-unit. But that can be even slower if tiles are tried and then discarded anyways because they might also be blocked.

I think I might have to dabble into pathfinding itself, which is a bit of a scary prospect. What I want is a pathfinding function, that, if it couldn't get a path to the destination, returns whatever path brought it closest to the target and maybe also ignores when a path is blocked by a unit instead of a solid obstacle.

That way I wouldn't need hacky and very processing-time-intense workarounds to basically achieve the same as that function would. I think it would reopen possibilities I have discarded for being too time intense.

[Xilmi]

AFAIK civilians use a simplified AI code, as thry only move once and not twice (like aliens do).

Civilians also get 2 actions, same as aliens.

Hu? What is that even about? From what I can tell there is no action-limit for the AI. When I had bugs in my code the alien would jiggle around doing like 10 or more actions. I think I need to specifically set action.type to "BA_NONE".
I think that maybe it has something to do with setting action.number -= 1, when the AI moves. I'm not sure it's necessary. But if it is, then the author of the original AI already used this "trick" to work around any potential action-limit.

[Meridian]

Hu? What is that even about?

It's about the _AIActionCounter variable in BattlescapeGame.cpp

[Xilmi]

It's about the _AIActionCounter variable in BattlescapeGame.cpp

I found this code inside of where _AIActionCounter is checked:

         if (!_save->getDebugMode())
         {
            _endTurnRequested = true;
            statePushBack(0); // end AI turn
         }
         else
         {
            _save->selectNextPlayerUnit();
            _debugPlay = true;
         }

Seems like that means it behaves differently in debug-mode and the reason for me to have thought that there is no action-limit is because I obviously debug my AI-changes in debug-mode.
I've also already realized that in Debug-Mode shooting doesn't cost ammunition.

I don't exactly agree with debug-mode changing the behavior of the game in ways like that. It can be kind of confusing to the unsuspecting programmer. I mean it right there explains why in my test-game without debug-mode there was a sectoid at the window that didn't shoot on their turn and probably also in general why I thought it felt easier than I thought it should feel.

I also obviously wouldn't want my AI be limited to two actions. "Move in, attack, attack again and move out" is a pretty common sequence of events that requires 4 actions.

Edit: Okay, I just need to make sure to do the "action.number -= 1"-trick for every action and set action.type to "BA_NONE" when I'm done at the end. Which is what I had to do anyways to avoid an endless-loop in debug-mode.

[Meridian]

That particular code just handles whether the AI turn should end (normal gameplay)... or if the player/developer gets a chance to move aliens manually after they have moved (feature of the debug mode).

[Xilmi]

That particular code just handles whether the AI turn should end (normal gameplay)... or if the player/developer gets a chance to move aliens manually after they have moved (feature of the debug mode).

Ah, okay. That makes sense.
That feature has proven actually very useful to see what reasons there could be for them not attacking when I thought they should have. (No lof, no TUs etc.)

Then there's a different reason for that particular sectoid not shooting and I couldn't analyze it because I wasn't in debug-mode.

I'll just keep using the workaround to get unlimited passes then .

[Xilmi]

I think I found the perfect solution for all my Pathfinding-Pains! 

findReachable already internally figures out how costly walking to each tile is.

And then discards that information while just returning a vector of tile-IDs.

I made a findReachablePathFindingNodes, that is the same except that instead of discarding the super-useful information, it returns it!

I then temporarily set the unit's TUs to 10000 and ran it.

So I get the information I need for AI (whether a tile is reachable and how far away it is) in a single function call that is processed almost instantly.

Afterwards I just need to look it up.

The way that findFirePoint in the regular AI determines the TU-costs to get around could also be changed to draw from a vastly bigger pool of possible tiles because I suppose the reason it restricts itself to the 121 closest tiles probably is to save processing-time that is wasted by doing a pathfinding-call to all of them individually.

It is such a relief, that I now can make the AI much better at determining where to go without compromising turn-times.

[Cooper]

More intelligent aliens could be a really interesting challenge.

Some things that would be cool:
-Picking up weapons if they have none (after dropping it due to a berserk for example)
-Making mind controlled xcom suicide with grenades or other explosive weapons
-Making mind controlled xcom throw away their weapons sometimes
-Also stoked about ideas already mentioned about using medkit, and scouts/snipers, etc. Maybe "medic" aliens can finally actually be medics
-Using medkits to wake up stunned aliens