Thanks for the report however this is not a bug.

Thanks for the report however that is working as intended.

The specific recipe is marked as having that fluid ignored by productivity. In this case, because the "hot" fluid is just a warmed version of the "cold" fluid that the ingredients list. It's not producing the fluid as much as it's just warming it.

Just like how the barrel filling and emptying ...

Thanks for the report however this is correct. The fluid is not effected by productivity in this recipe.

Steam networking has been having issues today. Given nothing has changed in the Factorio binary in several months that is the likely issue.

Thanks for the report. I can fix this, however it's only going to fix saves when migrated from 1.1. Once a save is in 2.0 or later the migration is already done.

Ah that would do it. I'll fix it for 2.1.

Thanks for the report however I am unable to reproduce any such issue when I test and you haven't provided any save file or test mod to show what issue you're running into.

If you'd like, you can keep posting new crash logs. However, Factorio it turns out is a better test of hardware than purpose-built stress testing software. The past 10 years of Factorio has shown that to be true: Factorio will expose instabilities in peoples systems that they otherwise can't ...

Actually, I may have figured out the issue.

* Burner inserters will grab "any acceptable fuel item" when they are low on fuel
* The burner inserter is grabbing a pentapod egg for fuel
* As the burner inserter fuel bar approaches zero (and while it's mid-swing) the pentapod egg in the fuel slot ...

Thanks for the report however I'm not seeing any bug here. If spoilage isn't available for the inserter(s) to use at the time they are low on fuel they will continue to move standard items. If they eventually run fully out of power they are stuck forever until something *externally* puts fuel in ...

Thanks for the report however I don't believe we will be changing this. I could simply make it apply the schedule to the ghost when the copy action is performed however it has more complexity than that: when in ghost form every individual ghost that makes up the train contains the full schedule for ...

Thanks for the report. The log file doesn't show anything useful in the crash which typically means it crashed outside of Factorio's code. Unless you know of a way to reproduce it there's nothing we can do.

Thanks for the report. This is now fixed for 2.1.

Thanks for the report however I don't believe we wil be doing anything about this. Simply don't hold the mouse button down while *also* trying to move with keyboard shortcuts.

Thanks for the report. This is working as intended: when copy-pasting settings in person it always tries to insert the full equipment and if it doesn't have the items to do so, it won't insert any and shows the "missing equipment" notification.

When in remote view, it can *never* insert physical ...

Sorry, what I meant to imply is: beacuse the two crashes are not related it makes me think failing/failed hardware. Neither crash is one I've seen before and both are in places that execute multiple times per tick virtually every game tick. That makes me highly skeptical that there's any actual ...

That log is showing it crashing inside the TransportBelt logic (completely unrelated to the first crash).

Note, the timeout is actually 5 hours. But this has been discussed internally and some change is wanted but has not been done.

This log shows it crashed in malloc - likely running out of RAM. Do you have any of the other log files?