Especially in the context of trams, trains need to be aware of:
Players standing on the tracks
Other rail vehicles standing ahead
Trains should brake down and sound their horn when something blocks the tracks, as well as slow down when a rail vehicle is ahead. This behavior needs only to be enabled on certain sections and at low speeds. The current idea is to have signs (using the signal aspect/influence point system - probably using a field in the "info" table of an otherwise neutral signal aspect) to enable/disable this mode.
A system needs to be implemented to efficiently solve these problems.
[imported from Hemiptera http://bugs.linux-forks.de/advtrains/184.html]
Especially in the context of trams, trains need to be aware of:
Players standing on the tracks
Other rail vehicles standing ahead
Trains should brake down and sound their horn when something blocks the tracks, as well as slow down when a rail vehicle is ahead. This behavior needs only to be enabled on certain sections and at low speeds. The current idea is to have signs (using the signal aspect/influence point system - probably using a field in the "info" table of an otherwise neutral signal aspect) to enable/disable this mode.
A system needs to be implemented to efficiently solve these problems.
Rail vehicles ahead
1f3a4c3b introduced some code in the train step that scans for trains on the same track for purposes of collision. This code can be extended so that when in DoS mode, the look-ahead distance is as long as the braking distance. This scenario should (exceptionally) be handled independent of the LZB subsystem because the target point may not be static, as the other rail vehicle can move as well. The overhead here is acceptable as long as only few trains run in DoS mode at a time.
Players on track
Because there are probably much more trains in a world than players, detection should be initiated by players. When a player is near a track, a globalstep should query trains with a path on this track and add appropriate LZB checkpoints.
The LZB subsystem needs to be extended to support "rechecking the validity of a checkpoint" in regular intervals. LZB should call a specified callback every 1-2 seconds to check if the LZB checkpoint is still needed (that is, the player is still on the track) and remove the checkpoint if not. Alternate solutions can also be considered (left up to the implementer)
More thoughts on this:
Rail vehicles ahead
1f3a4c3b introduced some code in the train step that scans for trains on the same track for purposes of collision. This code can be extended so that when in DoS mode, the look-ahead distance is as long as the braking distance. This scenario should (exceptionally) be handled independent of the LZB subsystem because the target point may not be static, as the other rail vehicle can move as well. The overhead here is acceptable as long as only few trains run in DoS mode at a time.
Players on track
Because there are probably much more trains in a world than players, detection should be initiated by players. When a player is near a track, a globalstep should query trains with a path on this track and add appropriate LZB checkpoints.
The LZB subsystem needs to be extended to support "rechecking the validity of a checkpoint" in regular intervals. LZB should call a specified callback every 1-2 seconds to check if the LZB checkpoint is still needed (that is, the player is still on the track) and remove the checkpoint if not. Alternate solutions can also be considered (left up to the implementer)
See also Mailing list discussion from 56i:
https://lists.sr.ht/~gpcf/advtrains-discuss/%3CRuDekSQAdET8Jcd5xuw5Xl_Aa4iATB3lRYZh625qXcihwt-VhMvj2nq48drH7nIDNVnJ3xbXYhWeUjHPEHFyfTs8OrEcVqA1RgtgCcQ0pDA=@protonmail.com%3E
[imported from Hemiptera http://bugs.linux-forks.de/advtrains/184.html]
Especially in the context of trams, trains need to be aware of:
Players standing on the tracks
Other rail vehicles standing ahead
Trains should brake down and sound their horn when something blocks the tracks, as well as slow down when a rail vehicle is ahead. This behavior needs only to be enabled on certain sections and at low speeds. The current idea is to have signs (using the signal aspect/influence point system - probably using a field in the "info" table of an otherwise neutral signal aspect) to enable/disable this mode.
A system needs to be implemented to efficiently solve these problems.
More thoughts on this:
Rail vehicles ahead 1f3a4c3b introduced some code in the train step that scans for trains on the same track for purposes of collision. This code can be extended so that when in DoS mode, the look-ahead distance is as long as the braking distance. This scenario should (exceptionally) be handled independent of the LZB subsystem because the target point may not be static, as the other rail vehicle can move as well. The overhead here is acceptable as long as only few trains run in DoS mode at a time.
Players on track Because there are probably much more trains in a world than players, detection should be initiated by players. When a player is near a track, a globalstep should query trains with a path on this track and add appropriate LZB checkpoints.
The LZB subsystem needs to be extended to support "rechecking the validity of a checkpoint" in regular intervals. LZB should call a specified callback every 1-2 seconds to check if the LZB checkpoint is still needed (that is, the player is still on the track) and remove the checkpoint if not. Alternate solutions can also be considered (left up to the implementer)
See also Mailing list discussion from 56i:
https://lists.sr.ht/~gpcf/advtrains-discuss/%3CRuDekSQAdET8Jcd5xuw5Xl_Aa4iATB3lRYZh625qXcihwt-VhMvj2nq48drH7nIDNVnJ3xbXYhWeUjHPEHFyfTs8OrEcVqA1RgtgCcQ0pDA=@protonmail.com%3E