More suggestions about gameyears.

[Dave]

I've been reading, with much interest, the game years discussions in the two threads here and here.

I appreciate the points offered by all parties in most of these threads but, unless I have misinterpreted or neglected to read properly, I saw no mention of simply changing the year displayed while still keeping the same time, etc.

As an example, I'm currently working on a few ideas that would require the game to start around 2221, or similar. So:

1921 becomes 2221, and thus 1922 becomes 2222, 1923 becomes 2223 and so on.

I have no desire in lengthening the amount of time that one can play, nor am I attempting to change the year that one starts in, since I want to be able to have vehicles introduced during the time and, as I understand it, vehicle introductions only occur up to 2044 (?).

So I'm wondering, would changing the year that is DISPLAYED in all areas, introduction dates in vehicle windows, etc, be able to be changed merely by a bit of .grf wizardry? Or would it require patchwork/selling my dog?

[DaleStan]

Changing the displayed value would probably be more tedious than hard; it would be a relatively simple (but still horribly tedious) matter of changing every instance of 1920. (There appear to be 14 such instances in TTD's code, and another 17 in TTDPatch.)
It's the side effects that would be a problem. If only to the display is changed, then internally, all dates are still 1920-based. Meaning that vehicles that are coded to be introduced in e.g. 1935 would get introduced in 2035 or 2235 instead.

[PikkaBird]

It's the side effects that would be a problem. If only to the display is changed, then internally, all dates are still 1920-based. Meaning that vehicles that are coded to be introduced in e.g. 1935 would get introduced in 2035 or 2235 instead.

Call me silly, but I think that's what Dave is asking for?

[DaleStan]

If Dave's controlling everything, then it's not an issue, but Ford Model Ts appearing 2222, or whenever it is, might cause a little confusion. Like variables 9E and 9F, this would probably be a write-only variable, so GRFs would just have to hope that their settings stayed put.

Since is the more I think about this, the more I do NOT want to think about how much bookkeeping would be required to keep as many as 31 different immediate constants properly synced. Though actually, two of those could possibly be ignored, if it were decided that the long introduction date properties should also be affected by changes to the baseline date.

EDIT: Got it backwards the first time around. If long and short introduction dates are both affected the same way, then two of the constants could be ignored.

[Dave]

Comments appreciated. Basically what I was going for was an(other) attempt at the long-mooted "Future Set". Since it'd be an entire replacement for Toyland, including all vehicles etc, it shouldn't matter in the first example you gave, but like you say - since its a big thing to have to maintain, I appreciate your viewpoint.

Thanks for the input.

[WWTBAM]

...and if it were a switch that was off by default, then it would be the users job to make sure everything was replaced or that the switch was off. But the other stuff is all fine by me.

[DaleStan]

Having studied this for a while, I see two options:
1) Change the display only. Internally, and in NFO, everything still runs on the standard 1920..2070/1920..2175/&c. timelines.
2) Change the display and the long intro dates. Internally, and in NFO, everything still runs on the standard 1920..2070/1920..2175/&c. timelines, but the long intro dates stay true to the displayed date, not the internal date.

Thoughts?

[Dave]

This would be perfect - would this seriously reduce the amount of work needed? How would it be done, etc?

[DaleStan]

Either a switch in ttdpatch.cfg, or a new property for action 0 feature 08.

I'm leaning towards newgrf, since that makes it possible to unload it in-game, but it also makes it harder to adjust long intro dates as proposed in the second option.

[Dave]

Forgive me for being so tiringly inquisitive, DaleStan, but I'm quite interested in this. By Long Intro Dates I assume you mean the dates in which vehicles are introduced right down to the day and month? I seem to recall Pikka's set has the ability to randomly introduce the vehicle 6 months either side of the actual intro date, which itself may also vary from game to game. I assume you mean something like this.

How often are the long dates used other than when the game is paused? There are also displays in the vehicle's info window in reference to the last service date, as I remember it. Where else is it displayed?

[DaleStan]

The long intro dates are the dword-sized intro-date properties, in days since 1/1/0. Only vehicles and bridges have them, currently (properties 2A/1F/1A/1A and 0F). Basically without exception, TTDPatch converts them to days-since-1/1/1920, limits them to the appropriate range, and hands them off to TTD.

The word-sized intro dates and byte-sized intro years only have a range of 180 or 255 years, so they have to stay at days-since-base and years-since-base, respectively. The long dates have a range of 11.76 million (10^6) years or so, so anything anyone might ever want can be encoded, regardless of the base. Especially since the TTD date display has a maximum range of a mere 65536 years.

[aahz77]

How often are the long dates used other than when the game is paused?

Quick aside: you can turn it on permanently with ShowFullDate.

[Dave]

The long intro dates are the dword-sized intro-date properties, in days since 1/1/0. Only vehicles and bridges have them, currently (properties 2A/1F/1A/1A and 0F). Basically without exception, TTDPatch converts them to days-since-1/1/1920, limits them to the appropriate range, and hands them off to TTD.

And I take it that this is the part that you feel could be manipulated? Either the "days since 1/1/0", or the "days-since-1/1/1920" conversion by the patch?

The word-sized intro dates and byte-sized intro years only have a range of 180 or 255 years, so they have to stay at days-since-base and years-since-base, respectively. The long dates have a range of 11.76 million (10^6) years or so, so anything anyone might ever want can be encoded, regardless of the base. Especially since the TTD date display has a maximum range of a mere 65536 years.

So the dword-size allows us to basically manipulate any date we want as long as it fits in with these that you referenced to in the above quote?

[DaleStan]

And I take it that this is the part that you feel could be manipulated? Either the "days since 1/1/0", or the "days-since-1/1/1920" conversion by the patch?

The <timeunit>s-since-1920 will all change their meaning to <timeunit>s-since-$BASE, where $BASE is a configurable value. The days-since-0 counters may or may not change their meaning. If they do not, the conversion from since-0 to since-1920 will have to be adjusted so it converts to since-$BASE instead. If they do change their meaning, then they'll change to days-since-($BASE-1920), meaning that the conversion from since-0 to since-1920 will continue to do the right thing, unmodified.

So the dword-size allows us to basically manipulate any date we want as long as it fits in with these that you referenced to in the above quote?

Dword-size lets you specify any date in the 1/1/0 .. 31/12/65535 range that TTDPatch can display, and quite a few dates outside it. Its purpose is to permit Open to have an NFO-functional game time of more than the 130 years available in Patch. (By "NFO-functional" I mean that NFO has its full power, most notably, to control introduction of new vehicles.)

[Prebral]

Isn't something like "allow fake years before 1920" already in TODO list? I have seen it in one version (cca half a year ago) and I have also suggested feature like this some time ago, except not for future but for past, especially for 19th century.

[Dave]

This has nothing to do with that though. This is about manipulating the dates displayed in game to at least allow the appearance of play from any year that the author may desire.

I think I'm getting it now - while I would manipulate the dates using a grf, any vehicles would still need to give the patch an introduction year that resembles the original.

So if I started in, say, 2221, and wanted a train to become available in 2289, I'd still need to put 1989 as the vehicle's introduction date. Correct?

Other than that, I will be keeping a note of this thread for reference. Thank you very much for your help DaleStan.

[DaleStan]

I think I'm getting it now - while I would manipulate the dates using a grf, any vehicles would still need to give the patch an introduction year that resembles the original.

So if I started in, say, 2221, and wanted a train to become available in 2289, I'd still need to put 1989 as the vehicle's introduction date. Correct?

Mostly. You'd set the base year to 2220, and then use an introduction date (prop 00) of "\w01-01-1989", which is "72 62", but would really be interpreted as "6272h (25202) days since 1 January, 2220".
If you used the long intro date (props 2A/1F/1A/1A) instead, you would need to specify 1/1/2289 ("\d836055" or "D7 C1 0C 00"), not 1/1/1989, which would be "\d726482" or "D2 15 0B 00". (This detail is still open for discussion; I like it, but I can be a bit of a masochist at times.)

I might have missed some leap days, especially in the long dates, but the general concept should be obvious, even if the numbers aren't exactly right.

[DaleStan]

Oh, and by the way, what I thought was the "Long format introduction date" for bridges is really the "Long format year of availability". As in, it's years-since-0, not days-since-0.

[Dave]

Once again, thank you for your kind help, Dale.

[DaleStan]

Okaaaay. Making the long-format intro dates stay true to the displayed year while the short intro dates stay true to the intro year causes rather interesting things to happen in GRFs that use the long-intro dates only when the desired date would be out-of-range for short intro dates.

In other words, my idea of "the baseyear adjustment will adjust all dates, except long intro dates" is breaking things in ways I can't permit. That leaves two options, and I haven't yet decided which one I like better:
1) The baseyear adjustment will adjust all dates, except long intro dates in the same GRF as the adjustment.
2) The baseyear adjustment will adjust all dates, period.