Merge branch 'diagonal_platforms' of https://github.com/Montandalar/advtrains - advtrains.git

diff options

author	Gabriel Pérez-Cerezo <gabriel@gpcf.eu>	2020-03-15 12:04:10 +0100
committer	Gabriel Pérez-Cerezo <gabriel@gpcf.eu>	2020-03-15 12:04:10 +0100
commit	fb837a449af3bc3f5d70b10d807fc53982520e9f (patch)
tree	01775ba838aa648b0450d9af1714df62b6296b78 /advtrains/models
parent	372cd7eb802934a4b567f61c84dc634ee1a463dd (diff)
parent	301dcf953e9a73d0e92f1a48af141200891f0e55 (diff)

Merge branch 'diagonal_platforms' of https://github.com/Montandalar/advtrainsrelease-2.1.2

Diffstat (limited to 'advtrains/models')

-rw-r--r--

advtrains/models/advtrains_platform_diag.b3d

bin

0 -> 1970 bytes

1 files changed, 0 insertions, 0 deletions

-- interlocking/database.lua -- saving the location of TCB's, their neighbors and their state --[[ == THIS COMMENT IS PARTIALLY INCORRECT AND OUTDATED! == The interlocking system is based on track circuits. Track circuit breaks must be manually set by the user. Signals must be assigned to track circuit breaks and to a direction(connid). To simplify the whole system, there is no overlap. == Trains == Trains always occupy certain track circuits. These are shown red in the signalbox view (TRAIN occupation entry). == Database storage == The things that are actually saved are the Track Circuit Breaks. Each TCB holds a list of the TCBs that are adjacent in each direction. TC occupation/state is then saved inside each (TCB,Direction) and held in sync across all TCBs adjacent to this one. If something should not be in sync, all entries are merged to perform the most restrictive setup. == Traverser function == To determine and update the list of neighboring TCBs, we need a traverser function. It will start at one TCB in a specified direction (connid) and use get_adjacent_rail to crawl along the track. When encountering a turnout or a crossing, it needs to branch(call itself recursively) to find all required TCBs. Those found TCBs are then saved in a list as tuples (TCB,Dir) In the last step, they exchange their neighbors. == TC states == A track circuit does not have a state as such, but has more or less a list of "reservations" type can be one of these: TRAIN See Trains obove ROUTE Route set from a signal, but no train has yet passed that signal. Not implemented (see note by reversible): OWNED - former ROUTE segments that a train has begun passing (train_id assigned) - Space behind a train up to the next signal, when a TC is set as REVERSIBLE Certain TCs can be marked as "allow call-on". == Route setting: == Routes are set from a signal (the entry signal) to another signal facing the same direction (the exit signal) Remember that signals are assigned to a TCB and a connid. Whenever this is done, the following track circuits are set "reserved" by the train by saving the entry signal's ID: - all TCs on the direct way of the route - set as ROUTE Route setting fails whenever any TC that we want to set ROUTE to is already set ROUTE or TRAIN from another signal (except call-on, see below) Apart from this, we need to set turnouts - Turnouts on the track are set held as ROUTE - Turnouts that purpose as flank protection are set held as FLANK (NOTE: left as an idea for later, because it's not clear how to do this properly without an engineer) Note: In SimSig, it is possible to set a route into an still occupied section on the victoria line sim. (at the depot exit at seven sisters), although there are still segments set ahead of the first train passing, remaining from another route. Because our system will be able to remember "requested routes" and set them automatically once ready, this is not necessary here. == Call-On/Multiple Trains == It will be necessary to join and split trains using call-on routes. A call-on route may be set when: - there are no ROUTE reservations - there are TRAIN reservations only inside TCs that have "allow call-on" set == TC Properties == Note: Reversible property will not be implemented, assuming everything as non-rev. This is sufficient to cover all use cases, and is done this way in reality. REVERSIBLE - Whether trains are allowed to reverse while on track circuit This property is supposed to be set for station tracks, where there is a signal at each end, and for sidings. It should in no case be set for TCs covering turnouts, or for main running lines. When a TC is not set as reversible, the OWNED status is cleared from the TC right after the train left it, to allow other trains to pass it. If it is set reversible, interlocking will keep the OWNED state behind the train up to the next signal, clearing it as soon as the train passes another signal or enters a non-reversible section. CALL_ON_ALLOWED - Whether this TC being blocked (TRAIN or ROUTE) does not prevent shunt routes being set through this TC == More notes == - It may not be possible to switch turnouts when their TC has any state entry == Route releasing (TORR) == A train passing through a route happens as follows: Route set from entry to exit signal Train passes entry signal and enters first TC past the signal -> Route from signal cleared (TCs remain locked) -> ROUTE status of first TC past signal cleared Train continues along the route. Whenever train leaves a TC -> Clearing any routes set from this TC outward recursively - see "Reversing problem" Whenever train enters a TC -> Clear route status from the just entered TC Note that this prohibits by design that the train clears the route ahead of it. == Reversing Problem == Encountered at the Royston simulation in SimSig. It is solved there by imposing a time limit on the set route. Call-on routes can somehow be set anyway. Imagine this setup: (T=Train, R=Route, >=in_dir TCB) O-| Royston P2 |-O T->---|->RRR-|->RRR-|-- Train T enters from the left, the route is set to the right signal. But train is supposed to reverse here and stops this way: O-| Royston P2 |-O ------|-TTTT-|->RRR-|-- The "Route" on the right is still set. Imposing a timeout here is a thing only professional engineers can determine, not an algorithm. O-| Royston P2 |-O <-T---|------|->RRR-|-- The train has left again, while route on the right is still set. So, we have to clear the set route when the train has left the left TC. This does not conflict with call-on routes, because both station tracks are set as "allow call-on"


context:
space:
mode: