[2.0.43] Rail signals cannot be ghost-placed next to a rail in oil ocean

[Upserter]

04-02-2025, 22-25-56.png (1.56 MiB) Viewed 1000 times

What did you do?

Tried to place a rail signal ghost next to a rail on the oil ocean on Fulgora.

What happened?

Received the message "Rail signals must be built next to rails"

What did you expect to happen instead?

I expected the game to place a foundation ghost as well as the rail signal. I have foundation in my inventory. When I place the foundation first, the rail signal placement is allowed.

Does it happen always, once, or sometimes?

Sometimes. It seems to depend on how my cursor has moved over other valid rail signal placement spots.

[tinker9]

Your rail signal is at a different angle to the rail, causing the error.

In some cases, the rail signal in your hand (or remote) stops automatically changing its orientation to match rails. I've seen this happen with copy-paste and blueprints (where it is possibly the expected behaviour.)

But I've also seen it happen when I've been placing a bunch of signals on Nauvis. It seems to happen more when the signals are over water. When the signal gets in this state, even re-picking it from the bar doesn't help. This has mainly happened to me when I've been placing signals remotely.

I haven't reported it before, because I've had trouble reproducing it.

[tinker9]

Ok, I think I've got a reproducer in 2.0.43:

What did you do?

Tried to place a rail signal ghost next to a rail on water on Nauvis, after placing another rail on water at a different angle.

What happened?

Rail signal does not build, even though the cursor is next to rails. Force and super-force build doesn't work, either.


What did you expect to happen instead?

I expected the game to rotate the rail signal to match the rail orientation, place a landfill ghost, and then place a rail signal ghost. When I place the landfill first, this happens as expected.

If I use force or super-force build, this should definitely happen.

Does it happen always, once, or sometimes?

Every time, after my cursor is holding a rail signal at a different angle on water.

If you can reproduce the issue, provide the exact steps!

1. Place two rails at different angles over water (or some other fluid)
2. Put a rail signal ghost into your hand (I did this remotely on the map, the other reporter did it from their inventory)
3. Move the ghost over the rail signal at one angle (doesn't seem to matter if it has been placed or not)
4. Try building the rail signal at the other angle

This state seems to persist even if I put the rail signal down, then re-pick it from my quickbar. Other rail signals also have this state issue. Picking other items in between doesn't seem to help.

Workarounds:
- put landfill/foundation/ice platform first, then the rail signal
- move over a rail at the matching angle on land, then place the signal on water

Save game: (the rail signal is in my hand in that state in the save)
https://www.sendspace.com/file/pyot0s

[robot256]

It's not obvious that this is a bug, it's just that the signal-placement helper has not been updated for force-building. It only shows, and snaps rotation to, places where signals can be built without needing to place landfill or deconstruct anything. To fix it, the devs will probably have to expand the situations in which the signal placement squares appear. I think having them ignore tile collisions, at least when the tiles are coverable, would make sense.

[eugenekay]

Your rail signal is at a different angle to the rail, causing the error.

In some cases, the rail signal in your hand (or remote) stops automatically changing its orientation to match rails. I've seen this happen with copy-paste and blueprints (where it is possibly the expected behaviour.)

But I've also seen it happen when I've been placing a bunch of signals on Nauvis. It seems to happen more when the signals are over water. When the signal gets in this state, even re-picking it from the bar doesn't help. This has mainly happened to me when I've been placing signals remotely.

I haven't reported it before, because I've had trouble reproducing it.

I have also seen dodgy Rail Signal "snap to rail", most often when handling the new "22.5 Degree" rail pieces and Signals. I have not been able to find a consistent reproduction - waving the signals around in an intersection nest does nothing interesting when you want it to, of course. Clearing the cursor & re-pipetting (via "Q") gets back to a good state, or pushing R/Shift-R to slightly change the signal angle.

[tinker9]

It's not obvious that this is a bug, it's just that the signal-placement helper has not been updated for force-building. It only shows, and snaps rotation to, places where signals can be built without needing to place landfill or deconstruct anything. To fix it, the devs will probably have to expand the situations in which the signal placement squares appear. I think having them ignore tile collisions, at least when the tiles are coverable, would make sense.

I don't remember this happening in Factorio version 1, so it could be a new bug.

[tinker9]

I can also reproduce this by trying to force-replace a medium electric pole next to a rail line, after moving the signal in my hand next to another rail at a different angle. (I'm doing this using remote view.)

[Hares]

Have you ever built a rail signal on foundation over the lake before failing to place a ghost? It's a known issue/won't fix that you need to "initialize" the base plate for each entity category for each unbuildable tile type, this is made because of Aquilo which has several stages of covering tiles.

[Gweneph]

This is a consequence of the way the filter-directions entity flag works. Whenever your cursor moves to a new tile while holding an item whose place result has the filter-directions flag it starts a search. It will check to see if that entity can be built in each direction starting with north and going clockwise until it finds one where it can build. If/when it finds one, it sets the cursor build direction to the found direction. The "bug" is that while checking to see if the entity can be built it doesn't check with non-default build modes. It could check instead using the build mode implied by the currently held modifier keys.

[tinker9]

The "bug" is that while checking to see if the entity can be built it doesn't check with non-default build modes. It could check instead using the build mode implied by the currently held modifier keys.

Sounds like a surprising behaviour, and poor UX. Something worth fixing?