Skip to content

Daylength #8397

andythenorth started this conversation in Features
Daylength #8397
Dec 18, 2020 · 7 comments · 13 replies

Daylength is much discussed.

Multiple patches exist. All are believed to have issues. Daylength fundamentally changes time scaling across the game in a way that was never anticipated. It's a design problem, not simply a programming problem.

So this isn't a 'vote here for daylength' discussion, rather it's to try and capture what people want from the game that leads them to the idea of changing daylength.

See also: groundhog year #8384


13 replies

Dec 18, 2020
Collaborator Author

Slow down vehicle progression

Play 1960 trains forever!

For many players, the game seems to progress quickly. A new generation of vehicles appears, so we upgrade and tune our networks. Then just as we finish, boom! A new generation of vehicles appears.

On busy or large maps it can be hard to keep up.

Slower progression of vehicles would make a more relaxing games for some players.

This can be solved in multiple ways, of which daylength is one. Others include using non-real intro dates in newgrf, or ideas like groundhog year #8384

3 replies

I for one find the rate of progression of vehicles in the default timescale overly fast.
Having more new vehicle announcements than can be usefully dealt with soon followed by silence seems a bit odd.

As an aside, reaching the "end" years and having no available vehicles at all for a particular cargo as they have all expired is very annoying.
(I added this just because I got hit by this problem.)

A lot of people (users and GRF authors) are seriously into vehicle realism, endless talk about stats, liveries, etc.
I would imagine that a solution based on non-real dates wouldn't go down so well.


michicc Dec 19, 2020

It should also be noted that many (not all) players that look for this goal still expect that vehicle speed, income, production etc per "real time" to remain the same.


A lot of people (users and GRF authors) are seriously into vehicle realism, endless talk about stats, liveries, etc.
I would imagine that a solution based on non-real dates wouldn't go down so well.

Can only second this!

Dec 18, 2020
Collaborator Author

Building very large networks on very large maps

I don't know if this one is a factor, but do some players just want a slower game so they can build very large networks on very large maps?

2 replies

This seems related to slowing down vehicle progression, unless you were getting at another reason why large networks don't work well with default game speed.


Building a network in a single area and observing it to monitoring it's function and for enjoyment can cause building a second network in another corner of the map bein finished in another, next era where my plan for the network (vehicles, visual nature) breaks. So for me time elapses often to fast. The only way to solve this conflict for me is to use only very small maps (where I wish to use bigger ones).

Dec 18, 2020
Collaborator Author

Reduced rate of town and industry cargo generation

I don't know if this one is a factor, but typical approaches to daylength will cause towns and industry to generate less cargo per month, which some players might find preferable?

Based on

This could alternatively be addressed in newgrf.

1 reply

Scaling town cargo generation to suit player preferences is quite easy and there are patches to do that.

Scaling industry cargo generation is another matter due to the issue of industry NewGRFs and the industry spec.
As far as I am aware there are no implementations of this.
I presume that this could be done within the NewGRF itself to a limited extent but I'm not aware of any that actually support that.

Dec 18, 2020
Collaborator Author

Making realistic simulations of real world transport networks

This one is based on the comment at

0 replies

Daylength fundamentally changes time scaling across the game in a way that was never anticipated. It's a design problem, not simply a programming problem.

A bit of a general comment, but the scaling of the original game is arbitrary and not in any way self-consistent.
Picking a different point in the space of arbitrary parameters, which wasn't previously anticipated, is not necessarily a bad thing.

0 replies

Here's what made me look into changing the daylength: we sometimes play an online game with friends on a persistent server, but people can't usually play at the same time; they log in during work, after, or someone may not even have time to play every day. For that purpose, the game progresses much too quickly. Come back after you've missed a day and you're hopelessly left behind. Even when there's room for everyone and we make sure not to hog all the good spots, you'll be missing out.

So I figure it's about the rate of advancement of technology, income, and growth rate of towns. We just want a slower general pace, with the years progressing considerably slower so that we can log in, build a line, and not come back a day later to massive cities and someone has made an absolute killing on their two oil lines that now have been running for decades. It's not about competitiveness as much as having a bit of fun together, so "balance" in that sense isn't the issue.

I have no clue about the capacities of the engine, code, or other problems. I just wanted to chime in to say what my friends and I are looking for.

2 replies

Of course, if you slow it down a lot and the trains move super slow, that would be quite a drag. So I suppose that could become a problem. You'd still want to see your lines in action and not moving in slow motion.


Here's what made me look into changing the daylength: we sometimes play an online game with friends on a persistent server, but people can't usually play at the same time

I 120% agree with @Rymdkejsaren1 ! This is exactly I was wanted game pace changing for. I just want same game balance, but I want it to be just slooower. And yet keeping animation smooth.

I wanted to log into server, spend there 1-2 hours after work, and leave it for next day. Or same but on weekly basis.

Good example is a Merge Dragons game, my wife's favorite. And I kind of envy, haha! She grows dragons, sends them to do some tasks. Then dragons get tired and she had to wait until next day.

AFAIK in OpenTTD "time" is represented by different game mechs which acts a bit independently. And the problem is to gather all of them to scale simultaneously.

Anybody knows what is the most recent patch? Is here a full list of mechs which we should alter for such feature (town growth, cargo manufacturing and so on)?


My preferred approach to "daylength" would be separating the "world history calendar" from the "game economy calendar".

A while ago I tried starting a patch that separated these such that you could scale up/down the speed of the "world history calendar" (mainly affecting vehicle types, industry types, and town house types available), while the game economy was changed to run on something resembling the player's wall clock time.
I changed the tick length (100% game speed) so 74 ticks/one day translated to very precisely 2 seconds, meaning one average 30 day month would be 1 minute on the clock. Then went about changing all the economy logic so things like industry production was calculated in "per minute" (i.e. changing "game economy months" to all be 30 days), and budget happening in 12 minute (360 day) increments.

The result would become having two clocks going on. One major issue I bumped into was actually naming things. Those new "economy years" (12 minute increments) need a snappy name that's still easy to understand, but also won't get confused with anything in the "world history calendar" time.
I don't remember exactly where I stopped/gave up, but I don't think it got to a playable state.

5 replies

One obvious issue with this approach is that is fundamentally changes the presentation of the game, and even at a default pace affects the game economy in small ways, since years become 5 or 6 days shorter.


I would enhance, generalize or rephrase this notion to following.

  • A There is a physical progress. It is associated with what we call "time" from one side. And from another site it is associated with some achievements (revenue, towns growth, etc).

    E.g. I have a bus, and it makes $500 a month. So I watch game calendar and see 1st Jan and $0, and then "few moments later" I check it again and observe 1st Feb and $500.

  • B There is an indication of physical progress. And here it goes. Speaking about bus, it could be displayed with many ways:

    • as a single trip (fast game pace) with $600 gross - $100 of running cost
    • as like 100 of trips (slow pace) with same total financial indicators.

And here outcomes two things:

  1. Game balance is configured as a set of rules for physical progress (A)
  2. User experience depends on both A and B + desirable "game pace".

Also another important thing:

  • Cargo unit and metric unit (space cell) are merely ways to indicate physical progress. Those may vary when we adjusting game pace.
    • For fast game pace bus transfers only 40 passengers a month with total distance of 30 cells.
    • For slow game pace bus transfers like 4k passengers with total distance of 3k cells.

So as an idea I propose to

  • collect rules of physical progress using original game settings
  • alter daylength
  • Adjust fares and perhaps towns & cities growth rates
  • profit

@kaomoneus I think that would quickly result in very difficult to understand in-game UI.

But let's run with it. Take my suggestion (since that's what you're replying to) with the separation of calendar and economy. The calendar runs as it does, with days of whatever tick length the player has chosen (default=74).

Then your suggestion would be to have a gigantic lump of additional settings like this?

  • Industries produce cargo every N seconds (default 7, which is actually a rounded display of 256 ticks)
  • Vehicles pay running cost every N seconds (default 60, which is 30 economy days)
  • Lifetime of vehicles is N minutes per designed lifetime in years (default 12)
  • Snowy and desert towns require resource deliveries every N seconds for growth (default 60, and citybuilder game scripts need to be aware of this)
    And a lot more similar to this, I can't list out right now. This all becomes a UI nightmare, which I personally don't think has a place in "vanilla". And all of this could just as well be configured by NewGRF. Pretty much any cost- or production-scaling you can think of is already available as NewGRF.

My opinion is that the best solution is to allow the core game to separate the calendar from the economy time, and let any cost- and production-scaling the player wants be handled by NewGRF and GS. The separation of calendar from economy time is the only thing that isn't possible to handle gracefully in mods, so only that belongs in the core game.


Well, I think I'm a bit out of what you mean by "world history calendar" and "game economy calendar". Could you please explain on some simple example?


World history calendar:

  • Introduction and obsolescence of vehicle models
  • Introduction and obsolescence of industry types
  • Introduction and obsolescence of town building types
  • Introduction and obsolescence of rail, road, and bridge types
    By changing the number of ticks a world history day takes you can speed up and slow down the pace of technological change in the world. This affects how much time you can spend in each "era" of the game.

Economy calendar:

  • How often industries produce cargo
  • How often running costs are paid
  • How often loan interest is paid
  • How often industries change production rate and how long they can stay without service before shutting down
  • How fast the reliability of vehicles deteriorate
  • How long vehicles can stay in service before they need replacement
  • How fast towns grow
  • How often towns in desert and snow regions need deliveries of special cargo to be able to grow
  • Many more things...
    All of these affect the economical balance of the gameplay, such as how many vehicles you need and the optimal length of routes. Some are roughly equivalent to scaling costs, while others don't have an obvious cost scaling.

My suggestion is decoupling those two concepts such that the economy calender runs on "real time" where everything is measured in minutes and seconds, instead of months and days.
The items in the world history calendar list can't really be changed by modding, without making the year scale look wrong. For that reason, the scale of those things should be changed by the core game, by simply making days longer or shorter (more or fewer ticks per world calendar day).
The items in the economy calendar list can all to some degree be changed by mods and difficulty settings. They don't need any more core game support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
9 participants