It was implemented for belts not so long ago and then for pipes. Mostly to prevent mixing of items or fluids when construction bots place underground pieces in random order and for some time they stay connected in unintentional manner.

A glimpse into sacred 0.16 changelog: - Placing output underground belt as ghost properly retains its type as output underground belt. Also underground belts now respect nearby ghosts and become output if there is input ghost nearby. Underground belt and pipe ghosts when hovered show outline of wher...

kovarex
Could be related to this 48213

I still couldn't replicate this even with ghosts.. with slight exception - when you have normal already-built input belt, and shift-click to put output belt that would connect to it - that shift-clicked output ghosts becomes an input. so when you create a blueprint out of that partially built contra...

There's something weird with your blueprint - both endpoints are marked as 'input'. When I create fresh blueprint of same type - it has proper input/output marking on endpoints and this (correct) behavior survives reexporting via string. So solution to your problem would be recreating this blueprint...

One reason to forbid that is due to not seeing what actually you blueprint/deconstruct. Another reason - it's not possible in map view (not zoomed in), so this sorta adds consistency. The fix was that dragging blueprint/deconstructor in zoomed-in-map view would ignore chunks that are in fog-of-war a...

Some more, it should be "Select for cancel deconstruction" instead of "Select for cancel Deconstruction" and "Select for blueprint" instead of "Select for Blueprint". Oh and may I ask why for 0.16? Isn't that just a locale change? Yeah, I scanned through all ...

Thx that will be fixed in 0.16

Thanks for noticing that Now it's fixed, but will come in 0.16

Post savegame here please, will be easier for us to track it down (and probably this issue is gone in current experimental 0.15.xx version). Saves are located at c:/users/<your-user-name>/AppData/Roaming/Factorio/saves

That will be reviewed during GUI review. One of our long-standing isssues

All zeroes happens when bytes are not flushed to HDD properly at OS level, one way to get this - instantly power off your computer during high HDD load. Process that remains active in task manager even after kill request is also sign of some hiccups at OS side. So this could be HDD problems or some ...

I couldn't make it crash in Win10-Pro, in Debug config as well which does a ton of extra checks.

Could it be that file is kept opened if client drops during map download or is unable to catch up?

canidae
Yes, that problem is fixed there as well.

There is monitor selection inside Graphics settings, did you try that?

Thanks for report, but in optimized-belts branch (coming 0.16) this problem is gone

I hope it's not sensitive to daylight saving when evaluated local clock goes an hour behind for everybody

Please attach savegame where it is easily reproducable.

One way to reproduce that is to move train a few tiles ahead in manual mode it still thinks it's at the station when put back to automatic