[Patch] Daylength, Cargodist with sprinkles

[Kogut]

Is it possible to merge more height level patch with cargodist++?

[Eddi]

they should be fairly independent from each other, so merging should be pretty straightforward. you'll have to do that manually yourself, however

[SpComb]

Is it possible to merge more height level patch with cargodist++?

As Eddi said, with a little luck, yes. But I'm not going to try it myself. Pulling autosep into these builds was a little risky already, and I'm very uncomfortable with pulling in any more random patches.

PS: expect to see an updated build once fonso pushes out the updated smallmap.

[SpComb]

Here's an updated v1.1.x series build against r19152 including the updated smallmap-zoom-in as merged with trunk, the reworked autosep patch, and ~200 bits of stuff from trunk.

As usual, no savegame compatibility

Outdated: See openttd-cargodist-minipack-r19387M

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

The win32 .zip and git .patch are also attached.

Patches included:

• cargodist
• automated-timetables-and-separation
• variable-daylength-01
• variable-daylength-02-towngrowthfreq
• variable-daylength-03-autofill-roundoff
• town-cargo-factor-01
• daily-autosave-00
• vehicle-name-length

Crash reports / feedback:
Please report any and all crashes from this build in this thread. 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.

Outdated: See openttd-cargodist-minipack-r19387M

[ChillCore]

As usual, no savegame compatibility

Code: Select all

line 4611		 SLE_CONDREF(Vehicle, ahead_separation,      REF_VEHICLE,                138, SL_MAX_VERSION),
line 4612		 SLE_CONDREF(Vehicle, behind_separation,     REF_VEHICLE,                138, SL_MAX_VERSION),
line 4621 		 SLE_CONDVAR(Vehicle, current_loading_time,  SLE_UINT32,                135, SL_MAX_VERSION),
line 8062		 SDT_CONDVAR(GameSettings, economy.town_cargo_factor,           SLE_INT8, 133, SL_MAX_VERSION, 0, 0,     0,   -16,      +8, 1, STR_CONFIG_SETTING_TOWN_CARGO_FACTOR,      NULL),
line 8070		SDT_CONDBOOL(GameSettings, order.timetable_automated,                      67, SL_MAX_VERSION, 0, 0,  true,                    STR_CONFIG_SETTING_TIMETABLE_AUTOMATED,    NULL),
line 8071		SDT_CONDBOOL(GameSettings, order.timetable_separation,                     67, SL_MAX_VERSION, 0, 0,  true,                    STR_CONFIG_SETTING_TIMETABLE_SEPARATION,   NULL),

Change numbers just before SL_MAX_VERSION to 139 or higher(trunk is at 138) for all of the above lines.

Code: Select all

line 8060	SDTG_CONDVAR("daylength_factor",                                 SLE_UINT8, 0, 0, _date_daylength_factor, 1,     1,     255, 1, STR_CONFIG_SETTING_DAYLENGTH_FACTOR,       NULL,                               133, SL_MAX_VERSION),

should read:

Code: Select all

SDTG_CONDVAR("daylength_factor",                                 SLE_UINT8, 139, SL_MAX_VERSION, _date_daylength_factor, 1,     1,     255, 1, STR_CONFIG_SETTING_DAYLENGTH_FACTOR,       NULL),

If this line was like that in the daylenght patch you used you really, really should report it there as to me that looks like a major booboo.



It could be that you have to replace:

Code: Select all

line 8052		SDTC_CONDOMANY(              gui.autosave,             SLE_UINT8, 23, SL_MAX_VERSION, S, 0, 3, 6, _autosave_interval, STR_NULL, NULL),

to read:

Code: Select all

line 8052		SDTC_CONDOMANY(              gui.autosave,             SLE_UINT8, 23, 138, S, 0, 1, 4, _autosave_interval, STR_NULL, NULL),
line 8053		SDTC_CONDOMANY(              gui.autosave,             SLE_UINT8, 139 , SL_MAX_VERSION, S, 0, 3, 6, _autosave_interval, STR_NULL, NULL),

but I am not sure as it might conflict with this:

Code: Select all

SDTC_OMANY(gui.autosave,                  SLE_UINT8, S,  0, 3, 6, _autosave_interval,     STR_NULL,                                       NULL),

a few lines below. Also this last line is in the unsaved settings section(that is the reason why I am not sure).


note:
I did not compile and test I just searched for SL_MAX_VERSION in your patchfile.
And if trunk bumps you should change the numbers again.

ps:
Including more heightlevels is not that hard but:
I still am able to crash it by placing airports near the borders.
I still have to extend the purple and dark green smallmap heightlevel colours (no asserts but high levels all have the same colour untill extended).
When clicking the smallmap the main viewport positioning is slightly off since the zoom out option was included and I have not yet tried with fonsos new code. Before the zoom out commit to trunk it was easy (also it was/is the only conflict with cargodist).
If you are willing to deal with the boohoos I could give it a go one of these days.

pps:
Sorry for the messed up coding style but the forum does not allow double spaces(autoreduced to one) and using codeblocks would be table braking.

EDIT:
Thanks Yexo.
Sorry small monitor users.

[Yexo]

Sorry for the messed up coding style but the forum does not allow double spaces(autoreduced to one) and using codeblocks would be table braking.

It does if you use [ code ] tags (without the spaces), like this:

Code: Select all

SLE_CONDREF(Vehicle, ahead_separation,      REF_VEHICLE,                138, SL_MAX_VERSION),

[SpComb]

If this line was like that in the daylenght patch you used you really, really should report it there as to me that looks like a major booboo.

I wrote it, and it's fully intentional. Note that it's an SDTG_CONDVAR - the arguments to the macro are in a different order. How good a choice this is is questionable, but it saved me from a lot of #include ordering pain.

As usual, no savegame compatibility

Change numbers just before SL_MAX_VERSION to 139 or higher(trunk is at 138) for all of the above lines.

You're right, I really should be fixing these for compatibility up from trunk, at least.

[ChillCore]

If this line was like that in the daylenght patch you used you really, really should report it there as to me that looks like a major booboo.

I wrote it, and it's fully intentional. Note that it's an SDTG_CONDVAR - the arguments to the macro are in a different order. How good a choice this is is questionable, but it saved me from a lot of #include ordering pain.

I did not know about the different order. I rest my case.

As usual, no savegame compatibility

Change numbers just before SL_MAX_VERSION to 139 or higher(trunk is at 138) for all of the above lines.

You're right, I really should be fixing these for compatibility up from trunk, at least.

With the moreheightlevels patch I bumped all values to 200/201 to save me the hassle.
cargodist does the same but uses different values(2 bumps to go).
If you want to do it the same way you should use an enum and not #define as Alberth was so kind to point out to me.

[bluebottle]

Obsolete: New build here.

This is a fresh build of r19152 for Ubuntu 9.10 (Karmic Koala), using SpComb's patch here.

• 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 more useful core dumps/backtraces.

Download: openttd_cargodist_minipack-r19152-no_debug-unstripped_i386.deb

As usual, no savegame compatibility

Crash reports / feedback:
Please report any and all crashes from this build in this thread. 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.

[michielh]

I keep having crashes with the latest build.. The game just keeps freezing at a random point ingame.

I've included the crasfiles

[fonso]

michielh: That's most likely a problem with the time table patch. The dump shows that somewhere, probably in UpdateVehicleTimetable(), the vehicle pointer v becomes NULL, which causes a Segfault later. But I can't quite get the MSVC IDE to match up the binary with the correct source code, so I can't give exact line numbers.

[Gathers]

The "Bytes at instruction pointer" in crash.log is the exact same as for a crash I fixed in autosep 0.71 (latest as of mar 6th) so it's probably that bug.

(To work around it, make sure to stop or de-automate vehicles before removing their shared orders, as that should be what triggers the bug.)

[SpComb]

Outdated: See openttd-cargodist-minipack-r19527M

Not dead yet! Here's an updated build to bring us further along trunk/cdist, as well as a fixed autosep for this crash.

Note that for this build, I tweaked the saveload versions a little. This build should now be able to load savegames from all previous official versions, as well as the matching cargodist version. As with cargodist, this build does not support loading games from previous versions of this build.

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

The win32 .zip and git .patch are also attached.

Patches included:

• cargodist
• automated-timetables-and-separation
• variable-daylength-01
• variable-daylength-02-towngrowthfreq
• variable-daylength-03-autofill-roundoff
• town-cargo-factor-01
• daily-autosave-00
• vehicle-name-length

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

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.

Outdated: See openttd-cargodist-minipack-r19527M

[bluebottle]

Obsolete, check here.

This is a build of r19387 for Ubuntu 9.10 Linux (Karmic Koala), using SpComb's patch here. 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 more useful core dumps/backtraces.

Download: openttd_cargodist_minipack-r19387-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.

Thanks SpComb!

[bokkie]

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.

Tried to change a road to one-way but then OpenTTD crashed on me: it's reproducible every time. It doesn't happen when building a new (one-way) road.

EDIT: also, seperation works strangely... on a route taking 93 days, with 3 busses the difference in starting date is 15 days (should be 23). With 6 busses, it's about 14 (should be 13, which is about right). And when selling busses until there are 2, the difference in starting date is 5 (should be 54, route now takes 109 days) even after FF-ing a few years.

[SpComb]

Tried to change a road to one-way but then OpenTTD crashed on me: it's reproducible every time. It doesn't happen when building a new (one-way) road.

Thanks. I'll have to take a better look at this later; the assertion itself is very generic, so I can't tell very much from it. It might be fixed in a newer trunk revision; I somewhat doubt that any of these patches affect the road code directly.

[Gathers]

EDIT: also, seperation works strangely... on a route taking 93 days, with 3 busses the difference in starting date is 15 days (should be 23). With 6 busses, it's about 14 (should be 13, which is about right). And when selling busses until there are 2, the difference in starting date is 5 (should be 54, route now takes 109 days) even after FF-ing a few years.

Which busses are you talking about? I had a quick look at your savegame (had some missing AIs and grf's) but couldn't spot any obvious bugs. Sometimes the difference in starting date seemed off but if I stopped other traffic or removed busses it seemed ok again. It might just be that traffic often makes the travel-times so random that this difference fluctuates?

Though if you could recreate this behaviour in a more "controlled" area on a map I'd be glad to take a deeper look!

(please post any future replies concerning separation in this thread)

[ostlandr]

Wow! The autosep patch really works! I had been playing "vanilla" OTTD for awhile when 1.0 came out, and I hate when buses bunch up.

The combo of cargodist with daylength and autosep really rocks!!! These buses were running nose-to-tail, and as soon as the auto timetable kicked in, they separated as seen in the screenshot. Now I have virtual bus drivers who can actually drive a route and keep a schedule- better than real life.

[SpComb]

Tried to change a road to one-way but then OpenTTD crashed on me: it's reproducible every time. It doesn't happen when building a new (one-way) road.

Building a one-way road on on a town-owned road crashed in vanilla trunk r19387 (while trying to display the town's manager-face in the resulting error message, no less).

---

Here's an updated build to stabilize the road code, as well as an updated autosep (make it 0.72 now).

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

The win32 .zip and git .patch are also attached.

Patches included:

• cargodist
• automated-timetables-and-separation
• variable-daylength-01
• variable-daylength-02-towngrowthfreq
• variable-daylength-03-autofill-roundoff
• town-cargo-factor-01
• daily-autosave-00
• vehicle-name-length

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.

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.

[bluebottle]

Obsolete: check here

This is a build of r19527 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.

Download: openttd_cargodist_minipack-r19527-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.