This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
dev:proposals:new-ks [2022-02-10 16:54] ywang [Example] formatting |
dev:proposals:new-ks [2023-03-26 10:10] (current) ywang |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== Proposal: Distant signaling ====== | + | ====== Implementation: |
- | // | + | //Please refer to the source code for implementation details and API documentation. This information is provided here. The filenames provided below are relative to '' |
+ | |||
+ | * The distant signaling API is implemented in '' | ||
+ | * Formspecs have been partially modified to support distant signaling. Some formspecs are now implemented in various '' | ||
+ | * Signal aspect accessors have been modified and are now found in '' | ||
+ | * A signal aspect API is introduced. This allows manipulating signal aspect objects (implemented using tables) and creating signal aspect groups, the latter of which makes it possible to create route signals. The relevant code can be found in '' | ||
+ | * A '' | ||
+ | |||
+ | **The changes break a few minor things:** | ||
+ | |||
+ | * The signal aspect formspec uses dropdown indexing, which requires Minetest 5.4.0 or later. | ||
+ | * '' | ||
+ | * The results are cached. | ||
+ | * The signal aspect is " | ||
+ | * '' | ||
+ | * There is no API for setting the signal aspect while bypassing the cache and signal aspect adjustments, | ||
+ | * '' | ||
+ | * When setting a field of the signal aspect object to '' | ||
+ | * Certain features of signal aspect objects are implemented using metatables. These objects are therefore not suitable for serialization, | ||
+ | |||
+ | It is planned to merge the newly introduced signal aspect cache with its counterpart in the routesetting system. | ||
+ | |||
+ | Please refer to the source code (listed above) for details. | ||
+ | ====== Proposal: Distant signaling | ||
+ | //This draft has been superseded. Please refer to the actual | ||
+ | |||
+ | //This draft is mainly written to address the issues that appeared in the first draft. In particular, it addresses a request to implement route signaling.// | ||
+ | |||
+ | ===== Distant signal assignment ===== | ||
+ | ==== Manual signal assignment ==== | ||
+ | Distant signals may be assigned to any signal. These distant signals are automatically set with the signals they are assigned to. | ||
+ | |||
+ | ==== Automatic signal assignment ==== | ||
+ | With automatic distant signal assignment, the user needs to assign distant signals to TCBs. A TCB may have multiple distant signals assigned to it. For combined main/ | ||
+ | |||
+ | These distant signals are then assigned to main signals when needed and unassigned when the aspect of the distant signal become irrelevant to rail operation. Specifically: | ||
+ | * When a route is set, the distant signals along the route are assigned to the upcoming signal (i.e. the signal first signal a train should encounter after passing the TCB). These distant signals are then set correspondingly. | ||
+ | * When a train leaves a TCB, the distant signal, if assigned to another signal, is unassigned. This should, at least theoretically, | ||
+ | |||
+ | ===== Setting distant signals ===== | ||
+ | * When a signal aspect is set, the distant signals are set correspondingly. | ||
+ | * When a distant signal is unassigned, its distant aspect is set to '' | ||
+ | |||
+ | ===== API Changes ===== | ||
+ | The functions are given as indices of the '' | ||
+ | |||
+ | ==== Signal aspect table ==== | ||
+ | * The '' | ||
+ | * The '' | ||
+ | * The '' | ||
+ | * The '' | ||
+ | * The '' | ||
+ | |||
+ | ==== Distant signal assignment ==== | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | ==== Setting signal aspect ==== | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | ==== Alternative signal aspect table ==== | ||
+ | The alternative signal aspect table is mainly intended for route signaling. | ||
+ | |||
+ | === Supported aspects === | ||
+ | The table of supported aspects should include the following fields: | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | When registering, | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | Each main aspect entry should contain the following fields: | ||
+ | * '' | ||
+ | * '' | ||
+ | |||
+ | The last entry in the list of supported aspects should have the '' | ||
+ | |||
+ | === Signal aspect translation === | ||
+ | * When a distant signal defined with the alternative signal aspect definition table is assigned to a signal that is not defined with the same signal aspect table, the distant signal is always given the //n-1//th entry (with //n// being the number of defined main aspects of the distant signal) unless the main aspect of the upcoming signal is -1, in which case the distant signal is given the first entry of the defined main aspects of the distant signal, or an entry in the translation table can be used to determine the distant signal aspect. | ||
+ | * When a distant signal defined with the current signal aspect definition table is assigned to a signal defined with the alternative current signal aspect definition table, the '' | ||
+ | |||
+ | ====== Proposal: Distant signaling (first draft) ====== | ||
+ | //This draft has been superseded.// | ||
In this proposal, error situations do not need to be detected unless it is explicitly stated that the error is signaled. | In this proposal, error situations do not need to be detected unless it is explicitly stated that the error is signaled. |