[0.12.29] diagonal rail direction

[reofarp]

Running

Code: Select all

game.local_player.surface.create_entity({name="straight-rail", position={0,0}, direction=defines.direction.northeast})

will create a diagonal straight-rail facing in the wrong/non-intuitive direction (compare to north/south and east/west).

Additionally diagonal rails seem to allow four different diagonal directions (1,3,5,7) (while horizontal/vertical only uses two (0,2)), but creating diagonal rails with directions 1 and 5 or 3 and 7 respectively produces straight rail in the same diagonal direction but both are offset by two tiles.

I've found some old bugreports about blueprints and diagonal rail, but those seem to have been resolved already (possibly in the wrong way?).

[DaveMcW]

Each diagonal rail snaps to a specific tile in a 2x2 grid. {0,0} is not a valid position for a northeast rail.

[reofarp]

Same thing at {1,1} (which {0,0} probably snaps to). It is a fact, that the API doesn't behave the same way as manual building does.
Manually building at {0.5,0.5} and rotating in hand doesn't change the Position, but using the API at {0.5,0.5} with directions 3 and 7 creates two rail tiles on different positions (and facing in non-intuitive directions).

edit: corrected directions

[DaveMcW]

defines.direction.northeast = 1
defines.direction.southeast = 3
defines.direction.southwest = 5
defines.direction.northwest = 7

I think the defines are wrong. Northeast/southwest rails are 3 and 7, Southeast/northwest rails are 1 and 5.

[Rseding91]

Rails use this logic when built:

• If the direction is not diagonal (North-East, South-East, North-West, South-West) then
• If the direction is North, North-East, South, South-West - change the direction to North
• If the direction is East, South, East, West, North-West - change the direction to East

The defines for direction are correct.

[DaveMcW]

Do you agree that this rail is northeast?

rail-direction.jpg (259.39 KiB) Viewed 3982 times

Why is its direction 7 (defines.direction.northwest)?

It is 7 in LuaEntity.direction, 7 in surface.create_entity(), and 7 in blueprints.

[Rseding91]

It's visually rendering as north east and/or south west - because that's how the sprite is setup. The actual direction of the entity is north west.

The main thing here is you're coupling the visual representation of the entity with the literal direction in the entity properties and for rails those two things aren't the same.

Think of it like this:

When the entity.direction == North the rail renders <L--R>
When the entity.direction == North-West the rail renders <L--R> rotated 45 degrees to the left.

[DaveMcW]

Any chance you could rotate the internal direction 90 degrees, so it actually makes sense?

[reofarp]

So the non-intuitive direction on diagonal rail seems to be intentional but there is still the weirdness of not having the same behaviour as the manual build mode:
Using create_entity at {0.5,0.5} with directions 3 and 7 will create two distinct rails, while in manual mode the rail-tile doesn't get placed somewhere else when you rotate it in hand.

I certainly do consider this a bug in the API.

[kovarex]

So the non-intuitive direction on diagonal rail seems to be intentional but there is still the weirdness of not having the same behaviour as the manual build mode:
Using create_entity at {0.5,0.5} with directions 3 and 7 will create two distinct rails, while in manual mode the rail-tile doesn't get placed somewhere else when you rotate it in hand.

I certainly do consider this a bug in the API.

The manual way of building works different. And it is not a bug. The reason is to make it possible to build diagonal rails without having to rotate every tile.

[Rseding91]

So the non-intuitive direction on diagonal rail seems to be intentional but there is still the weirdness of not having the same behaviour as the manual build mode:
Using create_entity at {0.5,0.5} with directions 3 and 7 will create two distinct rails, while in manual mode the rail-tile doesn't get placed somewhere else when you rotate it in hand.

Direction 3: SouthEast - is a distinct 4 way diagonal direction.
Direction 7: NorthWest - is a distinct 4 way diagonal direction.

As I said before - when a rail is built using a diagonal direction the game leaves it as is.

When you rotate by hand the rail cycles between 4 possible distinct rail directions: up-down, topleft-bottomright, topright-bottomleft and you end up with 3 directions possible.

When you build it by script you can manually set it to 2 additional valid directions that the standard rotate-manually cycle doesn't hit but are valid. Why you'd ever want those directions I don't know - it doesn't effect the state of the rail - but you can use them if you like.

I certainly do consider this a bug in the API.

You can consider it what you like, that doesn't make it a bug.

[reofarp]

When you build it by script you can manually set it to 2 additional valid directions that the standard rotate-manually cycle doesn't hit but are valid. Why you'd ever want those directions I don't know - it doesn't effect the state of the rail - but you can use them if you like.

This is correct for horizontal/vertical rail and this is also what I assumed to be the case for diagonal rail, but sadly for diagonal rail it is not.

Let me make this clear by an example with pictures (also for those who don't like to reproduce things themselves):

We have the following, with the big cross being position {0,0}

empty.jpg (5.04 KiB) Viewed 3774 times

Now we execute the command

Code: Select all

game.local_player.surface.create_entity({name="straight-rail",position={1,1},direction=3})

and get

rail1.jpg (5.84 KiB) Viewed 3774 times

Since rails should be undirected we expect direction 3 and 7 to be the same (as is 0 and 4 or 2 and 6 for vertical/horizontal rail).
Let's try the following code

Code: Select all

game.local_player.surface.create_entity({name="straight-rail",position={1,1},direction=7})

Now we get

rail2.jpg (6.36 KiB) Viewed 3774 times

See how the new rail got placed besides the other?

This is not related to {1,1} being an invalid rail location, because the experiment stays exactly the same whether we chose {1,1} as coordinate or any cordinates with values between 0 and 1.99..., the game snaps to {1,1}.
If you investigate this further you will notice, that you need all four diagonal directions to specify all possible visual representations of diagonal rail (no redundancy as in horizontal/vertical), because otherwise the coordinate snap leads to wrong positioning.

You can argue that it is not a bug (maybe you had your reasons when doing this, which I would love to hear), but I doubt that this is a clean way to do an API. Just imagine if the manual building worked that way (changig position when rotating): you'd get massive bug reports about this. It's just that us programmers know our way around it, but it is clearly a deficiency (if not a bug) in the API.