Thanks for the report. This has been fixed for the next release.

Thanks for the report however I don't believe we will be doing anything about this per the discussions on Discord.

Belt loops and splitters simply don't work as you're thinking they should when built like this and at this point in Factorio development there is no clear answer for changes to their ...

Thanks for the report however this is working as intended. The arms consume power when they start moving towards a chunk and don't constantly draw power while in operation. This is done on purpose to avoid constantly needing to touch the energy source memory and the performance of doing that as it ...

I think the fix for this will be limiting the electric energy interface values to some sane but large number.

That 100% sounds like a KDE Plasma developer issue given *we* didn't change anything and it got worse with their update.

However, I'll leave this for the linux guys to decide.

Actually, looking at that function more it looks like it's not going to be viable. It makes a copy-on-write version of a given processes memory - however it does it as *its own process* which you can then pull bits of data from using https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf ...

PssCaptureSnapshot is the mechanism used to implement this, but it has some serious implications for Performance and Memory Layout. Raymond Chen's Blog lays out some of the challenges. This facility is really for Debug purposes only - the Process Snapshot is given "low-priority memory ...

Fluid usage is here: https://lua-api.factorio.com/latest/cla ... e_per_tick

Neighbor connectable I didn't include - what's the point in having it?

The "Trash unrequested" checkbox is specifically disabled when personal logistics are disabled because the game specifically does not do trash-unrequested logic when personal logistics are disabled and we had bug reports/confusion where players would check-uncheck the setting and wonder why it wasn ...

Thanks for the report however this is not a bug. If that’s the behavior you want, you want to see the filter to “exact”, and not ”at least”.

I added them for the next release.

Thanks for the report. Unfortunately without a way to reproduce this, it looks like a one-off memory/CPU issue.

Do you have any idea idea how to possibly reproduce this? Are you having any other issues with your PC?

Maybe. But the logic was not written for "temporary stops made by scripts". It was made for player interaction and then a lua API was added to interact with that.

Thanks for the report. This is now fixed for the next release.

This is now fixed for the next release. I added some "immunity frames" (5 seconds) after landing where you can't be squashed.

This ended up fixed here 127123

Thanks for the report however all of these are correct. They are all "fly until" conditions. Just like how for trains and platforms wait conditions are "wait until" conditions.

Thanks for the report. This is now fixed for the next release.

Thanks for the report. This is now fixed for the next release.

Looking at the code, it seems it's explicitly set up so if there is a temporary stop in the schedule the train does not do interrupts. It seems to work this way so when you tell a train to go somewhere using the temporary stop logic, it always goes there and doesn't get re-routed somewhere else due ...