AI-Uveso (v112) - AI mod for FAForever

While I expect the AI has been designed for more conventional ladder 1v1 matches rather than the 1v1 map I chose, I've still noted various issues/flaws with what the AI did which I think would be applicable more generally. This was using the 1 June uveso mod:

Replay ID #14646432
Uveso adaptive Vs guncom:

• 1st Land fac location - it picks somewhere that requires the com to move (losing a couple of seconds)

• Power order - It has a hydrocarbon right by the starting location, yet focuses on building 3 T1 power gens first. It'd be more efficient to have the com assist the hydrocarbon once the first engi is done (e.g. have the com get t1 mexes while the engi is being built, then assist the hydrocarbon); on a map where the hydrocarbon is further away then I could see more merit in getting more t1 pgens first

• Power stalling and lack of focus - the AI has a com building 1 T1 pgen, an engi building a 2nd T1 pgen, and a 2nd engi building a hydrocarbon, all while power stalling. Far better to focus on the most power efficient option (Hydro), and pause any construction while power stalling until the power generation is completed

• Mass stalling/not claiming T1 mex - the AI mass stalled for a while (with far more spent mass then generated) all while 2 unclaimed mexes are in range of engineers. While mass stalling, more power is being started/built, and then a t1 factory; far better to focus on generating easy mass (t1 extractors), then the factory (assuming more build power is needed), and then more t1 power (assuming the planned strategy requires significantly more energy), than to try and do all at once

• Too much power - Far more power is built than needed (12 T1 and hydro would be enough if going for a gun upgrade, but instead the power is wasted)

• Engineers sent out dont start building at nearest t1 mexes

• Strange order changing - The first t1 engi sent out of the main base passes 2 unclaimed mexes, then goes all the way back to base while other engis go to where it originally was; presumably some command given to that first engi, but it would've make sense to take one of the others nearer the base for the new command and use the far out engi to build t1 mex

• Unused build power/factories - Lots of t1 land factories built, but some of these appear to sit idle.
  No need to construct more factories if the existing ones aren't going to be used. The factory also sat idle despite a big threat [guncom] being scouted

• Feeding an enemy kills - Scouts come across guncom - instead of sending all defenceless units away from it, and building up something to try and counter it, the AI keeps sending engineers and unarmed scouts piecemeal (giving the guncom free kills)

• Storage before T2 Mex - Engineers build mass storage between 2 t1 mex; better to first upgrade those mex to t2 before building the storage

• Mass generation prioritisation - The mass storage is built at the same time as the T2 mex upgrade, all while mass stalling. Normally it's best to focus on 1 mass generation (i.e. the t2 mex upgrade) first, and once complete move on to the next (e.g. mass storage). The exception being if there's significant amount of mass built up that can be used (not the case here).

• Unit mix - Preference for lots of engineers over any combat units, meaning vulnerable to just about any attack. Although lots of buildpower gives the option to try and respond quicker to threats (e.g. get quick PD up, or assist an air factory to rush bombers etc.), the AI didn't make use of the engineers and hence offered no resistance to the enemy commander.

• Counterproductive COM micro - The AI sent its unupgraded com (with no support) to fight mine. The AI com then 'stutters' (about 6m5s in), getting about 1 shot to every 4-5 of my coms (I'd expect 1 shot for every 2 of mine given mine had a speed upgrade) - it keeps rotating as if it's thinking about doing something else before switching to attacking my com. In observer mode it looks like this might be due to move commands sent to the com - maybe they're being sent/changed too often?

• Energy storage for combat - In the situation where you have lots of surplus power and build power, minimal ground units, but your com is about to get into battle, then getting 1 energy storage as a top priority might help sway the battle in your favour.
  In this scenario it wouldn't have been enough, but would still have been of a bit of use given the excess T1 pgens that had been built

• Response to attack - similarly to the unit mix point above, despite scouting an enemy guncom advancing on the main base, no units or pd were built in response to this threat (lots of engineers, land facs and an air fac were available). Instead some factories are idle, others are producing engineers, and 2 new naval yards are being built, all while mass stalling

@maudlin27

great feedback!

Well, my AI is a turle AI and normaly i would play on this map against the "rush" sub AI with a cheat and buildfactor of 1.7
The adaptive AI uses 40% of its overall income to upgrade mex etc. So it has no eco for combat units at the beginning.
Thats because turtle playes don't attack in the first 5 minutes with a Gun Com ^^ They use the ACU as engineer

I am not sure if we could make an duel style AI.
There are some limits by the game engine and we can't make everything possible.

Its like the ACU torsotwist. its adjusting the torso on almost every movement command.
So its sometimes not firing at all when evading.

But build order and better timing can be done.
I will do a test AI with your recommendations and see how it works.

Thank you again for your much appreciated feedback!

Is it possible for the AI to be reactive (e.g. the moment a scout reveals a threat the AI changes strategy), or does it have to try and pre-empt potential enemy attacks by covering all bases (e.g. build AA, PD, TMD, T2 arti in anticipation of potential attacks regardless of whether the enemy has any of the units in question)?

Similarly, if a command is sent to start construction of something, and a critical event happens (power stall, or to a much lesser extent mass stall) can the AI be told to change what it's doing then, or would it have to wait until the next event (e.g. construction finishes)?

In terms of the eco side, if the intention is to eco and not build any defence then I'd do a 'hard eco' - i.e. there's no point building so many t1 factories, engineers and power initially; better to get more mass generation (so t1 engi's prioritise any near unclaimed mex first, then switch to upgrading a mex near the core base to t2), enough power to support an upgrade to T2, get T2 upgrade on com or factory, and hope to then make use of the tech and eco advantage to turtle up before the enemy catches on and tries to rush. That is, a couple of token t1 land units won't help unless the enemy sends their com with no upgrades and no support, or builds zero land units (meaning their mex can be killed), both of which are highly unlikely, but having the capability to build lots of land units (without using such capability) is using up alot of resource and delaying the point at which you can get t2 defence.

Technically - yes - it is possible. However, the real weakness is that there are no metrics or functions that can easily, or more importantly, performance-wise, address that kind of scenario. The AI, unlike the human, has little to no ability to 'remember' what he saw, even just seconds ago. This makes pro-active behaviors difficult to construct.

Eco management is another weak area, and one the AI has some difficulty adjusting to - part of the problem is one of scale, another is the game design itself. Due to the random nature of the unit designs, there is little commonality in building costs and times - as a result, a constructor's consumption can bounce erratically from item to item, a condition which afflicts factory builds as well. Many attempts have been made to have the AI 'pause' his construction, which is unfortunately a band-aid on the problem - the real problem being one of reasonably accurate prediction of consumption. The side effect of the original code designed to 'pause' building is a ping-pong of rather costly events which don't solve the economy issue, but tend to push it around, and at some considerable cost to the performance.

There have been many potential AI developers over the years that have had the best of intentions, only to throw their hands up at the inability to address that flaw.

@maudlin27

Yes the AI can react to threat and is able to change its behavior.
Its not changing a kind of strategy, but builder will change what they build or what they attack.

In case we use custom made functions then we can also cancel build orders or stop an ACU
enhancement when we need to move the ACU. My AI is using a custom function for the ACU and is
able to cancel enhancements.

And again thanks for your detailed hints how the AI should make the first decisions.
I said it already i am a turtle player. My only experience with a competitive opening is watching
replays from Nexus and Tagada.

Since you are very interested in how the AI works, here is a good example of how
complex is it to move just the ACU around.

Here is a link to the LUA code lines for the ACU:
https://github.com/Uveso/AI-Uveso/blob/master/hook/lua/platoon.lua#L3396

You don't need to read the LUA code itself.
Just read the remark lines between the code (starting with --)
The function starts at line 3396 and ends in line 4181.
So there are about 780 lines of code needed to just move the ACU in a more smart way
than the original function.

The following function (ACUChampionBaseTargetThread) with 230 lines of code
is for the ACU targeting and awareness of enemy units around the ACU

Like Sprouto said, technically; Yes we can do everything.
But, you can't make every function more smart like the ACU function because we don't
have the CPU power for it.
The whole AI is programmed in LUA, and LUA is a language that is not precompiled.
The game is loading the plain LUA textfiles, then compiling it in a c-engine friendly format
and executes the LUA code.
And this is so incredibly slow compared to c-code.

But we can make better decisions on the start for buildorder or eco using.
(btw, upgrading the closest mex to the base is also a custom function,the original function
was uprading following the buildorder no matter how far away from the base the mex was)

We can't do anything but at least we can try to make a more competive 1vs1 AI.

Interesting, thanks for the info and link

With the massive caveat that I've never coded AI before, I thought I'd set out some thoughts on possible approaches to having the AI avoid some of the more detrimental issues regarding performance that I'd hope wouldn't be too resource intensive, in case my ramblings are of any use (although I expect better solutions to the below have probably already been worked through!)

• Have a choice of several (pre-planned) initial build orders which is decided when the map loads (e.g. based on no. of mexes, proximity of those mexes, and the distance of the nearest hydrocarbon, a preset build order is settled on, which would be setup for the preferred AI strategy - in this case an AI turtle), the idea being to get to a certain initial goal assuming minimal attacks from the enemy (e.g. for a turtle it might be getting t2 defences up). At its simplest level this could just be a build order for if there's a hydrocarbon in the main base area, a build order for if there's a hydrocarbon relatively near the initial base, and a build order for if there's no near hydrocarbon, with further subsequent adjustments re the no. of T1 power to be built and when to upgrade the first T2 mex based on how many nearby extractors and reclaim there is. This would only need calling once which may allow CPU overload issues to be avoided.

• Assuming it's possible to have some sort of event occur when an engineer is either idle or has finished construction (?), then before an engineer starts a new construction it considers the current resource expectations based on what's being built, and then decides if it should proceed or wait. If it was possible, then the accuracy of this approach would be improved if this check took place just before an engineer started building (i.e. when it's within range), to avoid the risk of say 10 engineers queuing up production that they have to move to, and all 10 thinking there's enough resources to start construction. If its not too resource intensive it could also check if the same building is already being built nearby, and assist that instead, with a few exceptions (e.g. t1 mex are so cheap that it's usually better to send engineers to multiple extractors at once instead of having them assist 1 at a time). If such a check would be too tough, could a variant be to store a temporary variable/array recording details of buildings that start being constructed, allowing a cycling through such variables once there're sufficient resources to resume construction

• If the engi chooses to wait, then either via a delayed command or a new construction event that causes idle engineers to be cycled through the engineer would then commence construction (once sufficient resources will be available)
  The delay command wouldn't apply where the unit/building to be built will help with the resource shortage (e.g. you don't stop a T1 engineer building a t1 mass extractor if there won't be enough mass, or stop them building a power generator if there won't be enough power)

• Certain 'critical' events cause a reprioritisation of existing engineers, with two of these critical events being power stall and mass overflow (or ideally the point at which such an event in the near future looks likely rather than waiting for it to actually occur). Assuming there's no way to create an event based off this, code relating to such a reprioritisation could be checked for at the point at which an engineer decides what to build (i.e. just before construction/when construction is completed), assuming there's some sort of event linked to this. Where such an event occurs then all engineers near the base get re-assigned (with any part-completed buildings recorded in an array to be referred to/resumed later). In the case of a power stall, the solution would be building more power (requiring an assessment of whether it's better to get t1, T2 or T3 where there's access to more than 1 tech level). In the case of mass overflow it'd be a bit harder to code a fix -if not at the experimental stage then a temporary fix is to upgrade mexes assuming enough power, while also getting more build power and if necessary energy as a priority so that the mass can be used.

More generally though, if the aim is to get the AI to improve it's 1v1 performance, it may be worth considering whether to always go for an 'eco/turtle' initial approach. That is, if I was to try and turtle/eco, on the majority of ladder 1v1 maps I reckon I'd get crushed by a rank 700+ player, since the preferred strategy seems to be mass t1 land spam coupled with a map that has loads of extractors and reclaim. If I dont do t1 land spam and instead try to e.g. upgrade my mexes to t2 early on with the mass that woudl've been spent on units I find I'll lose almost all the map control, and since t1 mexes are vastly more efficient than T2 mexes my opponent will be able to out-eco me, while also applying lots of pressure with their land spam (since unless the map is huge, they'll probably be able to have t1 arti attacking my core base before I can get t2 pd up).

I figured I'd have a go on a slightly more conventional 1v1 map for a comparison, and go with a more conventional mix of T1 spam units (although this is less t1 spam than I normally face as I need to work on my initial build order for 1v1 maps so I ended up upgrading my T2 mexes quite early instead) - see replay ID #14660835:

• As expected the AI still has similar issues with the initial build order (although my build order also wasn't great on this map!) and is slow to expand - due to this, about 4m in I've got about twice the mass income with a similar build power (and sufficient energy for my needs)
• I was pleased to see the AI reclaiming the nearby mass deposits
• My attack was slower this time, and the AI ACU did a much better job of defending, both dealing with an initial push by a handful of land units, and then having energy storage which it used effectively with overcharge to kill clumped up t1 land units, so I expect the previous map was just that I was a bit too fast with my rush.
• However, most of the ACU's shots were missing units (I purposively wasn't microing my units - just sent an attack command for all land units to attack the ACU) - if you check 7m30s in, almost all the shots miss. Not sure if this is due to the microing of the com again?
• It also failed to get any defence against me (bar a couple of land units) so my com could stroll in with no upgrades and do lots of damage (as the AI sent their com to hold off my land attack)

Update 06.Jun.2021(v94)

• Fix: ACU was waiting for 5000 energy not 500 to issue an enhancement.
• Fix: Sub AI Rush was not building Hydrocarbons
• Fix: LocationRangeManager can now create new locations everywhere. (no location marker needed)
• Fix: ACU was not building if the buildarea was between 12 and 13 map units away.
• Opt: Nomads ACU is now first enhancing with GunUpgrade, not Capacitor.
• For AI devs: New function CanGraphAreaTo(). Check if two points are on the same land/sea area

Update 21.Jun.2021(v95)

• Opt: ACU-AI point defenses are detecting as threat now.
• Opt: ACU-AI increased threat for mobile enemy units.
• Opt: Eco management optimized for first buildorders.
• Opt: ACU can now walk closer to the map border while evading from the enemy
• Opt: Added assist platoon for energy build and mass upgrade
• Opt: Increased the speed of the AI markergenerator by 15%
• Fix: fixed an issue with adding the first locationamanger on water.
• Fix: CanGraphAreaTo() no longer needs a unit, only position and layer
• Fix: SACU teleport function had an error while checking for SACU health.(thanks to Wingflier)

@maudlin27
I am still reading your feedback while testing buildorders. Great stuff!

Grabbed it from the "vault" (not sure why it's called that since there is nowhere I have seen that actually calls it the vault except the forums) Tradition runs deep, young padawan?

Anyway, I tried to DL from your link, it might be broken or not updated yet? I am also generally known to be an idiot so just ignore me if your link is fine and I am too dense to figure out how to DL it.

I checked the link and its working.

Here is the full download link for copy & paste:

http://faforever.uveso.de/AI-Uveso-Mod-v95.zip

That link worked, thank you. I don't know why the AI-Uveso-Mod-v95.zip link in the first post sends me to an untitled and about:blank page. Still doing it, but I'm sure it's something on my end.

Thanks for the help and I'm looking forward to your AI.

@Izzban

yes the link from the first post will open a new blank window and also should show you the download window.

Maybe you browser is downloading without your need to accept the downlod ?
Then you maybe have downloded the mod several times ?
(look at your download history).

I hope you enjoy the new AI.
If so, we have several more AIs in development, you should try them all
(join us on Discord if you like)

@Uveso
Is there a way to disable the suicide functions?
I rather have an all out war with the AI and defend myself from an onslaught of nukes, units and shells, than to have a t4 bomber hug my acu and commit seppuku.

How did the T4 bomber reach your ACU ? If the AI could reach your ACU with a T4 bomber then the problem is not the AI's.

@bude132

well, there is no option to disable the suicide function.

Only in case you are playing alone and not online, then there is a way to disable it.

The two platoonformers for the suicide platoons are located in
AI-Uveso/lua/AI/AIBuilders/Mobile Experimental-Air.lua
Your mod directory should be:
C:\Users\YOURNAME\Documents\My Games\Gas Powered Games\Supreme Commander Forged Alliance\Mods

To disable them you only need to set the priority of the platoons to "0"
You can find the two priority settings line in 436 and line 473:

Here are links to Git Hub to show you the exact lines:
https://github.com/Uveso/AI-Uveso/blob/master/lua/AI/AIBuilders/Mobile Experimental-Air.lua#L436
https://github.com/Uveso/AI-Uveso/blob/master/lua/AI/AIBuilders/Mobile Experimental-Air.lua#L473

To set the priority to 0 you only need to change the lines to:
Priority = 0,

If you do so have in mind the mod will instantly desync when played in multiplayer.

@Sprouto

Ah yes, the problem lies with me, I see.
Seriously... Why do you even comment.

The AI ganked me with two T4 Seraphim bombers from a non frontline position.
Before I noticed what was happening, it was to late and it instantly ended the match, because my whole shield installation was useless.
At the end I wasn't thinking "huh, I fucked up but died a glorious death." I was thinking "welp, that's fucking lame."

Just because I don't like a mechanic , doesn't mean there's an issue with me.
You should stop being an ass.

@Uveso
Thanks for the detailed answer.
In the meantime we've created a mod that disables the impact damage since we didn't want to break the AI.
We'll give it a go with the changes you suggested.

By the way, kudos for the AI.
When it doesn't yeet itself into your bases and suicides, it's a very enjoyable opponent and is way more challenging than the default ones.

@bude132 said in AI-Uveso (v95) - AI mod for FAForever:

Before I noticed what was happening, it was to late and it instantly ended the match, because my whole shield installation was useless.
At the end I wasn't thinking "huh, I fucked up but died a glorious death." I was thinking "welp, that's fucking lame."
Just because I don't like a mechanic , doesn't mean there's an issue with me.
You should stop being an ass.

Oversensitive much?
You didn't scout and the AI surprised you with bombers, it's a pretty normal way to die against players too. You disliking the mechanic does mean the issue lies with you, because it's just part of the game. It's not the AI's fault for being good enough to make use of it. Telling you that fact doesn't make him an ass.

Back to topic please, the question was:

Is there a way to disable the (AI) suicide functions?

So any answer that leads to disable the Suicide function is welcome.

Update 28.Jun.2021(v96)

• Opt: ACU-AI was evading from non combat units like massextractors.
• For AI devs: removed marker pruning from function CleanMarkersInMASTERCHAIN for all layers.

Hello,
First of all, thank you for this brilliant AI mod.
It has breathed new life into the game for us.

Has the recent FAF patch impacted this AI much?
E.g, the Aeon seem to build A LOT of shield disruptors. Attacking forces can seem composed almost entirely of them.