YACD - Yet Another CargoDestinations (v2.3 released)

[bokkie]

Eddi: growing outside catchment area would indeed influence the percentage, but a much lower absolute number isn't a logical consequence. Rating comes into play one step later so also doesn't explain this.

Michi_cc: I've been watching the same behavior in an industries with multiple destinations. With a production of 160, it was distributed as 120/40 one month, 40/120 another month and 160/0 a few months after that. I'm not sure whether this is intended but it makes planning the flow a lot harder. The extra challenge of destinations an sich is a lot of fun, but in OpenTTD I like some 'set and forget' so the margin in which it fluctuates should (IMO) be somewhat smaller.

Not using ChillCore's patchpack, I miss timetable based seperation in my passenger network... all busses are queueing after a while.

[Eddi]

you can do manual separation by setting the start date. autoseparation is evil, there's so many things wrong with it...

and you are wrong, the "X out of Y" values are already after applying the station rating.

[Michi_cc]

problem lies between Wali and Zion... Bus service is saturated and airplane stay empty . They don t leave and head to same station (connected though by city bus services) but they do leave and head to the same cities

First, hike up pf.yapf.route_travel_time_factor and pf.yapf.route_station_waiting_factor by quite a bit to give travel time and waiting cargo more effect. Secondly, let the aircraft actually fly the route for some time to let the travel time update. Otherwise the time is just a guess that's not totally accurate, which is more noticeable for very slow/fast and very short/long distance.

and you are wrong, the "X out of Y" values are already after applying the station rating.

You are not talking about the same thing I guess, bokkie means X local traffic out of Y total produced pax if I understood it right, whereas you think of the "X out of Y to local destinations" line.

The extra challenge of destinations an sich is a lot of fun, but in OpenTTD I like some 'set and forget' so the margin in which it fluctuates should (IMO) be somewhat smaller.

Please try http://www.tt-forums.net/viewtopic.php?p=944384#p944384 and report if (and what) the settings make it better.

-- Michael Lutz

[bokkie]

and you are wrong, the "X out of Y" values are already after applying the station rating.

You are not talking about the same thing I guess, bokkie means X local traffic out of Y total produced pax if I understood it right, whereas you think of the "X out of Y to local destinations" line.

Exactly, but I understand how it became confusing

(OT: In what way is timetable based separation evil? As said, I like some 'set and forget' and it seems to do the job. The most important thing is setting the start-date right, in the timetable itself one can create time to neutralize delays so this doesn't need to be automated. With trunk, I miss the option to use depots for this. It would be nice if I could use an order to make a vehicle wait in a depot, this would create an extra possibility to maintain the correct order and neutralize delays between vehicles. Using a station for this is less flexible as you would need to create big stations because with DTRS they might have to wait at each other to leave)

The extra challenge of destinations an sich is a lot of fun, but in OpenTTD I like some 'set and forget' so the margin in which it fluctuates should (IMO) be somewhat smaller.

Please try http://www.tt-forums.net/viewtopic.php?p=944384#p944384 and report if (and what) the settings make it better.

-- Michael Lutz

I've changed both settings (in the cfg and ingame) but distribution is still fluctuating a lot: with 160 produced, distribution ranges from 160 vs 0 to 40 vs 120 in a few months (dest1 vs dest 2).

[Michi_cc]

I've changed both settings (in the cfg and ingame) but distribution is still fluctuating a lot: with 160 produced, distribution ranges from 160 vs 0 to 40 vs 120 in a few months (dest1 vs dest 2).

To which values? And did you start a new game or was that on an existing game?

Some fluctuation is expected and wanted, as one of the factors is the stockpile size (if applicable for the industry) and an industry with a full stockpile should get a lot less than one with an empty stockpile. It's the same for the production influence, which is meant to let the cargo go the the industries you actually supply and not the others.

-- Michael Lutz

[Spacejens]

Just registered on the forum, after installing YACD and playing around with it for a few days. So far, my impressions are good.

It makes the game more varied, challenging and fun. I imagine any of the cargo destinations patches do that, but I've only tried YACD so far. One thing I particularly like about YACD is that it favors realistic transport networks, with both long distance travel (express trains etc.) between hubs and short distance travel (local bus networks) around each hub. With trunk, having a local network distributing passengers to more than one station would be kind of pointless in many cases.

Apologies if this has already been discussed elsewhere, but I didn't find it. How well will AIs be able to handle radically new options like this? In the games I've played, the AI is struggling even more than usual. I assume the AI API would need modification to enable them to check things like demands between stations and so on? If (when, I hope) a patch with some kind of cargo destination functionality makes it into trunk, I assume that would be in place as well?

[Yexo]

Apologies if this has already been discussed elsewhere, but I didn't find it. How well will AIs be able to handle radically new options like this? In the games I've played, the AI is struggling even more than usual. I assume the AI API would need modification to enable them to check things like demands between stations and so on? If (when, I hope) a patch with some kind of cargo destination functionality makes it into trunk, I assume that would be in place as well?

Indeed, when YACD/CargoDist/something similar hits trunk the AI api will have to be updated to make the new information about destinations available to AIs. When that's done all AIs will need to be updated to work with that new information.

[Spacejens]

Apologies if this has already been discussed elsewhere, but I didn't find it. How well will AIs be able to handle radically new options like this? In the games I've played, the AI is struggling even more than usual. I assume the AI API would need modification to enable them to check things like demands between stations and so on? If (when, I hope) a patch with some kind of cargo destination functionality makes it into trunk, I assume that would be in place as well?

Indeed, when YACD/CargoDist/something similar hits trunk the AI api will have to be updated to make the new information about destinations available to AIs. When that's done all AIs will need to be updated to work with that new information.

What, in general terms, is happening inside the AIs now? I guess they are just confused because the cargo is not unloaded as expected, and any detailed schedules are messed up as a result. That might explain why the more complex AIs seem to handle YACD worse than the basic ones.

[Lord Aro]

It might even be an option, to (temporarily) disable AIs when YACD (or whatever) gets to trunk...

[prissi]

First I just have to say that I find it amusing that simutrans -style destinations now reached OpenTTD, while they at the beginning were critisized as too complex ... but on to my quite late comments:

Thinking of the early comments and I think switching between different modes of destinations is imho good for OpenTTD, as most of the sets are not made with destinations in mind.

A stupid question: How is determined, which goods/pax is detroyed, when the service to a station dropped? This was one of the crucial question when I wrote the first try on that. I could solve that easily using the same weight graph that does the target selection; but this would be very time consuming with this patch.

On a more serious note: Since simutrans just recently obtained network capabilities I wonder how this patch handle tiles which are served by two different station? Can one company "steal" passengers by just providing a better service? We are currently just working on that part.

By the way, good routing is taking about 25% of the total resources in fast forward with simutrans in an 800x600 window. Same numbers should be possible in OpenTTD, especially since the sprite system requires much more CPU for updates than the static arrays of simple images in simutrans.

[planetmaker]

How well will AIs be able to handle radically new options like this? In the games I've played, the AI is struggling even more than usual. I assume the AI API would need modification to enable them to check things like demands between stations and so on? If (when, I hope) a patch with some kind of cargo destination functionality makes it into trunk, I assume that would be in place as well?

As you've obviously tested it yourself: yes, AIs have a VERY hard time. But that's indeed simply due to the fact that they know nothing about the existence of destinations. Thus they'll build as usual. And that most often fails.

If this patch enters trunk, AIs will of course get a handle to learn about destinations.

[Terkhen]

I have seen another bug, see the attached screenshot. It seems to happen when there are too many towns nearby.

Edit: Also, why are there so many destinations with 0 passengers desiring to go to them?

Edit2: The maximum number of passengers and mails also looks too big for a town of this size.

[Michi_cc]

Edit2: The maximum number of passengers and mails also looks too big for a town of this size.

That is the actual problem, number of demand destinations depends on max mail/pax, but as real generation is much lower, most destinations go empty.

I've got no idea why that number is too high though, as YACD does not touch calculation of the max number, only the actually transported number.

-- Michael Lutz

[Terkhen]

I have also observed a strange behaviour of "local destination" passengers. Town A has only a single station. Local passengers of A will pick up the line A-B and then B-A, to return to the same station. I am not sure, but I think that I am not being paid at all for them.

Edit: It seems that these local passengers appeared while I was doing a bus to metro change on that town, they seem to be gone from the station now.

[Michi_cc]

Edit: It seems that these local passengers appeared while I was doing a bus to metro change on that town, they seem to be gone from the station now.

That's probably expected. I assume that during the change you had more than one station in the town for a short while, which then generates local passengers. Those passengers don't vanish if the remaining station still covers their destination, but as payment calculation uses source and dest station coordinate, nothing is paid for them.

-- Michael Lutz

[bokkie]

I've changed both settings (in the cfg and ingame) but distribution is still fluctuating a lot: with 160 produced, distribution ranges from 160 vs 0 to 40 vs 120 in a few months (dest1 vs dest 2).

To which values? And did you start a new game or was that on an existing game?

Some fluctuation is expected and wanted, as one of the factors is the stockpile size (if applicable for the industry) and an industry with a full stockpile should get a lot less than one with an empty stockpile. It's the same for the production influence, which is meant to let the cargo go the the industries you actually supply and not the others.

-- Michael Lutz

25,40 for the .cfg setting and 25 for the console setting. That was on an existing game. Starting another game (same seed) doesn't seem to make a difference. I've also tried 1000 for the console setting in the new game, same problem. Stockpile size isn't im frage I should think because it never exceeds 50 in the industries. (Btw, nice balancing if it takes stockpiles and production influence into account!! ). New game attached as a savegame, maybe that answers more questions than it raises .

[Tafidis]

First of all, congrats on yet another serious attempt at introducing destinations into OpenTTD. In my mind, this (pax/cargo destinations in general) is what many people have waited to see for a VERY long time and inclusion into trunk should be landmarked as an OpenTTD 2.0 version. Why? Because it completely changes gameplay from the original (since TTO) behaviour of you (the player) choosing where cargo is taken. This is a fundamental departure from the original game goals (serve as much as you can as far as possible) towards serving what the (game) world needs.

Now just 2cc on YACD and cargodist. Both approaches are great and both make sense in a different way for pax and cargo.

YACD imho is great for passengers: people always want to go to some place (specific tile) for their own reasons. They might change their route based on what services are available and their quality (rating), but NOT their destination. The only addition/change I would see in this is that if a route doesn't exist for a passenger's intended destination tile, then that passenger should travel to the nearest reachable destination. This will allow an easier start, where if you connect two towns A,B, any passengers from A going anywhere in the direction of B would take this route. Of course, the distance between the target station and the destination tile cannot be greater than that of the destination tile and the origin tile. In simpler words, pax should try to get as close to their destination tile as possible.
Cargodist style pax generation for newly created links is somewhat less intuitive. Why would I change my destination because now there is a high capacity link to somewhere else? Only if I am a tourist, I guess.
Also, larger towns should attract more passengers, so as to alleviate the problem of huge amounts of passengers from cities disappearing into villages. So a smaller % of pax from city (but still many) go to nearby villages while a larger % of pax from villages go to the city.

Cargo is a bit trickier. Cargo packets should move between industries (as a whole) rather than tiles. Here cargodist makes more sense. A producing industry would like as much of its cargo transported per month as possible, thus it should prefer destinations (since it can choose) that guarantee fast delivery/adequate capacity. On the other hand, YACD alleviates the "connect coal mine to far away power station" strategy. I think the best of both is optimal here. Start with YACD style destinations for cargo but set the parameters so that an industry has a small number of accepting industries (at least initially). Now if the production increases, the number of accepting industries can also increase. And, if there are newly introduced reachable destinations for the cargo, add some cargo to those destinations if there is extra demand for transportation. Or better, update the amount of cargo targeted for each destination based on quality of delivery. Like each connected destination has its own "rating".

That's all. Please excuse:
a) long post
b) Possibly irrelevant comments, right now my PC is undergoing maintenance and I have neither patch installed (or OpenTTD)
c) Possibly off-topic discussion? Perhaps one of the patch devs (or OpenTTD devs) should open a "cargo destinations discussion & suggestions thread"?

[FooBar]

YACD imho is great for passengers: people always want to go to some place (specific tile) for their own reasons.
...
Cargo is a bit trickier. Cargo packets should move between industries (as a whole) rather than tiles. Here cargodist makes more sense

I was in the shower thinking the exact opposite

When you look at cargo transport, that's purely demand-driven. Industry B purchases something from industry A and gets a transport company to bring his order from A to B. So there is a specific amount of cargo that needs to go from A to B, regardless if there already is a transport connection or not. If there's no connection, you can be the company that is hired for the transportation of the cargo. This is exactly what YACD provides.

When looking at public transport: At home people decide whether to use the car or public transport, based on various reasons. One of those reasons is if they actually can use public transport to get to their destination. If they can't, they won't use it.
Those passengers who decide to use public transport show up in the game. Those who decide not to don't show in the game (because the game models public transport, not personal transport, like for instance SimCity does). So those who enter the system have by definition a destination that they can reach via the system. This is what cargodist provides.

The best option would be having both systems in the game, with a setting for players which system they want to use, preferrably split in "passengers" and "cargo" (and maybe cargo split in multiple sub-options, but I don't particularly see the added benefit of that).

[Tafidis]

Ok, I see what you mean. It can make sense both ways. I was mostly referring to passenger/cargo generation (and destination assignment) in both patches. In my mind, both cargo and pax transportation is demand driven. I am not even sure they should be treated differently (same for sub-categories of cargo, as you said) in order to avoid an overly complicated model.

Imagine you (a passenger) live in town A and want to go to a tile in town B (YACD style). Now this tile is not in the catchment area of any station but there is a station in town B. Why not go there and take a taxi or walk or something? This makes more sense than (a) driving all the way yourself or (b) going to town C because it has better service. So, player has no control over where the pax want to go, but an incentive to serve as many destinations as possible so that more pax will prefer their company network than that of competitors.

With cargo, player should have no control over which destinations say, a coal mine sends its coal to, but if two or more destinations are connected, then the generated cargo should (adaptively) "prefer" the better links so that more of its cargo is actually transported. E.g. if 50 out of 100 tonnes are designated for power stations A and B (the other 50 for destinations not connected yet), then more of it should go to A than B (progressively) if A has a better link. You still have to connect the other destinations (say, C & D) to get the other 50 tonnes out of the mine but once you do, the quantities going to each mine can be dynamically updated cargodist style.

In any case, target for cargo should be an industry as a whole, not an industry tile, since you would have to make sure the whole industry is in the station catchment area, which is rather unintuitive compared to what we have now.

[FooBar]

It can make sense both ways

Yes, it does. Therefore I think it would be great to have both options (+ no destinations at all, i.e. what we have now) at the player's choice. Now I don't think Michi_cc is particularly interested in implementing both at the same time, it might be useful to 'leave room' for the other implementation, so that it's possible to add it later without having to rewrite the whole thing.

In any case, target for cargo should be an industry as a whole, not an industry tile...

Yes, that would make more sense.