The get-route request on the monitor endpoint returns information about a route. This includes information on which routes conflicting with the requested one are currently granted. The current implementation for determining these conflicting routes follows the "standard" simple interlocking. That is, a route is actively in conflict if it is currently granted and listed as a conflicting route in the interlocking table. It does not use the same checking procedure as non-standard interlockers would. Therefore, a route may be safe to grant (i.e., have no active conflicts) according to the interlocker, but not according to the get-route reply.
This PR adds a check when determining conflicting routes for whether a 'sectional' (progressive route release) interlocker is currently set. If that is the case, the check for route conflicts is made using a checking function based on sectional interlocking logic. The necessary code for this check has been extracted from the artifacts generated when compiling a sectional interlocker. It is thus much longer than technically necessary (~14-19k LoC), but at least acts the same as the sectional interlocker added in the recent PR (https://github.com/uniba-swt/swtbahn-cli/pull/83). Just like the interlocker, it is currently working only for the SWTbahn-Full track configuration. This will have to be made more flexible in the future; it is not possible to achieve this in this PR before we need the 'game' to ready (in my view).
The added machine-generated code for the sectional route conflict check requires additional headers. I've placed these in server/src/obj; however, I know that this naming ('obj' folder in particular) is not ideal. I'd be happy to adjust this to whatever is requested as I struggle to come up with a good name. Note here: it is important to have naming such that the new obj/tick_wrapper.h and the existing tick_data.h are not easily confused.
The get-route request on the monitor endpoint returns information about a route. This includes information on which routes conflicting with the requested one are currently granted. The current implementation for determining these conflicting routes follows the "standard" simple interlocking. That is, a route is actively in conflict if it is currently granted and listed as a conflicting route in the interlocking table. It does not use the same checking procedure as non-standard interlockers would. Therefore, a route may be safe to grant (i.e., have no active conflicts) according to the interlocker, but not according to the get-route reply.
This PR adds a check when determining conflicting routes for whether a 'sectional' (progressive route release) interlocker is currently set. If that is the case, the check for route conflicts is made using a checking function based on sectional interlocking logic. The necessary code for this check has been extracted from the artifacts generated when compiling a sectional interlocker. It is thus much longer than technically necessary (~14-19k LoC), but at least acts the same as the sectional interlocker added in the recent PR (https://github.com/uniba-swt/swtbahn-cli/pull/83). Just like the interlocker, it is currently working only for the SWTbahn-Full track configuration. This will have to be made more flexible in the future; it is not possible to achieve this in this PR before we need the 'game' to ready (in my view).
The added machine-generated code for the sectional route conflict check requires additional headers. I've placed these in server/src/obj; however, I know that this naming ('obj' folder in particular) is not ideal. I'd be happy to adjust this to whatever is requested as I struggle to come up with a good name. Note here: it is important to have naming such that the new obj/tick_wrapper.h and the existing tick_data.h are not easily confused.