Just as an aside Maudlin. You can leverage the brain:TakeResource and brain:GiveResource as well to transfer energy directly should you want to implement more restrictive pgen gifting but still want to be able to quickly help allies if they have crashed power. I do it on mine though I don't play with AI on my team so never really done much validation on it.
AI Development Guide and M27AI v57 Devlog
Here is a new replay where the AI is seen having built 2 SMD nearly next to each other, both of which have nothing loaded, and that AI got destroyed by a nuke... https://replay.faforever.com/18075538
I only saw what was current on my team while playing. The dark red colored AI in the south is the one in question. Others may also have built multiple smd but I didnt watch the replay.
@teralitha Thanks, I'll have a look to figure it out (from an initial glance it looks likely to be an overlap between my firebase SMD logic and my main base logic but I'll test to confirm).
Re the T1 power gifting they're meant to transfer back to the original owner who then reclaims them once all teammates have sufficient power, so if this isn't happening if you send me a replay I can see why. Broadly, if all M27 teammates have a T3 PGen (the actual threshold is earlier than this) and the M27 gifted the PGens also has surplus energy (of 100 per second) then they should be gifted back.
Meanwhile they should only gift T1 PGens to a non-M27 teammate if that player has less than 10% energy stored (as well as less than 750 energy income per second)
Re its attacks I did see one (ai vs ai) game recently where 3 ythotha got sent to attack an enemy base at the same time but it's more likely to attack with 1-2 experimentals, while waves of units are more likely at lower tech levels (but if you're turtling up then it's far less likely)
@relentless Already implemented :), I like to share PGens as well since a lot of my build conditions are based on the AI's gross and net energy so giving the T1 PGens over makes those more reliable/accurate than estimating the overflow available to it.
Well, if it is intended that they gift Pgens back, I have never see it happen. All ive seen is once they have been gifted to someone, its permanent. I think the replay I just gave you should show this. And if they are gifting them to me, I am unable to gift them back. I believe that is something you would have coded into the AI, to not allow a player to gift them anything. If I notice they have given me something, I will usually control K them. I still think you should remove PGEN gifting at all.
I watched that replay back today and I saw that the red AI actually built 3 smd's(EDIT: Actually they built 5 of them which were all destroyed by artillery and then they promptly built 3 more! After which they got hit by a nuke and died...) and they were turning them on and off repeatedly. Definitely needs a change.
@teralitha Found the issue with the SMD (and why I've not come across it before) - Seraphim battleships can build nukes, so the AI was (correctly) seeing them as a nuke capable unit and trying to build enough SMD to prevent being overwhelmed by nukes if they were all building them.
I'll probably tweak it for the next version so limit the amount of SMD being built where the nuke launchers are battleships.
Also not seeing any 'left over'/isolated T1 PGens on the replay (about 45m in) - the only PGens out of place are where an ally whose base (and all their power) got mostly destroyed and so was gifted the PGens
Yea it wasnt the best example in that replay. Ive seen it happen more prominently on different maps.
So.. my cybran submarine can build nukes too. Does the AI react to that by building more SMD? perhaps I can trick the AI into wasting more resources into SMD then by building a bunch of subs...
@teralitha yes and yes (assuming it sees the subs), but you’ll be wasting mass on the nuke subs yourself since theyre not worth the mass for the tml effect, so it’s only likely to be viable on larger team games where every player has to build smd to protect from a nuke
The thing is... a single SMD can shoot down multiple nukes if it has enough loaded. Nukes travel slowly, so it would take like 3-4 nukes dropped at the same time to get past a single smd that is loaded with enough to stop them all. Anyway, I hope you can make an adjustment so the AI isnt over reacting to a nuke possibility and wasting resources. And seriously consider getting rid of the gifting, except in very extreme cases.
Those are all the main issues I see with the AI currently in my opinion.
- Too much gifting(and possibly not returning to owner)
- Too many SMD
- Producing way too many T3 engineers for their eco level.
- Not protecting base well enough with shielding and AA vs other M27AI that are going heavy on Air.(Pretty much every match i use M27 in, they all go berzerk with air units and spider bots)
Oh yea one other minor issue I forgot about, If the AI builds a naval factory, every AI team member will send some engineers over to aid it. Looks like the factory is surrounded by a rainbow. (And they only ever build one factory even when I set the options to be able to build more than one) I mean, that part makes sense, but they never aid my naval factory But really, they should be using their mass on their own production, because usually those AI are not doing so well on eco themselves.
@teralitha I'll see if I can fix the power gifting back when I next work through some minor changes (no time for current release though as it needed releasing today due to the upcoming rainbow cup but I did notice in a couple of the testing replays that the conditions were met for power to be gifted back yet it wasnt). It's not a big priority though as it just means the AI misses out on a small amount of reclaim.
Hopefully you should notice a difference with protecting the base against experimentals (it's probably still not enough to actually stop the experimental, but is more noticeable than before where sometimes almost nothing would be done)
Re navy it's working as intended - M27 will work with other M27 for navy, but not with non-M27 (since it has no control over how the non-M27 navy is used). How effective the 'coordination' approach is varies depending on the map (basically it's worse if the M27 start positions are far away from each other/closer to the enemy than each other). As the navy's still in it's early days it also doesnt have much logic re when it's better to stop building navy and focus on ecoing up, but I may not add that anyway (due to the risk of stopping naval production and losing navy, allowing the enemy to then destroy all of your eco with ships)
v55 Summary of changes
Smaller update due to the need to release by today (to avoid releasing a version just before a game is played with it in the rainbow cup tournament that starts tomorrow)
- Added logic specifically to try and defend against an incoming experimental attack
- 6 bugfixes, including pathing fixes on Dark Liver Mirrored map, and an issue that could cause platoons to get stuck for ages/ignore new commands they were given
- 13 Misc changes, including limiting the amount of SMD built slightly, certain ecoing decisions, and improvements to the mass stall logic.
- Fearghal – highlighting issues with M27 on Dark Liver Mirrored map
- Teralitha – Replay with M27 building too many SMD
Latest changes (v56-57 summary)
- New unit added - Stealth boat
- 10 Bug fixes, including a rare naval bug that meant naval units didnt move, gifted PGens not being returned to their owner, and a bug causing the ACU to not move (leading to M27's ACU chilling underwater in the last rainbow cup round while its base got torn to pieces nearby)
- 13 misc changes, including an expansion to dodging micro to work in an area (primarily to help naval units which for the AI end up stacking units ontop of each other making them highly vulnerable to any aoe), tweaks to queued torpedo bomber orders, and having naval factories build a greater variety of units at T3 (instead of only T3 units)
I revisited the approach to pathfinding thanks to Jip detailing the appraoch used by Balthazar for determining pathability which was much more accurate than M27's approach (broadly, M27 was checking how much the height changed at 0.5 intervals to determine if you could path there, but counterintuitively you get a more accurate result if you check the distance every 1 block, i.e. less frequently). As the changes took far less time than I was expecting I figured I'd release ahead of the upcoming rainbow cup games (as it should hopefully reduce the risk of strange results and also slightly improve game speed).