Another Daylength patch

[Alberth]

By applying the patch, and compiling the result. See also http://wiki.openttd.org/Patches
Note that using a release as starting point is generally not useful, as patches are normally not developed against releases, but against trunk / nightly versions.

[kamnet]

Also of note, patches are typically created against a SPECIFIC trunk/nightly versions. While they may also work against future versions, there is no guarantee due to the ever-changing nature of the code. If you do encounter a problem, then you will need to know some more detail about c++ and compiling in order to fix the issue. There's no guarantees that once a patch is published that its original (or even last) author will update it.

[Eddy Arfik]

Windows 64bit build against current trunk

[Eddy Arfik]

One thing I recently noticed with this patch is the higher you set the daylength, the easier it is to make money, since if a trip takes 100 days with daylength 1 it only takes 20 days with daylength 5, 10 days with daylength 10, etc... less days in transit means more money per trip. I considered this to be undesirable behaviour, therefore I've made a small change to the income calculation, multiplying days in transit by the daylength factor, meaning income per trip is now the same as in unpatched game regardless of daylength setting, the fact that vehicles can make more trips per year is in itself enough profit boosting. Attached is the modified patch for latest trunk and a Win64 binary

[pavel1269]

While you make per trip more money, the industry produces still at the same rate meaning, that it will take a way longer to load the vehicle, which gets extra decrease now.

[Eddi]

this is precisely why daylength patches have never been considered for trunk inclusion.

people always disagree on whether X or Y should be scaled by daylength.

[romazoon]

this is precisely why daylength patches have never been considered for trunk inclusion.

people always disagree on whether X or Y should be scaled by daylength.

so why no agreement have been reached to give the option to players to select himself what he wants to be scaled or not ?
to me it seems like most daylenght patch are doing that to some extent already.
Also, even if adding some advanced parameter is i guess not really the best, i m pretty sure advanced user will know how to make good uses of those "extra parameter", and newbie to Ottd won t really look after that feature in the begin i supose.

[Eddy Arfik]

While you make per trip more money, the industry produces still at the same rate meaning, that it will take a way longer to load the vehicle, which gets extra decrease now.

Of course, the vehicle can only make more profit if production is high enough that it doesn't wait too long for loading, I wasn't suggesting to change that.

this is precisely why daylength patches have never been considered for trunk inclusion.

people always disagree on whether X or Y should be scaled by daylength.

Indeed, you can't make everyone happy all the time, but my personal opinion is that a daylength patch should not scale anything, it should simply make the days pass slower, nothing more. If someone wants to scale production or running costs or whatever else, there is NewGRF for that. It appears that was the intended goal of this patch, however as I said above I recently noticed that printing money got easier the higher I set the daylength. I have run a test to show why I think the change to income calculation is necessary, I loaded the exact same savegame with 3 daylength settings and ran it for 1 year un-attended, the results are below:

Left: Daylength 1 | Middle: Daylength 4 (original patch) | Right: Daylength 4 ( with days_in_transit * daylength_factor)

daylength income comparison.png (9.4 KiB) Viewed 4847 times

As you can see, not taking into account the daylength factor when calculating delivered goods income has the effect of scaling income by the daylength factor.

[Pyoro]

But the year is four times longer now, why wouldn't you make four times as much money? The yearly budget window just completely arbitrarily "cuts off" profits after a year, if you look at "money per second" (MPS ) it still seems to be roughly the same ...
... admittedly, I personally couldn't care less. But I'm not sure this change is entirely logical.

this is precisely why daylength patches have never been considered for trunk inclusion.

people always disagree on whether X or Y should be scaled by daylength.

nvm that they the patches also tend to cause bugs with animations and such. Other things could theoretically be handled by sub-options.

[Eddy Arfik]

But the year is four times longer now, why wouldn't you make four times as much money?

Because I'm not moving 4 times as much cargo. Why should I be able to eliminate the effect of cargo decay in transport simply by making the year longer? Take for example an aircraft travelling across the map at 2000km/h, I get paid a certain amount for that trip. If I set the daylength to 10 I effectively get paid for making that trip at 20000km/h. To me that doesn't seem entirely logical.

[Eddi]

As you can see, not taking into account the daylength factor when calculating delivered goods income has the effect of scaling income by the daylength factor.

well, what i see is that running costs are halved for some reason, but maintenance costs are not.

[Eddy Arfik]

well, what i see is that running costs are halved for some reason, but maintenance costs are not.

Both versions with daylength have halved running costs compared to unpatched trunk, I'm not sure exactly why but I think it's because the vehicles spend more time waiting to load and less time moving.

[Wahazar]

I found that decreased time penalty is not a bad feature for Daylength patch.
In my opinion, the main reason of using daylength patches are large maps with low density of resources.
In such case, all original in-game mechanisms - time penalty for income, reliability decay, station rating decay - totally fails,
because they were intended to run with 256x256 maps.
I'm now testing reddit client and I'm happy with long runs without draining reliability to 0 or abruptly drop of income for ships going to far.

[Eddy Arfik]

I found that decreased time penalty is not a bad feature for Daylength patch.
In my opinion, the main reason of using daylength patches are large maps with low density of resources.
In such case, all original in-game mechanisms - time penalty for income, reliability decay, station rating decay - totally fails,
because they were intended to run with 256x256 maps.
I'm now testing reddit client and I'm happy with long runs without draining reliability to 0 or abruptly drop of income for ships going to far.

I don't disagree that those mechanisms are broken, but to me it doesn't seem like the right solution to simply bypass income time penalty to compensate, all that really does is boost even further the gross over-profit of cross map plane spam, especially with high daylength setting. It would be better to redesign these mechanisms to better handle larger map sizes. FIRS already does a good job of income time penalty and station decay with its flatter payment curve and improved station rating algorithm.

[abregado]

See here for what I am trying to do http://www.tt-forums.net/viewtopic.php?f=33&t=72873

Is it possible to modify the settings to your patch via the console during a game?

[Eddy Arfik]

See here for what I am trying to do http://www.tt-forums.net/viewtopic.php?f=33&t=72873

Is it possible to modify the settings to your patch via the console during a game?

Yes it is possible to access this setting through console, the setting is called "day_length_factor"

[chrissicom]

Hello there, a few years ago I worked on a daylength patch myself and decided to come back today and see what progress was made in this regard. I am amazed how dead pragmatism is in our world, that after so many years there is actually still zero progress and the same discussions are alive.

In my opinion a daylength patch has only one purpose: To slow down the game, so on large maps when starting in 1920, you can actually build a decent network of vehicles before it is the year 2000 and you have actually only used 10% of the map. Even on small maps I always found it annoying how fast time passes by and new vehicles come out, especially with NewGRFs that often have much more vehicles than the base sets.

Nothing else but the speed time passes by should be changed by a daylength patch. The rest is game mechanics that sorts out itself, i.e. when increasing the daylength factor by 4, everything works like you would expect (e.g. industries produce 4 times as much a month). If you think you earn too much in a year when slowing down the game by factor 4, you can use a NewGRF to increase running costs, but that is nothing a daylength patch should handle. I really see no logic in slowing down the game and at the same time manipulate an endless list of parameters just to make sure income, running costs, industry production etc. per year is the same at any daylength factor.

Let me come back in a few more years and see if pragmatism has finally won

[kamnet]

If you're so resolute as to not advance this patch and address the concerns and issues that players and devs alike have brought up, then what conversation is there to be had? You think the patch is perfect and that's it. Fine and dandy. Enjoy your pragmatism.

However, some of us REALLY like this patch, and would like to see the issues it does create resovled, and would like to see this get into trunk. If you want to help with that, that would be even better than just staying away, because we need all the help we can get.

[pavel1269]

Foremost thing to do would be to discuss what day length patches should affect and what should be left unaffected and have this more or less accepted by devs that this is a solution they would like to see. Discussions have arisen and I don't remember of any of them having any conclusion because the final word still depends on general agreement of devs which I don't remember to see anywhere.

[chrissicom]

Can you make a list of the mentioned issues that supposedly currently exist kemnet? It's been a while I looked at the sources.