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

[Korenn]

Yes, that's how I understood it. But then you would have, in absolute figures, more profit each year.

What I'm looking for is a patch that slows down gameplay, but will result in about the same profit each year as you would have on normal speed (and the same actions taken by the player off course).

In other words, the economy has to slow down as well.

I have working prototype of that. I'm now trying to figure out how to keep the animations at the original speed, while slowing down the gameplay. This turns out to be a bit of challenge since the animations are tightly coupled with the gameloop internals.

but if the economy slows down, you'll be staring at your first train for much, much longer before you have enough money to build the next one, and so on. If that's what you want then fine, but sounds very boring to me.

[chrissicom]

Yup and that's the reason I didn't slow down economy. The economy of the game doesn't go too fast in my opinion it's only that the eras pass by too fast so before you've built some cool steam tracks you'll have lots of electric trains available to you already.

[Valentijn]

Yes, that's how I understood it. But then you would have, in absolute figures, more profit each year.

What I'm looking for is a patch that slows down gameplay, but will result in about the same profit each year as you would have on normal speed (and the same actions taken by the player off course).

In other words, the economy has to slow down as well.

I have working prototype of that. I'm now trying to figure out how to keep the animations at the original speed, while slowing down the gameplay. This turns out to be a bit of challenge since the animations are tightly coupled with the gameloop internals.

but if the economy slows down, you'll be staring at your first train for much, much longer before you have enough money to build the next one, and so on. If that's what you want then fine, but sounds very boring to me.

Well, thats what I want. The reason why I want it is a different story.
In the beginning yes you will hae to be patient, but normally after a couple of years the money starts flowing in so fast I can't spend it in time!

The reason I want it is because I have some issues with my arms and hands, which prevent me from playing at normal speed.

[chrissicom]

I had another idea which in addition with the daypatch will do what you want. It's only on paper yet though and I have no working implementation. I intended to add a full tax system to the game where you pay income taxes etc. drastically reducing your profits. When you look closely your profits are "normal" but in real life you would pay a lot of taxes so your income are not the same as the profits.

[athanasios]

Valentijn's request is sound. In most games you can adjust the speed of the game. Should be the same in OpenTTD, and not only FF.

[Valentijn]

Valentijn's request is sound. In most games you can adjust the speed of the game. Should be the same in OpenTTD, and not only FF.

exactly. Apart from my personal 'wish', it's quite a common option. I can make a patch easily to have it run twice as slow as normal (or twice as fast). That will work ok. A downside is that smoke from factories and stuff also runs twice as slow (or twice as fast).

I'll make the patch and see if there's enough people liking it to have in in the trunk someday.

[planetmaker]

Current Version 4
Latest Revision I tested the patch with: r11060 (10/09/2007)
This patch was submitted to FlySpray as well since I'd really like this patch in trunk
http://bugs.openttd.org/task/908

I'd love to see it in trunk, too.

But is it just me, or is it a general thing? I cannot apply this patch anymore to the current revisions of the nightlies (r11539).

[pavel1269]

i'd love to see it in the trunk too, but there might be something to do.
here is an update:

[zhargon]

First time I've dropped in since miniIN died, & found the 6.0 beta, and lots of GRFs from TTDpatch work ! Great & thanks to all ....
- now, is there an updated executable of the Daylength Patch for 6.0 yet? (or will there be?) ((5.0.99 in the zip))
thanks

[chrissicom]

There will be yes, but first I will fix ChrisIN.

[pavel1269]

good to see you are active again
i am looking forward to see new features in daylength and in chrisin too

[andrewas]

This patch seems to affect savegames in some way. Under certain circumstances, saving will generate the assertion:

File:saveload.cpp
Line: 460

Expression: X>=0 && X<=65535.

It seems to fail as soon as you try and save with more than a couple of trains running on a 1024*1024 map - Ill try and narrow that down later. I know its harder to crash on smaller maps.

As for GRFs installed, I have george's ECS vectors, the UK renewals train set, genric trams, long vehicles, newships, planeset and newstations.

EDIT] Should have added that the patch was compiled against nightly 11542 as indicated in the filename, and not 11444 as indicated in the patch itself. Compilation against 11629 failed outright.

[init]

This patch seems to affect savegames in some way. Under certain circumstances, saving will generate the assertion:

File:saveload.cpp
Line: 460

Expression: X>=0 && X<=65535.

It seems to fail as soon as you try and save with more than a couple of trains running on a 1024*1024 map - Ill try and narrow that down later. I know its harder to crash on smaller maps.

Ahh, you have narrowed down the bug that I hit with ChrisIN to a single patch, that's nice. I stopped playing ChrisIN because of this bug.

[andrewas]

So this is a long-standing problem then? How did it manifest for you? I haven't been able to crash it on a smaller map yet, Ill try a game on a 512*512 map and see how it stands up.

EDIT] Just as bad.

[init]

So this is a long-standing problem then? How did it manifest for you? I haven't been able to crash it on a smaller map yet, Ill try a game on a 512*512 map and see how it stands up.

EDIT] Just as bad.

I played ChrisIN on a 2048x2048 map, and when trying to save after around Christmas 1950, it failed ("crashed") on the assertion.

[andrewas]

Doesn't really sound like the same issue then - Ive had this happen at the end of the first month, just playing normally. Unfortunately, the assertion doesn't provide much information and I run into heisenbugs whenever I try and attach a debugger to it - I get crashes somewhere in NT with debug = 2, and a crash in the midi player with debug = 1. Currently downloading Debian, hopefully it'll give me better results than cygwin. Most likely Chris will post a fixed version just as soon as I get a viable backtrace.

[andrewas]

Finally got a backtrace out of it - the crash seems to occur while saving _date_desc.

[pavel1269]

Friendly update This is best patch which i can play with ...

*update* sameone had problems while compiling ... new version

[Forked]

File:saveload.cpp
Line: 460

Expression: X>=0 && X<=65535.

I got around this problem in what I imagine is the ugliest way possible..

I changed:

case SLE_FILE_U16:assert(x >= 0 && x <= 65535); SlWriteUint16(x);break;

to:

case SLE_FILE_U16:assert(x >= 0 && x <= 965535); SlWriteUint16(x);break;

It compiles and it works.. we have a game going on 16k x 128 with 150ish trains and no problems at all so far.
(I don't know anything about C++ or anything.. I just figured that "x" in this case was bigger than 65535..)

oh btw.. I'm pretty sure this breaks compatability with all other savegames .. it also probably broke something else.. but I haven't noticed it so I'm happily playing multiplayer with daylength set at 20

[Bilbo]

I got around this problem in what I imagine is the ugliest way possible..

You only masqueraded the problem, not solved it. Perhaps full backtrace from GDB at point of that assertion would reveal the cause ....