User Tools

Site Tools


dev:proposals:timetable_plan

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dev:proposals:timetable_plan [2022-06-26 16:07] – ↷ Page moved from dev:lines:timetable_plan to dev:proposals:timetable_plan 56independentdev:proposals:timetable_plan [2026-01-22 20:00] (current) – orwell
Line 3: Line 3:
 The overall plan with the ''lines'' mod is to have a timetable scheduling system which is integrated with the other advtrains functions, especially the stop rails. This is the concept for it. The overall plan with the ''lines'' mod is to have a timetable scheduling system which is integrated with the other advtrains functions, especially the stop rails. This is the concept for it.
  
-This is currently a draft, and subject to discussion before I will start implementing it. **Please bring in your ideas, suggestions or critics.** Just add them under the relevant headline and sign them with your name (use the "signature" button in the editor toolbar)+This is currently a draft, and subject to discussion before I will start implementing it. **Please bring in your ideas, suggestions or criticisms.** Just add them under the relevant headline and sign them with your name (use the "signature" button in the editor toolbar)
  
 ===== Constraints ===== ===== Constraints =====
Line 32: Line 32:
   * some flags (such as "reverse here")   * some flags (such as "reverse here")
  
-//* The stop modes should get better names// --- //[[orwell]] 2021/04/19 22:11//+//* The stop modes should get better names// --- //[[dev:lines:orwell]] 2021/04/19 22:11//
  
 All arrival and departure times in the timetable are **relative** to the initial departure time of any given train. That means, the timetable only defines after how many minutes/seconds after its initial departure at the first location it should be where. All arrival and departure times in the timetable are **relative** to the initial departure time of any given train. That means, the timetable only defines after how many minutes/seconds after its initial departure at the first location it should be where.
Line 61: Line 61:
 ==== Timetable entry ==== ==== Timetable entry ====
  
-//This could use a better name// --- //[[orwell]] 2021/04/19 22:11//+//This could use a better name// --- //[[dev:lines:orwell]] 2021/04/19 22:11//
  
 At the first station in the timetable, trains "enter" the timetable and get timetable instances. For this, the timetable defines a //service interval// by means of two times: At the first station in the timetable, trains "enter" the timetable and get timetable instances. For this, the timetable defines a //service interval// by means of two times:
Line 161: Line 161:
 It would be nice to have a tabbed interface for the timetable UI: this way you could open multiple editors/viewers at once and quickly switch between them to validate the edits. It would be nice to have a tabbed interface for the timetable UI: this way you could open multiple editors/viewers at once and quickly switch between them to validate the edits.
  
-**... to be continued ...**+ 
 +===== Updates 2025/2026 ===== 
 + 
 +In the meantime I have merged the timetable system from Singularis/Cesky Hvozd in an altered form (although not all parts of it work yet. It goes along with a rework of the stop rail. 
 + 
 +The stop rail distinguishes the "timetable" and "non-timetable" situations. It also provisions for actions on departure and arrival, however this is not yet implemented. 
 + 
 +Things NOT implemented by Singularis's system which should be added later: 
 +  * Timetable recording 
 +  * Actions in the timetable (e.g. reverse, join, split, change display) (the same actions should be supported also on stoprail level 
 +  * Initial Departure Time should support intervals like 3/3/4. 
 + 
 +Things to change/fix about Singularis's implementation: 
 +  * Initial departure time / interval should be configured on the timetable, not on the starting stoprail. 
 +  * It should keep track of the existing slots and their trains, to support multiple starting tracks. 
 +  * Make departure times absolute in the timetable display (based on the initial departure time) 
 + 
 +Long-term wishlist: 
 +  * Joining and Splitting support 
 +  * Connecting trains 
 + 
 +==== Plans for a Signalling Simulator like game ==== 
 + 
 +I plan to evolve advtrains into kind of an "ultimate train-game" which unifies a Train Simulator (driving a train), a Signalling Simulator (signalbox panel) and a Railway Building Simulator (Luanti+advtrains, what it is now) into one game, so that in theory all three types of games can be played on the same server in multiplayer. 
 + 
 +This would warrant a separate proposal to be written later, [[dev:proposals:simsig]]. For now just the timetable implications. 
 + 
 +For a Train Simulator/Signalling Simulator mode, timetables cannot be "repeated" like they are currently with the interval property. Or, if they are, at least each "instance" needs a unique identification. However for long-running server this doesn't work so time has to wrap around at some point. 
 + 
 +At the same time currently with RWT we have the problem that the cycle number (then hour number) becomes quite large, which is not pretty. 
 + 
 +Proposed changes on Railway Time: 
 +  * The value in the hour place that is currently named "cycle" shall be named "hour". "cycle" gets a new meaning! 
 +  * Railway time hard-wraps around a globally configured cycle interval. I propose 24 real-life hours. But it should be configurable as server setting. 
 +  * Need to disambiguate between an absolute time and a time interval (relative time) 
 +    * Absolute time can be in string form e.g. 1;30;00 or in table form. It is not allowed in number form, only for backwards compatibility maybe. It is always between 0 and cycleTime 
 +    * Relative time can be in string, number or table form. it can be negative or positive. If it is in string form it must always include a + or a - at the beginning to make it clear that it is a relative time, e.g. +00;10;00, -00;03;30 
 +  * The RWT functions must be aware of this wrapping and calculate accordingly 
 +  * Repeating times are hard-capped at the cycle interval. 
 + 
 +For a short-lived simulator game a timetable can be written for a normal day (24 hours). For a long-lived server the same daily timetable repeats endlessly. For the server usecase we can use the per-timetable intervals to have regular train service as usual in intervals (e.g. every 10 minutes) 
 + 
 +Note: It may still be necessary to introduce some kind of "super cycle counter" if we need to represent times from a different cycle. But to avoid numbers going unnecessarily large, even this one should be capped (maybe at 7 days? 30 days?) 
 + 
 +**Now implemented as follows:** 
 +1 cycle == 1 day (24 hours). Repeating times hard-clip at day boundary. 
 +RWT wraps after 7 days (cycles) 
 + 
 +//It is very important to reiterate: to manipulate railway times one should always use the rwt functions.// 
 + 
 +The only guarantee made is that time intervals (not absolute times) may be safely treated as a number as long as they don't exceed 3 days worth of seconds
dev/proposals/timetable_plan.1656259678.txt.gz · Last modified: by 56independent