NADP: Not Another Daylength Patch

[Wolf01]

As the title says, this is not another daylength patch, its target is the same, but with a total different approach.

In substance it is made to "fake" the date, and on this fake date will be based all year introductions and various other things.
As for now the length is fixed: 1 fake year = 4 normal years which means that every normal year is 3 fake months long.
The final version will have this configurable from 1 to 12 where 1 means 1 normal year = 1 fake month and 12 means 1 normal year = 1 fake year (12 months), the values will be 1, 2, 3, 4, 6 and 12 for ease.

This patch is made on suggestions by Alberth, so I must thank him for the idea.
I didn't change the economy, I only faked the date, all is the same as before (you can check the bank balance windows), but I'll change some strings to reflect the multiplier so:
1 = monthly running costs
2 = bimestral running costs
3 = trimestral running costs
and so on to
12 = yearly running costs

Here you can find the patch if you want to give it a try, it's not complete (the day part) and the leap year handling is missing.
Don't pay too much attention at variable names, code style etc, I wrote it at 3AM, so I wrote the first thing which come in my mind

Any help is appreciate, especially in the day handling and the leap year part, I'll made the configurable multiplier in the next version.

[bokkie]

Maybe this is an interesting combination? http://www.tt-forums.net/viewtopic.php? ... w=previous . If the NewGrf provides a truck that normally would be available from 1920 to 1950, from (for instance) 1000 to 1500 and your patch shows 1920 to 1950, people wouldn't complain about years being wrong.

(Maybe I'm wrong but that's what crossed my mind when reading your post)

[Wolf01]

@bokkie: that was not the target, the year will be wrong in any case, when the patch will be done, the grfs date will be based on the fake date

As I promised, here is the patch with the advanced setting and some fixes, now the patch is based on the day instead of the year, but it is the same thing, if a day lasts 4 more times than the normal day, the year lasts 4 more times too.

[Wolf01]

New version with saving/loading of the date
Features
* in the Save/Load game window there's a "Current fake date" display (temp, maybe not, but with a different string)

Problems:
* seem the fake date is not loaded, I can't understand why (maybe because of the SetDate() in date.cpp where the real date is copied in the fake date

To-Do:
* Use the fake date as year introduction for vehicles (stations, objects...) of newgrfs
* Show the right period on graphs/bank balance and running costs (no, the economy won't change at all)
* AIs need to know about the fake date
* Admin network neet to know about the fake date

[Wolf01]

9 days have passed and I get headaches when trying to understand how to separate the dates.
BUT! I made a new version of the patch which fixes the loading of the date and the savegame name (now it saves with the shown date).

I already found the spots where I need to make changes to let the grfs use the fake date (it's easy, just search for _date), but before doing that I want to fix and improve the current code.
There are some cases which make me worried, such when the game checks for _date_fract, there I need to do it in another way, if it's possible, for example the conversion of the date before savegame version 147.

[Tafidis]

Hi, Wolf

For starters, kudos for your work and to Alberth for the suggestions.

Now, I had a go at a daylength patch myself a while ago (unpublished) which I abandoded. It followed the classic approach of changing DAY_TICKS =70 to a variable, which I later realized is wrong, due to reasons anyone can find by searching older threads with abandoned daylength patches.

Anyhow, your approach seems simpler and more elegant so I'd like to help. Here are some thoughts:

Why do we need daylength? Well, as we can scale the x and y of the map using maps larger than the original 256*256, daylength offers us the possibility to scale time. But, like in scaling size, daylength affects gameplay in several ways. For example, in scaling size, industry production changes have to occur more often in larger maps, which has been very well implemented in the game. However, the gameplay is still different in larger maps, in that a player can make much more money due to vehicles travelling much longer distances. It is also easier to get a max rating of 1000 in larger maps as you can get 80 stations and 120 vehicles no prob. Thus, in a large map, you get similar feel as you do in smaller ones, but also different in some ways.

Now daylength is desired by people for two reasons:
1) Be able to play longer before vehicles get outdated etc, a.k.a build steam train empire on 1024X1024 map without getting RSI, if at all possible. This one is the most common.
2) Be able to provide same services with less vehicles. This requires adjusting production inversely proportional to the daylength factor. For example, service a coal mine that produces 400 tonnes of coal/month with a couple of trucks with a carrying capacity of 20. Although this sounds realistic IRL, it is hardly the case in-game, even if the industries are next to each other. This one is less common, but myself (and I believe other people) would to love this in order to play detailed heightmaps of smaller geographical areas without over-congesting them with vehicles. Imagine a single train connect two towns 100+ tiles apart adequately, while going through a long, scenic route, mainlines that don't have to be 8-tracks-wide, no more junctions that are larger than towns etc.

In both cases, you do have to adjust the economy somehow, otherwise a player gets daylength_factor times the money they would normaly make in a game year (not true for the second case, but anyhow). Can this be done somehow with your apporach? I believe yes. Other things are also affected by daylength, such as servicing intervals, vehicle reliability drop (each day), station rating drop, and others. If all of these can be covered by your approach I am all for it to drop in and give a hand. I do have some basic C++ skills (nothing close to production level, but I understand how the laguage works, can compile and have done my own projects in the past).

If I understand correctly, you consider the original game date as internal_date and your "fake" date as the GUI date exposed to the player. This solves a number of problems I encountered during my attempt, in that you don't have to touch many things to begin with. I would suggest renaming the original game variables _date, date_fract etc to something else such as internal_date, internal_date_fract etc, and specifying a naming convention for your "exposed" date system so that you make sure only your own are indeed exposed (not only in gui, but also to NEWGRF and such).

I know it can get confusing but keep it up. This is something many, many people want in trunk and maybe this time is the time !

NOTE: I know you don't want to touch the economy at all, and that is perfectly fine, and consistent with the principle of keeping patches small. My thoughts above are more in the direction of "once this is working, can we then expand it to cover economy adjustments and other related stuff?"

Now, please let me know if I can help with something.

[Tafidis]

Patch updated to current trunk.

One question: The "fake date" does not seem to be displayed at the bottom line on the main view port. I.e, I started a game with a multiplier equal to 12 (longest) and days seem to pass each ~2.2 seconds, as usual, instead of 12 times slower. Am I missing something?

NOTE: I didn't check the code to see if this was implemented or not, but should it not be one of the starting points so that we can test what things happen within each day? SUGGESTION: Have the patch display BOTH dates, for debugging purposes

Other problem I just found: Savegame is always named January 1st 1930 no matter what the actual (internal or fake) date is.

EDIT: New diff with correctly bumped savegame version

[dihedral]

perhaps the console command 'getdate' could display both dates for debugging pourposes (possibly only in debug builds)?

[Wolf01]

As far I know there's a problem with the saved setting in the cfg, just remove the line from the settings file and reload the game, you should be able to use the daylength you want and see the effect.
I didn't figure out how to fix this bug.
About your other questions: this patch does not affect the economy, it only makes your clock run slower, but the world is still based on the *right* clock. Some things should be binded to the fake clock, such the vehicles intro dates, schedules etc, but for other things such economy, running costs etc I think is better to have them based to the right clock and just change their gui description based on the value of the daylength multiplier (for example with the multipler set to 6, one fake month = 6 months, the running costs could be explained as two months running costs which equals the *old* yearly running cost).
This mean that a lot of change need to be done in the guis, but it won't affect the economy as previous patches did.

[Eddi]

one of the worst things i ever saw in any of the daylength patch that "running costs per year" get changed. especially since this change makes it exorbitantly high, a multiple of their purchase costs.

ideally, both income and running cost should be divided by daylength, but since the money doesn't have fractional units, it would be better to multiply the purchase cost by the daylength, and only divide every value by daylength on display ("fake money" similar to "fake date").

this should easily be done by adjusting the base costs, they should easily be divided into ones that affect one time (purchase costs) and continuous (running costs). the initial and maximum loan should also be affected. the fake display is essentially the same thing as the currency multiplier, it should easily be adapted.