Additional railway queries API

[Sopel]

1. Make `get_connected_rail` also return the connection direction of the returned rail. So for example with the following setup

Code: Select all

F - front, B - back, [a-z] - identifiers, -> - connection
rail(F a B) -> rail(B b F)
a.get_connected_rail(defines.rail_direction.back, ...) -> (b, defines.rail_direction.back)

Use-case: https://github.com/Sopel97/railway_sign ... #L721-L743

2. A function to get a traffic direction on a rail as defined by connected signals (from the point of view of a rail passed as a parameter). This could also cover more cases than just inferring from segment's signals (which is what is possible now in script, see use-case below)

Code: Select all

local rail_traffic_direction = {
    indeterminate = 0,
    forward = 1,
    backward = 2,
    universal = 3
}

Use-case: https://github.com/Sopel97/railway_sign ... #L648-L674

3. A function to get all rail entities in a segment (defined by some rail inside it). It's doable from script but it's painful. See https://github.com/Sopel97/railway_sign ... #L760-L810

4. A way to access railway block information (in extended entity info view in game it already shows this). For example for checking if two segments are part of the same block or not - for this I'm currently doing the following, but it's not perfect and doesn't catch all cases https://github.com/Sopel97/railway_sign ... #L812-L843.
.

4.1. Potentially information about all railway block endpoints, with end signal entities and end rail entities along with their connection direction information.

5. A single function that returns a luatable with all neighbours. Equivalent to something like this:

Code: Select all

local function get_rail_neighbours(rail, dir)
    local entities = {}
    insert_if_not_nil(entities, rail.get_connected_rail{rail_direction=dir, rail_connection_direction=defines.rail_connection_direction.left})
    insert_if_not_nil(entities, rail.get_connected_rail{rail_direction=dir, rail_connection_direction=defines.rail_connection_direction.straight})
    insert_if_not_nil(entities, rail.get_connected_rail{rail_direction=dir, rail_connection_direction=defines.rail_connection_direction.right})
    return back_entities, entities
end

6. A single function that returns a luatable with all signals in a segment (potentially optionally include signals on the boundary of the segment? they are currently not returned by `get_rail_segment_entity`. Equivalent to something like this:

Code: Select all

local function get_segment_signals_and_traffic_direction(rail)
    return {
        front_in = rail.get_rail_segment_entity(defines.rail_direction.front, true),
        front_out = rail.get_rail_segment_entity(defines.rail_direction.front, false),
        back_in = rail.get_rail_segment_entity(defines.rail_direction.back, true),
        back_out = rail.get_rail_segment_entity(defines.rail_direction.back, false)
    }
end

7. Potentially a function that returns all start rails of blocks that a chain signal waits for to clear up?

[boskid]

ad 1/ Implemented for 1.1.62:

- LuaEntity::get_connected_rail also returns rail_direction and rail_connection_direction going back to origin rail.

ad 2/ No. The left-right buildability is a render only heuristic which is searching at most 5 rail segments deep from the starting position. That would not be accurate so i cannot expose this. Making it "accurate" would mean it would have to have an infinite recursion limit, would be expensive to run and would need to be redesigned in order to account for cycles to not freeze while processing them recursively.

ad 3/ Implemented for 1.1.62:

- Added LuaEntity::get_rail_segment_rails.

ad 4/ Implemented for 1.1.62:

- Added LuaEntity::is_rail_in_same_rail_segment_as.
- Added LuaEntity::is_rail_in_same_rail_block_as.

ad 4.1/ No. Details about rail blocks as such are not easy to be exposed because rail blocks are technically not save-loaded but recreated on load so order of everything stored inside of them is not deterministic. I am not going to implement this (at least right now).

ad 5/ No. That would be a redundant function. Just create a utility function on your end that uses LuaEntity::get_connected_rail.

ad 6/ No. That would be a reduntant function. Just create a utility function on your end that uses LuaEntity::get_rail_segment_entity

ad 7/ No. Traversing chain signal paths is not an option. Chain signals get their color due to recursive update but there are no details stored about this process after it is finished. This part is also not well defined because if there is a branch after a chain signal, by your definition it would be waiting at any of child signals as each one of them becoming green would make the chain signal in question to change from red to blue or from blue to green.

[boskid]

ad 7/ I was able to find something else that is possible to be exposed to a Lua and should give you ability to perform rest of your logic in your mod.

- Added LuaEntity::get_parent_signals.
- Added LuaEntity::get_child_signals.

[Sopel]

Thank you, this is more than I expected. Definitely covers everything that I can forseeably need.