SiegingAI builds too close to player or player's structures
Builders create purple cloud and try to build very close to player's buildings during SiegeAI attacks and during revenge attacks. In many situations purple cloud is casted over player's walls and turrets -> sieging often turns into a suicide raid attack with purple could. Is it by design ? Could you kindly please point to places in code to change it, to make builders and revengers settle a little further from players structures? Thank you!
P.S. As I wrote in other thread over 50% siege attacks by SiegeAI are abrupted and turn into raiding even without purple cloud because of too close settling place selected. SiegeAI selects correct places only in very early game when no walling and no far away turrets perimeter is built.
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.
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.
@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?
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.
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.
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
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?
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.
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.
@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.
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?
The commit you linked just tries to settle where the group is at when the group detects a player nearby
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).
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.
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 :-)
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.
Here is the behavior of latest Rampant3.0.3 (rev 267a4730e7eb068589ccc17cb33cfbe297b4f48b):
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).
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".
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.
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.
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)

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.
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.
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
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.
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.
The closest building site I witnessed:

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.

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:

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.
