[Patch] Daylength, Cargodist with sprinkles

[Eddi]

any chance you can check whether you can include the "Leave on Time" patch (http://bugs.openttd.org/task/2534) into your patch pack? I haven't checked if the patch is any good, but it was requested here: http://www.tt-ms.de/forum/showthread.php?tid=4645 [german]

[bluebottle]

This is a build of r19733 for Ubuntu 9.10 Linux (Karmic Koala), using SpComb's patch above. Check that post for information on the patches included as well as any caveats.

• As with the distro OpenTTD package, you need to have the data files in /usr/share/games/openttd/data/.
• This build is unstripped to provide better (i.e. useful) core dumps/backtraces.
• Any warnings about downgrading to version 1.1_svn_0 can be safely ignored.

Download: openttd_cargodist_sprinkles-r19733M-no_debug-unstripped-i386.deb

Crash reports / feedback:
Please report any and all crashes from this build in this thread, unless you can also reproduce them in a nightly or cargodist/autosep build.

It's a good idea to also post the crash.* files that OpenTTD produces, along with any relevant information relating to the crash (such as a recent savegame and a description of the circumstances of the crash).

Additionally, comments or suggestions as to the behavior of the auto-separation patch should go into the Automated timetables and separation topic.

I won't be producing any binaries for Ubuntu 10.04 for at least a couple of weeks.

[Freak_NL]

Are there any Ubuntu users that actually need binaries? Building and patching OpenTTD is quite manageable on Linux.

I'm ten years into playing a game (starting in 1920, 2048*2048) with Chill's patch-pack (including this patch set) and the daylength set to 3. No complaints so far; it's nice to be able to take your time to build and extend a large network without having to worry about upgrading all those steam engines when you've barely started.

[DJ Nekkid]

is this build compatible with 19601's savegames?

[SpComb]

is this build compatible with 19601's savegames?

Tentatively, yes, since fonso hasn't changed cargodist's savegame stuff since then.

[SpComb]

If you want something (like an updated version), you need to learn to ask for it (or has everyone moved over to CPP?). It won't come by itself.

Updated version, including many hours of messing around with git to rebase everything against fonso's new branches. The public git repo has not been updated yet.

Includes recent changes from cargodist, as well as ~1.5 months worth of trunk.

Download: openttd-cargodist-sprinkles-r19964M-win32.zip (.pdb.gz, .patch, .svn.patch, .log).

The git .patch is also attached, but the win32 .zip doesn't fit in the 4MiB attachment size limit anymore. Download from the above link.

Savegame compatibility:
This build should be able to load games saved by all previous official OpenTTD versions, as well as the matching vanilla cargodist build.

No word on compatibility with previous cargodist-sprinkles builds.

Crash reports / feedback:
Please report any and all crashes from this build in this thread, unless you can also reproduce them in a nightly or vanilla cargodist/autosep build.

It's a good idea to also post the crash.* files that OpenTTD produces, along with any relevant information relating to the crash (such as a recent savegame and a description of the circumstances of the crash).

Additionally, comments or suggestions as to the behavior of the auto-separation patch should go into the Automated timetables and separation topic

[ostlandr]

Thankyouthankyouthankyou!!!!!!!!

I really appreciate the update.

[fonso]

I'm sorry for the butchering in my git repository, but it had to be done sometime. I didn't know anyone was regularly pulling from it. I'll be more careful from now on.

[SpComb]

I'm sorry for the butchering in my git repository, but it had to be done sometime. I didn't know anyone was regularly pulling from it. I'll be more careful from now on.

Agreed; It was inconvenient, but understandable.

I had based my own feature-branches off your master branch, to be in sync with cargodist in terms of what trunk revision it's based off.

[Kogut]

Crash, but not with newest version

[Kogut]

Click on aircraft in station menu results in list of ships, clicking on ship results in aircraft list.
Thanks for that pathpack!

[ChillCore]

The second one was a bug in trunk which has been fixed in r19968.
I do not know if the crash is related.

And I agree very nice patchpack indeed.

[Kogut]

OK, so I am waiting for new pathpack version.

[boogieman1402]

First of all, thanks for all the effort put into this, makes for a nice game experience

Second, apologies if I'm 'blaming' the wrong patch, I'm making a bit of an educated guess.

I'm playing a game running ColdIce's build of Chillcore's patchpack, R20030 (v7). I've noticed when I set the daylength factor to a large value (64 in the current game), town growth goes negative. In about 6 months time, one town I just started servicing dropped in population from over 6000 to slightly less than 3000, another from 4000 to 2000. Both towns were being services with a single station where passengers, goods and food were being delivered (I'm using FIRS). Another town, being serviced by 6 different stations grew to a 20k population with a shorter daylength setting, then dropped to barely 5000 in a few months with the high daylength setting.

When I set daylength to 4, I see those towns start growing almost immediately, so it seems I did get the idea

Potentially relevant settings: Town growth speed is normal, town cargo generation factor -1

I'm running this game with TTRS 3.02a, but I don't think that's involved. I noticed the same behaviour with the previous version of Chill's pack (V6.3) and I wasn't using TTRS then.

Any other info needed, let me know. I'll also be happy to provide a savegame.

[ChillCore]

SpComb, just for information,
I have increased the running_ticks in vehicle_base.h and in vehicle_sl.cpp from byte to uint16 in my patchpack.
I have not (yet) increased other values.

Maybe there are a few more places where values need to be increased for higher daylenght settings.

[Dante123]

for better money/income balancing due daylength the following suggestions:
would it be nice to add a function/multiplier to make trains and vehicles get old faster ? (example: make vehicles/trains/boats/plains get old faster with daylength factor ? y/n)
same thing for the running cost ?

[ostlandr]

One of the things I like about the daylength patch is that vehicles stick around longer. If I'm making too much money, I can always tweak the running costs in difficulty settings, and add some fun grfs like increased building costs.

for better money/income balancing due daylength the following suggestions:
would it be nice to add a function/multiplier to make trains and vehicles get old faster ? (example: make vehicles/trains/boats/plains get old faster with daylength factor ? y/n)
same thing for the running cost ?

[aantono]

Any chance we could get a new version of the Cargodist merged into this patch? It has a new model of supply scaling added and it would be nice to try?

[SpComb]

I've updated the git repo with a freshly merged copy. The old git repo was replaced entirely due to the changes from back in June, so you'll need to check out a fresh copy to use it (or rebase...).

for better money/income balancing due daylength the following suggestions:
would it be nice to add a function/multiplier to make trains and vehicles get old faster ? (example: make vehicles/trains/boats/plains get old faster with daylength factor ? y/n)
same thing for the running cost ?

Fixing the money/incoming balancing issues in the game isn't my priority, and "add a new advanced option" isn't really a good solution for it either.

I have increased the running_ticks in vehicle_base.h and in vehicle_sl.cpp from byte to uint16 in my patchpack.

Check, I've included this as well.

I'm playing a game running ColdIce's build of Chillcore's patchpack, R20030 (v7). I've noticed when I set the daylength factor to a large value (64 in the current game), town growth goes negative. In about 6 months time, one town I just started servicing dropped in population from over 6000 to slightly less than 3000, another from 4000 to 2000. Both towns were being services with a single station where passengers, goods and food were being delivered (I'm using FIRS). Another town, being serviced by 6 different stations grew to a 20k population with a shorter daylength setting, then dropped to barely 5000 in a few months with the high daylength setting.

This is very likely to be a direct result of this patch, since it directly modifies the town growth rates (more ticks between town growth steps; ~same number of town growth steps per month). This was because it was difficult to service a town with 20k pop using just BR92's...

I've only ever play-tested with a daylength factor of 4 or so, and it's defiantly plausible that there's a decrease in town pop in the long term, and that the effect is more drastically visible with extreme daylength settings (64 counts as such).

Currently, I'm not exactly sure what time interval is used for shrinking the towns, but there's some mechanism going awry when the town growth happens too rarely.

Needs more investigation.

[aantono]

Just to clarify - do a git pop from http://git.qmsk.net/?p=openttd;a=shortl ... -sprinkles and compile? No more need to patch the official trunk?