I've played with an m28 adaptive against two m28 adaptives on this map. In the early game it was easy to take map control with it as it pushed with me. The only thing I noticed is because of the map control it was more likely to starting eco'ing while the enemies struggling to try regain map control. This resulted in the illusion of it not doing much, but then it had an experimental before I'd got to that point.

From a map control perspective it took 8 mins for the game to be some what decided. I imagine it would be similar for you depending on what your gameplay style is. I guess perhaps you could explain what type of strategy your using on this map?

Other question, are you playing against aix m28's? That could explain why it feels like your team mate isn't doing much. I usually find once you go past 1.2 m28 becomes really difficult.

Did you enjoy learning Kotlin? I've got almost no experience with golang, but I do like that if it has no errors in the ide it will generally work.

If you use terraform in your real world job its also handy since all the providers are in golang so makes troubleshooting easier(which is why I started trying to learn it).

If you do decide to try a prototype I'd be interested in learning more.

The blueprints-ai.lua file that Nomander referenced is what you want to look at.

Your obviously motivated to do something positive here. I don't believe we can dynamically adjust threat during the game as the blueprints are read once on startup sort of thing. BUT, I think the development team would be more than happy to see someone put time into improving the existing threat calculations that we are creating. The current calculations are based on a formula that Balthazar did however long ago and some adjustments since then and while it is ALOT better than what we had originally there is room for improvement.

You'll eventually hit limitations since threat also depends on situational factors (a sniper bot in dangerous unless an enemy Obsidian tank is sitting next to it sort of thing). So why not rather than making a mod look at improving what we are doing now? We're happy to collaborate and provide feedback on the impact it makes on AI games.

@keul
You just need to give us some replay ID's to go off. We can investigate, especially if its happening that early in the game.

@mrmcbeefycakes I've done valley setups a bunch. But never with this number of AI's. I'm thinking there are some oddities around the terrain that could cause the path finding to take longer.

I agree with Jip that you don't 'really' need that many AI per game. I'm not sure if you are struggling to be challenged with a lower number. If you are I'd be remiss to mention the amazing m28 AI available on faf. You certainly won't need more than 1 per player to get a good fight.

If you have a couple of the replay links from where you saw bad stuttering I can take a look as it's possible there is a pathing loop happening that needs to be looked at.

When you say 8-14 bots are you meaning 8-14 AI players? or just 8-14 units.

I've spent the last few days playing with and observing the reclaim rate changes and I really like them, I hope they go in. The economy swings are not so volatile where props are involved.

It didn't seem to give me any more time to interrupt someone from reclaiming all my wrecks from a skirmish I lost though.

I have a question as I've always wondered how this works.
In the numbers you've got there tagada. How does it translate to the various engineers tiers? like is the number you've got there of 20m/s for a wreck based on a t1 engineer. What part of the blueprint affects how much mass an engineer can pull in per second?

I'm curious about this one. When I play with my friend he often complains about this problem and I never get it so we were writing it off to lag or something.

But the difference is he plays exclusively UEF where as I mainly play Cybran. Everyone here that is mentioning it is also playing UEF.

Well the AI is running a separate thread of logic for every experimental compared to a human so that's going to cause sim issues at some point.

Also depends on which AI.

No changes have been made to the AI for a few months now so I don't think it's a change in that regard.
Which map and which mod are you using. Have you tried it without said mod? Usually a 5.9 AIX should result in pretty quick teching and building.

One thing you could do is observe the AI to see what it's doing thats causing this problem. There are also logs produced that can give us an indication of something is going wrong that's stopping it

@clyf

I'd always wondered what the Melee functions were created for. I thought that early on they had actual melee units that later on got cut. Didn't consider that it could have been for things like the firebeetle.

@sandwhale
There is an issue affecting the AI currently that may have been impacting the AI in your games. I noticed the issue is affecting both the default AI and Uveso currently. Due to be sorted with a hotfix tomorrow.

But as Jip said, providing us a replay of issues will really help us identify whats going on. You can just post the replay ID or link that you can get from the faf client.

I would suggest some of the other AI's as well, though it seems like your after something that would send large armies against your defensive positions which not many of the newer AI will do. The Uveso Rush variant is probably the most fun for that play style.

I had to watch that just to witness greatness. Looks like the reissuing of commands to the acu got him killed.

I had a closer look. Ignore what I said above, this looks like a bug related to an expansion condition which is failing rather than a factory builder which is running too often. Will fix.

This is on the agenda, its a bit of a butterfly effect. We've been sorting out the AI's economy which is giving it spare economy that it in turn spends on other things. On naval maps it can lead to it getting carried away with an excessive amount of T1 naval factories and frigates.

Is it perhaps possible, since the costing/duration while being in the blueprint is not static in the teleportation logic to adjust the cost and time based on the distance that wants to be traveled?

This would allow teleportation to scale in cost and charge duration with the more distance desired. If someone wants to teleport across a 20km map they can but its going to cost alot more and have a longer delay than a shorter distance.

Whats the determining factor in the teleport range? e.g Is it aimed at 10km maps?

btw if your going to use the default ai use the adaptive one, the easy and normal one are more for people that have just picked up the game. Perhaps we should update the normal one as well.

This is going to sound like a long winded explanation.

None of the defensive builders have been removed, BUT the economic requirements for the defensive builders have been increased.
The reason for this was due to the AI destroying its economy on every game when it wasn't using large aix multipliers which resulted in a human player being in one phase of the game and the AI being two phases behind.
The other impacting reason is because the economic upgrade triggers have NOT been touched, so the AI has spare economy but it is throwing that economy at mass extractor upgrades rather than balancing its spending. This was supposed to be rectified in a structure manager feature that would better control mass extractor upgrades but this wasn't ready in time for the 3rd iteration so the AI's economy is still out of whack.

What will happen in the future is that we will get the structure manager sorted which will allow AI to better balance its economic distribution, there is a feature for defensive structure placement that is also due to be implemented. Then we will rewrite how the AI builds defenses in general and implement a better focused defensive logic for the turtle AI personality with the other AI having a more efficient reactive defense build logic.

So post the replay link and I'll take a look and see if the reason it isn't doing defenses is purely the above or if there is some other issue that can be fixed.