[0.17.x] Biters don't attack anymore

[TheRealBecks]

Hi,

I already mentioned it here that the biters won't attack anymore the longer we play. The more pollution we produce the less biters will attack us. When getting to robot production then the biters are boring! I think it's happening since 0.16. It's a real game breaker that the 'survival' fun is gone once again... :/

Regards,
Becks

[Rseding91]

Thanks for the report however after loading your save I don't see anything wrong. The biters are barely in your pollution cloud and so attack sometimes once they absorb enough pollution.

[TheRealBecks]

Thanks for the report however after loading your save I don't see anything wrong. The biters are barely in your pollution cloud and so attack sometimes once they absorb enough pollution.

I don't know when the biter behavior has been changed, but back then there were way more attacks with way bigger crowds. There were several crowds meeting and attacking afterwards, that's why we think it's a bug. Their lame behavior is boring my mates an me, it was way more fun with the bigger crowds attacking way more often. That has been changed several months ago, maybe with version 0.16 :/

Also I'm wondering how much pollution needs to be created to get the biters attacking. We've tested lots of scenarios since version 0.16 also with mega bases with abnormally much pollution, but it's totally broken! At the late game biters won't even attack anymore!

[FuryoftheStars]

May want to give the Rampant mod a try: https://mods.factorio.com/mod/Rampant

[Rseding91]

You're also on a ribbon world which just doesn't work well with biters since a lot of your pollution is just off in out-of-map chunks.

[BlueTemplar]

Why is pollution even allowed to penetrate those ?
Wouldn't having pollution only allowed to spread into in-the-map chunks make for more interesting gameplay ?

[Rseding91]

Why is pollution even allowed to penetrate those ?
Wouldn't having pollution only allowed to spread into in-the-map chunks make for more interesting gameplay ?

The "normal" game is an unlimited map and so that's what everything has been programmed for. "Ribbon" or "limited" style worlds are the ab-normal and we aren't looking to make the normal game slower CPU calculation wise to make the ab-normal better.

[mrvn]

Why is pollution even allowed to penetrate those ?
Wouldn't having pollution only allowed to spread into in-the-map chunks make for more interesting gameplay ?

The "normal" game is an unlimited map and so that's what everything has been programmed for. "Ribbon" or "limited" style worlds are the ab-normal and we aren't looking to make the normal game slower CPU calculation wise to make the ab-normal better.

Seriously? How is it faster to spread pollution every tick several out-of-map chunks deep instead of stopping at the first? Is a simple "if (x < min_x || x > max_x || y < min_y || y > max_y)" really going to affect normal maps?

Or even better add a flag to chunks "if (chunk.pollutable)". I would love to have chunks that block the spread of pollution for the RibonMaze mod. Or for generating maps with uncrossable mountains. Not even pollution can cross them.

[Rseding91]

You missed the key part: in the normal game there are no "out of map" chunks so the game does no checks for "is out of map" every time pollution spreads. If that was added the normal game would have to check *every* *single* *time* pollution spreads if it's spreading to an out-of-map chunk which literally never happens in the normal game.

[boskid]

There is "out-of-map" tile. Even if you have ribbon/island world, map is still full 2d-plane. By setting map width or height, you only affect map generator which decides what tiles to put, but still whole map may be used.

If you want to verify this, open ribbon world, enter editor ("/editor") and paint over out-of-map tiles (shift+left click).

Flags like "chunk.pollutable" would affect pollution spread routine as it would require to count to how many chunks pollution can be transfered to (to avoid loosing pollution on unsuccessful pollution transfer). This is however small overhead and could be implemented.
I think mods may be able to read and set (LuaSurface.get_pollution, LuaSurface.pollute) per-chunk pollution level so it could be possible to "transfer back" pollution that escaped ribbon or maze (assuming in maze there are at least 2 out-of-map chunks to detect from which chunk pollution was transfered).

"chunk.pollutable" flag could be updated on chunk tile change to avoid tile lookup every tick or to be left available for mods to be updated

[mrvn]

You missed the key part: in the normal game there are no "out of map" chunks so the game does no checks for "is out of map" every time pollution spreads. If that was added the normal game would have to check *every* *single* *time* pollution spreads if it's spreading to an out-of-map chunk which literally never happens in the normal game.

First: What is normal? Do you mean the default map setup? Well, even without mods the map setup can be edited. The map dimension is there to be set by any user. I still call that a normal game.

Second: Yes in the probably *thousands* of cpu cycles required per block each time pollution is spread from one block to the surrounding there would have to be *one* *single* *check* to catch an out-of-map chunk.

You might say that it causes another memory access and adds another branch and extra opcodes. Usually though the cache line holding the flag will probably be read into cache anyway. The branch won't be taken unless on a ribbon world and can be predicted very well. And often the extra opcodes just disappear in the pipeline and are run basically for free while waiting for memory or other opcodes.

My question stands: Is a simple "if (x < min_x || x > max_x || y < min_y || y > max_y)" really going to affect normal maps? Or the even simpler "if (chunk.pollutable)"? I imagine a chunk has a value for how much pollution it can absorb. I imagine that will only hold positive values. So a negative value could be used to non-pollutable chunks. So you wouldn't even need more memory for the flag.

[Rseding91]

It's not as simple as you try to make it sound. The map dimensions are stored on the map gen settings which pollution logic doesn't touch right now. Chunks have no such "max pollution" value and so there's no way to mark a chunk as "can't have pollution".

To put it simply: I'm not changing how it works right now (if ever). Don't play limited sized maps - the entire game is built around the map not being limited. The fact someone put a "ribbon" world preset was a mistake and now we have to deal with these reports about the fact that the game isn't built for that kind of map.

[mrvn]

It's not as simple as you try to make it sound. The map dimensions are stored on the map gen settings which pollution logic doesn't touch right now. Chunks have no such "max pollution" value and so there's no way to mark a chunk as "can't have pollution".

Not "max pollution". Absorbtion. Each tile absorbs a certain amount of pollution every tick depending on it's type. Grass absorbs more than sand for example. And entities (trees for example) absorb pollution too. At least that's how it was described in the past.

Are you telling me the chunk has no variable that holds the amount that can be absorbed every tick for the whole chunk? Each time you iterate over all tiles and entities to figure out how much pollution is absorbed? Well, add such a variable and the time saved by not having to iterate over all tiles and entities will more than make up for a out-of-map check.

To put it simply: I'm not changing how it works right now (if ever). Don't play limited sized maps - the entire game is built around the map not being limited. The fact someone put a "ribbon" world preset was a mistake and now we have to deal with these reports about the fact that the game isn't built for that kind of map.

Fair enough. I just don't buy the "it would be too expensive to do this" excuse. I figure it's a "I'm busy doing more important stuff" situation, which is fine. Just say so.

[BlueTemplar]

My question stands: Is a simple "if (x < min_x || x > max_x || y < min_y || y > max_y)" really going to affect normal maps? Or the even simpler "if (chunk.pollutable)"? I imagine a chunk has a value for how much pollution it can absorb. I imagine that will only hold positive values. So a negative value could be used to non-pollutable chunks. So you wouldn't even need more memory for the flag.

That is not enough :
1.) There are more complex map shapes possible :

(One might want to address more cases than just ribbon/box world...)

2.) Having zero absorption for out-of-map chunks doesn't seem to be a good solution either - the pollution would just keep spreading into the void, which might cause RAM limit issues (and doesn't seem "realistic").
In fact, it seems that that's what was happening before 0.17.12 (the Big pollution overhaul), when absorption for out-of-map tiles seem to have been added on the wiki.
Before that see this bug report :
viewtopic.php?f=23&t=66182
And it seems like this thread is basically a duplicate of this one :
viewtopic.php?f=5&t=67400

There is "out-of-map" tile. Even if you have ribbon/island world, map is still full 2d-plane. By setting map width or height, you only affect map generator which decides what tiles to put, but still whole map may be used.

If you want to verify this, open ribbon world, enter editor ("/editor") and paint over out-of-map tiles (shift+left click).

Flags like "chunk.pollutable" would affect pollution spread routine as it would require to count to how many chunks pollution can be transfered to (to avoid loosing pollution on unsuccessful pollution transfer). This is however small overhead and could be implemented.
I think mods may be able to read and set (LuaSurface.get_pollution, LuaSurface.pollute) per-chunk pollution level so it could be possible to "transfer back" pollution that escaped ribbon or maze (assuming in maze there are at least 2 out-of-map chunks to detect from which chunk pollution was transfered).

"chunk.pollutable" flag could be updated on chunk tile change to avoid tile lookup every tick or to be left available for mods to be updated

Yeah, this - reverse the logic :
- create a "map_has_out-of-map_tiles" flag that would be set if the map used a non-default map size setting*, or if a script ever added out-of-map tiles
- make the completely out-of-map chunks, to "throw back" pollution - during the next pollution update (the next second) if it's too computation-heavy...
*technically, even the normal map has out-of-map tiles, but they are so far away that hardly anyone would care...

This won't be perfect because pollution will still spread through "fine" mazes (the above map example might need some thicker gears), and extra calculations would be done on fine mazes for naught, but it would still be better than now !

[mrvn]

My question stands: Is a simple "if (x < min_x || x > max_x || y < min_y || y > max_y)" really going to affect normal maps? Or the even simpler "if (chunk.pollutable)"? I imagine a chunk has a value for how much pollution it can absorb. I imagine that will only hold positive values. So a negative value could be used to non-pollutable chunks. So you wouldn't even need more memory for the flag.

That is not enough :
1.) There are more complex map shapes possible :

(One might want to address more cases than just ribbon/box world...)

Oh, I like that map. What mod is that?

Also have you considered using cliffs instead of out-of-map tiles to create barriers? With the ribon-maze mod I player with having cliffs rise out of water to form the traversable parts. I think it looks much more natural that way.

2.) Having zero absorption for out-of-map chunks doesn't seem to be a good solution either - the pollution would just keep spreading into the void, which might cause RAM limit issues (and doesn't seem "realistic").
In fact, it seems that that's what was happening before 0.17.12 (the Big pollution overhaul), when absorption for out-of-map tiles seem to have been added on the wiki.
Before that see this bug report :
viewtopic.php?f=23&t=66182
And it seems like this thread is basically a duplicate of this one :
viewtopic.php?f=5&t=67400

I didn't suggest setting a zero absorption for out-of-map chunks. What needs to be stopped is the spreading. I only suggested using the absorption value of a chunk to be reused to mark out-of-map chunks. negative: out-of-map, don't even spread pollution here, positive: amount of pollution absorbed per tick.

There is "out-of-map" tile. Even if you have ribbon/island world, map is still full 2d-plane. By setting map width or height, you only affect map generator which decides what tiles to put, but still whole map may be used.

If you want to verify this, open ribbon world, enter editor ("/editor") and paint over out-of-map tiles (shift+left click).

Flags like "chunk.pollutable" would affect pollution spread routine as it would require to count to how many chunks pollution can be transfered to (to avoid loosing pollution on unsuccessful pollution transfer). This is however small overhead and could be implemented.
I think mods may be able to read and set (LuaSurface.get_pollution, LuaSurface.pollute) per-chunk pollution level so it could be possible to "transfer back" pollution that escaped ribbon or maze (assuming in maze there are at least 2 out-of-map chunks to detect from which chunk pollution was transfered).

"chunk.pollutable" flag could be updated on chunk tile change to avoid tile lookup every tick or to be left available for mods to be updated

Yeah, this - reverse the logic :
- create a "map_has_out-of-map_tiles" flag that would be set if the map used a non-default map size setting*, or if a script ever added out-of-map tiles
- make the completely out-of-map chunks, to "throw back" pollution - during the next pollution update (the next second) if it's too computation-heavy...
*technically, even the normal map has out-of-map tiles, but they are so far away that hardly anyone would care...

This won't be perfect because pollution will still spread through "fine" mazes (the above map example might need some thicker gears), and extra calculations would be done on fine mazes for naught, but it would still be better than now !

Pollution is handled per chunk. So yeah, anything finer than chunk sized is getting lost. That's why I also ignored out-of-chunk tiles. They exist but for the purpose of pollution spreading they are irrelevant. Just another type of tile really.

I'm not sure how factorio would recognize an out-of-map chunk other than being outside the map dimensions. It could then set a out-of-map flag in the chunk structure when generating the chunk and the on_chunk_generated event could be allowed modify that flag. That would allow having out-of-map chunks inside the map to make mazes that even pollution has to follow or to create natural barriers to pollution.

Using LuaSurface.get_pollution and LuaSurface.pollute is a non starter. Adding per chunk work in the on_tick handler really doesn't scale well.

[BlueTemplar]

My bad.

Not a "mod", a RedMew "scenario". (Try clicking the above picture! )

[TheRealBecks]

Ok, so you guys hijacked my thread...?!

Back to the topic:

You're also on a ribbon world which just doesn't work well with biters since a lot of your pollution is just off in out-of-map chunks.

If it's no bug that the biters won't bite, is there any way to tune the behavior to get waaaayy more masses to attack?
Also it's our first ribbon world and it worked badly the other normal maps before, too. Can be seen here in my post: viewtopic.php?f=23&t=67861#p413423

[BlueTemplar]

In 0.17, people tend to complain about the opposite problem :
viewtopic.php?f=16&t=69133

But there are plenty of ways that you can adjust biters to your liking :
https://wiki.factorio.com/World_generator#Enemy
(Check also the Advanced tab.)

[TheRealBecks]

In 0.17, people tend to complain about the opposite problem :
viewtopic.php?f=16&t=69133

But there are plenty of ways that you can adjust biters to your liking :
https://wiki.factorio.com/World_generator#Enemy
(Check also the Advanced tab.)

I don't think that these settings will help as these are commands for the biter evolution and expansion. But what I want is more spam, not bigger biters

I found some useful commands that I will test a while:

Code: Select all

/c game.map_settings.enemy_attack_pollution_consumption_modifier=100
/c game.map_settings.pollution.diffusion_ratio = 0.2
/c game.map_settings.min_group_gathering_time = 100 
/c game.map_settings.max_group_gathering_time = 300
/c game.map_settings.max_wait_time_for_late_members = 20
/c game.map_settings.max_gathering_unit_groups = 100
/c game.map_settings.max_unit_group_size = 500

These are the default values:

Code: Select all

/c game.map_settings.enemy_attack_pollution_consumption_modifier = 1
/c game.map_settings.pollution.diffusion_ratio = 0.02
/c game.map_settings.min_group_gathering_time =  3600
/c game.map_settings.max_group_gathering_time = 10 * 3600,
/c game.map_settings.max_wait_time_for_late_members = 2 * 3600
/c game.map_settings.max_gathering_unit_groups = 30
/c game.map_settings.max_unit_group_size =  200