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

[chrissicom]

Just posted an updated version which does not build up on the previously released version though but was written from scratch once again. I made it as less intrusive as possible. There is only one option now to set the daylength factor. Vehicle running costs are now automatically adjusted according to the daylength and this is not an option anymore. I decided for this for two reasons. Firstly there's less code to change and secondly it doesn't make sense not to adjust the running costs as it would make the vehicles utterly cheap to maintain and the game even easier than it already is. Cargo payment rates are not affected by this patch which means that in theory you can transport "normal cargo amount * daylength factor" per year and get paid accordingly.

[PhilSophus]

Nice little patch

However, it might be a bad idea to define DAY_TICKS as a non-constant value. All-caps usually implies a constant and some code may rely on the fact that DAY_TICKS does not change, though I didn't find obvious problems like initializing a constant with it when doing a quick search.

Replacing all occurrences of DAY_TICKS with DAY_TICKS * _settings_game.economy.daylength (there aren't that many) while increasing the patch size would be cleaner IMHO.

BTW, I just noticed that the following code in aircraft_cmd.cpp (and the other vehicle command files) does not scale by daylength factor as the factor _settings_game.economy.daylength is both contained in the enumerator and implicitly in the denominator in DAY_TICKS. Was that intended?

Code: Select all

CommandCost cost(EXPENSES_AIRCRAFT_RUN, GetVehicleProperty(this, 0x0E, AircraftVehInfo(this->engine_type)->running_cost) *
                 _price.aircraft_running * _settings_game.economy.daylength * this->running_ticks / (364 * DAY_TICKS));

[chrissicom]

That is intended because the costs per year are multiplied with the value of daylength and this small part "this->running_ticks / (364 * DAY_TICKS)" defines how many ticks the vehicle was actually running so we need to divide running_ticks by 364 * the actual DAY_TICKS and not 74 which is just the default value. I am playing a game with my brother with this patch for a few hours already (game years) and see no negative behaviour so far.

The reason I simply changed the DEFINE for DAY_TICKS into a non-constant value was because I didn't want to change so much code in so many places. It's not just the running costs, but for example also the time competitors start that is influenced by DAY_TICKS.

I know it's not a perfect solution yet though that's why I didn't feel like submitting it to flyspray for trunk consideration

[Eddi]

for a patch that is likely to never ever get to trunk (in this form), modifying as little code as possible is much more important than codestyle.

especially when you want to keep it in sync with other patches, like timetables, which make heavy use of the DAY_TICKS "variable", which would immediately create conflicts all over the place

[SVW-Gigant]

Hi, any German lang version of this patch-version too?

And are the 3 options planned in future (running costs, delivery costs and poduction factor)?

[Gremnon]

They used to be included, and still are, only now you don't get to choose if they're on or not.
Which is why I'm sticking to the old daylength. It still compiles for me, so I'll use it instead.

[PhilSophus]

for a patch that is likely to never ever get to trunk (in this form), modifying as little code as possible is much more important than codestyle.

especially when you want to keep it in sync with other patches, like timetables, which make heavy use of the DAY_TICKS "variable", which would immediately create conflicts all over the place

Being the author of the patch you are probably referring to , that was exactly what I was worried about. I certainly don't assume a constant changing its value. So, while this dirty trick might make patching and compiling seemingly easier, expect strange things to happen in timetables when changing daylength. Conflicts would actually be an indication that the patches could interact in an undesired way and force you to think about how to do correct that. Lucky enough the internal base unit in the timetable patch is ticks, so maybe only the GUI part would be affected.

[Wolf01]

for a patch that is likely to never ever get to trunk (in this form), modifying as little code as possible is much more important than codestyle.

Not always

especially when you want to keep it in sync with other patches, like timetables, which make heavy use of the DAY_TICKS "variable", which would immediately create conflicts all over the place

That's why I wanted to rewrite my daylength patch (the latest version on which this one is based) to be changed only when creating a new game
I noticed that too many changes to the daylength during game are bad, but if you start with a value and continue to use it, all runs well
What does this mean? 1) Can be stored in savegames but doesn't need to be MP safe, since you won't be able to change it anymore; 2) no more problems with timetables; 3) no more problems with income/cargo payments graphics; 4) no more problems with vehicles reliability/running costs

If it was for me I would have set a constant to 86400 and left it there, in the right places

[Eddi]

for a patch that is likely to never ever get to trunk (in this form), modifying as little code as possible is much more important than codestyle.

especially when you want to keep it in sync with other patches, like timetables, which make heavy use of the DAY_TICKS "variable", which would immediately create conflicts all over the place

Being the author of the patch you are probably referring to , that was exactly what I was worried about. I certainly don't assume a constant changing its value. So, while this dirty trick might make patching and compiling seemingly easier, expect strange things to happen in timetables when changing daylength. Conflicts would actually be an indication that the patches could interact in an undesired way and force you to think about how to do correct that. Lucky enough the internal base unit in the timetable patch is ticks, so maybe only the GUI part would be affected.

well, yes, you were worried about it, but all i ended up doing was replacing every occurance of "DAY_TICKS" with "DayLength()", and i don't recall having any serious problems, except i could not update properly, because of the conflicts... the only option was to rip all patches out, and assemble them again,

note that the initial patching process had no or very few conflicts, because the new timetable lines were not touched by daylength at all.

[PhilSophus]

@chrissicom: I described a playability issue with ECS vectors and daylength patch in this post. IMHO one solution to the problem would be to call monthly loops n times per month for a daylength factor of n.

[Tekky]

IMHO one solution to the problem would be to call monthly loops n times per month for a daylength factor of n.

Hmmmm, I don't think this would be the ideal solution, because some code relies on the fact that the monthly loop is called exactly once per month (for example factories updating their "production last month" statistic), while other parts of the code just require that the monthly loop be executed "from time to time" in fixed intervals and don't care whether this interval truly is a calender month.

For this reason, I believe the daylength patch will have to introduce two kinds of monthly loops

1. monthly loops which retain their literal meaning
2. monthly loops that are called every 74*30 ticks, i.e. the number of ticks that a month has without the daylength patch. These loops should no longer be called "monthly loops" so they can't be mixed up with the literal monthly loops. It may be best to give these loops names according to real time instead of game time, for example have one loop that that is called every second, one loop that is called every minute and one that is called every 10 minutes, in addition to the loop that is called in intervals equivalent to one month of non-daylenth time, which is only provided for compatibility for code that is not daylength-aware.

[Eddi]

i don't understand the problem you describe there.

what i did in my local modification of daylength was to only call the 256-tick-callback for newgrf industries only every daylength*265 ticks. that way, the production cycles of newgrf industries are downscaled to the same amount every month, regardless of daylength.

[Gremnon]

Hope no one minds me doing this.
I fixed a little problem with the diff where there was a bit failing in saveload.cpp. Uploaded the new diff, it's otherwise the same as the old one, still works with the nightlies for now.

[SargeFIN]

Is it possible to get this patch working in 0.6.3 version?

I downloaded this patch and overwrited the openttd.exe and one file in lang directory. After that the game won't start.

Is there a newer patch or how can I get this to work?

EDIT: Hmm, do I also have to load the .diff file which is in the first page? In same post where is the .zip file?

[fire87]

Since I installed OpenTTD on Vista, and added some new sets here and there (mostly basic), I found out after throwing up a game that I was unable to save properly, i.e. a nice little message pops up.

I will be unable to provide a savegame, because the game doesn't let me save.
Here is the message:

Code: Select all

*** OpenTTD Crash Report ***
Date: 2008-12-03 22:55:49
Build: r14293M built on Sep 12 2008 13:21:03
Reason: Assertion failed at ..\src\saveload.cpp:506: x >= 0 && x <= 65535
Language: english.lng
Exception C0000005 at 0043380E
Registers:
 EAX: 044E4318 EBX: 00000000 ECX: 0017F848 EDX: 044E435A
 ESI: 00039440 EDI: 00000063 EBP: 0017FA74 ESP: 0017FA60
 EIP: 0043380E EFLAGS: 00010206

Bytes at CS:EIP:
 88 1D 00 00 00 00 8B C6 C1 E8 08 50 E8 78 FA FF FF EB 81 3B D3 7C 14 7F

Stack trace: 
 0058A7C0 005DA4BC 00000063 0058A7C0 005A2810 0017FA98 00433FDB 005DA4BC
 00000000 0058A7C0 0041DF8F 00434030 00586EC0 0058A938 0017FB60 0043422E
 00000000 00434267 00000001 005C56F0 00000000 00434EE5 035941E1 035941F0
 00000005 76B885E7 7E5598F7 FFFFFFFE 76B2B4DF 76B2B545 00FD80E0 773B03B2
 76B2B558 0017FAF4 00000018 00000000 0017FBC8 00000000 00000000 00000000
 00000005 00000000 00000000 0017FB88 773B2ED6 0017FB24 00000000 0017FB78
 773B081D 75641380 00000000 756413A9 08EE6045 035941E1 035941E1 76B2EB36
 00000024 00000001 00000000 00000000 0017FAB8 0017FF78 00541037 00000000
 0017FB84 0042AA61 00000001 00000009 035941E1 035941F0 00000000 75473D09
 76B2EBFF 0017FB9C 0042AD89 035941F0 00000000 75473D09 75473D09 00000000
 004F0A47 005F0684 005DB1D4 0017FCDC 00000000 0017FBA0 035941F0 0359420E
 00000000 00000000 000A0614 0000000F 00000000 00000000 035941E1 0000029E
 00000291 0042A453 0017FCF4 00000001 00000001 01000112 00000000 00000A21
 FFFFFFFF 00000000 00000000 FFFFFFFF 0017FDFC 005A1C08 00000000 00000000
 00000000 FFFFFFFF 00000000 00000000 00000000 028A6C08 00000700 00000000
 00000088 0101017E 0017FB80 028A2B18 0017FD84 77442926 03240A00 FFFFFFFE
 773BF735 773BF285 00000000 028A2B20 00000080 028A9650 00000100 0017FD94
 0017FCF4 00000104 00770E5E 0017FCB8 7565E5A8 00770EBA 0017FD00 0017FCF4
 00000104 00000000 FFFFFFFE 0017FCF4 00000001 0000002E 0017FE00 0044B1CC
 0000FDE9 00000000 00770E5E FFFFFFFF 0017FCF4 00000104 00000000 0017FEF8
 0044AD8B 00000001 0017FDF8 FFFFFFFE 00000000 5C3A4322 676F7250 206D6172
 656C6946 78282073 5C293638 6E65704F 5C445454 6E65706F 2E647474 00657865
 00170020 77442926 032430B9 FFFFFFFE 773BFA88 773BF945 773E2F1F 00000018
 0017FEB4 00260036 028A0000 44707042 00000133 00000000 028A2B1F 00000080

Module information:
 C:\Program Files (x86)\OpenTTD\openttd.exe handle: 00400000 size: 1951744 crc: E4FA01B9 date: 2008-09-12 12:22:50
 C:\Windows\SysWOW64\ntdll.dll handle: 77390000 size: 1165688 crc: 13109A59 date: 2008-01-21 02:50:59
 C:\Windows\syswow64\kernel32.dll handle: 75630000 size: 855552 crc: 8BD5A7A6 date: 2008-01-21 02:48:58
 C:\Windows\system32\WINMM.dll handle: 746C0000 size: 189952 crc: D22FC585 date: 2008-01-21 02:49:07
 C:\Windows\syswow64\msvcrt.dll handle: 76DB0000 size: 680448 crc: E5AE7FEC date: 2008-01-21 02:49:58
 C:\Windows\syswow64\USER32.dll handle: 76B10000 size: 648192 crc: 71D17591 date: 2008-01-21 02:49:14
 C:\Windows\syswow64\GDI32.dll handle: 757A0000 size: 302080 crc: 8879465D date: 2008-02-22 05:01:50
 C:\Windows\syswow64\ADVAPI32.dll handle: 75BA0000 size: 798720 crc: F58CDFCB date: 2008-01-21 02:49:45
 C:\Windows\syswow64\RPCRT4.dll handle: 759C0000 size: 677376 crc: D934A698 date: 2008-04-12 03:30:28
 C:\Windows\syswow64\Secur32.dll handle: 75540000 size: 76800 crc: 60AA6967 date: 2008-01-21 02:49:02
 C:\Windows\syswow64\ole32.dll handle: 76C60000 size: 1315328 crc: 6B931D39 date: 2008-01-21 02:51:04
 C:\Windows\syswow64\OLEAUT32.dll handle: 75C70000 size: 563200 crc: B69E10E1 date: 2008-01-21 02:50:58
 C:\Windows\system32\OLEACC.dll handle: 74680000 size: 215040 crc: EF3061D3 date: 2008-01-21 02:48:27
 C:\Windows\syswow64\WS2_32.dll handle: 755A0000 size: 179200 crc: 5D581120 date: 2008-01-21 02:50:35
 C:\Windows\syswow64\NSI.dll handle: 75740000 size: 8192 crc: 10729B39 date: 2008-01-21 02:50:15
 C:\Windows\system32\IMM32.DLL handle: 75AB0000 size: 116224 crc: 7DF39BE4 date: 2008-01-21 02:49:24
 C:\Windows\syswow64\MSCTF.dll handle: 75F30000 size: 806912 crc: 66ABCC79 date: 2008-01-21 02:51:02
 C:\Windows\syswow64\LPK.DLL handle: 75E40000 size: 23552 crc: 7700F1BA date: 2008-01-21 02:49:00
 C:\Windows\syswow64\USP10.dll handle: 76BE0000 size: 501760 crc: 09CF36C9 date: 2008-01-21 02:49:13
 C:\Windows\system32\SHFolder.dll handle: 75010000 size: 7168 crc: 1CA14A5C date: 2006-11-02 09:46:13
 C:\Windows\syswow64\SHELL32.dll handle: 76000000 size: 11580416 crc: 78DE6C7E date: 2008-04-24 04:58:20
 C:\Windows\syswow64\SHLWAPI.dll handle: 755D0000 size: 351744 crc: F95C1869 date: 2008-01-21 02:50:03
 C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6001.18000_none_5cdbaa5a083979cc\comctl32.dll handle: 74B20000 size: 1684480 crc: 57ECDF87 date: 2008-01-21 02:48:06
 C:\Windows\system32\wdmaud.drv handle: 716B0000 size: 166912 crc: 5FC059D1 date: 2008-01-21 02:50:56
 C:\Windows\system32\ksuser.dll handle: 73010000 size: 4608 crc: 4C647881 date: 2006-11-02 09:46:05
 C:\Windows\system32\MMDevAPI.DLL handle: 71680000 size: 149504 crc: 29FF5B91 date: 2008-01-21 02:50:22
 C:\Windows\system32\AVRT.dll handle: 71E40000 size: 12800 crc: EB589AA0 date: 2008-01-21 02:50:36
 C:\Windows\syswow64\SETUPAPI.dll handle: 76E60000 size: 1590272 crc: BB6B35BF date: 2008-01-21 02:50:28
 C:\Windows\system32\WINTRUST.dll handle: 75180000 size: 171520 crc: EE6B6CCB date: 2008-01-21 02:49:56
 C:\Windows\system32\CRYPT32.dll handle: 74A20000 size: 977408 crc: 49821E3F date: 2008-01-21 02:50:45
 C:\Windows\system32\MSASN1.dll handle: 74FF0000 size: 59904 crc: 7A69072B date: 2006-11-02 09:46:06
 C:\Windows\system32\USERENV.dll handle: 75020000 size: 108032 crc: AC76B003 date: 2008-01-21 02:49:02
 C:\Windows\syswow64\imagehlp.dll handle: 75830000 size: 153088 crc: EEF49677 date: 2008-01-21 02:48:37
 C:\Windows\system32\AUDIOSES.DLL handle: 71650000 size: 116224 crc: 30C70121 date: 2008-01-21 02:50:36
 C:\Windows\system32\audioeng.dll handle: 712C0000 size: 397312 crc: 17666E45 date: 2008-01-21 02:50:36
 C:\Windows\syswow64\PSAPI.DLL handle: 75EA0000 size: 12288 crc: D7B812C5 date: 2006-11-02 09:46:12
 C:\Windows\system32\msacm32.drv handle: 71CF0000 size: 21504 crc: 1F6A62A4 date: 2008-01-21 02:48:15
 C:\Windows\system32\MSACM32.dll handle: 73F80000 size: 71680 crc: A2E8F836 date: 2008-01-21 02:50:47
 C:\Windows\system32\midimap.dll handle: 71C20000 size: 17408 crc: 44FD6876 date: 2008-01-21 02:48:15
 C:\Windows\syswow64\CLBCatQ.DLL handle: 75930000 size: 523776 crc: C2EBF5E6 date: 2008-01-21 02:49:34
 C:\Windows\system32\uxtheme.dll handle: 73FA0000 size: 234496 crc: 0DEE7E88 date: 2008-01-21 02:51:05
 C:\Windows\system32\dmime.dll handle: 6F000000 size: 178688 crc: 3063C87B date: 2008-01-21 02:47:50
 C:\Windows\system32\DSOUND.dll handle: 71560000 size: 444416 crc: 1F6BF3CC date: 2008-01-21 02:48:57
 C:\Windows\system32\POWRPROF.dll handle: 73020000 size: 97280 crc: 968A09AC date: 2008-01-21 02:51:13
 C:\Windows\system32\dmusic.dll handle: 714C0000 size: 101888 crc: C5478A00 date: 2008-01-21 02:47:50
 C:\Windows\system32\dmsynth.dll handle: 71610000 size: 105472 crc: 246B7E26 date: 2008-01-21 02:47:50
 C:\Windows\system32\dmloader.dll handle: 70D70000 size: 38400 crc: 43D1875C date: 2008-01-21 02:47:50
 C:\Windows\system32\mswsock.dll handle: 72EA0000 size: 223232 crc: 3746AAB9 date: 2008-01-21 02:48:39
 C:\Windows\System32\wshtcpip.dll handle: 73070000 size: 9216 crc: 10C50FC1 date: 2008-01-21 02:48:43

System information:
 Windows version 6.0 6001 S

It could be only me messing up somewhere, though I highly doubt it, as I haven't touched the game physics at all. The only patch I have is the Daylength patch. Oh, and nightly build r14293 I believe it will be...

I certainly hope atleast someone can point me out the where the problem here lies.

[Bami]

I'm having the same error, on a windows XP build compiled using MinGW, and on a unix machine using the tutorial on the site, both with revision 14293 and the current revision (only change between r14293 and the latest one is a change in the save game version number from 202 to 203 or something like that).

I want to make a game last about a month of continous play (So me and some friends can have a persistent game)

The savegame crashes sometimes, but I've found that setting the day multiplier to 4 allows me to save and load, but anywhere above that the assertion gives me an error.
Probably something like the current tick variable growing too large and growing out of its container (it's being an unsigned int 16), and therefore the assertion failing. I could fix it myself if I knew where the variable is stored (like physically, what c file), but I've done squat at ottd development.

[planetmaker]

Probably something like the current tick variable growing too large and growing out of its container (it's being an unsigned int 16), and therefore the assertion failing. I could fix it myself if I knew where the variable is stored (like physically, what c file), but I've done squat at ottd development.

Go looking into settings.cpp There the variable types of all advanced settings (patch settings) are defined.

[Bami]

My initial hunch was right, sorta, it was not the current tick that grew too large, it was the daylength variable

Daylength is saved as byte in settings, but saved and loaded as uint8. I don't know why that would fail an assert that checks if it's between values, but changing it to uint8 in settings_type.h (line 315 fixed it.)

I'll try to put out a patch, but I'm not that proefficient with coding in C/C++ (I'm a java programmer), nor with TortoiseSVN.

edit, this is strange, I compiled both with the same source, but only the windows version doesn't crash.
In other words: Starting a server in windows, and joining with the unix client: no problem
Starting a server in unix, joining with a windows client: server crashes.

[SmatZ]

If it is not known yet:
When there are more than 255 ticks a day, Vehicle::running_ticks will overflow causing too low running costs. Maybe there are more cases similiar to this one.

Daylength is saved as byte in settings, but saved and loaded as uint8. I don't know why that would fail an assert that checks if it's between values, but changing it to uint8 in settings_type.h (line 315 fixed it.)

byte == uint8 (both are unsigned char)

edit:
Crash is most likely caused by this:
SLEG_VAR(_next_competitor_start, SLE_FILE_U16 | SLE_VAR_U32),

_next_competitor_start may be > 65535 with longer daylength, causing this crash.

[Hamilton2007]

Somebody feels like adding this patch to the latest nightly, if i could i would, but patching hasn't worked for me up till now, shame...

I tried the bin from the first post but it doesn't support ECS and only English is added to Lang folder.