Clock
Model Train Script keeps a model clock — a configurable time-of-day that runs at your chosen speed independently of real wall time. Set it to "08:00" running at 6× speed and a full hour passes on your layout every ten real minutes; departures, freight calls, and station scenes can play out at a pace that fits a session rather than reality.
The clock is the time source for everything in automation that cares about hours and minutes:
- Timetables — entries are matched against the model clock.
- Clock conditions in scripts — condition rules that fire after or before a target model time.
- Clock execution events — script triggers that fire when the model clock matches a pattern (e.g.
*:30,09:00).
Setting the clock
Open the Automation tab in the throttle and tap the Clock row at the top of the Status section.
| Setting | Description |
|---|---|
| Start / Pause | Runs or pauses the clock. By default the clock starts running when you load the profile — you can change that under Defaults. |
| Time | The current model time. Tap to pick hour and minute. |
| Speed | A multiplier from 1× (real time) to 10× (ten times faster). |
| Reset to defaults | Resets the clock's current time and speed back to the configured defaults (see below). |
The Clock row in the automation tab also exposes a play / pause icon and a reset icon for quick access — tap them without opening the editor.
Changes take effect immediately. Setting the time rebases the clock so that scripts and timetables see the new value on the very next tick.
WARNING
Nothing tied to the clock will fire while it is paused. Timetables, clock-rule conditions, and clock execution events all rely on the clock advancing. If a schedule isn't starting or a script isn't reacting to a clock event, check that the clock is running.
Defaults
The editor has a collapsible Defaults section that controls how the clock initialises whenever you load the profile (typically at app launch):
| Setting | Description |
|---|---|
| Use real time | When on, the clock starts at the current real-world time. When off, the configured default time is used. |
| Time | The starting time when Use real time is off. |
| Speed | The starting speed multiplier (1×–10×). |
| Running | When on, the clock is running when the profile loads. When off, it loads paused and you start it manually. Defaults to on. |
| Apply now | Applies the configured defaults to the clock immediately. Same effect as the Reset to defaults action. |
Defaults are saved within the active profile.
In the throttle layout
A small chip in the top-right corner of the layout view shows the current model time and speed at a glance — for example 09:42 6×. When the clock is paused the chip dims and shows a small pause icon. Tap the chip to start or pause the clock, the same as toggling Start/Pause from the editor. You can hide the chip from the profile configuration ("Show clock on layout").
Behavior
- Running on launch by default. When the profile loads the clock takes its time, speed, and run state from the defaults — running by default. Toggle Running off in the Defaults section if you want it to load paused.
- Single instance. There is one clock per profile — every script, timetable, and event sees the same model time.
- No background ticking. While running, the clock advances every second by speed model seconds. While paused, it stays at the displayed time.
- Defaults persist. Time and speed values you set on the running clock reset to the configured defaults on the next profile load. The defaults themselves persist with the profile.
Best practices
Start the clock before starting timetables or scripts that listen for clock events. A common mistake: starting a timetable while the clock is paused. The schedule waits forever because no clock events fire.
Set the default time if you want a specific moment. Otherwise the clock starts at the real-world time when you opened the app. Timetables that fire "at 08:00" won't run if the clock is already past 08:00.
Keep speeds modest for predictable scripts. At 10× a minute on the model clock passes in six real seconds — fine for atmospheric scheduling, but tight if a script needs to drive a vehicle through a long block before the next event fires. Match the speed to the slowest action in your busiest schedule.
Use clock conditions for "after this point" gates and execution events for "exactly at this time" triggers. The condition is evaluated when something else asks the script to check; the execution event fires the script because the clock ticked past the pattern.