SiegingAI builds too close to player or player's structures

[veden]

SiegingAI builds too close to player or player's structures

[glimpsebeyond]

I'm playing with Krastorio 2 and Space Exploration (with default SE map settings) and the biters are aggressively expanding into my walls. It feel crazier than a death world. 6 hours in and I've not been able to push them back even a bit.

[garrotte13]

I'm playing with Krastorio 2 and Space Exploration (with default SE map settings) and the biters are aggressively expanding into my walls. It feel crazier than a death world. 6 hours in and I've not been able to push them back even a bit.

Maybe you make biters nests eat your pollution OR allow pollution cloud to reach chunks adjacent to nests - looks like Rampant treats even upcoming pollution cloud as aggression and generates a lot of action points for sieging. It sometimes makes the game go into eternal war with biters when using flamethrower/flame turrets or other pollution producing weapons.

Anyway a simple rule of purging all nests in 3-4 chunks away from your walls will completely stop sieging unfortunately. Rampant is too peaceful if keeping nests far away from player's structures AND player's pollution -> no provocations -> no action points -> peace.

[veden]

@garrotte13
By design not really, just need to design a better algorithm for doing siege squad movement.
https://github.com/veden/Rampant/blob/master/libs/SquadAttack.lua#L124
Is the location to start, but the change will require more than value adjustment most likely. If you figure it out, make a merge request please.

Upcoming pollution cloud shouldn't do anything, only pollution covered spawners.
The latest version in the repo creates a separate AI for each regional base, so there should be more AI actions taking place.

@glimpsebeyond
As for siege AI being crazier than death world, I think that is to be expected. Are you asking for a change?

[garrotte13]

Thanks! I'll try to find something.

Upcoming pollution cloud shouldn't do anything, only pollution covered spawners.

Unfortunately it is the case. If I allow pollution to reach adjacent chunks I see a stable 100% sequence of nests expansions in the direction of my walls every few minutes. And most of them are very close to my walls. Therefore game punishes a lot just for reaching adjacent chunks. And I have only 2 choices - to stand with my char nearby all the time till PUs dissipate in the problem chunk, or to go and kill nests in that adjacent chunk. Last choice is preferable.
When covering spawners chunks with pollution I get both intensive raidings and expansions, but that is an expected behavior.

Yeeah, I saw Rampant3.0, but not ready for a new game start now these days... I'll try it at some moment.

[garrotte13]

I think the problem is not in Rampant, but in general way how pollution is dissipated - not only through absorption, but 2% per second migration into adjacent chunks. When pollution levels on the edge of cloud are low one can't see its spread, but chunk with nest does recieve some PUs in very small amounts and immediately absorb them by nests - game never shows pollution in the chunk with a nest as it doesn't update the map view so often. Probably those some amounts like less than 1 pollution unit is nothing to form biters raid, but enough to trigger builders actions.
E.g. taking 10 PUs in such adjacent chunk => 0.2 PU incoming every second and immediately eaten by nest. (0.2*600) / 2=60 pollution only after 10 minutes of reducing pollution in adjacent chunk is no more than just one attack group of tier1 7-14 biters depending on map settings. After evo 30% it won't be enough to form even 1 raid attack before pollution income ends. As a result player doesn't witness any biters attacks, but several siege nesting attempts in a row every several minutes.

P.S. I hope it's obvious, how 10 PUs can generate 60 PUs in other chunk - those 10 PUs are also supported by persistent incoming pollution from other higher PUs chunks located closer to pollution source.

[veden]

I had forgotten Rampant checks for adjust chunks for pollution because otherwise pollution absorbing nests wouldn't potentially be counted because when Rampant checks the chunk under the nest it may not have pollution on it because the spawner absorbs it and i can't check the current absorbed pollution by a spawner.
So the system currently over estimates pollution covered nests vs under estimating them.
Sieging groups will stop further from the player structures in the version on master branch

[garrotte13]

Difficult to give feedback after logics changes. So many great changes... I'm still in process.
Original issue (thread description) occurred only once after switching to Rampant3.0. But I feel that AI sieges are in general less often, less stupid (I once monitored settle points during SiegingAI stage - far away migrations occured only). I see much more migrations to intermediate points somewhere between my perimeter structures and enemy base - I don't know if it's result of this fix or entire Rampant3.0 logics change...
Anyway it became more interesting. AI doesn't obliterate with sieging nests if pollution cloud is in adjacent chunks. Sometimes it doesn't react at all, sometimes it builds a lot of nests in different places of entire territory between my base and enemy nest (I mean the nest with upcoming pollution cloud) - unpredictable behavior if compare it to Rampant2.2. I increased Difficulty Scaling to 1.2 - maybe it did some changes to logics too?

[garrotte13]

Still can't say for sure for SiegingAI, but fix definitely didn't help for revenge nesting when purging enemy bases - AI still tries to make nests nearby player character and turrets.

[veden]

Difficulty scaling doesn't have any direct effect on logic.
There most likely is a change in squad count because the bases are not acting as a single ai anymore.
I wouldn't have expected the siege changes to have any real effect on revenge nesting.

[garrotte13]

@veden
I'm about your phrase

Sieging groups will stop further from the player structures in the version on master branch

and FACTO-94
Like SiegingAI such "revenge" in form of settling new nests shouldn't occur on positions near player's character or his turrets, because it becomes a purple gas attack purely, not building nests.

[veden]

The siege AI states move towards player and player structures.
All other AI states move away from player and player structures.
If a settling group rolls a kamikaze then the group will move towards player and player structures.

What do you consider near same chunk, one chunk, or many chunks?

[veden]

The commit you linked just tries to settle where the group is at when the group detects a player nearby

[garrotte13]

I already understood what's the feature of SiegeAI.

If a settling group rolls a kamikaze then the group will move towards player and player structures.

So builders group will come up to player or his structures as close as possible before trying to settle? But after releasing purple cloud they will always attack player/structures instead of morphing into structures, won't they? Or you mean the situation when they "forget" about plans to build and switch into attack squad without purple cloud (situation not described in this issue)?
I saw once a situation a big pack of biters stuck in some intermediate state, but it was a one-time glitch as they started berserk attack after purple cloud appeared, then turned around and returned to settle point (I didn't check my luck if they build anything or what - just quicky ran to them and killed them).

The commit you linked just tries to settle where the group is at when the group detects a player nearby

If they detect only player, but not his stuctures (walls/turrets), then it doesn't help with original issue in comment 0 as the problem of SiegeAI is with attempts to build too close to player's buildings first of all. Player usually is not there.

I'm sorry if I mixed two absolutely different AI logics parts - SiegeAI when player can be very far away and revenge building group when player is usually somewhere nearby (but not always - he can just install turrets from one side of the base while destroying its nests/worms from the other side).

[veden]

So builders group will come up to player or his structures as close as possible before trying to settle?

Yes

But after releasing purple cloud they will always attack player/structures instead of morphing into structures, won't they?

If they are kamikaze groups then no

Or you mean the situation when they "forget" about plans to build and switch into attack squad without purple cloud (situation not described in this issue)?

If the player is within a chunk distance to the group then they should should to attack. If they are two chunks distance they should settle.

If they detect only player, but not his stuctures (walls/turrets), then it doesn't help with original issue in comment 0 as the problem of SiegeAI is with attempts to build too close to player's buildings first of all. Player usually is not there.

Meant to say player structures and I have an unrelease fix for when the player is nearby without or with structures as the player previously wasn't being accounted for.

[garrotte13]

If the player is within a chunk distance to the group then they should should to attack. If they are two chunks distance they should settle.

That's really great! Is it about SiegeAI?

So as I understood you: unlike SiegeAI builders groups, that "revenge" builders squad is intentionally building as close as possible to player or his turrets, correct? Then my complain is wrong for such settlers' behavior and purple cloud over my character and my turrets in this situation is by design. While your fix is only for SiegeAI - SiegeAI groups should not trigger purple cloud unless a bad luck - I installed my walls/turrets perimeter on the edge tiles of chunk and cloud reaches them via range of 33 tiles. Hope I did understand you this time :-)

[veden]

pretty much.

I'm trying out having both siegeAI and revenge builders do the one chunk attack and two chunks settle logic in an unreleased version.

[garrotte13]

Here is the behavior of latest Rampant3.0.3 (rev 267a473):

I suppose that circle shows the purple cloud zone location precisely (maybe approx half a tile correction is needed).

Cloud center is in the same chunk player's wall and turrets are -> zero chunks distance between settling point and player's buildings. Player char was about 5 chunks away or more.

And here is an example of perfect sieging (I don't know if presence of player's char 2 chunks away made it so good or randomizer was so lucky):

In my humble opinion this is the smallest range builders should come up. This one or even one more chunk away (to be successful in late game).

In both cases looks like it was AI reaction to pollution cloud. Debug console messages mention both AI_STATE_RAIDING and AI_STATE_SIEGE. Don't know what it means and don't need this info - turned it on only after first builders group failed (first screenshot).

[garrotte13]

In both cases looks like it was AI reaction to pollution cloud. Debug console messages mention both AI_STATE_RAIDING and AI_STATE_SIEGE. Don't know what it means and don't need this info - turned it on only after first builders group failed (first screenshot).

Aaaah, those messages do have different baseId value - does it mean that in Rampant3.* different enemy bases have different AI states at the same time? Note in mod changelog " - AI is now per regional base".

[veden]

I don't see any units associated with the first unit group screenshot.
The reason for two chunks max is that is how far the pathing looks forward to move, in order to plan further out would require an additional pathfinding step or a new algorithm for settlement planning.
Yes, you now have many AI states per surface, so revenge is localized in addition to having different regions of the map act differently.

[garrotte13]

I don't see any units associated with the first unit group screenshot.

Why do you expect to see them? They are dead before purple cloud dissipates and that's the main idea of this issue thread - they tried to settle too close to player's structures and they did it quite often in Rampant2.2, now they do it probably less often, because AI is less agressive, punishes less for pollution cloud, but issue is still actual. You can put together this screenshots post with the first post to get the full picture of SiegeAI issue I'm about.
I didn't get about 2 chunks max. 2 chunks distance is enough to stop moving and start building. No need to detect and stop before. 2 chunks = 64 tiles, great to catch even endgame player mistakes of not installed adv flamethrower/rocket turrets vs biters high tiers.
While on provided screenshot (first one) it's 0 chunks distance (about 20 tiles in this case). Not good.

Yes, you now have many AI states per surface, so revenge is localized in addition to having different regions of the map act differently.

That's a great step in mod's dev roadmap! Looks much more interesting and complex so far, less predictable behavior.

[garrotte13]

I don't see any units associated with the first unit group screenshot.

Here is another screenshot with units dead bodies in almost the same situation (1 chunk distance this time I believe)

[veden]

in the last screenshot the group actually tried to settle the chunk before the wall which most likely means that they planned that settling spot 3 chunks out.

[garrotte13]

Do you mean that builders squad selected this chunk when biters were 3 chunks away from it and they did not take into account the proximity of player's walls/turrets? Then probably I incorrectly understood the idea and you meant that biters are able to react to player's structures and change settling point only in range of 2 chunks and looks like they often make walk routes of 3+ chunks between milestones to estimate player's buildings in range.
But then... in most cases they will be too late to change plan and will try to settle very close to player like in all screeenshots provided and original issue description. The only case it works is when walk route ends exactly 2 chunks away from player's buildings. And no way to fix it without decreasing walk routes length or increasing detection range.

[veden]

Do you mean that builders squad selected this chunk when biters were 3 chunks away from it and they did not take into account the proximity of player's walls/turrets?

Yes

Then probably I incorrectly understood the idea and you meant that biters are able to react to player's structures and change settling point only in range of 2 chunks and looks like they often make walk routes of 3+ chunks between milestones to estimate player's buildings in range.

Walk routes are planned with 2 chunk detection, it is possible they move 3 chunks. The groups should never being moving 4 chunks.

But then... in most cases they will be too late to change plan and will try to settle very close to player like in all screeenshots provided and original issue description. The only case it works is when walk route ends exactly 2 chunks away from player's buildings. And no way to fix it without decreasing walk routes length or increasing detection range.

Correct

[garrotte13]

I think the problem is not in Rampant, but in general way how pollution is dissipated

Oh, I found hidden game settings in API
min_to_diffuse

The amount of PUs that need to be in a chunk for it to start diffusing. Defaults to 15.

Therefore for pollution below 15 it doesn't spread to adjacent chunks ! What a disappointment. Then part of what I wrote is wrong. Also it explains many things like stuck pollution in chunks map, weird diffusion rules sometimes, Air Filter wasting filters&electricity etc.

[garrotte13]

Do I understand correctly, that for Rampant 3.1+ a new fix of this issue was made? So far I didn't see this issue after 3.1 release.

[garrotte13]

The closest building site I witnessed:

[garrotte13]

Another close call here :-) One chunk away, but still a full chunk away in the end - good! You can see untouched trees in the mid of two chunks below chunks with my turrets. If this is the closest builders can come - then it would be perfect. New nest appeared directly in turrets range while purple gas area was out of range and as nests appeared -> it was fruitful correct place selection.

[garrotte13]

Looks very good now for SiegeAI. Enemies stop one full chunk away or attack my buildings. No purple gas cloud damage on my buildings.
Thank you! Now with my Warmonger mod KR creep really creeps via SiegeAI, puts fear into not prepared hearts...

UPDATE 06.02: I was wrong. Fix didn't help. Biters do go for nesting to the same chunk player's structures are in:

[garrotte13]

And to prove one additional time here is a nice picture of purple gas destroying everything just because I was unlucky and build defense line exactly on the chunk border. Therefore technically hopeless builders tried to settle in adjacent chunk, but applied purple gas on neighbouring chunk too where my structures stood.

[garrotte13]

I have another idea here:
Can you please move phase of purple gas ejection in time?
Biters come, stop, spawning process initiated via factorio engine and as it takes some fixed minimum time, then create cloud on half or one third of that minimum time period. Then there still be guaranteed free place for buildings while no fruitless purple gas ejection.

[garrotte13]

aah, forgot the most important part (probably very difficult or impossible to implement): Rampant mod should check if biters are still there before creating gas cloud.

[veden]

the problem with getting unit group count isn't that it is hard, it is expensive in terms of processing because to get the count you need to access the unit group members array which creates all the entity objects even if you are just grabbing the count of units.

[garrotte13]

why not? Biters are not settling new spawners every second.

[garrotte13]

Oh, actual situation is much worse than I wrote. Purple gas appears even when all builders already have switched from building to suicide attack !
Video: https://youtu.be/n_0WRjysay4
Please ignore players proximity - initially I noticed this situation when my player was far away. Thanks to random seed saving we are able to repro everything :-)

Such mod's logics neglects the work on this issue fix :-(
No matter how distance is calculated, no matter how properly player installs defenses (even if it is a combo of rocket turret + flamethrower turret here): in any situation if chunk's border is aligned this way to player's structures and biters were able to peacefully enter the destination chunk, then gas will be ejected and nuke everything in ~25 tiles range from any tile inside the 32x32 area of that target chunk. It's like biter had a grenade launcher, fired immediately after crossing chunk border and his launcher had a range = 32 and grenade dmg area was 14x14.

[garrotte13]

Maybe all I wrote in last few posts here is a negative reaction to this purple gas concept. And it is off-topic for this issue, because applied damage can easily be repaired automatically starting late mid-game. Why not to get some grenade damage - some new fun in game.

I whine about this gas cloud, because it often does not what intended to - if you invented it to guarantee successful nesting, then why it also works as damager and natives' tool for brutal destroying native flora. When it often kills a huge forest I retained for a long time to limit pollution spread or when it devastates the entire idea of Rampant Evolution mod - it causes some pain in my ... . I wonder what factorio guys did to make vanilla nesting successful in forests, why didn't they implement a mechanism of precise deconstruction of colliding trees. Autoplaced nests look so beautiful in the shadow of surrounding trees.

[garrotte13]

I whine about this gas cloud, because it often does not what intended to - if you invented it to guarantee successful nesting, then why it also works as damager and natives' tool for brutal destroying native flora. When it often kills a huge forest I retained for a long time to limit pollution spread or when it devastates the entire idea of Rampant Evolution mod - it causes some pain in my ... . I wonder what factorio guys did to make vanilla nesting successful in forests, why didn't they implement a mechanism of precise deconstruction of colliding trees. Autoplaced nests look so beautiful in the shadow of surrounding trees.

Turned off purple gas. Looks fine so far for me - sometimes migration is able to build only worms, but migration often sends builders to already occupied place with the same result. I'll need to try fresh game with it...
It's difficult question: someone is very ECO, like me, and can't see how natives kill surrounding flora; while others prefer to blast trees and get everything into concrete tiles. Very personal here.

Concerning original problem I see it as a lower success chance of sieging. Especially after midgame when flamethrower and rocket turrets completely protect adjacent chunk from enemy nesting. But maybe there is a balance here and more often successfull sieges would obliterate even most tolerant players before mass artillery protection is set up :-)

[garrotte13]

Started a completely fresh new game 2 days ago with turned off puple gas.
I added difficulty for almost all parameters (110 biters in directly formed groups, 1.2 in Difficulty Scaling, about 1.3 in everthing else - biters health, worms health and range, 1.5 for healing rate) and added initial bases frequency 300%/300%, tiles pollution absorption 60%, pollution-provoked attack cost 50%. Hardcore!
Trees are alive, enemies expand with harder to notice footprints (no signals of nearby expansion anymore). Fun !
I don't know from now on when biters do their futile sieging attempts too close to my defenses. And I don't care, because it's hot in any case.
I'm happy.

Off-topic.
The only thing I had to do was to increase coefficient for mutation Adapter Modifier to value 7, because without it biters mutate into physical resistant at 7% evo or earlier - before I get oil (I have a train map setup - need to survive and fight for distant big resource patches at very beginning). Maybe adding some evolution check for mutation could be useful to avoid physical resistance till evo 25%, laser/electrical resistance till evo 45% and so on.
Looks like "killed biters" value is calculated not for one faction, but for entire map. And 4500 killed biters - that's a very small value to start mutations into something resistant, because many players start without oil nearby, but with nests close enough.
I suppose it depends on bases frequency, starting area size, resources distribution - players have to change this value considerably and no way to automatically adapt this value in mod code.

[garrotte13]

I had forgotten Rampant checks for adjust chunks for pollution because otherwise pollution absorbing nests wouldn't potentially be counted because when Rampant checks the chunk under the nest it may not have pollution on it because the spawner absorbs it and i can't check the current absorbed pollution by a spawner. So the system currently over estimates pollution covered nests vs under estimating them.

Therefore this problem still exists in Rampant3. It's a combo of Rampant's "overestimation" and Factorio engine's limitation (min_to_diffuse constant making small PUs pollution cloud to rest for HOURS in chunks with no trees). In the end there are only two outcomes:
a) player goes and purges those nests in pollution-free chunk to stop endless biters nesting.
b) biters build nest in that adjacent chunk and quickly eat the remainder of PUs, after that they stop sieging.

In vanilla another outcome commonly prevails: those PUs are slowly absorbed by land.

P.S.
What I don't understand here is some conflict in factorio wiki and real factorio behavior:
https://wiki.factorio.com/Pollution#Chunks
It doesn't work like it's written there. PUs are absorbed by tiles not in absolute values, but in some percentage. So when PUs amount becomes very small and there are no trees in chunk, it takes dozens of minutes to reduce PU level by 1.0. And I'm about normal tiles (grass/sand/dirt) or even creep tiles, not about landfill.

[garrotte13]

Oh, I found this place in your code in chunkPropertyUtils.processNestActiveness(map, chunk) and set check value for adjacent chunks to 12.5 (some percentage of min_to_diffuse value) - hope it will help. Living 3 years with this additional Rampant difficulty.. mmm and with Warmonger creep dirty remove process it became especially painful endless cycle (kill, clean tiles, kill again...)

[garrotte13]

P.S. What I don't understand here is some conflict in factorio wiki and real factorio behavior: https://wiki.factorio.com/Pollution#Chunks It doesn't work like it's written there. PUs are absorbed by tiles not in absolute values, but in some percentage. So when PUs amount becomes very small and there are no trees in chunk, it takes dozens of minutes to reduce PU level by 1.0. And I'm about normal tiles (grass/sand/dirt) or even creep tiles, not about landfill.

Problem is not factorio ! It's alienbiome mod. A totally corrupted piece of mod. It overwrites absorption values for all tiles of all mods. Looks like all mods from Earendel should be used with extreme care as improperly implemented.