I would respectfully disagree - that suggestion has already been implemented a long time ago - these suggestions are to change the current behaviour (and not to revert it to how it was previously).

A couple of quick QoL suggestions:

#1 - prevent the deconstructer from acting on moving vehicles.

How many times have you accidentally deconstructed part of a train and maybe not even realised until later? (maybe for anyone who wants this functionality to still exist there could be a force remove ...

Note that this is not a gripe. I will admit that adding diminishing returns is definitely not my favourite ever feature, but I am trying to learn to live with it...


What does seem odd to me is that diminishing returns is based on the number of beacons, rather than the number of modules.

If I want ...

That doesn't do what's required - it sees that station stop as completed, and goes back to the loading station, not on to the next not-disable unload station.

So just picked up Factorio for the first time since 2.0 ... and definitely not impressed to say the least!

I have in my megabase very very large stations that require significant holding areas close to each platform to enable enough throughput.

To facilitate such, each train has 2 stops - xx Load ...

I am afraid I can't reproduce this as it was in the middle of a firefight, but hopefully the explanation will be enough to go off.

I was clearing out some nests, and I was about to kill the last worm, but all of a sudden it seemed like my gun jammed. I pressed fire repeatedly and nothing happened ...

When placing even a very simple blueprint from map view, the placement needs to be much more exact than it used to be.
The entire blueprint is green and snapped in the correct place but cannot be placed until the mouse is in a very specific position. No errors are produced.
I would guess that the ...

addendum: shift and left click also now seems to destroy the blueprint, even though that's not in the tooltip

Please bring back the clear blueprint functionality, updating an existing blueprint is so much less intuitive now :/

Addendum 2:

-Building (non-blueprint) wagon/train ghosts on diagonal rails seems to be impossible (although I'm not sure if I've ever tried this before TBH).

-Building (non-blueprint) wagon/train ghosts on vertical rails also seems to be impossible, but works on horizontal.

-Building (non ...

As an addendum - the vertical mouse placement (for horizontal rails), seems to be the only thing that matters, and vice versa. The horizontal mouse placement on horizontal rails (and vertical on vertical), seems to make no difference at all.

Thanks for reporting this, I get the same issue, just a tad annoying and weird. :/

I can confirm this fixes the bug I posted.

Thanks - I think (this means by main game is no longer broken and I can go back to playing... just when I thought I'd nearly broken the addiction...)

Glad to see that someone else has noticed this! :)

It happened with the 0.49 release. I posted about it twice, first time it was thought resolved with a different fix, and the second time it was assigned as not a bug :( .

https://forums.factorio.com/viewtopic.php?f=7&t=72111
https://forums ...

Has this behaviour changed intentionally since .49? Prior to this, when a reserved signal was closed by the circuit network (after the reservation was made), it would still read the reserved state, and the transition to the red state - it would only stop reading when the signal went back to green ...

Re-posting below as bug was not fixed as reported in: https://forums.factorio.com/viewtopic.php?f=11&t=72111

Doesn't happen in .48, started in .49, still broken in .50-.52

If a train reserves a path through, but does not start passing, a signal that is subsequently closed via the circuit network ...

Unfortunately this has not been resolved in 0.17.50

OK, update after more experimentation to recreate:

If a train reserves a path through but does not start passing the signal before it closes, then it will not read the change in state to red (the amber state stops being red correctly, but red doesn't start).

If the same train reserves a path ...

Doesn't happen in .48, started in .49

When a train reserves a path through a signal that is subsequently closed via the circuit network before the train has finished passing, the signal stops reading it's colour state as soon as it is closed.

Prior to .49, it would keep reading it's state until ...

Nope, this still occurs in 0.17.39

Thanks for the update kovarex - it would be really nice to see this fixed in future, as it really is immersion breaking, if nothing else.