Transport Tycoon Forums

Posted: **17 May 2009 15:03**

Sorry for such a shameful first post,

Anyway i really have to ask if please anyone can compile a (windows)binary-version with this more than wonderful patch. I have tried to do it self (the past 4 days), but I was not able to do it in anyway.

I have played around with the previous binary version of this patch but this caused an enormous lag when i had about 50 trains (and different directions).

Hopefully somebody is so kind to help and provide.

Thanks in advance
Bart

Posted: **17 May 2009 22:24**

there's a binary on the previous page, which appears to be the latest version

Posted: **21 May 2009 00:12**

I compiled and tested on Windows now, trying to find that crash you are all reporting - but I still can't reproduce it. So what about the following: Each of you who experiences one of those crashes please post some information here:

A savegame of sometime before the crash. It doesn't have to be right before it as I see that's hard to do.
Information about which versions of cargodist and trunk you are using.
Information about your build environment (MinGW, Cygwin, MS, BuildOttd) best with version information or which precompiled binary you are using.
The approximate game date at which the crash occurs in the provided save game.
What you were doing at that date.

This should help me narrow down the problem.

pshemko wrote:I've noticed something weird going on with my passenger numbers. In the attched savegame there are some 66 passengers waiting in Port Pronnley. It's a terminus, so the train that's pulling in should take all of them. Yet, it empties the station, but shows only 45 passengers on board. What happened to the rest of them?

This is interesting. I think it's "only" a bug in the station GUI where it displays a different amount of passengers than there actually are. At least I couldn't find a bug in the loading code which would lose cargo. I'll examine it further.

Gathers wrote:Hi, I think I've just found an easy to reproduce bug.
Just build a bus, a bus station and send the bus there with a order to load fully.
Then, while the bus is loading, select the last row of it's order list and his 'delete'.
For me, on your latest git, it generates something like this.

Thanks a lot. I check the order list now for NULL before using it. This should prevent the crash. Updates in first post and git.

Btw, if anyone could produce a backtrace of the other crash, that would make me really happy ...

Posted: **21 May 2009 01:11**

Hi,

this also crashes after some minutes. Made with:

Openttd r16305 + cargodist_r16305.diff (compiled under FreeBSD 7.1 with gcc version 4.2.1 20070719 [FreeBSD]).

It also crashes with Openttd r16305 + cargodist_r16305_2.diff.

Posted: **21 May 2009 07:02**

Found another oddity with passenger numbers. Beburg springs is a transit station, there are 69 passengers 'waiting' for trains either to Slenton (49 passengers) or Ketburg (20 passengers). Despite the fact that there are multiple trains leaving in those directions those passengers stubbornly refuse to board a train.
Also, Cunningville Woods seems to have 36 passengers going to 'unknown station'. It's been more then a year since one of the routes got decommissioned, but apparently that's not good enough to discourage them from waiting

Grfs: eGRVTS v1.0, Canadian stations set 0.3d and Canadian trainset 0.3d.

Posted: **22 May 2009 11:30**

I sometimes had trains refusing to pick up people or even coal and fixed that by parking them in a depot/somewhere away from stations, killing all orders, and recreating them slowly. Does that work for you?

Posted: **22 May 2009 16:56**

I would very much like to try this patch - do you think it would break my game if I loaded this on an established and large game?

Posted: **22 May 2009 17:51**

Loading Cargodist on existing games:
If your game contains trains with orders that only contain the first and last station (and the train stops everywhere), then it will not work OK.
On the intermediate stations, many passengers will be waiting, the numbers will explode.

But this is not an issue with cargodist, in my opinion, if someone creates a timetable, all stations where the train should stop should be listed in the Orders window (TTDPatch style).
The thing is, that if you have long IC routes, with many intermediate stops, it is annoying to manually add each station. Especially because you have to add the stations in reversed orders as well.
Hopefully, someone comes up with a patch where you can select the first and last station (and optionally some via stations if the route is ambigious) and then aufo-fill all intermediate stations.

Example:

route A --- B --- C --- D --- E

train is an intercity, and should only stop at A, B, C, and E
User adds orders for A and E
Orderlist: A, E

then pushes the autofill button
resulting Orderlist: A,B,C,E,C,B
(the existing path finder algorithm might be usable for this autofill procedure)

then cargodist will work fine

Posted: **22 May 2009 18:14**

Thanks, I'll try setting it up like that. When I place the stops in, do I have to set each station to be 'express to'?

EDIT: I almost forgot...would it be possible to get an exe with extra-large-maps pack? If not, I'll try to do it myself this weekend.

Posted: **22 May 2009 20:23**

fjb wrote: this also crashes after some minutes. [...]

Nasty, ... the station pool can indeed change its size. And again, I've learned something. Find fix in first post or in git.

About those implicit and conditional orders, what do you think about the following ideas:

Whenever a vehicle arrives at a station where cargodist didn't expected it to go this is interpreted as an override order. This means the vehicle will unload and deliver and then load whatever cargo is there, without caring about destinations. If that happens repeatedly with the same vehicle, the vehicle could be marked as override vehicle which shows that behaviour at every station it visits. Like this you can still use these orders if you really like and it will create less chaos than it does at the moment. It's just a fallback to traditional routing.
An even better way to solve this is a switch somewhere in the settings where you can choose between either cargodist or conditional and non-nonstop orders. If you switch to cargodist, all conditional orders are ignored and all other orders are interpreted as nonstop. However, I fear there are people who like to use cargodist for some cargos and esoteric orders for others.
I could evaluate conditional orders before the vehicle arrives at a station and thus try to find out where it will go afterwards. Then I could load it with cargo for that place. However this is useless if the condition is based on load percentage as the load percentage will definitely change at the station. Yet load percentage is probably the most used conditional order.

Posted: **22 May 2009 20:53**

pshemko wrote:Found another oddity with passenger numbers. Beburg springs is a transit station, there are 69 passengers 'waiting' for trains either to Slenton (49 passengers) or Ketburg (20 passengers). Despite the fact that there are multiple trains leaving in those directions those passengers stubbornly refuse to board a train.
Also, Cunningville Woods seems to have 36 passengers going to 'unknown station'. It's been more then a year since one of the routes got decommissioned, but apparently that's not good enough to discourage them from waiting

The passengers waiting at Beburg Springs and Cunningville Woods are stuck forever. They are all going via the same station they are at, so no vehicle can pick them up. The "to" lines are just generated from the flow stats at the various stations and don't mean anything for those passengers. I guess originally they wanted to be delivered to the stations where they are now, but somehow that failed. Either you set an explicit transfer order or the stations didn't accept passengers and you had an explicit unload order. Creating passengers that are stuck is not a solution in both cases and I'll change that.

However, I don't actually know if you did anything like that and so I'd like some more information. Can you provide me with a savegame of before the passengers got stuck and tell me what you did afterwards?

Posted: **22 May 2009 21:09**

pshemko wrote:...

Just to make sure: You did follow my advice to delete all save games created with those versions which had the self-refering link stats, didn't you? Otherwise this is very easy to explain and already solved.

Posted: **22 May 2009 22:01**

Would you like me to remove those older builds, fonso?
Or would you like to keep them around for debugging?

I tried with the latest posted and had the same problem as before.
Loaded game never saved with cargodist or patched build.
Random exit. Same conditions as before.
Just observing a few station gui. i did change the destination/via/source order for a few. but that was a bit before the crash.
No clue why.

EDIT:
i tried with the previous posted.
sorry, did not see it there yet.

Posted: **22 May 2009 23:40**

New version in first post and git:

I found and fixed some problems with timing out links. These may or may not be related to the stuck passengers pshemko is reporting. Also I found and fixed a problem with the MCF algorithm where it would check the wrong flows for circles. This may or may not be the reason for the problems with the station GUI, as the station GUI still (and correctly) doesn't like routing circles.

Posted: **23 May 2009 08:20**

Thanks for all this fonso! To pach this with msys, which number do I use after -p? 0,1,2 don't work.

Posted: **23 May 2009 08:57**

Wasila wrote:Thanks for all this fonso! To pach this with msys, which number do I use after -p? 0,1,2 don't work.

Checkout r16392 with your favourite VCS, be in the root directory (where you see directories like src/, bin/, doc/ and the configure script), then use -p1:

Code: Select all

patch -p1 < cargodist_r16392.diff

This works for me at least. If you have further problems, I need to see some more output to give useful answers.

Posted: **23 May 2009 09:21**

I got this:

$ patch -p1 < cargodist_r16392.diff
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/projects/openttd_vs80.vcproj b/projects/openttd_vs80.vcproj
|index c6b09aa..165eead 100644
|--- a/projects/openttd_vs80.vcproj
|+++ b/projects/openttd_vs80.vcproj

Posted: **23 May 2009 09:30**

Wasila wrote: can't find file to patch at input line 5

Is there a folder called "projects"? If yes, is there a file called "openttd_vs80.vcproj" in the folder "projects" (give me the output of "ls projects")? If no folder, what folders and files are there (give me the output of "ls")? How did you check out or otherwise produce the folder you are in (subversion, git, mercurial, copied from somewhere ...)?

Posted: **23 May 2009 09:38**

The file is there. This is what I got:

$ ls projects
determineversion.vbs openttd_vs80.sln openttd_vs90.vcproj.user
generate openttd_vs80.vcproj strgen_vs80.vcproj
generate.vbs openttd_vs80.vcproj.in strgen_vs90.vcproj
langs_vs80.vcproj openttd_vs80.vcproj.user version_vs80.vcproj
langs_vs80.vcproj.in openttd_vs90.sln version_vs90.vcproj
langs_vs90.vcproj openttd_vs90.vcproj
langs_vs90.vcproj.in openttd_vs90.vcproj.in

I used msys and SVN to get the source.

Posted: **23 May 2009 10:44**

Wasila wrote:The file is there...

I did the following with MSYS/MinGW in a newly created folder "test" with only cargodist_r16392.diff in it:

Code: Select all

fonso@WINDOWSTEST ~/test $ svn checkout -r 16392 svn://svn.openttd.org/trunk .
[... checkout messages omitted ...]
fonso@WINDOWSTEST ~/test $ patch -p1 < cargodist_r16392.diff

For me it works. I suggest you retry it like this. I can't figure out what is wrong with your current source tree without personally looking at it.

Transport Tycoon Forums

Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution

Re: Cargo Distribution