It looks like we'll need a copy of your blueprint-storage.dat from the Factorio application directory.

Failing as in the function call returns an unknown/invalid value - it is. Failing as in the function call never returns - there's nothing we can do about that.

The expectation and contract is: calling the function with valid arguments returns some value and we process that. In this case, that ...

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

Thanks for the report however this is working correctly based off the values you've define in the energy source. You specifically set scale_fluid_usage to false and so it's consuming all available fluid (up to the defined per-tick amount), and producing *way* more energy than it actually needs to ...

Thanks for the report however I don't believe we will be changing this. "putting fish back" is an Easter egg and as such it works how it does, and if too many issues arise with it our go-to will be to remove it rather than add increasingly more complexity.

I don't see any answer to this that won't have bigger issues. The engine is simply not setup to deal with the scenario you're giving it. The simple answer is: you just can't do that and expect it to work.

Thanks. I was able to reproduce it using some of the mods shown in the video and found and fixed the underlying issue for the next release.

Which in-game thing is not being migrated that you expect to be migrated?

I'd specifically like the mods directory containing the old mods that need updating since I have no idea which version(s) you have locally when trying to reproduce this, and trying to figure out which mods I can install, that then need updates - that also make this happen - has not worked for me.

Thanks for the report however this is working as intended. A crafting machine does not have storage for all the individual blueprints in a given book and so when it consumes the book to craft it ejects the blueprints/items in it onto the ground.

If that's not what you want, simply right click on ...

I was not able to reproduce this, but I can see in the code what was going wrong and it's now fixed for 2.1.

4 times actually: viewtopic.php?p=666169#p666169

Based on all 4 crashes being in different places, none of them being reproducible, and none of them pointing at places other people are crashing in, I’m like 99% sure your hardware is faulty.

Thanks for the report however autosave indexes are based off the time in the save file and are not shared/incremented across different saves.

Specifically the autosave index used is computed as: (update-tick / autosave-interval - 1) % autosave-slots + 1

Thanks for the report. Do you know of any way to reproduce this crash?

Thanks for the report however the crash log does not show anything useful about the crash. The only way I’ve seen this crash in the past has been failing hardware (most commonly RAM). Unless you know of a way to reproduce it.

By placing a given tile it may make placing another invalid (tile placement rules can require you do not build within x distance of another tile). So can place tiles is not likely to be super useful.

Thanks for the report however this is simply how trains work on curves. If you want to avoid this, you can't have the train stop on a curve.

Ok, I added a hidden config option for 2.1.

If I was to add a setting (hidden or otherwise), there are 2 scenarios where the visualization happens: on mouse-over of a fluid entity, and when holding a fluid entity in the cursor.

It's unclear if a setting would disable both, or just one, or if there would be a desire for two settings.

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