Page 4 of 14
Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 11:35
by sc79
Nice work, but any chance of fixing the backwards compatibility? A fix was posted on the first page (assuming its that simple) and I didn't see any followup in the thread. I'd really like to load some of my established games.
Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 11:53
by Gonozal_VIII
PhilSophus wrote:However, if you changed the following line in settings.cpp (about line 1394), it would work.
Replace 84 by 87 (the savegame version of the patched version), i.e. it should read
Code:
SDT_CONDBOOL(Patches, disable_tree_growth, 87, SL_MAX_VERSION, 0, 0, false, STR_CONFIG_PATCHES_TREE_GROWTH, NULL),
yes i read that and i did what he suggested directly after i read it. i don't know much (more like nothing) about savegame compatibility so i don't know why/if it doesn't work now.
Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 12:04
by Trond
With latest version it is atleast not possible to load games from 0.6.3. it says 'invalid chunk size'...
Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 15:21
by Roujin
Some of the other patches you merged also intoduce new settings, e.g.
Code: Select all
+ SDT_CONDBOOL(Patches, timetable_separation, 67, SL_MAX_VERSION, 0, 0, true, STR_CONFIG_PATCHES_TIMETABLE_SEPARATION, NULL),
change the minimum savegame version of all newly introduced settings (here it's 67) to trunk savegame version + 1 (thats 87, if it wasn't increased since PhilSophus wrote that post), then you can load from trunk.
edit: just checked. Yoricks pathfinder selection overhaul was accepted into trunk, raising trunk savegame version to 87. That means two things for you to do:
1) remove his patch from your pack,
2) set minimum savegame version of all newly introduced settings in your pack to 88
right?

Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 15:25
by Yexo
Gonozal_VIII wrote:PhilSophus wrote:However, if you changed the following line in settings.cpp (about line 1394), it would work.
Replace 84 by 87 (the savegame version of the patched version), i.e. it should read
Code:
SDT_CONDBOOL(Patches, disable_tree_growth, 87, SL_MAX_VERSION, 0, 0, false, STR_CONFIG_PATCHES_TREE_GROWTH, NULL),
yes i read that and i did what he suggested directly after i read it. i don't know much (more like nothing) about savegame compatibility so i don't know why/if it doesn't work now.
In the code you define for every variable in the save-game in what versions in can be found. So in the line above you say disable_tree_growth is a variable that is saved in savegames from version 87 to SL_MAX_VERSION (the latest version at compile-time). At the moment, the latest version (that trunk uses) is 86. That means you should define that your patch uses savegame version 87 (already done) and change all savegame variables to 87 and later. The line above is just one example of this.
For example lines 5231 and further from you patch:
Code: Select all
- SLEG_VAR(_cur_player_tick_index, SLE_FILE_U8 | SLE_VAR_U32),
- SLEG_VAR(_next_competitor_start, SLE_FILE_U16 | SLE_VAR_U32),
+ SLEG_CONDVAR(_cur_player_tick_index, SLE_FILE_U8 | SLE_VAR_U32, 0, 85),
+ SLEG_CONDVAR(_cur_player_tick_index, SLE_UINT32, 86, SL_MAX_VERSION),
+ SLEG_CONDVAR(_next_competitor_start, SLE_FILE_U16 | SLE_VAR_U32, 0, 85),
+ SLEG_CONDVAR(_next_competitor_start, SLE_UINT32, 86, SL_MAX_VERSION),
_next_competitor_start is now defined at being int32 since version 86, but all savegames of version 86 are from trunk (or old patches, but they don't count), and trunk didn't change this. That means openttd with your patch will try to load an int32 while there is an uint16 saved, and the size won't match, hence the "invalid chunk size"-error.
Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 15:30
by Roujin
/agree with Yexo, except for the part with the savegame version, as i wrote above - it's 87 in trunk now so do everything as he said, just with each number increased by one

Re: Gonozal_VIII patchpack r12106
Posted: 13 Feb 2008 15:33
by Gonozal_VIII
thanks for the explanation, i think i get it now, i will make a new version soon (either tonight or tomorrow morning)
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 06:28
by Gonozal_VIII
brand new version ready to download in the first post... i changed the savegame version everywhere so it should now be able to load trunk or older games, i changed a lot of stuff in almost every patch, especially yapp and daylength so there could be bugs, be careful and don't let them bite you

(didn't notice any while i was testing but they are good at hiding)
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 06:37
by Trond
Great! /me waits for win32binary

Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 06:40
by Forked
Trond wrote:Great! /me waits for win32binary

it's ready
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 06:50
by Trond
Forked wrote:Trond wrote:Great! /me waits for win32binary

it's ready
Thats what I call service!! Thanks!
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 06:58
by Forked
Thank the developers, patch creators and gonozal

they do the real work

Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 07:56
by sickie
When you update your patchpack, you could specify the changes you made. Reading your last and first post doesn't tell what's new, just updated the trunk or any of the additional patches too?
Gonozal_VIII wrote:i changed a lot of stuff in almost every patch
Any "functional" changes (you changed something that has to do with features)?
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 08:00
by Gonozal_VIII
no new patches but lots of updates, fixes and better savegame compatibility
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 12:37
by bokkie
It has all the patches I can wish for so I don't mind

I'm playing with the following GRF's: Generic Road Vehicles by Zephyris, Pikka's Industries and UKRS (and some other not really relevant ones). Now gameplay-wise only subways (probably not going to happen soon) and better airports (which are in the works) would really add to the game but this is already much more fun than 'plain' trunk.
One bug I found in the before-last version (that's probably not English

) is that the timetable is shown in ticks (even though I didn't specify that in the configuration), but maybe that's already worked out in the last version.
Attached another bug but I'm really not sure what would've caused it. Wagen 38 somehow loses money when it delivers cargo ('Kosten €230') this year, even though it didn't do that last year. And other trucks that share route with it don't lose money. Because of this, it's loss is even bigger than it's runner costs! Also attached is a savegame, r12106 version and the GRF's mentioned above (and some others but it'll probably load just as well without them).
Now going to try to load the old savegame with the new binary! Maybe the bugs are already solved in that one

Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 12:42
by Gonozal_VIII
timetable is always in ticks with daylength >1 and the negative income comes from transfer, that's not really negative, only the last leg of the transfer chain.
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 13:25
by bokkie
Timetable/ticks: Alright, but when I modify values in the timetable input is in days. For instance, when I try to change the waiting time, I have to give '3' as input to get 221 ticks. Now that's inconsistent

.
Loss by truck: How can it be that the same truck made money last year and loses money this year, while doing exactly the same work? And that some trucks make money and this truck loses money while doing exactly the same work (shared route)?
Loading savegame didn't work with the new binary (as expected) but no harm done, the previous build is stable enough to keep playing. Thanks for the effort!
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 14:23
by sickie
Yes, no savegame compatibility with previous build. And one another thing I noticed in latest build: broken support for ECS vectors. Raw material industries have 0 cargo left and never produce anything. And I get allot of blank newspaper news for industries. Firstly I thought it was my fault (ECS GRFs order), but then I tried with previous build of patchpack and everything worked normally.
As for Timetable/ticks: In my opinion, it's better the way it is, so that you need to enter days and not ticks. It's not nice to calculate ticks, easier for me to change the value in days.
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 15:50
by bokkie
Maybe it's just personal (well opinions always are

) but when I see that a bus is say 85 ticks late and I need to change my schedule (for instance, because the number of passengers has grown) it's easier to just add 85 ticks to the previous number than guessing the number of extra days that equals 85 ticks. Next to that, days are a bit inprecise and it doesn't seem to be possible to use decimals (',' and '.' don't work).
EDIT: just turned the patch option 'show timetable in ticks instead of days' on, that changes the input from days to ticks. Problem solved, but it's pretty counterintiutive to me. Patch option off should mean show everything in days (and not only the input), patch option should mean show everything in ticks IMO.
Re: Gonozal_VIII patchpack r12134
Posted: 14 Feb 2008 17:44
by Gonozal_VIII
ecs: there is a bug in trunk newgrf handling introduced in 12124, fixed in 12139, that's why ecs industries don't work with my patchpack, will be fixed with the next update.
timetabling: i just tested, you are right, with daylength set to >1 and patchsetting display timetable in ticks off, it displays the timetable in ticks (daylength patch does that) but wants days as input (without using the daylength factor) when you manually change it, inconsistent indeed. i think i will change the display back to days if it's set to days and multiply by daylength factor too... that way it will be consistent with the patch setting.
truck income: transfered goods lie around for a different duration, the truck gets the difference between the yellow transfer income and the full income, slow transfer means less income therefore negative numbers, has nothing to do with any of the patches.
savegame compatibility: i didn't know much about that until yesterday, but it should work much better from now on (able to load trunk, beta and older games, possibly not earlier versions of my patchpack)