Chill's patchpack v14_7

[bluebottle]

Hmm? Strange result? Or should I ignore the first few lines?

Code: Select all

*********-desktop:~$ dpkg -l debhelper
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Naam           Versie         Omschrijving
+++-==============-==============-============================================
ii  debhelper      7.0.17ubuntu4  helper programs for debian/rules

Those first few lines are telling you what the letters in the left columns mean.

When trying to re-install it says I allready have the newest version.

You do, for your version of the distribution. Each release is generally kept static, apart from security fixes. Otherwise we'd be fed a constant stream of upgrades and new bugs.

Which brings me to my next two questions.
If/when I upgrade my Ubunbtu install to 10.4 will I still be able to use the binaries I have compiled with 9.04?

Maybe. Personally I wouldn't bother and would recommend compiling yourself a new one. New LibC is a good enough reason by itself, and there will probably be new threading models, etc.

Also while searching for answers to my first question I have seen some reports about issues with NVIDEA drivers with newer Ubuntu. Are those already solved?

Not sure, but my NVidia card has been fine. I even have temperature monitoring of it now!

ps:
Thank you for your time and patience bluebottle, much appreciated.

No, you're welcome. More people knowing more about Linux makes the world a better place.

EDIT: I would recommend that you don't try to upgrade, because you will have to upgrade to 9.10 and then to 10.04. Just do a fresh install instead.

[Muzzly]

Hello,

I was looking for cargodest + copypaste combination. And at last found this patch pack. Thanks !!!

But it crashes sometimes . I am useing precompiled binary r20033 downloaded from this forum. Could someone take a look ?

Thanks.

[ChillCore]

The crash save is unloadable as it is zero bytes. You do not happen to have a savegame from a little before the crash as the crashlog seems to be incomplete. (It stops in tick 0 and you do not have pause enabled.)

May I ask what you were doing at the time of the crash?
Were you laying track as suggested by the screenshot? Or something else?
Is there a reproducable way to make this crash happen?

Thank you for reporting muzzy.
I hope I can find and fix the cause of your problem.

[Haiya-Dragon]

I'm currently hosting a MP game with a time delay factor of 15. Everything is rock stable without any desyncs or crashes whatsoever. We're currently in 2008, and started in 1890, so that's quite a lot of playing time

One thing that bothers me a bit is that cargodist doesn't seem to have a working 'off' switch for certain cargoes. I tried setting the corresponding distribution flag in the Link graph settings to manual, but that doesn't appear to have the desired effect: these cargoes are still being routed the cargodist way.

Other than that, a brilliant patchpack!

[ChillCore]

I'm currently hosting a MP game with a time delay factor of 15. Everything is rock stable without any desyncs or crashes whatsoever. We're currently in 2008, and started in 1890, so that's quite a lot of playing time

Unfortunately my internet connection is not stable enough to play online. If it was I would defenately swing by.
I would love to see the savegame when you are done.
Would you mind making one before the server is reset? Please.

One thing that bothers me a bit is that cargodist doesn't seem to have a working 'off' switch for certain cargoes. I tried setting the corresponding distribution flag in the Link graph settings to manual, but that doesn't appear to have the desired effect: these cargoes are still being routed the cargodist way.

What cargos would those be?
You can distribute cargo the way you want by setting orders as full load and full unload. But I have not yet tried that myself on purpose so I do not really know what cargodist will do in that situation. Hmm, something to try in clean cargodist.

Other than that, a brilliant patchpack!

Thank you for your kind words. Glad you enjoy it.

[Muzzly]

The crash save is unloadable as it is zero bytes. You do not happen to have a savegame from a little before the crash as the crashlog seems to be incomplete. (It stops in tick 0 and you do not have pause enabled.)

Autosave file was also zero.

May I ask what you were doing at the time of the crash?
Were you laying track as suggested by the screenshot? Or something else?
Is there a reproducable way to make this crash happen?

I do not remember well. I think was doing nothing. Just thinking where to put another track.
I cannot reproduce it.
But the error happen for a second time. I do not have a crash dump or screenshot of a first crash.

I have to add. The error window (with assertion failed) appeared twice. Once when error happend, then appear window with save dump information and then assertion windows (with same error) appear again.
Could it be that error happen when openttd tries to save a file. That would explane why autosave and crash.sav are of zero size.

I will try to play with it a bit more, maybe I could reproduce it somehow .


P.S. (offtopic) is there somewhere another not very old binary with cargodist and copypaste patches.

bye,
Eduard

[Haiya-Dragon]

I'm currently hosting a MP game with a time delay factor of 15. Everything is rock stable without any desyncs or crashes whatsoever. We're currently in 2008, and started in 1890, so that's quite a lot of playing time

Unfortunately my internet connection is not stable enough to play online. If it was I would defenately swing by.
I would love to see the savegame when you are done.
Would you mind making one before the server is reset? Please.

Will do It will take a while as every game day takes about 30 seconds. A full year would be about 3 hours of playing time!

One thing that bothers me a bit is that cargodist doesn't seem to have a working 'off' switch for certain cargoes. I tried setting the corresponding distribution flag in the Link graph settings to manual, but that doesn't appear to have the desired effect: these cargoes are still being routed the cargodist way.

What cargos would those be?
You can distribute cargo the way you want by setting orders as full load and full unload. But I have not yet tried that myself on purpose so I do not really know what cargodist will do in that situation. Hmm, something to try in clean cargodist.

That would be all cargo except passenger and mail. It becomes a major headache when trying to route farm supplies to 20 farms via a central farm station (think FIRS farm clusters here). For some reason the cargodist won't allocate cargo to all the supply routes to these farms.

I managed to circumvent it by destroying the station and starting a new one. After rerouting all the trains to the new station (with link setting at manual) it works as it should. Haven't tried the load/unload yet, although the trains which already use that don't show a change in behaviour.

[Muzzly]

Hello people,

here is another bug I found. This time I can reproduce it.
This bug has nothing to do with my first topic ( I think it is another bug).

Info:
I used version binary r20033 downloaded from this forum.

Steps to reproduce a crash:
1. load autosave6.sav file
2. find a train number 22.
3. delete all its orders.
4. just wait for 3 seconds.

P.S. On the other hand I have to say that the game is stable . I was playing for 3 days, till I touched train 22 .

Kind regards,
Eduard

[ChillCore]

Thank you for the report muzzy.

I do not think it has to do with train 22 as the game crashes also without touching anything ...
Do you still have autosave5.sav for me to test?
I am rebuilding v7 with debugging enabled on linux to see if I can find the cause for the crash.
It is also possible this was something in trunk that has been fixed in the meantime.

Also as there have been a lot of bugfixes and codechanges in trunk lately I might be making my way to v8 soon.
Thank you Devs for your continued efforts.

Any other request for patches besides this one:

Is it possible to include this patch. Close adjacent level crossings.
http://www.tt-forums.net/viewtopic.php? ... 91&start=0

Speak now or wait untill v9.

[Muzzly]

Hello,

yes I have just noticed that it crashes because of other train.
Sorry for disinformation.

Before changing train 22, I have deleted orders of train 18. They both belong to the same group. I was intending to change their routes.

So, here is the correction:
1. Take file autosave3.sav file
2. Delete orders of train 18.
3. Just wait

salute,
Eduard

[Muzzly]

Hi ChillCore,

Any other request for patches besides this one:

Yes, I think drive-through depots patch would be also cool ( especially with "bigger depots grf" )
Here is the link to forum http://www.tt-forums.net/viewtopic.php?f=33&t=42312

It look silly when 12 cars train fits to one small depo

salute,
Eduard

[ChillCore]

Before changing train 22, I have deleted orders of train 18. They both belong to the same group. I was intending to change their routes.

So, here is the correction:
1. Take file autosave3.sav file

1. Aha that one does not crash ... yet.

2. Delete orders of train 18.
3. Just wait

2. Instead of deleting orders I have sent it to depot, sold it, cloned train 22 and removed the orders. (Deleting them just like that removes the orders from train 22 also and I have forgotten how to stop sharing orders for the moment.)
3. Instead of waiting I have sent it back on its way after CTRL-clicking the center on vehicle button and followed it.

Your game seems to crash when train 18 comes at a waypoint while having no orders.(*)

Here is how to fix autosave6.sav:
Upon loading your game pause the game if you do not have autopause enabled.
Find train 18 and prepare its gui to give it orders.
Now unpause and give it an order, the closest by station is easiest, complete the rest of the orders as you wanted and remove the random order you have given to prevent the crash. You should now be on your merry way.
If you ever feel the need again to completely change orders make sure there is always one order in the list until this issue is fixed.

(*)
Some time ago I noticed a crash with non-stop orders.
When a train had a non non-stop order before an order to go to a waypoint the game crashed when it arrived at the waypoint.
fonso fixed that one in cargodist.
Now because of seeing what makes your crash happen (when a train arrives at a waypoint with no orders in its orderlist), I have tested non non-stop orders again and the game seems to crash also if a waypoint order is followed by a non non-stop order to a station.
I do not know if both issues are related and if they are bugs coming from cargodist ...

Yes, I think drive-through depots patch would be also cool ( especially with "bigger depots grf" )
Here is the link to forum viewtopic.php?f=33&t=42312

I'll have a looksie at the code.
If there is not too much conflicting code and the patch is functional it should not be a problem. No promises though.


ps: You may want to fix your quote in the previous post. muzzy said no such thing

[Muzzly]

Your game seems to crash when train 18 comes at a waypoint while having no orders.(*)

Yes, I have tested it. This is the main reason. Train with empty order list passing a waypoint.
Thanks for a hint

I have tested non non-stop orders again and the game seems to crash also if a waypoint order is followed by a non non-stop order to a station.

Yes, that is also true. But usually I prefer to use non-stop order.
Orders without non-stop flag are nondeterministic orders. See:
http://wiki.openttd.org/Passenger_and_c ... stribution

I have to say, that those two errors DO NOT occur when using ONLY cargodist patch.
I tested those two cases with openttd-cargodist-g17340e3e-windows-win64.zip downloaded from http://bundles.openttdcoop.org/cargodist/g17340e3e/. So I think it is not the problem of cargodist patch.

ps: You may want to fix your quote in the previous post. muzzy said no such thing

Fixed

Impatiently waiting for Chill's patchpack v8
Eduard

[Haiya-Dragon]

Perhaps it would be nice to add Panorama screenshots.

[ChillCore]

Allow me to present v8.
Below what has changed and attached the new version.
First posts will be updated in a bit.
Note: Not savegame compatible with the previous version.

Updated:
- Moreheightlevels to r20202
- Cargodist to r20211

Added:
- Close adjacent level crossing.
- Panorama screenshot.
- Measurement tool. (Extended to scenario editor.)
- Configurable Treeline height. (Extended to all climates and adapted to fit the moreheightlevels patch.)

Removed:
The extra hotkey for opening the cheat gui is gone. We have hotkeys.cfg now.

Disabled for the moment:
Diesel smoke patch.
It causes a segmentation fault after loading some savegames. (eg. Coop's PublicServerGame_188)
If you want, you can enable it by following instructions in train_cmd.cpp. (Search for "diesel smoke disabled for now ..." 1/4 to 4/4 and do as suggested in TODO:, below each there is another TODO)
The segmentation fault does not seem to happen with new games nor does it happen with all loaded savegames.
A good reason for disabling it is that it also crashed my long lasting savegame ...
Once I can figure out what causes the crash I might enable it again.

Did not make it:
Drive through depots.
This one needs a major bump to trunk.
Sorry muzzy, maybe in a later version.

To test:
Trains with nondeterministic (non non-stop) orders and trains without orders in combination with waypoints. (Note that cargo might no longer be distributed as you expect. See first post of the Cargodist thread.)
fonso has made some changes in the Cargodist patch and these seem to be fixed, please confirm ... I only tested briefly with known ways to crash the patchpack.
Thank you fonso, once again.



EDIT:
@The one person that already downloaded the patch:
The previous posted patch was against r20210. I forgot to bump my release folder, sorry for that.
While bumping I have kept "mine" for both conflicts (train_cmd.cpp and viewport.cpp).
@ everybody else:
The attached version is the correct one.

[Kogut]

From first post:

- Make sure ALL your orders are non-stop. (If not your game may crash)

Is it still true? Why?

[ChillCore]

From first post:

- Make sure ALL your orders are non-stop. (If not your game may crash)

Is it still true? Why?
From first post:

The answer is twofold.
-As long as the link to the compiled binary points to v7 the crash warning is still true for people that can not compile themselves.
I will remove the crashing bit when there is a new compiled binary for windows and when the no more crashing fix has been confirmed.

-V8 should fix the crashing bit but for Cargodist to function correctly you still want your orders to be non-stop.
If not trains might stop somewhere along the way and unload regardless of what Cargodist says to do with it. (Trunk behaviour -> unload at the next stop.)

I will update the first posts soon. You will know when it is done when the topic title says: v8.

[NekoMaster]

Um, I tried patching Openttd r20211 with the v8 patch but all I get are constant Hunk Errors, I think that all the hunks failed

Anyone wanna have a go at figuring this out or maybe just compiling a generic linux build?

[ChillCore]

Uh?

I assume you know where to put the patchfile. Did you apply it with -p0? It is a svn patch ...

Were you the first person to download the patch by any chance?
By mistake I had uploaded the patch against r20210 with the wrong name. See my edit a few post back. I have replaced it with the correct patch. You can check by opening the patchfile and checking the first few lines. If it says r20210 you are the one and you can either download the fixed version or patch the r20210 source and do as I suggested in my edit while bumping.
If you are the one to have downloaded that version, there was only one download before I replaced it, I can see why you are having many failed hunks as there where lots of changes in many files in r20211.

I have just tried against a clean source with the correct patch and I have no failed hunks. Sorry but I will need more info if you want more help.
Lets start by checking what the first few lines of the patch say.

[Kogut]

Why tree creations is so slow? Problem happens only with moreheightlevels on, in result tree part of map generation takes abot 5 minutes (all other parts less than 10 seconds), even with trees disabled!
Unfortunatelly map generation with moreheightlevel off is broken - every setting results in almost flat terrain.
One question - is anybody interested in windows binary of that patch?