M28AI Devlog (v162)

maudlin27

v144 Update
9 changes, including:

Transports shouldn't drop a zone already being dropped
Pre-emptive PD against further away enemy threats
Asfs should be less likely to engage non-priority enemy air threats if lacking air control
2 LOUD specific changes - more Blackops ACU upgrade support, and M28's nuke dodging logic should now be supported in LOUD

Acknowledgements

Vortex - several replays, and highlighting that M28's nuke dodging logic wasn't working

maudlin27

v145-146 Updates

In shared armies mode, if there is a mix of M28AI and human players on the team, M28AI should only consider the eco of the M28AI players when deciding if it is overflowing mass (to cater for a game played between players who would control M28AI's units while letting M28 choose what to build)
4 changes relating to M28 trying to better deal with gunships with MAA (it should consider retreating/consolidating its MAA forces in some scenarios, as well as retreating more generally if faced with a gunship threat it cant handle)
3 changes primarily related to improving M28's build order on the ditch and similar maps with huge amounts of reclaim so it scales its power and build power faster
Slightly reduced the tendancy to build t1 arti early on
1 LOUD specific change (relating to getting t1.5, 2.5 and 3.5 units a bit sooner)
Very minor optimisation and a couple of minor profiling bugfixes

Acknowledgements

Tryth - replay of a shared armies game where M28 overbuilt engineers due to human teammates overflowing mass
Sladow - several replays against M28, including one where M28 AIx 1.4 was beaten (on the ditch)
Vortex - LOUD replay and highlighting potential improvements

kagurazakanana

Hi maudlin27
Thank you for your detailed feedback. I have gone through your response, and I appreciate the clarification you have provided on various issues. I’ve also taken your suggestion to prepare a replay showcasing one specific issue observed with the M28 AIX Overwhelm rate.

Replay Details:
In the attached replay, you can observe the following anomaly:

AIX Overwhelm rate inconsistency: In the replay, many of the factories themselves fail to respond to the overwhelm multiplier properly. In the later stages of the game, there are also instances where production power seems to get applied without any observable incremental increase. Additionally, energy and mass extractors seem to receive a partial benefit, but the benefit applied is inconsistent and varies across different buildings.
I believe this has to do with how the multiplier is handled in relation to newly constructed buildings, which may not be adjusted correctly.

Reference to FACN Platform Fix:
About ten years ago, I was working on a similar AI system for the FACN platform (similar to FAF but based in China, forked from an older version of FAF). At that time, while facing a similar issue with adaptive AI not applying overwhelm and cheat buffs accurately to new buildings, I managed to implement a fix to resolve it on that platform.

Here is an example of how I approached it in Unit.lua under Unit = Class(moho.unit_methods):

lua

OnStopBeingBuilt/--------------Enable AIX Detection Thread
if ScenarioInfo.type ~= 'campaign' then
local AIBrain = self:GetAIBrain()
if string.lower(AIBrain.BrainType) ~= 'human' and self:GetAIBrain().CheatEnabled then
if ScenarioInfo.Options.AdpAI ~= 'off' then
self:ForkThread(self.CheckAutoAIbuff)
end
end
end
Additionally, I implemented a periodic check function to ensure proper multiplier adjustments:

lua

CheckAutoAIbuff = function(self)
if not self:IsDead() then
if ScenarioInfo.type ~= 'campaign' then
local AIBrain = self:GetAIBrain()
if ScenarioInfo.Options.AdpAI ~= 'off' then
local refreshTime = (tonumber(ScenarioInfo.Options.AdpAI) * 60)
if not nextRefresh then
nextRefresh = refreshTime
end
if string.lower(AIBrain.BrainType) ~= 'human' and self:GetAIBrain().CheatEnabled then
local timeSecs = GetGameTimeSeconds()
RemoveCheatBuffs(self)
if timeSecs < nextRefresh then
SetupAICheatS(AIBrain,self,AdpCheatMult,AdpBuildMult)
elseif timeSecs >= nextRefresh then
if (AdpCheatMult <= 1000) and (AdpBuildMult <= 1000) then
AdpCheatMult = AdpCheatMult + (AdpCheatMult/2)
AdpBuildMult = AdpBuildMult + (AdpBuildMult/2)
end
SetupAICheatS(AIBrain,self,AdpCheatMult,AdpBuildMult)
nextRefresh = nextRefresh + refresh time
end
end
end
end
self:ForkThread(self.AIXWaitUnit)
end
end
This was one of the approaches that I found effective for resolving the inconsistent multiplier application for newly constructed buildings. However, with the passing of time, I no longer recall all the intricate details of this solution and how specifically it was implemented, which makes it challenging to apply the same exact logic to the current FAF system.

FACN Lua.nx2 File:
To support your investigation, I will include a FACN lua.nx2 file for your reference. This might provide useful insights during the repair process. Unfortunately, I could not attach the entire file due to its size (over 1GB). In this version of the AI system, I had successfully addressed the issue of inaccurate multiplier application on new buildings. However, as mentioned earlier, some of the finer details of that implementation have since been lost, and I’ve found it difficult to map this solution onto the FAF environment.

Additional FACN Code (for Health Scaling):
Regarding AI scalability, I had implemented a setting in FACN that allows the AI to have X times the normal health. This feature, when combined with the proper adaptive AI system configuration, can allow the AI’s health to increase progressively over time. Below is the relevant code that implements the health multiplier, which can be adapted further for dynamic health growth.

Example from Unit.lua/SetupAICheat:

lua

if ScenarioInfo.Options.AIMultHP ~= "off" then
AISetMaxHealth = tonumber(ScenarioInfo.Options.AIMultHP)
unit:SetMaxHealth(unit:GetMaxHealth() * AISetMaxHealth)
if EntityCategoryContains(categories.COMMAND, unit) then
unit:SetHealth(unit, unit:GetMaxHealth())
end
unit.HealthM = tonumber(ScenarioInfo.Options.AIMultHP)
end
Supporting function in Unit.lua:

lua

function setupHealthMultiplier(unit, Mult)
unit:SetMaxHealth(unit:GetMaxHealth() * 10)
unit:SetHealth(unit, unit:GetMaxHealth())
end
This code ensures that AI units can initially have a health multiplier (X times their normal health). To achieve the goal of having dynamic health growth over time, you can combine this multiplier setup with a proper adaptive AI configuration that adjusts the multiplier periodically. The health multiplier would then increase as game time progresses, allowing AI units to scale effectively in longer or more challenging scenarios.

Regarding Other Mentioned Issues:
As for the other points I previously raised (such as the behavior of naval battles, air attacks, and misuse of ASFs), I haven’t encountered those issues again as of this response. Should any of those issues arise in future matches, I’ll make sure to record the replays for further analysis and share them with you for a better evaluation. I look forward to understanding how these can be improved further.

Replay Settings:
M28: 1.0*1.0

M28AIX Overwhelm rate: 0.1

M28AIX Overwhelm interval: 0.5

M28AIX Overwhelm limit: 10.0

Mods included:

M28AI v145
All Faction Quantum Gate V2.0 (created by jayTac)
Map:

3v3 Durex v10 Hotfix
lua(FACN) (2).zip 3v3_durex_v10.v0005.zip lastgame.zip

maudlin27

@kagurazakanana said in M28AI Devlog (v146):

3v3 Durex v10 Hotfix

Do you have a copy of the map you used? I can't find it on the FAF map vault

Edit: Although doing a sandbox test of AIx overwhelm to check if it was adjusting the build rate I realised the implementation was only adjusting resource generating units, so the build rate adjustment should be fixed in the next version. If you still run into issues after this then post a replay (and the map if it's not on the vault) with an example unit and timestamp illustrating the issue and I can look into further.

maudlin27

v147 Update
8 changes, mostly relating to minor bugfixes, including:

Fixed a bug with AIx overwhelm not increasing the build rate of units
M28Land should consider building non-land experimentals occasionally late-game to give it a small bit of variety
Fixed a couple of bugs that could result in air factories not building units in rare cases

Acknowledgements

Fearghal – replay which contained a number of niche errors
Kagurazakanana – Highlighting that M28’s Aix overwhelm modifier wasn’t adjusting build rates
c04spoon - LOUD replay where M28 overextended

maudlin27

v148 Update
13 changes, including:

Naval AA units should be more likely to retreat from enemy units
Fixed a bug where naval units would think they were always outranged by the enemy
Subs should prioritise shield boats and then other subs
Low ranged skirmisher units should be more aggressive when lacking intel if the ACU is nearby
4 MOD specific changes, including support for mods that require a build rate for factory units, building PD if it can be built on water in LOUD, and having M28 make use of the Blackops experimental aerial fortress

Acknowledgements

c04spoon - Naval replay prompting a number of this update's changes
Vortex - Replay where M28 failed to support his ACU with land units

maudlin27

v149 Update
27 changes, including:

New performance mode option in game settings which uses simpler approaches for parts of M28 logic to make it run slightly faster, although also not quite a strong. As a rough guide, I'd expect this makes things run 10-20% faster overall, and if combined with M28Easy and the maximum delay between land unit orders, it ends up being roughly 50% faster.
6 mod specific changes, including better support for experimental factories and the XtremeWars experimental spaceship (which should no longer idle), and more aggressive use of Seraphim bombardment ships when navy is won
Increased experimental unit variety if M28's unit prioritisation is disabled (meaning it will build a much wider range of units, but they are much more likely to not be appropriate in the circumstances)
Gunships should be more aggressive when they have a large threat and sufficient AA to handle the enemy asfs
Reduced the number of LABs built early on
Limited the number of engineers to be built on small islands

Acknowledgements

Vortex - LOUD replay highlgihting issues with the Seraphim bombardment ship and overbuilding engis on islands
WesMaggs - describing a scenario where M28's gunships were too cautious
Radde - A number of 1v1s on Xander Adaptive, whigh highlighted some early-game issues M28 had, as well as some other niche issues (such as land experimentals being overly cautious in some scenarios)

maudlin27

v150 Update
12 more changes, including:

Sub consolidation logic to try and group subs together when fighting more often
Gunships should retreat to heal up sooner if they're having a habit of dying to ground defences
Made adjustemnts to ACU aggression to only factor in friendly direct fire units
Several adjustments for dodging missiles (to make it less likely units try to dodge)
2 MOD specific changes, including improving M28's assessment of whether it will win an air fight in LOUD when inties are involved.

Acknowledgements

Radde – Several more replays (on v148)
C04spoon – LOUD replay
Vortex – LOUD replay

maudlin27

v151 Update
Smaller hotfix update with 7 changes:

Short ranged units should be less likely to attack enemies and should try and group closer together
Units whose shots are blocked should be slightly more likely to move than before.
Fixed a bug that would break all M28 ACUs for the rest of the game if M28 thought an enemy ACU could be killed. Also added in a redundancy so in future it should only temporarily break the logic if such a bug was to reoccur.
Experimentals should be slightly more likely to suicide into an enemy experimental instead of retreating (although this will need further refinement).

Acknowledgements

Radde - A number of replays
Vortex - several LOUD replays

maudlin27

v152 and v153 updates
21 changes, including:

Fixing a bug where M28 wouldnt build mass storage if player 1 was an M28 teammate who died
Fixed several issues relating to shared armies (message should only display to the person clicking the button; air staging should release M28 controlled units even if they haven't been toggled to have control; non-M28 controlled friendly units shouldnt be reclaimed for mass)
Land experimentals that cant kite should be less likely to retreat from an enemy experimental
Fixed a bug where M28 would incorrectly consider the enemy to have no naval threat
Torpedo launchers should no longer be built in response to an enemy engineer
Transports should be more likely to be built, and introduced 'engineer support' transport logic so if a plateau wants an SMD and has no t3 engineers one should be airlifted over

Acknowledgements

Radde – Various replays (which were the basis for the majority of changes)
Marlo – Highlighting issue on fort Clarke assault where some of the M28 ACUs would suicide into T1 PD
Cleo – describing some issues with shared armies mode where M28 would reclaim friendly units.

maudlin27

v154 Update

Fixed a bug that meant M28 logic relating to units damaging others wasn't triggering (e.g. relevant for determining if units aren't blocked from hitting enemies) and expanded to add a redundancy for gunships to make sure they retreat when damaged.
Island drops should no longer try and drop on islands with enemy PD
Fixed several occasional issues with M28's late-game arti template (building T3 pgens in the designated place for T3 arti; engineers owned by an M28 teammate blocking construction)
When an experimental dies, most of hte time M28 should assign an engineer from a nearby base to reclaim the wreck (in additino to its normal reclaim logic)
Fixed a rare bug that could mean a unit on attack-move being given a move order would stay attacking.

maudlin27

v155 Update
Another mini update:

Fixed a typo relating to a niche scenario where considering whether to get a novax to help with enemy naval threats
Reworked ASF support logic so they should try and stay even closer to a friendly experimental air unit than before
Fixed a bug with working out if a table is empty (that I presume has been around in both M28 and M27 for 3-4 years!)
Asfs should be more likely to engage enemies attacking restorers and czars (by including the restorer/czar anti-air capabilities when deciding whether the fight can be won)
Fixed an issue with M28's chat messages not working in LOUD (introduced in v152)

Acknowledgements

Radde - several more replays
C04spoon - Mentioning that M28's chat messages had stopped working in LOUD

MrPhalanx

Hey Maudlin! I also found out, that the chat messages do not work with the Steam Version as well now, also a small bug, when you select MULTIPLE repair drones (UEF) (For ex. at the Kennel), the UI in the left is broken (only a blank square is visible), if you select a SINGLE drone, then everything works fine.

maudlin27

@MrPhalanx Just to check, is the chat bug something that happens in the latest version v155 (as there was a bug with this in a previous version)

maudlin27

v156 Update
14 changes, including:

A few different build orders and early game approaches added to try and make M28 a bit more unpredictable (for now whether it rushes a bomber; gets no bomber at all; gets LABs or no LABs, although long term I'm hoping to add some further variation)
Adjusted how short range units support longer ranged units where they're having their retreat cut off
A team with a mix of different factions should prioritise ahwassas if they decide to build an air experimental

Acknowledgements

Jorne - 1v1 vs M28 Easy
Radde - Lots of teamgame replays vs M28

art-wiedzmin

FA Mission 6 (Overlord) with Combined human-AI armies. https://pastebin.com/yAmjETHf

art-wiedzmin

Okay It works fine if comment out these lines in M28Overseer.lua.

    elseif not(bApplyM28AI) and oBrain.M28AI then
        --oBrain.M28AI = false
        --oBrain.M28Team = nil
        --M28Team.CreateNewTeam(oBrain)
        if bDebugMessages == true then LOG(sFunctionRef..': No longer applying M28AI to brain '..oBrain.Nickname..'; assigned it to the team '..(oBrain.M28Team or 'nil')) end
    end

(2112 - 2114 lines in version 157 from git)

log with enabled debug: https://pastebin.com/yKHa4hbH
log with enabled debug (after comment out): https://pastebin.com/nNqUA4ME

I don't quite understand the logic structure itself, but it seems to be designed for an individual AI player, and breaks down with a combined AI-Human mode (player moves to the newly created team number 5 after Fletcher's betrayal).

goblinsly2

I have a question. Is there any way to make your M28 AI teammate give you a unit ? I would like his engineer/sacu or any unit/building/exp that can make an engineer/sacu. tnx

maudlin27

@goblinsly2 Not currently, no

kagurazakanana

Subject: Issue Report and Feedback on Large Naval Maps with Concentrated Resources

Dear Mod Author,

I am writing to report some issues and provide feedback based on my experience playing on large naval maps (greater than 20km) with concentrated resources.

On these maps, I've found that bomber snipes and precise SCU teleport attacks are highly effective strategies. I believe exploiting the AI's tendency to multitask allows for consistent SCU teleport raids or SCU + TML teleport attacks (targeting structures like SMDs or ACUs). The ability to quickly retreat and re-engage makes this a low-cost and effective way to target vulnerable points in the base. Teleporting directly into the base center, bypassing PD and heavy defenses, is often more effective than using satellites.

Furthermore, in the late game, with a larger number of engineers, it's possible to conduct ASF sweeps of the player's base (even if they are lost, they are quickly replaced) followed by bomber snipes, specifically targeting the player's ACU and SMDs.

Here is more specific feedback based on a 40x20 naval map with concentrated resources:

M28aix's ASF manufacturing is strong, but its air superiority is weak. Its ground strike/bomber units fail to closely coordinate with its ASF escorts, resulting in the ground strike/bomber units lacking adequate protection.
After achieving air superiority in an engagement, M28 failed to quickly capitalize by deploying its ground strike/bomber units to eliminate key enemy units.
M28's air units, such as ground strike aircraft, appear overly cautious. They often patrol in the middle of the map instead of actively engaging in targeted strikes.
A recurring issue persists: M28 built a significant number of T4 air units (15 in this instance), but M28aix repeatedly pulled them back and forth, hesitant to attack the player's main base. Even as M28 lost the game, its T4 air force remained unused.
Large-scale naval battles felt too sparse. M28 invested more heavily in naval units than the player, but its unit composition was problematic. For example, it built insufficient numbers of battleships (BBs) and submarines. It constructed a large number of destroyers (DDs) which were destroyed by the player's concentrated BB fire before they could reach effective range. Additionally, a large portion of M28's navy patrolled in the middle of the map. M28 did not seem to intend to concentrate its naval forces for a decisive attack on enemy fleets, important shipyards, or land targets. I suspect the AI "A-moved" a target, but the varying speeds of the units prevented them from focusing fire effectively. Consider having the AI initially group its fleet near the player's base before initiating a coordinated rush.
The AI remains vulnerable to ACU and bomber assassination tactics. Even with full map vision, the AI's ASF did not intercept bombers. This made assassinations very easy. We assassinated four of M28's largely undefended ACUs using two Mavors.
M28aix built Diamond defenses within several shield generators, but it lacked any defense against SCU teleports. We teleported an SCU next to one of M28's Diamonds. The Diamond was instantly destroyed by friendly fire from battleships and missile ships, while my SCU safely returned to base.
The previously mentioned AI overwhelm issue has not been resolved. In several matches, after the AI's structures were destroyed, newly constructed buildings still appeared to have the base production rate, and the bonus values applied to existing structures were also incorrect.

Thank you for your time and dedication to the mod. I hope this feedback is helpful in improving the AI's performance on these types of maps.