Another Daylength patch

[FLHerne]

Wow, you do know how to apply a patch and compile, but seriously have no idea what you are doing. Of course the executable with the patch applied is going to desync from 1.3.0. You could try to read this Wiki page.

He might mean that he gets desyncs in multiplayer between two executables with this patch applied?

[tamat]

yep, thanks FLHerne for making the right guess, I do test it with the same binaries. Come on, I've been coding my whole live. I'm not a random newbie.
Just wanted to know if somebody managed to do it with the latest trunk version, that is all.

[Arie-]

Sorry, my bad then. If nobody has further improved this patch the same problems might still exist, unless the problems you previously experienced came from trunk (stable?). At least I can't help you, good luck .

[Brokken]

Just a rather simple question...
I don't believe anyone develops a patch or applies it for himself, without creating a working executable version.
So my question is: Can't you upload the executable version along with the patch files?

I tried to apply the patch myself (following the Wiki-Guide), but both MS VS 2012 and 2010 just keep throwing me errors...

Regards, Brokken

[3298]

I could give you Ubuntu binaries, but you probably don't want them.
On a more serious note: Please tell us what your compiler complains about. Without that info nobody can fix it.

[Brokken]

Even though the Wiki Guide claims it has been tested on Windows 8 64 bits, it doesn't work for me.
VS 2012 opens the project file, but in the Solution Explorer it says (incompatible)
VS 2010 see the following...

The Wiki Guide has the following steps, that I can't apply to the project

2.4 A popup will ask you to update the compiler settings, click Update button.
--> There was no popup

When compiling for release, it says about 17 times
>d:\programs\svn\svn\openttd\trunk\src\language.h(17): fatal error C1083: "unicode/coll.h": No such file or directory

In the folders, the files exist, but without the (XX) behind them... I have no clue what that means, though.

[Brokken]

Oh, I forgot to mention, I didn't even get as far as applying the patch.
The Errors come from plain OpenTTD

[tamat]

I suggest to compile using MinGW, it is more friendly than VS, use this guide: http://wiki.openttd.org/Compiling_on_Wi ... sing_MinGW

[Brokken]

OK, I now used MinGW and followed all steps, I got two errors concerning the settings_gui
here is the settings_gui.cpp.rej content. I'm still looking where to place the content, since I figure that's all it takes.

--- src/settings_gui.cpp
(revision 24599)
+++ src/settings_gui.cpp
(working copy)
@@ -1588,6 +1589,7 @@
SettingEntry("economy.smooth_economy"),
SettingEntry("economy.feeder_payment_share"),
SettingEntry("economy.infrastructure_maintenance"),
+ SettingEntry("economy.day_length_factor"),
};

/** Economy sub-page */
static SettingsPage _settings_economy_page = {_settings_economy, lengthof(_settings_economy)};

[Brokken]

Ok, so I entered it at the end of the following block

Code: Select all

static SettingEntry _settings_economy[] = {
(...)
	SettingEntry("difficulty.disasters"),
            <this is where>
};

but opening advanced settings ingame causes my next post

[Brokken]

Getting the same error as him... except Line 845. don't know what his Solution two posts later is supposed to be. Can anyone tell me?

Crash when trying to open Advanced Settings, compiled with this patch only against r24623
Assertion failed at line 1090 of daylength/src/settings_gui.cpp:
this->d.entry.setting != NULL

btw I'm using:
MinGW on Win8x64
the latest trunk
tdl r24599.patch

[Kogut]

the latest trunk
tdl r24599.patch

Use r24599, as specified in patch filename. Or wait for patch update.

[Brokken]

Ok, I guess I could have thought of that... But I didn't, so thank you very much, it seems to be working now

[pavel1269]

Just a rather simple question...I don't believe anyone develops a patch or applies it for himself, without creating a working executable version.

The first version of this patch I have on my computer is r20153. There I definitely had a nice working executable and it might even be somewhere here in the topic. Over the time as I only update the patch I compile without optimizations which means that I can test the version, but it is completely unplayable and that's the reason I don't upload such a version here as I often just test if I can actually

Nevertheless here is the update also with the executable. I'm sorry that the executable is saved on a server like that but upload here did not work.

Working build: http://ulozto.net/xQLnYswJ/ottd-r25493- ... length-zip

[Brokken]

Thank you very much

[starscr3am]

Well Pavel, you just mad my day! I waited months for a new day lenght patch! Thank you so much.

[Djohaal]

From what I gathered reading this thread, when you increase the duration of year -all- the game simulation variables get streched to match, what means factories produce much more slowly right?

One thing I'm experience while playing this patch is that my convoys spend the greater portion of (real) time sitting on stations waiting for goods to pile up since production is much slower. While the passing of years change is acceptable and makes the game far more enjoyable, a great portion of that time is spent waiting for things to actually happen.

Did you consider making the overall timeline progression slower while keeping the industry productivty rates (when compared to real time) higher? To compensate that income is processed faster, all expenses should also be raised accordingly. That's the solution used by simutrans, when you raise their "bits per month" variable (which determines the lenght of a month), all the variables get multiplied by the altered coefficient, except the speed of your trains, so when you, say, increase the month duration x4, all your trains can do four times more hauls in the month. They offest that by also multiplying all the expenses by the lenght factor.

I'm not sure if what I'm suggesting is just too complicated and wouldn't be feasible to implement tho it seems that was already done and royally broke GRFs.

[Eddi]

some daylength patches had a setting for that

[pavel1269]

Djohaal: Yes, I considered that and from the very beginning and it was actually my plan. To slow down years by lets say 20 times and slow down production by 5 times.

First of all, when I coped with NewGRF compatibility, I noticed, that multiplying just ticks per day breaks NewGRFs. With this helped me George, the author of ECS. I found that I would have to change all callback times and that was just not good approach for me. So I am now skipping tick incrementation.

With the ordinary day length patch approach, the productions are the same so I wanted to lower the industry production. If you look at my first approach, I already implemented that, but it works only for non-NewGRFs, which is not really usable.

So now, the production is slow and I see only two possible approaches for it to get multiplied. First, create a day length patchvar for the NewGRFs to cope with day length modification. Second, simply multiply all productions, including callback(s), but for NewGRFs, keep track of original productions as well, because you have to provide to them the unmodified numbers or you will break them. *

Both of these approaches are more or less for different patch, simply "Multiply production" which would be used with conjunction with day length. For myself, I altered station ratings so I am not punished for train not waiting 24/7 in the station, and thus I am happy without the multiplying production.

edit: * But only for primary industries, secondary should be left unmodified.

[Djohaal]

Yeah that is a difficult issue to tackle. SpComb's pack (which I beleive eddi is mantaining now) seems to alter the production rates, am I right?
Thanks for the attention