LuaTrain:front_rail/rail_direction_from_front_rail

[Choumiko]

• Added LuaEntity::get_connected_rail. It takes a table with rail_direction (0 front, 1 back) and rail_connection_direction (0 left, 1 straight, 2 right) and returns a new rail (or nil) following that specification from the given rail entity.
• LuaTrain::front_rail, LuaTrain::back_rail, LuaTrain::rail_direction_from_front_rail and LuaTrain::rail_direction_from_back_rail None of the methods takes any parameters.

Been playing around with the new API a bit and noticed a few things. Not sure if these are bugs or working as intended.
The rail_direction_from_front_rail seems to dependent on the locomotives cardinal direction.

Code: Select all

Locodir   rail_direction_from_front_rail
North     0
East      0
South     1
West      1

This seems to be ok and quite usefull, for diagonals it get's strange though:

As you can see the rail_direction jumps from 1 to 0. (depending on the LuaEntity.direction of the LuaTrain:front_rail).
I'd expect it to be consistent for the diagonals too, like

Code: Select all

Locodir   rail_direction_from_front_rail
NE     0
SE     0
SW     1
NW     1

PS: I guess it's a bug, at least my post looks more like a bug report than a question

[ratchetfreak]

Remember that diagonal rails are just triangles I think that has something to do with it

can you check all 4 directions to see that all act the same?

[Rseding91]

The direction is correct for the angled rail (although it does read weird). I'll write up an explanation later today when I'm back at my computer and can verify what I'm typing

Essentially you don't need to care about the rail direction - it's only useful in the context of "get_connected_rail". It knows how to properly interpret the direction accounting for the rotation of the rail you're calling it on.

[Choumiko]

Essentially you don't need to care about the rail direction - it's only useful in the context of "get_connected_rail". It knows how to properly interpret the direction accounting for the rotation of the rail you're calling it on.

That's partially what i thought. Haven't had the time to try it much yet. So I'm looking forward to the explanation/wiki update (especially since i got 3 days off starting saturday ).

[Rseding91]

Hmm, after writing a small test mod I did find that the get_connected_rail behaves differently depending on curved tracks rotation which while you could write a method to properly iterate along the rails we already have that on the C++ side.

I'm going to look into exposting the iterator similar to how surface.get_chunks() works so you can simply call: for rail in train.get_forward_path() or something similar.