Chill's patchpack v14_7

[Lord Aro]

Erm
make
instead of
./make

I thought you knew how to compile...

[NekoMaster]

oh dear, i really was tired today...

[Scautura]

Wild compiled patchpack appears!

http://www.scautura.com/bg/openttd-cust ... -MINGW.zip

Diff is attached for GPL compliance and posterity:

[Melfice]

Wild compiled patchpack appears!

http://www.scautura.com/bg/openttd-cust ... -MINGW.zip

Diff is attached for GPL compliance and posterity:

Awesome!
Now, what's it for? Windows? Linux? Mac?

My toaster?

EDIT: Windows. Lovely. Works just fine!
Thanks!

[Wasila]

Chillcore, is there no other solution to my problem with demolishing roads? It's really getting on my nerves...

Thanks,
Wasila

[Gord]

Only just started playing with this pack. My goodness, just when you thought this game couldn't get any better! Thank you!

It's a shame that infrastructure sharing raises many issues in conjunction with these patches....but I'd rather go without than running the risk of constant crashing. (There used to be a passenger destination patch ages ago where passengers could walk between stations...including competitor's stations, this would make a good alternative...will have to see if I can dig it out, probably far too old by now)

Sorry, getting off topic.....


My game is going very well with the latest version of this pack so far. Thank you very much!

[hthhs]

@ChillCore

departureboards and wallclock have been updated - please check the first post of their thread if you're interested in including the newest version.

Having glanced at the timetable automation and separation patch, I'm of the opinion that my patch should not break it.

May I ask why you would want to do that? Trunk keeps almost all the files in the src folder unless they adress something very specific. eg. pathfinder, tables, saveloadcode, etc.

Having since had some sleep, I would also like to know what made me want to do that

[daBorg]

Hello,

I think I've found a conflict between the 24hr wallclock and automated timetables. The problem seems to be as follows: If you put up a train connection with a timetable and allow the train more time for a certain distance than it actually needs ( say, 8 minutes instead of the needed 7 minutes), it will not wait this time excess time in a station but simply carry on, thus moving the departure times. Moreover, this only happens
if the option "Ensure Separation using Timetables" is activated.

To show you what I mean, here are two screenshots illustrating the problem. The train should always leave Fahrdorf at five past the full hour, given that its timetable takes 60 minutes, as illustrated in the first screenshot (here the option "Ensure Separation using Timetables" has been deactivated).

The train has been running correctly for many hours, "Ensure Separation using Timetables" being deactivated.

Bildschirmfoto 2010-09-28 um 11.58.32.png (398.89 KiB) Viewed 1443 times

On this screenshot, however, the departure times are fluctuating with the train becoming earlier and earlier. This is after just one round trip! In this case, the option "Ensure Separation using Timetables" is activated.

Times fluctuating, with activated option.

Bildschirmfoto 2010-09-28 um 11.59.12.png (405.95 KiB) Viewed 1443 times

Moreover, I've tested this with the option "Automatically managed timetables" activated and deactivated, which didn't make a difference.

Ok, and finally the savegame, this is after the route has just been set up and the train leaving on the correct time.

Fahrdorf Transport, 08_40 Day 507.sav

(137.06 KiB) Downloaded 77 times

The save is from a game from patch version 10.1, comiled against trunk revision 20842.

[hthhs]

@daBorg

The separation code is setting the train's lateness counter to zero whenever it makes a stop. Therefore the train starts its next order immediately and this changes the scheduled dates of all its future orders. The departure boards and 24h clock are behaving as they should be - watch the timetable window of the vehicle; the scheduled dates of its orders will change whenever it makes a stop with separation enabled.

I wouldn't think of it as a conflict, merely the behaviour of separation being more visible. It can certainly be undesirable, though!

Incidentally, if automatic timetable management is enabled and a vehicle's timetable is automated (i.e. the Automate button in its timetable window is depressed) then its timetable length may change, thus affecting the departure boards of stations it loads from. However, if the timetable is not automated, then it will work as expected (unless separation is enabled). In my opinion, this behaviour is expected.

[daBorg]

The separation code is setting the train's lateness counter to zero whenever it makes a stop. Therefore the train starts its next order immediately and this changes the scheduled dates of all its future orders. The departure boards and 24h clock are behaving as they should be - watch the timetable window of the vehicle; the scheduled dates of its orders will change whenever it makes a stop with separation enabled.

Ok, thanks, that explains it.

I wouldn't think of it as a conflict, merely the behaviour of separation being more visible. It can certainly be undesirable, though!

That's my problem, because if I don't use automatic separation ( so the Automate button not being pressed ) I want my trains stick to their timetables and not change them on the fly. Anyways, I should probably put this in the Thread on Automated Timetables then if I want it changed .

[Wasila]

CargoDist has received a key GUI update which I'd like to make use of *hint hint*.

Are all the serious, game-corrupting bugs with v10 ironed out now? I don't want to corrupt my v9 save when I upgrade.

[ChillCore]

Chillcore, is there no other solution to my problem with demolishing roads? It's really getting on my nerves...

I have been looking at your problem a bit. I was going to say change the "attitude towards area restructuring" in the difficulty settings to permissive but it seems to be MIA. The Moreheighlevels patch decides to load the pre-savegame version 4 dificulty gui, I have not yet found why or how this happens.
There is also "Allow removal of more town-roads, ..." in Advanced settings->construction and, as someone already pointed out, there is the magic bulldozer in the cheat menu. If you decide to use the magic bulldozer do not forget to disable it afterewards, IIRC towns can also destruct a lot more then before while expanding.
Also when I tested it before I deleted those roads while the rating was outstanding and without cheating. The ratings, as seen in the screenshot, went down after removing the roads.

Only just started playing with this pack. My goodness, just when you thought this game couldn't get any better! Thank you!
It's a shame that infrastructure sharing raises many issues in conjunction with these patches....but I'd rather go without than running the risk of constant crashing. (There used to be a passenger destination patch ages ago where passengers could walk between stations...including competitor's stations, this would make a good alternative...will have to see if I can dig it out, probably far too old by now)
Sorry, getting off topic.....
My game is going very well with the latest version of this pack so far. Thank you very much!

Thank you for your kind words.
Infrastructure sharing ... there are a few issues with it, constant crashing is not one of them IIRC.
The problem for me is that, for the moment, it is no longer maintained, so fixing things would become my problem ...
I have not yet tried to merge it to see how it behaves with the patchpack. I might try to do so at some later point in time though if I can get it to work against current trunk, maybe.

departureboards and wallclock have been updated - please check the first post of their thread if you're interested in including the newest version.
Having glanced at the timetable automation and separation patch, I'm of the opinion that my patch should not break it.

It seems to be working just fine for the moment. I'ĺl have a look at updating to your latest version.

May I ask why you would want to do that? Trunk keeps almost all the files in the src folder unless they adress something very specific. eg. pathfinder, tables, saveloadcode, etc.

Having since had some sleep, I would also like to know what made me want to do that

Happened to all of us at some point I think ...

Hello,
I think I've found a conflict between the 24hr wallclock and automated timetables.
...

...
I wouldn't think of it as a conflict, merely the behaviour of separation being more visible. It can certainly be undesirable, though!
...

Thank you for having a looksie hthhs.

CargoDist has received a key GUI update which I'd like to make use of *hint hint*.

Yes, I had a looksie at it but I liked the previous version better where the links had the colour of the cargo transported. I somewhat like the new version also with the links changing color according to flow but IMHO the links become a bit meaningless when all cargos are enabled.
I will try to merge the old and the new, maybe have an entry(1 not 6) in the smallmap_gui where you choose to see or the type of cargo transported or the flow.
If I have to chose between the two I'd would prefere sticking with the old links.

Are all the serious, game-corrupting bugs with v10 ironed out now? I don't want to corrupt my v9 save when I upgrade.

I have not yet tested with version 10_1 as I have been looking at the code more than playing.
I will test again after updating the departures patch to its current version.
Also, untill now all autosaves and all manual saves with daylenght setting 1 did not corrupt. Autosaves are with longer daylenght.

[Wasila]

Also, untill now all autosaves and all manual saves with daylenght setting 1 did not corrupt. Autosaves are with longer daylenght.

Not sure I understand this. The autosaves will change the daylength setting?

[Scautura]

Also, untill now all autosaves and all manual saves with daylenght setting 1 did not corrupt. Autosaves are with longer daylenght.

Not sure I understand this. The autosaves will change the daylength setting?

As I understand it: The manual save was changed to have a daylength of 1, but the autosaves had whatever the setting was at the time.

I can support the "works fine" side - I have a manual save with daylength 3 from an earlier v9, and it loads and plays fine in the v10 I posted above. Even reloading the same game saved in v10 works fine from my point of view.

[bluebottle]

This is a build of r20842 for Ubuntu 10.04 (Lucid Lynx), using Chillcore's great patch pack. Packaged as a .deb for easy installation/removal/upgrade.

• 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. This is similar to including the .pdb file for MSVC builds.

Download: openttd_chillcore_r20842M-no_debug-unstripped-i386.deb

Report all bugs or crashes to this thread.

[ChillCore]

Also, untill now all autosaves and all manual saves with daylenght setting 1 did not corrupt. Autosaves are with longer daylenght.

As I understand it: The manual save was changed to have a daylength of 1, but the autosaves had whatever the setting was at the time.
I can support the "works fine" side - I have a manual save with daylength 3 from an earlier v9, and it loads and plays fine in the v10 I posted above. Even reloading the same game saved in v10 works fine from my point of view.

In my test game if I save manually with daylenght setting set to 10 the game will sometimes corrupt if saved manually. This will only be noticed when trying to load said savegame.

Code: Select all

Crash reason:
 Signal:  Aborted (6)
 Message: Assertion failed at line 37 of .../chipp_v10/src/date.cpp: fract < DAY_TICKS

So what I do before saving manally, usually before I stop playing, is reduce the daylenght setting to 1. I also leave the autosave enabled while playing so I can use those as a backup if my manual save corrupts, read: if I forget to reduce the daylenght setting. (for autosaves the daylenght setting does not matter.)
@Wasila: As your savegames are rather big, you can reduce the number of autosaves that are kept in the configfile somewhere.

The strange thing is that sometimes I can save my game manually with a longer dayleght setting without corrupting it.
This never happened before introducing the departures patch. Also it still happens with the latest version of the departures patch.
My guess is that it is a conflict somewhere between daylenght and the departures patch, or something that is not yet handled correctly while saving manually.
I do not think that GRFs can be the cause buit as always with OpenTTD, you never know untill you look at the code .

Also pre v10 savegames all load correctly (from v9_9_4 onwards) No matter wat the daylengh setting is/was. When saving them with v10 and v10_1 you can corrupt them however.

Edit:
Thank you for the build bluebottle.
That reminds me that I have to retry building my own now that I have Ubuntu 9.10.
I managed to install a newer debhelper in 9.04 but it still failed building on other dependencies which I have not yet investigated ... I might have a looksie later again before wiping my disk if your interested that is.

[bluebottle]

Thank you for the build bluebottle.
That reminds me that I have to retry building my own now that I have Ubuntu 9.10.
I managed to install a newer debhelper in 9.04 but it still failed building on other dependencies which I have not yet investigated ... I might have a looksie later again before wiping my disk if your interested that is.

You're welcome.

It should work fine with your 9.10. Give it a shot:

Code: Select all

mv os/debian .
(OPTIONAL) export DEB_BUILD_OPTIONS=nostrip
dpkg-buildpackage -rfakeroot -uc -us -tc

Of course, 10.10 will be out soon, so you might want to think about getting to 10.04, but maybe that's why you're wiping your disk?

[ostlandr]

I done broke it:

crash2.zip

(151.26 KiB) Downloaded 66 times

Wild compiled patchpack appears!

http://www.scautura.com/bg/openttd-cust ... -MINGW.zip

Diff is attached for GPL compliance and posterity:

[ChillCore]

Of course, 10.10 will be out soon, so you might want to think about getting to 10.04, but maybe that's why you're wiping your disk?

Did I really write 9.10? I did ... OOpsie.
I am already on 10.04 , I guess I was doing to much at once.

I can build debug builds me, yay.
The only odd thing I noticed was this: (just before building the package)

Code: Select all

   dh_shlibdeps
dpkg-shlibdeps: warning: dependency on libicui18n.so.42 could be avoided
if "debian/openttd/usr/games/openttd" were not uselessly linked against it (they use none of its symbols).

I will be wiping my 9.04 disk to have it as a data storage once I moved all my files over.
I do no really see the point of keeping it as everything seems to run smoother on 10.04.

I done broke it:

Can I see a savegame please. I can not reproduce it.

[Melfice]

I had a crash involving the minimap, where it couldn't... specify some cargo-types? I don't know.
I accidentally deleted the log, but did some testing of my own and couldn't reproduce it so I filed it under the instabilities of the nightlies plus the patchpack plus having too many windows open in-game.

The emergency save worked just fine, though, and I picked up right where I left off to play for another 10 in-game years without further problems.