Signal Relation Incosistency

[EMREOYUN]

When used locally, some signals connect to the wrong signals in the relation. Does the relations required to be fixed my hand?

Wrongly connected relationship:

The correct one:

[GNimrodG]

Yeah it's known bug... sometimes the trains just teleport or something happens to them.
I haven't found a solution to this yet, other than manually checking the signals and removing the broken connections.
I think the problem is the TTL here, I tried lowering it from the previous 1 hour to 5 min that didn't help much...

If I connect to the DB with QGIS to visualize the connections there are lots of broken lines there:

[GNimrodG]

Block signals have a rule to them so they don't get that messed up but for main signals I couldn't find a solution yet.

[EMREOYUN]

Yeah as far as I can see, only the links that include block signals are broken. That is caused by a server restart, especially on EU3 which restarts per 4 hours and bit messy playground which can break things apart. In every restart, even though the train is minutes late, it will be put in the correct position which meets with the time. It could generate these broken connections.

[EMREOYUN]

It seems some commits made the signal connections are working correctly. I've been running the server for a while with a fresh instance and signals getting matched with correct signals.

[GNimrodG]

Yeah I limited the TTL of trains' old signal information, so it expires when a server restarts. There are still occasionally some wrong connections though.

[EMREOYUN]

Which ones? I can look it up on my server to confirm.

[GNimrodG]

DZ_G11 connected to DZ_G13 which shouldn't happen because they're parallel to each other. And even DZ_G13 connected to DZ_G11 so they're each others next AND prev signals. Same with Dra_A and Dra_E.
I actually wrote a query to detect this:

SELECT signal_connections.prev,
       signal_connections.next,
       signal_connections.created_at                                   AS first_created_at,
       s.created_at                                                    AS second_created_at,
       concat(signal_connections.prev, '<->', signal_connections.next) AS id
FROM signal_connections
         JOIN signal_connections s
              ON s.prev = signal_connections.next AND s.next = signal_connections.prev

Then DW_P (DGW) connected to Bo_D1 (Bukowno) which shouldn't be possible because there is Sławków between them.
Also DS_G connected to DW_P which is wrong because there is DW_B the entry signal to DGW between them.
Also somehow Ju_G (Juliusz) connected to DZ_L1 (DGZ) which is an impossible connection.

[GNimrodG]

I also fixed lots of this issues manually so my instance is pretty okay now.

[EMREOYUN]

DZ_G11 connected to DZ_F in my server which shouldn't be possible for the same reason you wrote. Dra_A and Dra_E are also connected. I guess I will use SRTD to connect all signals manually with a script since the source code of SRTD contains all signals and their connections except before Grodzisk Mazowiecki.

Also, how do you visualize connections on the map?

[GNimrodG]

I use QGIS to visualize the connections. I connected it to the PostGIS DB and created a view which creates a LineString from the signal_connections
Here is the query for that:

SELECT concat(
               CASE
                   WHEN p.next_finalized = true THEN concat('[', p.name, ']')
                   ELSE p.name
                   END, '->',
               CASE
                   WHEN n.prev_finalized = true THEN concat('[', n.name, ']')
                   ELSE n.name
                   END)              AS id, -- without an ID QGIS can't read the data
       signal_connections.prev,
       signal_connections.next,
       signal_connections.distance,
       signal_connections.created_at,
       st_makeline(p.point, n.point) AS geom,
       p.next_finalized              AS start_finalized,
       n.prev_finalized              AS end_finalized,
       p.next_regex                  AS start_regex,
       n.prev_regex                  AS end_regex
FROM signal_connections
         JOIN signals p ON signal_connections.prev = p.name
         JOIN signals n ON signal_connections.next = n.name

Then you can just import this view as a layer in QGIS.

I used screenshots of the dispatcher tables to correct the signals on my server manually with hand. I might look into importing connections from SRTD too.

[GNimrodG]

Also an intersting thing I noticed that there is a third (I think non-electrified) track between SG and Bedzin, between signal SG_C (which I don't have on my server) and B_P (which has been used enough times to appear on my server, discovered at 2024-06-16 19:10:43) that isn't there on the SRTD.
SG side:

Bedzin side:

Also on my server there is signal LA_F110 which shouldn't be accessible in the current state of the game.

[EMREOYUN]

Also an intersting thing I noticed that there is a third (I think non-electrified) track between SG and Bedzin, between signal SG_C (which I don't have on my server) and B_P (which has been used enough times to appear on my server, discovered at 2024-06-16 19:10:43) that isn't there on the SRTD.
SG side:

Bedzin side:

Also on my server there is signal LA_F110 which shouldn't be accessible in the current state of the game.

Probably those are came from EU3, where there is no rules. I once sent a train to LA_F4M once to test a theory. As far as I know, SRTD only contains accessable routes and might not include every route in the game like Grodzisk Mazowiecki - Warsawa is completely missing and some minor issues that makes trains disappear on the routes. Maybe hopping and sending a train on track 3 from Bedzin might add SG_C on the map as well.