Daylength Patch [12/09/2008] Compatibility: r14293

[Wolf01]

I can confirm, there were two

Code: Select all

+STR_CONFIG_PATCHES_DAY_LENGTH                                   :{LTBLUE}Default day length: {ORANGE}{STRING1}
+STR_CONFIG_PATCHES_DAY_LENGTH_ECONOMY                           :{LTBLUE}Day length affect economy: {ORANGE}{STRING1}

[pavel1269]

it used to be called .... Daylength effect vehicle running cost ... or sth similiar .... now its implemented by default

[kul]

it used to be called .... Daylength effect vehicle running cost ... or sth similiar .... now its implemented by default

All I know is that setting the daylangth to 15 doesn't increase my yearly interest on bank credit, nor does it seem to affect my running costs.
I did however apply the patch (r15447) to another version (r15655) the patchfile suggests it's a single variable now.

Code: Select all

+############ daylength advanced setting
+STR_CONFIG_PATCHES_DAYLENGTH                                    :{LTBLUE}Daylength factor: {ORANGE}{STRING} * 2,22 seconds at normal game speed
+########
+

[pavel1269]

it is now, and if it doesnt increase interests, then, somewhere is error, i looked into code, and that "Daylength affect vehicle running factor" appeal like always true

will try it later

[Earl Sven]

I think there might be something amiss with the economy setting, I have applied the latest version of this patch (15447) and then I patched the same source with the routemarker patch for r15700 and it would seem the running costs of vehicles are unchanged, i.e. still £10000 a year for for the Collett Panier, even with daylength set to 10x. There is an earlier version available on the daylength one about 100 revisions after this patch which I will try later but at the moment I don't think with that second patch included at that revision this is working right.

[Wolf01]

The first version did not take in account the running costs of vehicles, that's because the YEARLY running cost is YEAR based and not TICK based and it is the same at every day length you set.
There was a big problem: the enormous ammount of money you earned with a single travel (the cargo payment was tick based, I don't know what is now) because with daylength set to 10 your trains were able to do 10 times more profit with the same running cost, just an example.

So I did a modification, I added a multiplier/divider to the vehicle running costs, so it was based on the daylength as every other price, this to fix it.
This generated another problem, people were used to the old costs, usually you compare the cost and the speed of two or more trains when you need to purchase a brand new one, now it's more difficult.
The modification multiplied the running cost to reflect the exact value, so the train purchase cost was $1500 and the running cost of $3000 instead of $300 (with daylength=10)
And this was the "Daylength affect running cost" part of the patch

The other part was due to the ridicoulus productions of the industries, you know that an industry producing 14 tons of coal/month it is silly at normal speed, with daylength set to 10 it still was 14 tons at month, your train needed 10 times more time to load!
I added a new option: "daylength affect industries production" so the monthly production was 14*daylength->140, the train then loads the same ammount of cargo in the same ammount of REAL time, and paid the same running cost in the same REAL time as before, both settings turned on gave you the standard balance, but with all the components of income and costs multiplied, eg. 5-3=2 and (5*10-3*10)/10=2.

Finally I merged the two options into one -> "Daylength affect economy" because it's silly to multiply the running cost but keeping the production the same or vice versa.

I really don't know how daylength works now, I stopped my development on r9xxx and then it was taken up by Chrissicom, so I really don't know if the current setting affects both the running costs and the production rate, if not it is wrong, because it should do it

[Aali]

It does affect running costs, but its very buggy, and it does not affect industry production at all.

(Running cost is displayed as daylength * original running cost, but in my test runs with daylength 10, the actual amount deducted is almost 3 times less than what is displayed in the vehicle info)

To make a "proper" daylength patch, the first step would be to separate all the periodic (needs to be done every X ticks) events from the ones that do need to happen every day/month/year, because at the moment they're all tucked away in the daily/monthly/yearly loops which leads to huge differences in gameplay when the daylength factor goes up.

[Wolf01]

So it's really changed, my version was buggy because of the poorly written code, but at least the right bank balance was saved
This version fixed most of mine bugs, but seem to have messed up some other things, I really don't know what is better

[Earl Sven]

So I gather that essentially the patch works by using a multiplier on every tick dependent variable, and perhaps modifying some variables such as running cost that were not previously tick dependent. How many variables are we talking that would require modification to work with this patch? Is it dozens or hundreds or even thousands?

I have barely any experience of coding myself beyond a few simple C projects so I'm not able to take on the task of writing a patch such as this myself, but the way I see it surely you simply need to add a multiplier (either n = daylength multiplier, or m = 1/daylength multiplier) to the front of each variable depending on whether or not it should increase by a factor of n or decrease by a factor of n (so for example industry production per month would need to be multiplied by n, but cargo payment rates would have to be multiplied by 1/n, since they are day/tick dependent). I suppose a further complication would be to ensure that tick-based events that happen in real time were unaffected, or you might end up with ultra slow trains. I have no idea how many thousands of lines of code comprises OTTD, I imagine its a lot, but surely there must be an efficient way to multiply variables when they are created rather than finding every instance of a particular time dependent variable and adding an individual multiplier.

Perhaps I'm stating the obvious here, its just that the only problem I can see with implementing something like this is the scale of the implementation, and possible changes to variables that are time dependent further down the development road (but this is an issue with any patch).

[Eddi]

the problem is not so much writing the patch, but providing a good concept of determining for each variable, whether it should be tick-based, day-based or configurable. that was the main problem for all previous patches, there was no clean concept behind it.

some of the variables are modified by a factor. other code parts need to be run less often instead. and in places where numbers should be divided, a handling for fractional values is necessary.

[2007Alain2007]

update to daypatch_r15821 patch and build

daypatch_r15821.diff

daypatch_r15821.7z