Eddi wrote:
anyway, what i really was searching for, but didn't find was the place where i can tell it to not establish links for orders "no loading and no unloading", which should be treated like waypoints for the linkgraph...
It shouldn't establish links there. If you have an example where it does, please post it here. I don't know the place from the top of my head, but there is all that logic with last_loading_station and last_station_visited and somewhere along those lines I made it ignore stops with "no loading and no unloading" - at least I think that's what I did.
in that case, it doesn't seem to work...
i tested in a fresh checkout of gee309916-cd, and an order list like:
go to A (full load)
go to B (no loading and no unloading)
go to C (normal)
go to B (no loading and no unloading)
and links A-B and B-C get established, no direct link A-C.
Could it be that ONSF_NO_STOP_AT_DESTINATION_STATION used to be set in those cases and is no more? Then the condition in OrderList::GetNextStoppingStation needs to be amended by:
i tried this out, but it doesn't work properly. now, a link A-C is created, but the A-B and B-C links still exist. (looks like this is done on arrival of the train at the station)
besides that, there are some missing () in your check.
Is that a new feature? Vehicle with "no loading" and "no unloading" but stops at a station? I think it also creates a link from the last_loading_station to the current one when it stops. So you probably have to check where the last_loading_station is set and don't set it for stops where it can't load or unload ... but I'm not sure right now.
I've fixed the issue with no loading and no unloading and the other problem with strange behavior if a vehicle has only one order. Vehicles with only one relevant order will only load cargo "to any station" now, by the old loading rules.
I've also changed the timeout handling so that the timeout for links depends only on the length of the link, no more on the capacity. Using order analysis to find existing links is impossible as we cannot know what cargoes a vehicle carries when it visits some link. You could create conditional refit orders which cannot be properly analyzed before they're executed.
I've also improved the handling of conditional orders. Now, if you have a conditional order it will be evaluated when loading and the resulting next station will be used to choose the cargo.
There is one exception: If the condition refers to load percentage a random choice between the two alternatives is made. This choice is made in each loading round and thus if the vehicle loads for some time with high probability cargo for all possible destinations will be loaded.
If the condition doesn't refer to load amount and its value changes after loading but before execution of the order that's bad luck for you. However, I think it's reasonable to assume that this won't happen too often.
I've found an even better way to deal with conditional orders based on load percentage: The vehicle will now report the next hop it can load the most cargo for. This prevents situations where the random choice would result in a next hop for which no cargo is waiting and the vehicle would leave the station without loading anything even though there is cargo waiting for the other next hop.
Whatever, I have updated Cargodist once again and introduced a new feature that you might be interested in: Now instead of only refreshing the next link while loading a vehicle will refresh all the links that it expects to visit until it comes back to the current station.
This means you can now have a vehicle full load at a station and when the link graph runs it will plan a distribution for the whole trip, not just for the next station. That problem was one of the reasons why you wanted the static order analysis for adding and removing links.
something i was wondering about:
the advanced option "load vehicles gradually"
should that be turned off ?
i noticed when this function is turned ON, when a train with 5 passenger wagons arives and there are 50 people waiting, 10 get put in each.
with the function OFF, wagon 1 is filled max (example 40) and second than gets 10.
this means when a train has more than station A<->B it can have several type of passengers in the different wagons.
That behavior is the same in trunk. Yes, you can have people from different places in the same wagon and the vehicle GUI will only show you one of those places. The gradual loading option influences this only slightly: You'll get more partly loaded wagons if it's turned on.
Hey, I'm sorry, but I haven't been playing OpenTTD that much recently. I might get into it again in a few months, but currently I'm not that into computer games. If I did play a game OpenTTD these days, it is always a CargoDist build. Thanks for your work so far.
Yea that's so not the case
I always keep up to date in here, even though I currently don't have the time to play. One of the downsides of OTTD is that it's immensely time-consuming... I'll do play the occasional game though, and I'm also sure I'll find some more time for it in the future.
As a side-node: I can't stand to play OTTD without Cargodist anymore, it's just sooo boring! so kudos for achieving that
Thanks for all the nice words. I was just making a little fun of myself for posting 5 times in a row, though. I didn't intend to go fishing for compliments
The last changes I did have the effect that you can use all order constructs (including conditionals, full load with intermediate stations, even refit orders) and cargodist will understand them.
When helping someone on IRC to get openttd to compile, I noticed that cargodist gives the following warnings on MSVC 2010. I don't know how valid they are, but it might be useful to look at them:
Hirundo wrote:When helping someone on IRC to get openttd to compile, I noticed that cargodist gives the following warnings on MSVC 2010. I don't know how valid they are, but it might be useful to look at them:
Thanks for the report. I think I've fixed those, but as I don't have MSVC I can't really be sure until the compile farm builds it.
Hey, as I don't see a post on this subject: is it known that save games from the gc0d4fe7a build cannot be loaded? With the gc0d4fe7a build OpenTTD consumes 100% CPU after a few/several days but does not crash. Later builds consider the save game faulty. Off to a newer build...
edit: an example save game attatched. Wait until 8th of September.
Hello, I tried newest version from git (commit 5d3e26eb7) under linux x64 and it was occassionally crashing. I tried to look it up with gdb and came up with easy fix, below.
Otherwise , cargodist is GREAT Had several hours of fun with it!