Thanks for the report,

The Surface list is purposely limited to 60% of the screen height, so that it doesn't occlude other GUIs or chat, etc.

The recent change "Changed platform requests importing from platforms to allow providing the item to cargo landing pads.", lead to this exact situation in my save, and honestly I don't know how to mitigate it.

My use case, was a 'flying mall':

Single 'hauler' platform which was flying around ...

Thanks for the report,

I took it as more a bug report, that the simulation clamping was too strict in relation to the desired 'camera zoom',
This should be fixed for the next release, as in the clamping just prevent extreme deviation from the desired zoom, not the absolute value

Upon further thought, I decided to change the logic to allow dropping (it is a simple change),
If something too hazardous results I may consider changing it back (bear in mind this is experimental)

So now in the next release, requests with just 'Import from: Platform' won't block dropping those ...

Thanks for the report,

I have removed the GUI limitation in the next release

adding this would not cause circular requesting (unless i suppose you request from a ship that is itself requesting from the planet, but at that point they are doing it to themselves)


Yes this is the key reason I made it work this specific way,
Because it would be quite easy to accidently make ...

Yea the shallow slots scroll pane style has a minimal height of 2 slots:
`minimal_height = slot_size * 2`

In the base game usage we don't really do smaller ones

I guess for CustomInventory we can just clear the `minimal height` in the scroll pane style

Gameboyaac wrote: Fri Jul 17, 2026 4:05 pm I can provide 2 saves, my most recent and one on the day it occurred, although the nest is already cleared unfortunately. I've marked where the base was in the attached screenshot:

They still can be helpful, please upload them here and I can check them

Thank you for the report,

For now I don't want to be touching the logic, its is all technically working correctly and not causing an issue

The gameplay affect, maybe its the player being smart, maybe its ruining the defence/offense balance, we can see how it goes

I vaguely remember seeing this as patched, but apparently not. Biters still sometimes generate worm only bases on expanding. Suggested fix: walk without rhythm as to not attract the worms.


Hello, thanks for the report,

Can you provide a save game?
Ideally one with the base and one before the ...

I encountered something very similar when refactoring some unit logic, so I assume it is the same and that it is fixed in 2.1

Thanks for the reports,

It looks like the expansion groups that failed would fall into a semi-passive state that preventing other groups but didn't move to attack.

It is fixed for an upcoming 2.1 release

Seems they were waiting for their last pal to join the party
Anyway for an upcoming 2.1 release, I made it so they will just start building the base when the main group arrives

This is not easy to reverse, I suppose you don't have a save game from a few hours earlier?

What I suspect, it may be a little bit funny, that there is this 1 chunk with just spitter spawners:

factorio-run_jkr7uZXpIs.png

And with 2.1 I made it more 'naturalistic' with the base spawning, that ...

Looks correct, thank you for the report though

DSL-Exodus wrote: Sat Jun 27, 2026 4:30 pm I am a little confused. Was it a bug and you fixed it? Or was it something I was just imagining?

It was a bug, and I fixed it during 2.1 development (there was a lot of rewriting of expansion planner to clean things up, and this is one of the weird situations I solved)

Thank you very much for the report, and welcome to the forum

Thrust was being undereported in 2.0 by a factor of 60: 120393
The values in 2.1 should be correct

So placing stuff as the player in those expansion chunks will still prevent them from expanding to there? As long as there is enough Player Stuff there that is.

Or did you finally manage to get rid of the trick where you just spam eight pipes in a chunk to reduce expansion rates to near zero ...

Judging by the Title. the intention was to have Biter Bases not overcrowd themselves, while player stuff merely reduces the chance, am I seeing that correctly?


One major part of the rework and fixing for 2.1 was trying to ensure that the nests don't over crowd in explored but otherwise ...

Thanks for the report, and the details info and images

The early game expansions spawning without any worms has been fixed for the next release
(Overall expansion group size and balance still in the process)