#TimeTabel
Options can be great, but they introduce dilemmas. Me and some classmates got permission to take Palaeobiology with credit towards our life sciences degrees in 2019. This forced me to take advanced cancer genetics with no proper cancer modules, because everything else had a timetabel clash.
1) Students tell us that they like choice and a broad range of options (including true interdisciplinarity) in their programmes of study.

2) Students tell us that they sometimes find it difficult to navigate options because the systems we use for this are confusing.

1/x
April 24, 2026 at 10:21 AM
#TimeTabel #Actionplanning
stichting-s4r.nl/agenda/demon...
@stichting-s4r.nl 👉📲 stichting-s4r.nl

🪧 12:30-14:30 #uur demostratie op het Anna van Buerenplein
📃 13.30 # uur aanbieden manifest aan Tweede Kamer
✈️ 16:30- 21:30 #uur commissiedebat Tweede Kamer over Schiphol
Demonstratie 👋 nachtvluchten
Het is zeer belangrijk om ons als burgers te laten zien en onze belangen rond gezondheid en leefomgeving op de agenda te houden. Daarom gaan we 19 mei naar Den Haag voor een demonstratie en het…
stichting-s4r.nl
May 19, 2026 at 6:17 AM
Timetabel Wischfest #wischfest #metal #festivals
June 27, 2025 at 4:50 PM
OpenTTD Development • Re: JGR's Patch Pack
Hey JGR, [del]since the last update,[/del ] I only noticed the “dispatch slot” issue when loading an older save game. It seems to have been missing for quite some time. I would still like to have it back. Otherwise, I would have to make a lot of adjustments to all my old games. I miss the option to select “Dispatch Slot” for train orders. Selecting “Dispatch Slot” helps me send trains to the depot for cleaning after one day of circulation. I think the “Timetabel state” is very good. Is it possible to set the maximum speed of the train here? For example, reduce the current maximum speed by 10% or 20% (also observe speed limits indicated by signals). Is it possible to create a +1 day option here? If I select a time => 2329, and a vehicle arrives (due to a delay) at 0012, then this rule no longer applies. Changes at the end of the day (freight trains often run overnight and can then use passenger routes) cause difficulties. It would be sufficient to be able to set a range between two times (=> <= 2329 - 0300). Is there a chance for my second patch "progsignals_use_lateness_counter" to be reviewed or integrated? I still miss this feature. But if “Timetable state” were to include signal-dependent speed reduction, that would also be sufficient. Regards Mike Statistics: Posted by OTTD0143 — 27 Feb 2026 08:12 * * *
www.tt-forums.net
February 27, 2026 at 3:07 PM
OpenTTD Development • Re: JGR's Patch Pack
Hey JGR, [del]since the last update,[/del ] I only noticed the “dispatch slot” issue when loading an older save game. It seems to have been missing for quite some time. I would still like to have it back. Otherwise, I would have to make a lot of adjustments to all my old games. I miss the option to select “Dispatch Slot” for train orders. Selecting “Dispatch Slot” helps me send trains to the depot for cleaning after one day of circulation. I think the “Timetabel state” is very good. Is it possible to set the maximum speed of the train here? For example, reduce the current maximum speed by 10% or 20% (also observe speed limits indicated by signals). Is it possible to create a +1 day option here? If I select a time => 2329, and a vehicle arrives (due to a delay) at 0012, then this rule no longer applies. Changes at the end of the day (freight trains often run overnight and can then use passenger routes) cause difficulties. It would be sufficient to be able to set a range between two times (=> <= 2329 - 0300). Is there a chance for my second patch "progsignals_use_lateness_counter" to be reviewed or integrated? I still miss this feature. But if “Timetable state” were to include signal-dependent speed reduction, that would also be sufficient. Regards Mike Statistics: Posted by OTTD0143 — 27 Feb 2026 08:12 * * *
www.tt-forums.net
February 27, 2026 at 12:35 PM
OpenTTD Development • Re: JGR's Patch Pack
> > 1) Would it be possible to include Timetabel state (delays) in the programmable signals for train status? Or perhaps elsewhere? For example: if the train is on time, then the speed should be reduced. I always build in timetable buffers, and if the train is on time, then it can certainly travel slower. > > https://youtu.be/ZYwUzPKvif4 Here is the PR : https://github.com/JGRennison/OpenTTD-patches/pull/957 Motivation / Problem There is currently no way to determine whether a train is early or late when it arrives at a programmable signal. This would be useful to give priority to late trains over early ones. Description This patch adds a condition based on the vehicle’s lateness counter (in ticks) to the signal conditions. The lateness value can be positive (late) or negative (early). Limitations The lateness counter is not recalculated when the train reaches the signal. You may add waypoints before the signal to obtain a more accurate lateness value. It is also very unlikely for a vehicle to have a lateness counter exactly equal to zero. Therefore, you may want to add a small tolerance in your tests (e.g., 74 ticks for 1 day). Currently, the feature only works with and displays values in ticks. It could be useful to allow specifying days instead of ticks, but with the daylength factor applied, 1 day may be too large an interval for practical lateness checks. Statistics: Posted by MagicBuzz — 05 Jan 2026 18:42 * * *
www.tt-forums.net
January 5, 2026 at 6:56 PM
OpenTTD Development • Re: JGR's Patch Pack
> 1) Would it be possible to include Timetabel state (delays) in the programmable signals for train status? Or perhaps elsewhere? For example: if the train is on time, then the speed should be reduced. I always build in timetable buffers, and if the train is on time, then it can certainly travel slower. Here you can find a branch including my patch (better town placement) and your request (lateness counter in the programmable signals). This is a prototype as it should be improved : - lateness threesold to avoid being late of early for 1 tick - display and type lateness in ticks or days regarding the timetable setting (currently only in ticks: default 1 day = 74 ticks) - use %age of the current order or course time (might be better than absolute lateness counter) https://youtu.be/ZYwUzPKvif4 (sorry, I'm not familiar with PBS nor speed restrictions... and I always use automatic and auto-separation timetables rather than scheduled timestables, so it didn't work at the first attempt on the video ). Source code: https://github.com/SylvainDevidal/JGRPP ... e_lateness I will definitely use this patch, but not in the way you described it. I would use it to give long reservation for late trains : this will reduce the number of stops during the course, and help them getting back on schedule. Statistics: Posted by MagicBuzz — 30 Dec 2025 15:41 * * *
www.tt-forums.net
December 30, 2025 at 5:06 PM
OpenTTD Development • Re: JGR's Patch Pack
> Hey JGR, > > I have two requests. > > 1) Would it be possible to include Timetabel state (delays) in the programmable signals for train status? Or perhaps elsewhere? For example: if the train is on time, then the speed should be reduced. I always build in timetable buffers, and if the train is on time, then it can certainly travel slower. > > 2) Is it possible to record travel times at the push of a button? On single-track lines, recording them by Autofill (values from the next journey) the route is quite difficult with heavy traffic. > > > Thank you for the great work. > > Now all that's missing is Realistic Train Shunting. But as I understand it, this is rather complex and therefore won't be included in the patch pack in the near future. > > Regards Mike On 1, it only really makes sense to make decisions based on the lateness/earliness at timing points. This sort of scheme sounds overly fragile and labour-intensive to me. On 2, use automate instead of autofill. > Hello, > > I have a suggestion too > > Better town placement : viewtopic.php?t=92587 > > > https://github.com/SylvainDevidal/JGRPP-patches > > Currently testing it, and it looks like to work fine > > Standard (option disabled) : > > Capture d'écran 2025-12-25 234904.png > > We notice some towns are on mountain peaks, and they are not near rivers or coastline. > > Default (option enabled with default radius - 5) : > > Capture d'écran 2025-12-25 235114.png > > We don't have towns on peaks, and town near the sea or river as sticked to it. > > Maximum radius (25) : > > Capture d'écran 2025-12-25 235219.png > > Town are not on mountains at all, and most of them are besinde rivers or sea. > > I tried with a big map and hundreds of cities, it take a bit more time to generate the world, but not much. I don't have an issue in principle with this sort of thing. In your code, handling the edges of the map is not done correctly, and there are other technical and code style issues, but these are resolvable. The performance cost could also be reduced without too much difficulty. Statistics: Posted by JGR — 25 Dec 2025 23:58 * * *
www.tt-forums.net
December 26, 2025 at 1:47 AM