I'm close to producing something semi-usable (pending the fixes ont he hitprobabilities), and I spent my last day debugging my working copy.
Here's one thing that really puzzled me:
some aliens end up having "ent->chr.reservedTus.reaction>0" while the other members of the reservedTu struct seem uninitialized (like weapon).
AI_FighterCalcBestAction considers using "tu = ent->TU - move", which is fine as long as noone has enabled RF. This ends up in aliens trying to use more TU's than they have while shooting (G_ActionCheck returning qfalse), and even worse, when moving (so they end up a few spots before their cover destination in plain LOS/LOF).
I replaced the usages of "ent->TU" with "G_ActorUsableTUs(ent)", as an immediate patch to this behaviour, but this needs to be looked into more detail as it gimps some aliens (less tu's) without a reason.
For some reason RF keeps giving my alien who's interrupting a chance to play as if it was his turn. Somehow it only works for the alien that is reacting, and I like this one. The problem is that the G_ActionCheck always returns false because "level.activeTeam != player->pers.team". activeTeam is set for the player.
So currently, this RF doesn't work with the AI I'm building unless some changes in trunk in the past 2 weeks adressed this issue. If someone is up-to-date in trunk, try and see if G_ActionCheck's first if statement is ever entered while you're causing a RF.
Also: please consider rolling the 2.3 AI back to it's release version, at least for changes produced in this thread. Lemme play around with the AI in the trunk, and if we deem them to be proper AND STABLE, then we can copy them to 2.3. You could keep the dodon patch if you think it's ok, but I believe it's behaviour is only fitting along with the fixes in the damage estimation.
The mess I created by that 'innocent' code refactorization that got posted in 2.3 introduced a series of crash-bugs. Thank god for geever pointing that out to me the hordes of angry players.
UPDATEOk, since the playtime is now below 2-3mins for small maps, haven't crashed in 3 hrs and I merged with latest trunk, I guess you can have a look at my current work copy and see how it feels:
the diff vs trunk 31041. I have no idea how easy it is to apply those, I spent like 40 mins trying to get mine to work when I was moving to latest trunk.
The entire g_ai.c file if you don't like the patch You should also add "#define GUETE_DAMAGE_AVOID_FACTOR 0.4" in g_ai.h.
PLEASE DON'T COMMIT THE PATCH. There are quite a few things I need to do before we can consider that one, namely the performance.
Kildor on IRC mentioned that he gets an undefined reference for TR_TestLine on line 165, you can just delete lines 33 up to 203 and get away with it (as long as you don't try to enable math estimation as mentioned later on). Also delete the entire AI_CalculateDamageMath in this case.
Now some general notes on the code: Currently only the sampling damage estimation via G_ShootSingle is in, after applying some sensible optimizations. You can find some blocks of "#if 0/#endif" that drop the main dmg estimation function of 31041 and most importantly the code that enables selection between sampling and math-based damage estimation.
The reason why the math-based (see: CL_GetHitProbability) is out is because:
a) it has some inherent problems with occlusion (as mentioned in previous posts) which are still not fixed
b) I think I did something wrong. The result comparison between those the two estimation methods vary so much, as to imply it.
Uncomment the block before line 500 to see the difference with the math enabled (while commenting out line 500). You may wish to also comment-out 494-497 and all lines referencing testTotalDamage, these are used to compare results from both damage estimations.
You will find many //-style comments, these are things that need to be removed/ironed-out before considering to applying this patch to trunk.
I'd mention the new wonderful things I saw my critters do, but I'm biased and want to hear your own comments. The bad things I've spotted so far that I need to fix are:
* Need to preclude from the G_Vis calculation (next to the HideNeeded) any units we expect to kill. Example: a machinegunner chose to run away and hide from a lone knife yielder that had the misfortune to end his turn 2 blocks away from him. The knifer was also the only one in the building.
* Get rid of the RF TU's that are auto-magically held for some (apparently random) aliens. Waaaait a moment, I do remember that shaken actors 'refuse to let his guard down', maybe this is the perpetrator?
Also, in reference to the dodon patch, I switched the "!HideNeeded || !G_Vis..." to "!G_Vis && !HideNeeded". The reason is that you want to be BOTH non-visible AND non-shootable, and in that order, is because:
a) If you're visible, you're most likely shootable, so don't use the horrendously expensive HideNeeded (I kinda beefed it up a bit)
b) You can be non-visible and still shootable: EXACTLY Behind someone's back (so CLOSE_IN maximizes too). Which was what the critters (melee units mostly) would prefer to do in closerange. It can be 'oh WOW!' if you didn't pay attention on the enemy's turn, but unless we can find a way to only allow this via non-visible flanking moves, it's too silly.
A very precious performance trick that I just thought:
Since the G_Shoot*'s are the performance hitters, and AI_HideNeeded really hammers those mulitple times for each alien, why not create a 'Threat Map' that is common for all the aliens? The only thing mobile in our turn is us, so all the damage an enemy can apply to a certain square is almost (unless we cut a LOF with the body of an alien) fixed (sans the armor protection). Assuming that aliens really consider 200 spots to move (as per shaun's post), they will also check damage received from 8 enemies, with an avg of 3 different firetypes. So 200x8x3=4800 calls to damage estimations (ha! times 10 for the sampling)
Then we should (we actually don't) do the same in the case we shoot-and-move (FindHidingLocation), times the amount of aliens we move == the reason this is still slow.
If we share a 'threat map' common for all aliens, we should be dropping the performance cost of hiding anywhere from X-fold to 2X-fold (where X is the number of aliens we have).