AI-Uveso (v113) - AI mod for FAForever

maudlin27

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.

Sprouto

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.

Uveso

@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.

maudlin27

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)

Uveso

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

Uveso

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!

Izzban

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.

Uveso

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

Izzban

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.

Uveso

@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)

bude132

@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.

Sprouto

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.

Uveso

@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.

bude132

@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.

FemtoZetta

@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.

Uveso

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.

Uveso

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.

Stin

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.

Uveso

Hello @Stin,

Thank you for your kind words.

The FAF patch has normally no impact to my AI.
I develop my AI on the deploy/FAFdevelop branch of the game, and test
gamepatches with my AI before they are released.

The Aeon shield disruptor is a special unit and has maybe some wrong bluprint entries.
I guess the AI gives a buildorder for shield or cloak units and gets a shield disruptor if it has the Aeon faction.

I will check that, thanks for reporting !

Deribus

Any self-awareness features planned to celebrate the upcoming v100?