[GS] Peaks and Troughs - 24h Timetabling
Posted: 10 Nov 2020 20:48
One of the newest features in JGR that allows gamescripts to make use of the time of day. As such, I present:
Peaks and Troughs GS
In normal OpenTTD, the time does not actually matter, and a certain frequency at a certain time is either always enough, or never enough. Scheduled dispatch allows for 24h timetabling, but there is no reason to.
In real life, we have peak hours, which create a much more complicated logistic problem. Of course, how this travel demand varies throughout the day depends a lot on the culture. Here in the Netherlands, people do not take a train earlier or later than the one that lets them be exactly on time, creating a hyper peak, but when you leave work isn't that important. Elsewhere, like the Swiss S-Bahn, the evening and the morning peak are both a bit wider, and the same height, they have two roughly equal peaks. In Japan, being early is frowned upon, as is leaving earlier from work than your manager, and working hours are less flexible than elsewhere. This creates both a massive morning peak, and an extremely wide and low evening peak.
In this gamescript I tried to roughly recreate this relationship between time and travel demand using 3 presets. None of these 3 presets should generate more passengers than other presets.
See here the demand graphs: This gamescript adds a logistic challenge that is nothing like you've ever seen before, makes 24 hour timetabling imperative, and finally gives you a reason to create a railyard or overnight bus storage.
This gamescript requires JGRpp version 0.39.0 or newer.
I want to thank JGR for taking my request for time-based travel demand, and turning it into a few simple gamescript functions, so I can make it a lot more than an internal feature ever would've.
Changing the amount of ticks per minute will slow down or speed up changes, and thus lengthen or shorten peaks. Changing the daylength does not affect these changes.
License: GPLv2
Credits
Author: Erato
New GSDate functions: JGR
Data:
- Hyperpeaks: 2015 Nederlandse Spoorwegen - NS
- Equal peaks: 2010 Zürcher Verkehrsverbund - ZVV
- Japan: 2015 Ministry of Land, Infrastructure, Transport and Tourism
Made using Minimal GS.
Minimal GS author: Zuu
Gameplay notes.
There is not a lot that can be changed within this gamescript to fix issues pertaining to station rating. That has to be done with a NewGRF. Should a poor station rating reduce the morning peak significantly or make night freight impossible, then a NewGRF will have to be doctored to make station rating drop more slowly. Maybe fixing it at 100% works well enough. There's a NewGRF for that here:
viewtopic.php?p=1228729#p1228729
Let me know if this plays better or worse.
From testing it has been found that running this gamescript on existing savefiles will give very unsatisfactory results. It is important that all passengers will be transported, for example using peak services, as they will wait for multiple hours or even days. This may sometimes stretch the peaks.
The server I playtest this on has 148 ticks per minute, which is twice default, this makes the peaks a nice length and allows for a large amount of peak vehicles to transport everyone.
Further testing is still required.
Peaks and Troughs GS
In normal OpenTTD, the time does not actually matter, and a certain frequency at a certain time is either always enough, or never enough. Scheduled dispatch allows for 24h timetabling, but there is no reason to.
In real life, we have peak hours, which create a much more complicated logistic problem. Of course, how this travel demand varies throughout the day depends a lot on the culture. Here in the Netherlands, people do not take a train earlier or later than the one that lets them be exactly on time, creating a hyper peak, but when you leave work isn't that important. Elsewhere, like the Swiss S-Bahn, the evening and the morning peak are both a bit wider, and the same height, they have two roughly equal peaks. In Japan, being early is frowned upon, as is leaving earlier from work than your manager, and working hours are less flexible than elsewhere. This creates both a massive morning peak, and an extremely wide and low evening peak.
In this gamescript I tried to roughly recreate this relationship between time and travel demand using 3 presets. None of these 3 presets should generate more passengers than other presets.
See here the demand graphs: This gamescript adds a logistic challenge that is nothing like you've ever seen before, makes 24 hour timetabling imperative, and finally gives you a reason to create a railyard or overnight bus storage.
This gamescript requires JGRpp version 0.39.0 or newer.
I want to thank JGR for taking my request for time-based travel demand, and turning it into a few simple gamescript functions, so I can make it a lot more than an internal feature ever would've.
Changing the amount of ticks per minute will slow down or speed up changes, and thus lengthen or shorten peaks. Changing the daylength does not affect these changes.
License: GPLv2
Credits
Author: Erato
New GSDate functions: JGR
Data:
- Hyperpeaks: 2015 Nederlandse Spoorwegen - NS
- Equal peaks: 2010 Zürcher Verkehrsverbund - ZVV
- Japan: 2015 Ministry of Land, Infrastructure, Transport and Tourism
Made using Minimal GS.
Minimal GS author: Zuu
Gameplay notes.
There is not a lot that can be changed within this gamescript to fix issues pertaining to station rating. That has to be done with a NewGRF. Should a poor station rating reduce the morning peak significantly or make night freight impossible, then a NewGRF will have to be doctored to make station rating drop more slowly. Maybe fixing it at 100% works well enough. There's a NewGRF for that here:
viewtopic.php?p=1228729#p1228729
Let me know if this plays better or worse.
From testing it has been found that running this gamescript on existing savefiles will give very unsatisfactory results. It is important that all passengers will be transported, for example using peak services, as they will wait for multiple hours or even days. This may sometimes stretch the peaks.
The server I playtest this on has 148 ticks per minute, which is twice default, this makes the peaks a nice length and allows for a large amount of peak vehicles to transport everyone.
Further testing is still required.