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

[Digitalfox]

Awesome job! This was one of only two patches (the other being the plane crash reducing patch)I was waiting for to make the nightly more playable (to me, so don't flame!) than 0.5.2 or the last MiniIN.

Is there anyone who would be so nice as to send me an .exe with this patch? I can apply the patches but have yet to sucessfully compile afterwards. Still working on figuring that out.

If you use windows you can try this tool

http://www.tt-forums.net/viewtopic.php?t=31823&start=0

[Solomon555]

Sweet! Thanks. I'll take a look at that program.

[chrissicom]

That's a nifty tool I'll check it out too

When you are using Visual Studio to compile you have to make sure that the DirectX SDK, Platform SDK and a few other files are in place. There's a detailed explanation here: http://wiki.openttd.org/index.php/Micro ... 2B_Express

Took me a while to get it working as well so don't give up

[chrissicom]

I have made some small changes to the code, used the correct format to comment my variables and changed version to 1 since I have intensily tested this now and can also say it's perfectly multiplayer save.

I will submit it to Flyspray and maybe it gets added to trunk would be cool.

http://bugs.openttd.org/task/908

[chrissicom]

Posted a small update to the .diff so it works with the latest trunk version. I also added a win32 binary with language file for those who can't or don't want to compile themselves and are on Windows

[triple7pilot]

[Edit]Wrong Topic

[chrissicom]

A little more detail as to what is not working would be very welcome

When you are using Windows all you need to do is replace your openttd.exe and /lang/english.lng file with the ones in the attached .zip file (first post).

If you want to use the .diff file you need to have an application setup to compile OpenTTD and the latest source code from SVN. If these terms say nothing to you I assume you are using using Windows and therefore should use the files from the .zip file which should definitely work fine as I've tested them before.

If you can give us more detail about your problem we can also offer more detailed help

[chrissicom]

Just a small update for latest trunk

[chrissicom]

I've redone the patch and mostly improved the logic and readability I also submitted it to Flyspray for possible trunk inclusion Have fun playing with it.

[KrevRenko]

Hello!

I compiled this using BOTTD with r10877 from svn. Getting assertion failures in saveload.cpp line 463(unsigned 16bit check) whenever I try to save a game after more than a few game-days (~15 days?) within starting the game.

Using daytime coef. 16 on a 512x512 map. Otherwise using nothing out of ordinary.(DBSetXL 0.82, av8 and that's it)

If you need more info just tell me what to post.

EDIT: Same thing happens on 64x64 map without any GRFs.

[mr.kreezie]

I think this patch could be very useful for multiplayer games. Sinces no-one plays at midnight or when they have to work... too many changes in a short time could ruïn your company..
Is it in trunk?

[Smoovious]

Nope... but it is in the ChrisIN fork... here --> http://www.tt-forums.net/viewtopic.php? ... &sk=t&sd=a

-- Smoovious

[chrissicom]

Hello!

I compiled this using BOTTD with r10877 from svn. Getting assertion failures in saveload.cpp line 463(unsigned 16bit check) whenever I try to save a game after more than a few game-days (~15 days?) within starting the game.

Using daytime coef. 16 on a 512x512 map. Otherwise using nothing out of ordinary.(DBSetXL 0.82, av8 and that's it)

If you need more info just tell me what to post.

EDIT: Same thing happens on 64x64 map without any GRFs.

Can you send me a savegame? I'd like to load it with a debug build myself as I can't reproduce the problem unfortunately.

[KrevRenko]

OK, I have one working and one broken savegame from the same game. The earlier should load, The later crashed the game while saving.

I just hope this is not my fault (or BOTTD), there is not much to mess up with BOTTD I thought :-[

Good luck with this, I'd love to have it from the trunk

EDIT: Just realised the later save is 0 bytes long no need to upload that, however, it is from 27th Feb 1926, so 3 days later it should already crash.

[chrissicom]

Did you modify anything else when applying the daypatch? I just compiled r10972 with the latest revision of daypatch and I can't load your savegame which usually indicated an additional change you did, e.g. adding another patch that stores something in the savegame.

[KrevRenko]

Hello,

well, I assumed that since I was compiling this with BOTTD, it would be a clean single-patch compile, but apparently, things must have gotten mangled with all my other attempts at copiling without purging the cache. Compiled once again, had no problems. I'm sorry, didn't mean to waste your time.

Me stu'uh-pud.

Now, go for trunk!

[chrissicom]

Don't worry you didn't waste my time and any questions are welcome it could as well have been a bug in my patch so if you experience problems in the future don't hesitate to post again I am here to help with my patches.

[KrevRenko]

OK, so I have one thing that breaks by changing daylength, and that is timetabling.

High daylength -> few days en route -> inability to timetable in days properly. (The day unit is not fine enough, you can travel through the map in two days, half a map in one day, quarter of a map in 1 day, 1/8 of a map in 1 day, 1/32 in 1 day)

Switch to ticks for timetabling->still only get multiples of ticks per day by autofilling->nowhere near good reference values for tweaking(and hard to measure on one's own)

Since timetables are trunk code now, it is probably up to you to alter that patch to properly fill in timetabling values in ticks, or maybe use more 'human' units (maybe hours, minutes at bigger daylengths, morning/afternoon/night at lower settings?) instead of multiplying day values by ticks_per_day(or whatever the const is)...

(I haven't looked into the sources, so I just think this currently works that way by observing... is it 74 ticks per 1 day at daylength 1? I'm getting multiples of 1,184(IIRC) ticks when timetabling with daylength 16, i.e. 2,386 ticks for ALL 2-day journeys)

It is normal that a lot of things rely on the original TTD day's length, and I understand it must be tedious to fix it all. I think it's worth it, though, as it is one of the best ideas for playability (like you can really get into a family of trains before it expires in favor of a more modern wave), so keep it up, man!

Oh, this was tested with ChrisIN r10982, but I still think the interference is in the trunk code. Just to avoid another faux-pas.

EDIT: Also, what if a journey, a stop and another journey takes less than 1 day? Right now it is just manual tick-guessing as currently the autofill makes this 3 days (thousands of ticks) long.

[chrissicom]

I have thought about this issue some time ago already but at that time I came to the conclusion that timetabling in ticks is the only solution. A day is a day no matter how long it takes so when using days for timetabling you ought to use the length of the day that is current in the game or it will get really confusing.
The original day is 74 ticks which is equal to 2,22 seconds if OpenTTD doesn't require 100% CPU (50% on Dual Core respectively) i.e. runs at full speed. Daylength 2, 3 etc. is 2x74 ticks, 3x74 ticks etc. so at daylength 16 one day will take 35,52 seconds in theory but you need to take into account that not every machine runs OpenTTD at full speed so with higher daylengths this number becomes more and more an approximation of the real time. So it's easier to speak of it in ticks, as ticks stay ticks no matter how long one takes. So daylength 16 equals 1184 ticks. Iirc timetabling is possible in 1-tick steps so you can handle the timetables in a really exact way.
What is currently done by daypatch, that when using timetables / day instead of / tick then the daylength you have set will be used instead off the original daylength (which is called DAY_BASE with this patch). Of course I could change the way timetables handle days so that it always uses the original days but I think that leads to confusion.
Anyway don't hesitate if you have a good idea how to improve this situation as I want to make this patch good enough to make it into trunk

[KrevRenko]

Well, it is difficult to say out of one's head if a journey will take 8000 or 9000 ticks.

That's what the autofill feature is for.

The problem is, when autofilling the timetable in ticks, the timetable will NOT be filled with real travel lengths, for example:

Assume daylength 16, then 1 day = 1,184 ticks.

Train goes A -> B in 1,800 ticks ~ 2 days.

It fills num_days * ticks_per_day into the timetable when autofilling.
In this case, that becomes 2 * 1,184 = 2,386.

2,386 - 1,800 = 586 ticks of inaccuracy with no way of telling how you should adjust the timetable in game.

I think it would be enough to either:
-modify timetable autofilling so that it fills in real travel times, i.e. 1,800 instead of 2,386 ticks,
or:
-call 74 ticks a timetable-unit(TTU)(*insert smart name here*) and have timetabling use that as a unit. That would mean that timetables would remain constant even if you change daylength mid-game (i.e. user wants to rush through an era boring for him, then slows time down for Age of Fun)

Personally, I think the second solution should not be hard to code, wouldn't break anything and the numbers would be simpler to manage(users don't wantto mess with hundreds and thousands as it is with ticks)

What do you think of this?