YACD - Yet Another CargoDestinations (v2.3 released)

[Eddi]

yes, that is exactly what it means.

first, this patch must be extended to provide an AI interface that allows to get suitible destinations for AIs, and then all existing AIs must be updated to use that interface. the last step is unlikely to happen before this patch is introduced in trunk, and even then maybe only for some AIs.

[fieari]

[...] I've been playing this more, and noticing that while it works fine for passengers, other kinds of cargo... don't seem to work properly. By that I mean, vehicles will suddenly stop loading cargo at all. I've found it's particularly repeatable with situations where cargo must be transferred between multiple vehicles... oil by train to a dock, picked up by ship for example. The ship, after the 2nd or 3rd load, will simply wait at the dock forever while the train keeps depositing more and more oil. The oil states it is headed for the ship's destination, but it never gets picked up, and with a "Full Load" order, the ship just stays at dock doing nothing.

Is this a known issue?

Been playing even more, and I'm beginning to wonder if the issue is that cargo is not only being routed to specific destinations, but also being routed via specific vehicles? I made a simple train loop, Oil to Refinery, with two trains and each train loading to full. Here's a timeline of events I witnessed:

1) Train 1 loads completely, leaves station
2) Station starts stockpiling more oil-- lets say 20,000 liters.
3) Train 2 arrives, does not load 20,000 liters. In fact, as the oil wells produce more oil, ONLY the new oil gets onto train 2, leaving 20,000 liters at the station
4) Train 1 arrives, picks up the 20,000 liters.

This would explain why my previous games using tanker ships going across the entire map seemed to stop picking anything up. The next ship to pick up the oil left at the station might be a full year from arriving or longer, while the ships waiting might have to wait a very long time indeed to pick anything up that's assigned to them.

Am I correct in my interpretation of what's happening? Or is something more screwy going on?

[Eddi]

use shared orders to avoid this problem.

[Kogut]

I'm new to the game so I apologise if this has been asked before. I notice that NoAI integration is still a todo item according to the first post... does this mean that none of the current AIs know how to deal with cargo destinations?

yes

[jub]

Hello,

sorry if the question was asked before, but I have slight problem with playing version 2.3. When some industry closes and I have some cargo in direction to this industry (either in some train or station) it looses its destination and is stuck there. It is especially annoying with trains. Did I configure something wrongly or is there some other problem? I play with ECS.

[Expresso]

Is there any plan on introducing a cargo reduction parameter? I have played 20 game years and some of my pax stations are already overloaded and I really can`t put more trains on my network anymore.

This is not a problem of YACD, but of OpenTTD in a more general sense.
It should be solved independently.

Might be, but it is not a problem in normal OTTD games without pax destination, as all trains take all available cargo. But with the change of that logic, the generated cargo is in no relation to the possible services any longer. Therefore, it should be part of the patch introducing the destination that corresponding reductions can be done. Cargodist has it, and so does the old cargodest patch.

It might be a good idea to implement something like this as a difficulty setting.

[jub]

Hello,

I did not receive any reaction, so I would like to ask again, do anybody experience the problem, that when cargo is transported and the its destination is closed (industry is closed), then the cargo is left permanently loaded. I would presume that the behaviour should be that it is unloaded at first available station, otherwise with time it can disable transportation on some line completely. The only thing I can do now is to manualy change the order temporarily to unload to force the removal of cargo from vehicle. Is there any other way how to prevent this behaviour? Or it is bug,unwanted/wanted feature?

Regards,
Jub

[ChillCore]

jub,
If I understood correctly this patch is on hold because of some issues that are not easily solved. (¿CPU usage and maybe something else?)

Anyway about your bugreport ... that is most likely unwanted behaviour.
You can help the developer to find/solve this issue faster by providing your savegame, preferably saved while zoomed in on the problem.
Even better would be if you could save the game right before the "problem" industry closes. That way he does not have to wait for one to close to see what happens (or does not happen that should happen).

[jub]

Here is the example of the problem. Prunford Food processing plant closes at the end of 1973. There is 5 tons of cereals stuck in train 5, which is not unloaded and the only way to remove it is to change the order to explicit unload.

The save uses ECS and 2cc.

[Expresso]

Cargo packets in trunk appear to keep track of how long they are in transit by a day count; so once a day each cargo packet must be visited in order to increase that counter (at least, that is what I gather from the code). For some cargoes it is entirely valid, for others there's no point to that.

Why not keep track of two dates? The first is the last "event" for the cargo (being picked up/dropped off at a station) and the second its creation date. This eliminates the need to visit each and every cargo packet in game, only those at stations and those which are perishable).

In my opinion a bit of performance could be gained from changing this behavior.

[Rubidium]

Why not keep track of two dates? The first is the last "event" for the cargo (being picked up/dropped off at a station) and the second its creation date. This eliminates the need to visit each and every cargo packet in game, only those at stations and those which are perishable).

How to handle daylength, cheats back in time and all other related issues that mess with the date? How to handle not aging when in a station?

[Expresso]

Why not keep track of two dates? The first is the last "event" for the cargo (being picked up/dropped off at a station) and the second its creation date. This eliminates the need to visit each and every cargo packet in game, only those at stations and those which are perishable).

How to handle daylength, cheats back in time and all other related issues that mess with the date? How to handle not aging when in a station?

Wait Why is all that a problem?

[Kogut]

Why not keep track of two dates? The first is the last "event" for the cargo (being picked up/dropped off at a station) and the second its creation date. This eliminates the need to visit each and every cargo packet in game, only those at stations and those which are perishable).

How to handle daylength, cheats back in time and all other related issues that mess with the date? How to handle not aging when in a station?

Wait Why is all that a problem?

Cargo loaded in year 1991, travelled 10 years (2001), somebody used time cheat to go back 10 years (1991), cargo delivered (1991) - result: cargo travelled 0 years, according to event-creation check.

[fonso]

I'm just reading that IRC discussion from October 17th and it seems the inline path finding using A* is not as good as it seemed after all. So, for reference, I'm going to explain how I did it in Cargodist. I don't know if that's actually faster in the case shown there as I didn't test with a game like that.

In Cargodist a snapshot of the relevant parts of the game state is taken in regular intervals. That snapshot is fed into a thread which models the routing problem as a multi commodity flow problem (MCF). MCF is an NP-complete problem and thus also "known to be hard". Yet there are some OK heuristics for it and I implemented one of them (or rather something similar to one of them). In the thread I give it plenty of time to solve all the routing at once. This is why there is a delay between changes in the game and reactions in the routing. The delay could be reduced by making the time taken depend on the size of the problem instance and/or allowing for less accurate results if the problem gets too big. At the moment the time and accuracy are the same for all MCF instances. When the calculation is finished the thread is joined and the resulting "route plan" is merged back into the game state. This also happens at predetermined intervals to avoid desyncs. Then when a cargo packet needs to be routed it just needs to look up the correct next hop in the route plan without any pathfinding. In order to collect the necessary data for modelling the MCF problem moving averages of capacities are kept for each link. They're updated whenever a vehicle arrives at a station.

[Michi_cc]

So, for reference, I'm going to explain how I did it in Cargodist. I don't know if that's actually faster in the case shown there as I didn't test with a game like that.

Generally, I don't think solving a MCF problem is faster than A* pathfinding. The different approach in CargoDist allows to "hide" that cost in a thread though, so it appears faster (as long as you have at least two cores). Doing the same in YACD would only be possible by restructuring and reordering the main game loop.

-- Michael Lutz

[fonso]

Probably it's not inherently faster, but MCF can be solved in one go for a given link graph and the routing plan can be used for a relatively long time. It also needs only a limited amount of data and so it's easy to parallelize it. Cargodist also doesn't consider unconnected destinations which probably reduces the problem size. It's not dependent on number of houses or industries as only connected stations are seen as cargo producers or consumers.

[Michi_cc]

Probably it's not inherently faster, but MCF can be solved in one go for a given link graph and the routing plan can be used for a relatively long time.

Reusing the same plan for a long time means a slow reaction to changes though. Right now YACD takes waiting cargo count, time since last vehicle and more into account, which basically can change each tick. If all that is removed, it would be possible to start caching some things.

One thing I'd like to try (whenever I have enough time and inspiration) are different pathfinding algorithms. There are algorithms specific to packet routing which fit YACD much closer than A*.

-- Michael Lutz

[fonso]

Of course Cargodist's reaction will always be slower than YACD's but it doesn't have to be as slow as it is now. There is a lot of potential for optimizing the thread scheduling so that the results are quickly merged back when they are available. At the moment most of the delay stems from waiting for the scheduled merge time. I'm scheduling all jobs equally no matter how big they are and so most jobs get much more time than they actually need.

[damerell]

Wait Why is all that a problem?

Cargo loaded in year 1991, travelled 10 years (2001), somebody used time cheat to go back 10 years (1991), cargo delivered (1991) - result: cargo travelled 0 years, according to event-creation check.

Well, cheating back in time could be responsible for rewriting all the cargo packets; that would still be enormously preferable to rewriting them every day.

[Wasila]

Is this project dead? It appears to be a thousand revisions out of date.