8 Years of OpenTTD Scheduled Dispatch

It all started with this git commit..

Actually no, it doesn’t. It started before that.

And there is also 4 months to go before the 8^th year mark.

The History

There are one thing I love to see in a transport network, and that’s a perfectly timed things. Whether that’s a timed overtake of faster train, to the efficient usage of passing loop on a single-track line.

This was technically possible in the regular OpenTTD, but it would be an extremely painful thing to do¹ and not really feasible to operate on a larger scale. Not to mention quite fragile.

I think that there was a seperated patch that try to fix this problem by forcing clock-face timetable on everything, but I think they try to do too much and make thing very complicated, let alone not being backward compatible. So that patch kinda faded into the abyss.

That was when I seriously started thinking of how to efficiently implement this feature in OpenTTD, and came up with the idea of Scheduled Dispatch. In the basic term, the first version of the Scheduled Dispatch was basically just a mechanism to, once a vehicle/train reach its first order, delay its departure until a specific in-game time/date. This sounded like a very simple idea that should be effective, so I went on to implement.

It took me just about a week or so to finish the patch in its first form. I know I didn’t have a chance for merging into vanilla, but JGR graciously agreed to include my patch into his patch pack, despite him saying that he probably won’t use it.

The Feature

Despite being nearly 8 year ago, the first revision of Scheduled Dispatch has most feature that exist today (in additional to the core feature of scheduling dispatch):

• Delay: Allow train that arrive late past their intended scheduled departure to depart immediately if it’s within a delay that is set by the user.
• Schedule duration: Set the length of the schedule loop. Allow that is usually called “1-hour schedule” and “24-hour schedule.”
• Number of vehicle calculation: Automated calculation of the required number of vehicles.
• “Reset dispatch”: to reset the internal state of the dispatcher in case things gone weird.

Further Development

Unfortunately, about half a year after the patch went public, I kinda stopped playing OpenTTD for a while. it was years later that I came back and discovered that the Scheduled Dispatch has grown way larger than I could even imagine.

The biggest improvements are implemented by JGR: multiple dispatch schedules that can be assigned to any schedule (an elegant solution that I could not come up with at the beginning) and integration with conditional order and routefinding restriction that allow even more advanced train movement.

Since JGR said that he didn’t play with Scheduled Dispatch, I asked him about the improvements. He said that there are some private communities that use Scheduled Dispatch in a big way and request those features.

I never expect Scheduled Dispatch to get this big.It was just something I worked on to satisfied my needs, and the primary reason I submitted the patch was so that I don’t have to maintain my own changes. I expect a few people may enjoy them, but not at this level.

In fact, I didn’t even think a lot about the name. Scheduled Dispatch make sense for me, and maybe for other, but the name, IMO, sounds intimidating. If I knew it would get this big maybe I would have spent more time thinking of a better name.

I love that people love it, use it, and abuse it. I love that people claim that OpenTTD JGR Patch Pack is the only game that allow you to fully model realistic train system. But I don’t think I can really lay claim to Scheduled Dispatch, for I have not touched it for years and the community and JGR has make it into a great major feature, far beyond my wildest imagination.

But still… Can I be proud of it?