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

[Roujin]

here you go

edit: removed - please see two posts below for fixed version.

[Trond]

Awesome Roujin. Thanks a lot! This one with newest trunk for station animations, WOHOO

[Roujin]

I noticed a glitch with drawing of the clock for daylength values between 15 and 30 and fixed it. Please redownload the fixed .diff in this post if you downloaded the one I posted earlier.

[Trond]

Let me just add that this update from Roujin is the version BEFORE nappe1 added the 'disable daylength affecting industry production' option, so if you used his version, this wount work with those savegames... (so I'm told )

[Roujin]

What Trond says is true, however i've also updated the version nappe posted, so whoever used his version can continue now with the following:

daylength_r12802_indprod.diff

daylength for r12802 (Nappe's version with industry production)

(26.19 KiB) Downloaded 114 times

Please note that it's not able to load current trunk. I can either make that OR compatibility with older versions of this patch due to not-so-optimal usage of the savegame version system.

However I'll be posting another version shortly that is able to load trunk and introduces a sensible savegame version usage. I strongly encourage you to use that one if you're starting a new game.

[Roujin]

So here, as I promised, is the new version I made, which I recommend you all to use. It includes all the features (also the last one added by nappe) and can load current trunk. However it can not load older versions of this patch.

I added a system that makes it possible to maintain backwards compatibility from now. Let me explain it for anyone who wants to update this patch further.

There is a constant named PATCH_BASE. This is set to 200 and never to be changed. (Well, when trunk hits savegame version 200 maybe, but that's far off).
Then there's PATCH_SAVEGAME_VERSION. Now it is 1. If some feature is added or removed/changed, bump this version by 1 and set your settings accordingly (min/max version).
SAVEGAME_VERSION is computed by PATCH_BASE + PATCH_SAVEGAME_VERSION (leave it this way).

Now to the interesting point: What if trunk bumps it savegame version?
Then, bump PATCH_SAVEGAME_VERSION as well and edit the new setting introduced in trunk by splitting it up in two: one is valid from trunk version it was introduced in to PATCH_BASE, and the second one is valid from PATCH_BASE + [the patch savegame version you bumped to].

This way you will still be able to load from older versions of this patch and trunk and be able to save/load new settings in trunk.


---
If you are just a casual player of this patch, you don't need to worry about what I wrote above this line. It's just important if you want to add something to this patch or update it over a trunk savegame bump and keep backwards compatibility.

[Gedemon]

I used this patch since some times now, and I can't play without it now...

The version I used is based on an old release here (before the time on date). I've made vehicle buying cost a factor of daylength, as is running cost...

... then I've applied it on max loan to speed up start, added a self-made mortgage patch, and multiplie also loan interest to keep some difficulty to the game. and using basecost grf help...

in fact this way the game is more difficult, keeping interest below income is quite challenging

some things I've noted :
- tree growth should be slowed by daylength factor
- town rating should be updated more often... this one is linked to the first from a gameplay POV
- how is town growth btw ?

[Trond]

There used to be a patch that stopped treegrowth altogether, not sure if that is updated lately tough.
Agreem town rating should be updated more often if possible, they way it is now, when you play with high daylenght, its a pretty long time between each time it is updated, and that can be a tad annoying at times.
Town grows pretty fast, but when they get to a certain size it seems to stall alltogether anyway (30-50000), but you can start a game in 1940 and have some cities at 25.000 +- in 2-3 years . This doesnt bother me much, it makes moving passengers easier, because you can actually make money on it early on .

(My views are based on daylenght 32).

[Gedemon]

Roujin, would you submit it to Community Integrated Version ?

[Roujin]

sure can do.

But there'll be no savegame compatibility there, just so you know.

[Trond]

I dunno if this was intentionally or because of changes inn trunk, byt trying to patch the fixed r12799 (http://www.tt-forums.net/viewtopic.php? ... 80#p683691) gave me one of those errors about savegame invalid chunk size... I guess that just means its time to toss all old savegames and just start over with it sad but true, hehe

I also noticed the r12805 build did have some fuzz when compiling, but I ran it trough tortoise, and we'll se if that one works as intended now...

EDIT: Seems to work okey with the r12805 build now.

[Trond]

Any chance of an update to latest trunk for the fixed patch Rouijn? there seem to have been some changes to vehicle base or something that i think is a bit over my head

[Roujin]

Any chance of an update to latest trunk for the fixed patch Rouijn? there seem to have been some changes to vehicle base or something that i think is a bit over my head

Trond, Trond... The conflict in vehicle_base.cpp is merely some #include's at the same position... you should really get yourself some tool that enables you to handle something easy like this.. (solution: add this first, then that, no matter the order of this/that)

However, savegame version in trunk was bumped, so I'm updating it with a proper check that should keep it savegame compatible.

Currently working on it...

edit: done. enjoy.

[Trond]

Actually I did that with tortoise, only at 1st I messed it up using just one of the lines instead of all 3 that I got in that conflict. When trying again after I wrote my post up there, I included all 3 and it worked fine... but then, when you're not a c++coder you never really know if what you did was right, or if it just worked becoz I got lucky, and that there should have been somre more changes...

The savegame I bumped the other day, thats easy even for me now

Thanks anyway, now I'm gonna look at how you did it and compare with how I (tortoise) did it

What you're saying is infact what I was wondering, if the order of the 3 lines had anything to say... Now I know, so thanks for that too

[Roujin]

The order of #include lines generally don't matter.

But when there's a savegame bump in trunk, some a bit more complicated measures have to be taken to keep it compatible.
I'll try to explain how it works.

A savegame bump is usually done if some setting that is stored in the savegame is added/changed/removed.

say, trunk bumps from savegame version 94 to 95.
In case something got added, somewhere a line like the following was added:

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 95, SL_MAX_VERSION)

it could also be CONDBOOL for a boolean setting, or other stuff.. anyways: the 95 and then SL_MAX_VERSION denote the minimum, and maximum version this setting appears in. SL_MAX_VERSION is just an upper bound for versions, currently it stands for 255, but theoretically it would mean infinite.
So it means here: this value was introduced in savegame version 95 and since then, occurs in all future versions.
Now with my compatibility scheme, you have a fixed value SL_PATCH_BASE (I set it to 200) and a PATCH_SAVEGAME_VERSION that starts with 1 and is increased everytime some setting changes (either in trunk OR in your patch). The "real" savegame version is computed with SL_PATCH_BASE + PATCH_SAVEGAME_VERSION

Now, assume that your patch had PATCH_SAVEGAME_VERSION = 3 before, and now you want to update over a trunk savegame bump where some setting was added. First you increase your PATCH_SAVEGAME_VERSION to 4. Then you duplicate the (new in trunk) setting, and tell the program it exists: 1) in normal (unpatched) versions up to SL_PATCH_BASE and 2) in (patched) versions starting with SL_PATCH_BASE + 4. (the first version of the patch where this setting existed)

So the code would change from

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 95, SL_MAX_VERSION)

to

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 95, SL_PATCH_BASE)
xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], SL_PATCH_BASE + 4, SL_MAX_VERSION)

Note that in the versions SL_PATCH_BASE + 1 to 3, the program assumes that this setting did not exist. And this is exactly the case, you know? In the previous version of the patch, the trunk didn't have this feature yet, so the patched version didn't have it either. This is the essential point of all of this...

---
Now for the other two cases that can happen I'll just write the code that has to be changed:..

setting changed in trunk:
from

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 36, 94)
xxx_CONDVAR([somevalues] [name_of_setting], [changed_type_of_setting], 95, SL_MAX_VERSION)

to

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 36, 94)
xxx_CONDVAR([somevalues] [name_of_setting], [changed_type_of_setting], 95, SL_PATCH_BASE)
xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], SL_PATCH_BASE + 1, PATCH_BASE + 3)
xxx_CONDVAR([somevalues] [name_of_setting], [changed_type_of_setting], SL_PATCH_BASE + 4, SL_MAX_VERSION)

setting removed in trunk:
from

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 36, 94)

to

Code: Select all

xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], 36, 94)
xxx_CONDVAR([somevalues] [name_of_setting], [type_of_setting], PATCH_BASE + 1, PATCH_BASE + 3)

[Trond]

I got a chance to try figuring this out when trying to make a r12929 build... I failed
No matter what I change a compiled version will NOT run my savegame from r12918. This is just a bit or two over my head... The problem is I really dont get what values in the patch file I should be changing...

I tried to change some of the values under the Index: src/saveload.cpp tag from 1 --> 2 and 94 --> 95 and the some under the Index: src/settings.cpp where it says PATCH_BASE + 1 --> PATCH_BASE + 2. That didnt do me any good, still no working on loading my previous savegame with this patch.

Now, I dont really know what didnt work, because I'm not this advanced with coding, its been a few years since I actively coded and at the time it was much assembler code I was working with. I do think it must have something to do with the fact that I dont know what settings have changed in trunk, and even more to do with where to add them in the patchcode...

Anyways, some of the stuff you explained I do understand and some is a bit to advanced for me, I really apreciate you taking the time to write that whole explanation and I will most certainly be looking back at it in the future when new problems arise, but as of today, I guess updating this patch to latest trunk (with enginepool!!) is just to much for me... Hope you find the time to do it

EDIT:

Just noticed the above tests wasnt done with the latest version you put up here a couple of days ago, so now I tried that.

I changed the values in saveload.cpp that was 93 -> 94, 94 -> 95 and 2 -> 3. (code seen below unchanged) I didnt change anything else. I guess all the changes done in various files with r12924 (enginepool) is what is causing this to be way to hard to fix for a newb like me, so I just give up for now... I see in changelog for r12924 that a lot of the files that get a few changes with this patch, did get a lot of changes with that rev. so I just azume this is my major problem right now...

[Roujin]

oh right, enginepool got into trunk. time for an update.

I'll post it later and explain what exactly I did.. maybe it's clearer from that than from my theoretical example before..

[Trond]

That would be awesome Roujin!

[Roujin]

Let's see what trunk did in r12924 (concerning savegame versions), using Mercurial.

Code: Select all

saveload.cpp:
    35.7 -extern const uint16 SAVEGAME_VERSION = 94;
    35.8 +extern const uint16 SAVEGAME_VERSION = 95;

openttd.cpp:
   27.34 +	/* Force dynamic engines off when loading older savegames */
   27.35 +	if (CheckSavegameVersion(95)) _patches.dynamic_engines = 0;

settings.cpp:
    36.7 +	SDT_CONDBOOL(Patches, dynamic_engines,          95, SL_MAX_VERSION, 0,NN, false, STR_CONFIG_PATCHES_DYNAMIC_ENGINES,      NULL),

the first one is easy. Trunk savegame version bumped, so I add a little comment what was changed, and bump my patch savegame version (from 2 to 3).

Code: Select all

[in saveload.cpp]
 * patch savegame version 3:
 *  trunk savegame version bumped to 95
 *  trunk added dynamic_engines (settings.cpp)
 *  trunk added savegame check (95) in openttd.cpp
 *
 * --- add further versions here --- */
const uint16 PATCH_SAVEGAME_VERSION = 3;

now i go for the third one (in settings.cpp): this is what I described theoretically above - trunk added a setting.

Code: Select all

SDT_CONDBOOL([blabla],          95, SL_MAX_VERSION, [blabla]),

this means basically "this setting is valid from savegame version 95 up to infinity (theoretically)."
Now I want to change that a bit so it says "it is valid from 95 to the number right before my patches start, not valid for my patch versions 1 and 2, and then valid again".
so i change it to:

Code: Select all

SDT_CONDBOOL([blabla],          95, SL_PATCH_BASE, [blabla]),
SDT_CONDBOOL([blabla],          SL_PATCH_BASE + 3, SL_MAX_VERSION, [blabla]),

note that SL_PATCH_BASE is the number right before the patched versions: the first version of the patch was SL_PATCH_BASE + 1.

---
now for the second change, in openttd.cpp: this is something new I didn't describe before.
"CheckSavegameVersion(95)" basically just checks if the savegame version of the savegame to be loaded is below the number given (here 95). So in this particular case it checks if the savegame version is older than 95, and if it is, it switches the dynamic_engines setting off.
We want to change the if-expression to "Is it below 95, OR is it (below patch version 3 AND at least patch version 1)".
"at least patch version 1" is the same as "NOT below patch version 1", or in code:

Code: Select all

	if (CheckSavegameVersion(95) || (CheckSavegameVersion(SL_PATCH_BASE + 3) && !CheckSavegameVersion(SL_PATCH_BASE + 1))) _patches.dynamic_engines = 0;

You see, it does exactly what I wrote in words.

---
I don't know if that now helped you understand it a bit more or not, but anyways, have fun with the patch & engine pool

edit: removed - see two posts below!

[Trond]

I will read trough your eplanations later, but for now I can't compilw it with BOTTD, it just toss out the usual 'config.log' already exists error message, so I have no idea what failed. I can easily make a clean trunk compile, but not a compile with this trunk... Yeah, I know... nag nag nag