Repeat game years aka Not Daylength

[Tafidis]

Happy New Year all,

been lurking for a while (some years), thought I 'd have another go at patching openttd, just 'cause .

One of the features I had been missing when I was playing (still do, although very rarely) was the ability to scale the rate at which game years pass. Commonly known as daylength. While many discussions and patches have tried to address this (too bored now to find all the old discussion threads), at the end of it all it boils down to two motivations:

• Game years fly by so fast (so much like real years - goodbye 2017 ). No time to build a steam empire, especially in larger maps player cannot connect all towns before game becomes futuristic
• Would like station rating to decay slower, towns/industries to produce less (esp with cargodist on), so that I can really connect tiny towns with buses/smal DMU/EMU on single rail without suffering in station rating.

This patch (r27955) only addresses the first motivation, in very simple way: in advanced settings -> environment, you find the new setting "Number of year repetitions". Here you set how many times each year will be repeated. Zero (default) means no repetitions (default trunk behaviour). If set to a positive integer value, then each year will be repeated that number of times. Repeating simply means that after 31st December XXXX it is again 1st January XXXX. Nothing else is touched, except that you see the number of repetitions currently set and how many have already taken place in the status bar (see screenshot).

The advantage of this method is that it does not touch any game mechanics and should work fine with all GRFs and in combination with other patches (both not tested). It recycles the code used for when the game reaches the hard-coded maximum year 5000, when it simple wraps around forever. It is possible to combine this patch with a solution for the second motivation above, either a Station/Town/Vehicle GRF combo that reduces production and makes station rating much less sensitive to days_since_last_pickup, or a separate patch, if needed.

The setting can be changed within a game, so you can slow down during historical periods of your interest and still speed up again when your network has been laid out and you do not want to wait forever till new engines become available.

Obviously, N repetitions corresponds to a "daylength factor" of N+1. I.e. 1 repetitions of each year will make the game last twice as long.

Current status: alpha
Setting flags: not saved in savegame, can be changed within game, synced with server (untested)

Known glitches:

• Graphs are not touched. The current game year is correctly shown. Previous repetitions of the current game year appear as previous years.
• Finances window shows current year correctly. Previous repetitions of the same year appear as previous years. Previous repetitions of the first game year are not shown at all, only current repetition.

known side-effects:

• Stuff like age of vehicles proceeds normally, that is, setting 3 repetitions per year means that a train bought in 01.01.1930 (original game year) will be 8 years old come 01.01.1932 (since 1930 and 1931 will each have run 4 times). This is actually wanted, me thinks.
• Of course, servicing the industries/towns for a longer time causes production/size growth. This can lead to a situation where the amount of produced cargo exceeds the capacities offered by vehicles available in that (game) time frame. Amend this using vehicle/industry sets that offer larger capacities.

untested side-effects:

• Do I need to say it? Inflation OFF!
• Have not tested this, but do not know what happens if an engine becomes available within the year and then that year repeats, or how engine reliability curve is affected. Probably it works as expected, but not tested.

Before I created the patch, I tried a gamescript approach. Reason was that it is much easier for people to install a gamescript and test/try this, while patching requires compilation, which is hard for most. My plan was to use the change date cheat from within my script. Unfortunately, gamescripts cannot cheat . The script went as far as creating a sign every new year. I was overjoyed. Then I realized it is not possible to cheat via signs (now I wonder was it ever possible? Or was it only in TTDPatch?).

I have also considered implementing the patch as a cheat, i.e. only make it possible to set the number of repetitions via the Cheat GUI. In essence, the patch is equivalent to calling the "set date" cheat automatically each New Years!

I have not submitted the patch for trunk inclusion (obviously), but only to stir discussion and perhaps more development in this area. I would like to hear thoughts and ideas

[Alberth]

should work fine with all GRFs and in combination with other patches (both not tested). It recycles the code used for when the game reaches the hard-coded maximum year 5000, when it simple wraps around forever.

The end year is not 5000, it's 5,000,000. That's makes wrapping a very academic case, as likely nobody ever considered that year. I once checked how long you have to play OpenTTD to reach that year, and it's longer than a life time.

So I think it's safe to say that no GRF ever considers the possibility of the same year appearing again. I would expect that that some GRFs do date computations, leading to negative ages, which they likely don't expect to happen. Obviously, many GRFs are not that advanced, and will work to some extent.


Personally, I still believe the simpler solution is to make a GRF that introduces new models at a slower rate, and extends life times. The only problem is then that the year displayed is bot a normal earth year any more, but one of the alternative earth, where steam era lasted to the 2200s before new technologies were introduced.

Another idea I had was to make a "steam forever" GRF, where you have many more models, from 1850 or so right up to 3000 or some other year far away. Improvements would be slower likely.
If you make a similar GRFs for diesel, electric, mono, and/or maglev, and add parameters of the start and end years, a user can decide when each type of engine is available in his game.

[andythenorth]

A long time ago, Eddi gave me a similar patch for repeating years, the concept does work surprisingly well

[acs121]

If you want to have towns producing less cargo, there is already a patch for that (included in JGR's patchpack).

[Eddi]

A long time ago, Eddi gave me a similar patch for repeating years, the concept does work surprisingly well

are you sure that was me?

anyway, the repeating year used to be 2070, so it probably works, but that generally was after anything grf-related was finished, so repeating in-between years may still cause unexpected behaviours.

[Tafidis]

Thanks for the replies. Few points:

• Suspension of disbelief
  

  The only problem is then that the year displayed is bot a normal earth year any more, but one of the alternative earth, where steam era lasted to the 2200s before new technologies were introduced.

  Exactly. By that logic, it is enough to play with "vehicles never expire" and simply not upgrade to diesel until 2100, electric until 2200, etc. Imagining the alternative earth is (for me at least) more of a stretch than not upgrading.
  
  Another idea (not mine, but cannot remember whose) is that of a GUI date. This idea fits well with Alberth's suggestion as well as with year repetition. The GUI date exists only for display purposes. This is unfortunately quite extensive work, if one wants to include not only status bar, but also graph legends (not straightforward to even find proper names for all the time units - i.e. "years" could be "months" at 12x, but what could they be e.g. at 8x?), and even drop-downs ("sort trains by profit last 13-day period" - lol).
• flexibility
  To my knowledge, all daylength patches so far had to fix the daylength factor at the beginning of the game. Not the case here, as noted in the first post.
• scalability
  (at least some) daylength approaches encounter rounding errors at large daylength factors. Not the case here. Simply repeat the year as many times as you like!
• plausibility of approach

  I would expect that that some GRFs do date computations, leading to negative ages, which they likely don't expect to happen. Obviously, many GRFs are not that advanced, and will work to some extent.

  Although I buy the argument on its face, could you (or anyone, if and when you got time) provide a concrete example of such a GRF date computation, so that I can download said GRF and see if/how it breaks?

[Alberth]

Sorry, but I can't. GRF is not a language that I understand, so I couldn't even tell you how to do it in GRF, it's all magic for me.

[Gwyd]

Although I buy the argument on its face, could you (or anyone, if and when you got time) provide a concrete example of such a GRF date computation, so that I can download said GRF and see if/how it breaks?

A couple of things I've tried with NewGRFs have had reference to the date. GRFs like UKRS2 has train liveries changing by date. I once made a GRF where a train got dirtier by age. I think these will still work, but not entirely as intended.

[Tafidis]

Hello again. Here is a new version.

Features:

• Introduced a GUI date to the status bar, which proceeds slower than the normal trunk date. The GUI date is accompanied by a 24h clock. Smallest time unit is now a quarter of an hour.
• The GUI date updates on each new trunk day only. You will only see times like 12:30 or 12:45 only at large-ish numbers of repetitions (e.g. >23)
• Clicking on the date itself toggles between the GUI date and the normal date accompanied by the number of repetitions set and the current repetition number (e.g. 3/7)
• If the repetitions are set to 0, the date and the status bar reset to their default behaviour

I also did some digging, in order to give credit where it is due. Arie posted the idea of repeating game months in this thread. Fonso proposed a GUI date in this one.

Some concerns about breaking gamescripts that use ticks to measure how long they have been running for are voiced in the first thread.

I also played around a little bit and noticed the following:

• Vehicles remain in their "trial" period for N trunk years. Newspaper article that announces their official introduction feels funny when you have been using them for that long
• I think not saving the setting is the way to go. I like the fact that I can load any of my trunk savegames and be able to micromanage things, especially when dealing with larger, full maps with cargodist and all towns connected in a congested network. Now I can take my time and clear all those passenger queues and then speed up again (of course, it is all just an illusion )

[Rasto12]

Could somebody upload a compiled version with this patch included (win64)? Thank you so much.