Project: cargodest

[Celestar]

About the distance factor: does it vary according to the size of the town? IMO, a bigger town should attract passengers from further away than a small town (that means more passengers at an equal distance), and should be able to produce slightly more passengers in destination of small, far away villages.

I also wonder how the route is chosen... Travellers going from A to B would rather choose:
the fastest route ?
the cheapest route?
the one with the less transfers?
the one with the less stations to visit (transfer or not)?
the first one that is available?
a mix of all those factors (except first available) with a formula linking them together?
or do they choose randomly?

I would be very interested to know exactly how this works, because at the moment I think my TGV lines (much faster) are not used enough, whereas my metro lines (slower, more stops, but maybe a few less changes depending on the destination) too used.

edit: I precise that I am only mentionning passengers at the moment, I have not yet tested other cargoes.

No, the distance dependency does not depend on the town size, but it's a nice idea. I've added it to some of my lists.
Cargo takes the "cheapest" route, whereas a route cost is the sum of individual legs (a leg is the trip from one scheduled station to another scheduled station, regardless of whether the cargo remains on board or not). The cost of each leg is equal to the Manhattan Distance times a vehicle factor (currently 1 for aircraft, 2 for trains, 3 for road vehicles and 4 for ships) plus an additional 25 "stopover penalty". The cheapest route is taken. Always.
Later this week the vehicle factors and stopover penalties will be customizable.

Celestar

[fabca2]

I also wonder how the route is chosen... Travellers going from A to B would rather choose:
the fastest route ?

it looks difficult to define "fastest" route, for example If I have serverall different trains in a route, should I state the route speed is the fastest train speed ? (imagine you have your TGV and ten old stream operating on the same route, are you sure this route is so fast ?).
remind we are speaking about route, distance is a quite good approximation of speed, what you have to do is to use more straight rails for TGV line... or having more stop (penalty) for your subway.
and btw does it makes sens to link two city with subway ?

[Wolf01]

Timetables might be the answer
Some people already said they are against an use of timetables on cargodest, but IF this can be an optional use?
You aren't forced to use timetables to run the vehicles, but if you use them you can fine tune the loading times (instead of full load, load for 1+ days, which depends on how much late is the vehicle)
If you want to make the cargo to chose between the short or the fast route, you should use timetables

[Mondane]

Reading all this great stuff about CargoDest, I was thinking about this:

Wouldn't it be cool that cargo/passengers propose a destination where no station is build yet, or which isn't reachable from the current station?

This would encourage players to connect to those destinations sooner.

Maybe not all the time, but perhaps implemented as a marketresearch. The player has to pay money to start a research for a city/industry to find out to which other station/town/city/industry the cargo/passengers want to go most.

The results could be that a lot o f people want to go to town X, which isn't being served yet. Now, the player can make a connection to this town.

[Brianetta]

evaarties, the subsidy window could be used to that effect already. One thing I'd like to see is available subsidies highlighted where I have a station in at least one of the towns already.

[fabca2]

If you want to make the cargo to chose between the short or the fast route, you should use timetables

I'm not sure.
Timetable is on vehicule level, not on route level.
You can have different vehicule class that operate this route (then with different timetable), how do you want the system define the "route timetable" ?
example train 1 : has the following order : A -> B -> C -> A
train 2 is faster (different timetable) has order : A -> B -> C -> D -> E -> A
both share route A->B->C (btw "share" is not the right word, "define" is better here)
train 3 has order A -> X -> Y -> C -> A

for passenger from A to C, cargodest will have to choose between two routes : A->B->C and A->X->Y->C
not between tree trains (tree timetable) this is why timetable is not relevant from my point of view.

okay, it can works if you (in your game) assume that this case won't occurs (*), but you cannot enforce this rule to every games of every ones.

(*) you must ensure that on a route, all train will have same timetable : share same order list, and drive at same speed, a little bit restrictive to be interesting, imho.

regards.

[Mondane]

evaarties, the subsidy window could be used to that effect already. One thing I'd like to see is available subsidies highlighted where I have a station in at least one of the towns already.

I totally forgot about that, yeah the subsidy window does already a lot of what I want. The only thing that is different, is that in my case you pay for the research and you do not gain mutiplied income. That part of the idea, I still like to see in the game.

[jub]

Updated windows binary.

[dbkblk]

I have updated the game with your build and now..it don't work !!

The bug is on the screenshot.

[cmoiromain]

about the routes:

you say there is a different cost factor depending on the vehicle. Could the running cost of the vehicle used be taken in account? I guess that would be pretty hard to do if different engines run on the same route though...

And about the way they choose, thanks for the explanation. I'd still like to find a way of making things more realistic, I'm currently thinking about it (though I have strictly no idea what is realisable). I would like to have passengers to take the bus, then metro to go to the TGV lines, there they take the metro again, and finally the bus. In my case, I have a TGV line as well as metro lines (RER if you prefer, which link various towns together but are much slower). TGV is much much faster, but way more expensive. I would like people to prefer TGV for longer distances, even when RER is available. A solution would be that when the TGV arrives, they will use it. However, if it is full, they will go for the RER (in other words, when there are two ways of reaching the same point, they chose the first available).

One last thing, about the transfer money:

IMO we should get the transfer money immediately, and not only in the vehicle stats: Imagine taking the route described above (bus, metro, TGV, metro, bus). You have to pay each time separately. In all my games I have reached a point where I cannot make any more money, I am in deficit even though each vehicle has an enormous profit, and all are loaded by 100%. I believe this is due to the fact that the transfer money disappears in mid-air, so the vehicle profits are smaller than the running costs.
This gives me an idea of a suggestion to make: it could be possible to create groups of stations (just like vehicle groups), and have special characteristics for each group. For example, I could create a group for all my TGV stations, and a group for all my metros in Paris. I could assign a value to the metros in Paris, saying that it costs the same amount to travel from any of those stations to the other, independent of the vehicle used (like it works IRL, it costs one ticket to travel inside Paris, no matter where you go).

[el koeno]

If you want to make the cargo to chose between the short or the fast route, you should use timetables

I'm not sure.
Timetable is on vehicule level, not on route level.
You can have different vehicule class that operate this route (then with different timetable), how do you want the system define the "route timetable" ?
<snip>

I think for vehicles with shared orders, their timetables are shared as well. That would mean routes will have to be based on vehicles with shared orders (as in the previous incarnation of paxdest).

I wouldn't mind using timetables, as long as they require no user input. That means that they should be on autofill by default, and some mechanism should be in place that prevents them from getting out of whack if conditions change, e.g when vehicles are upgraded by faster models, shortcuts are constructed, or traffic increases.

Re. transfer money:
I think it's important to get your passengers to their end destination ASAP. If they have to wait at a transfer station for too long, the end-payment might be lower than the transfer money. I'm not sure about this though...

[Celestar]

about the routes:

you say there is a different cost factor depending on the vehicle. Could the running cost of the vehicle used be taken in account? I guess that would be pretty hard to do if different engines run on the same route though...

And about the way they choose, thanks for the explanation. I'd still like to find a way of making things more realistic, I'm currently thinking about it (though I have strictly no idea what is realisable). I would like to have passengers to take the bus, then metro to go to the TGV lines, there they take the metro again, and finally the bus. In my case, I have a TGV line as well as metro lines (RER if you prefer, which link various towns together but are much slower). TGV is much much faster, but way more expensive. I would like people to prefer TGV for longer distances, even when RER is available. A solution would be that when the TGV arrives, they will use it. However, if it is full, they will go for the RER (in other words, when there are two ways of reaching the same point, they chose the first available).

One last thing, about the transfer money:

IMO we should get the transfer money immediately, and not only in the vehicle stats: Imagine taking the route described above (bus, metro, TGV, metro, bus). You have to pay each time separately. In all my games I have reached a point where I cannot make any more money, I am in deficit even though each vehicle has an enormous profit, and all are loaded by 100%. I believe this is due to the fact that the transfer money disappears in mid-air, so the vehicle profits are smaller than the running costs.
This gives me an idea of a suggestion to make: it could be possible to create groups of stations (just like vehicle groups), and have special characteristics for each group. For example, I could create a group for all my TGV stations, and a group for all my metros in Paris. I could assign a value to the metros in Paris, saying that it costs the same amount to travel from any of those stations to the other, independent of the vehicle used (like it works IRL, it costs one ticket to travel inside Paris, no matter where you go).

I'd be best if you could show me a savegame or something

Celestar

[Gaebrial]

I'm trying to get this patch working, but the make command can't find the boost libraries. Do I have to place the boost libraries somewhere specific? I've tried following the instructions on the boost page (where I downloaded the libraries from), but I don't speak Unixese fluently, so I may have mistranslated it. I get errors like "error: boost/graph/adjacency_list.hpp: No such file or directory" and "error: ‘boost’ has not been declared". I've even tried running the make command with the -I parameter pointing to the boost library (currently "~/boost_1_36_0", but I've tried it in different locations with no success). I've successfully compiled the example on the boost website, so the boost libraries must be installed correctly. In addition, I can locate and open the particular files that make says it cannot find, so I know they are there. So why can't make find them?

[Celestar]

routing_classes.h includes <boost/graph/adjacency_list.hpp> (This file includes a bazillion of others)

So if any directory /path/to is in your default include list (like /usr/include or /usr/local/include), the files need to be placed in /usr/include/boost/graph/adjacency_list.hpp.

If you have it somewhere else, you can use the -I switch, but the boost stuff needs to be installed in some directory called boost/

Celestar

[Forked]

Two days in a row cargodest has made me come late for work.

[Tvel]

Great patch!

But i am thinking, is there a way a train to skip next order if there is no passengers/cargo to unload on the next order?

[Gaebrial]

routing_classes.h includes <boost/graph/adjacency_list.hpp> (This file includes a bazillion of others)

So if any directory /path/to is in your default include list (like /usr/include or /usr/local/include), the files need to be placed in /usr/include/boost/graph/adjacency_list.hpp.

If you have it somewhere else, you can use the -I switch, but the boost stuff needs to be installed in some directory called boost/

Celestar

I don't mean to sound thick, but what do you mean by "default include list"?

I've tried "make -I ~/boost_1_36_0".
I've tried "export PATH=~/boost_1_36_0:$PATH" followed by a simple "make".
I've tried "./configure -L~boost_1_36_0" followed by "make".
I've tried "./configure --shared-dir=~/boost_1_36_0" followed by "make". This did actually appear to pick up the boost directory, but couldn't find any files in there.

All of the above result in the make command being totally unable to find the boost files.

If somebody could explain in simple terms exactly which hoops I have to jump through in order to get this working, I would be most grateful.

(Incidentally, for what it's worth, I'm using an iMac with OSX Leopard. I don't know if that makes a difference.)

[jub]

Your compiler didn't find include files because they were not on predefined paths.

You could try 'make install' in case it is provided by the library or copy include files by hand to the correct location or modify the makefile for openttd to take your 'boost' directory into account.

[Celestar]

routing_classes.h includes <boost/graph/adjacency_list.hpp> (This file includes a bazillion of others)

So if any directory /path/to is in your default include list (like /usr/include or /usr/local/include), the files need to be placed in /usr/include/boost/graph/adjacency_list.hpp.

If you have it somewhere else, you can use the -I switch, but the boost stuff needs to be installed in some directory called boost/

Celestar

I don't mean to sound thick, but what do you mean by "default include list"?

I've tried "make -I ~/boost_1_36_0".
I've tried "export PATH=~/boost_1_36_0:$PATH" followed by a simple "make".
I've tried "./configure -L~boost_1_36_0" followed by "make".
I've tried "./configure --shared-dir=~/boost_1_36_0" followed by "make". This did actually appear to pick up the boost directory, but couldn't find any files in there.

All of the above result in the make command being totally unable to find the boost files.

If somebody could explain in simple terms exactly which hoops I have to jump through in order to get this working, I would be most grateful.

(Incidentally, for what it's worth, I'm using an iMac with OSX Leopard. I don't know if that makes a difference.)

Do you have a "boost/" subdirectory in boost_1_36_0/ ?

Celestar

[Gaebrial]

routing_classes.h includes <boost/graph/adjacency_list.hpp> (This file includes a bazillion of others)

So if any directory /path/to is in your default include list (like /usr/include or /usr/local/include), the files need to be placed in /usr/include/boost/graph/adjacency_list.hpp.

If you have it somewhere else, you can use the -I switch, but the boost stuff needs to be installed in some directory called boost/

Celestar

I don't mean to sound thick, but what do you mean by "default include list"?

I've tried "make -I ~/boost_1_36_0".
I've tried "export PATH=~/boost_1_36_0:$PATH" followed by a simple "make".
I've tried "./configure -L~boost_1_36_0" followed by "make".
I've tried "./configure --shared-dir=~/boost_1_36_0" followed by "make". This did actually appear to pick up the boost directory, but couldn't find any files in there.

All of the above result in the make command being totally unable to find the boost files.

If somebody could explain in simple terms exactly which hoops I have to jump through in order to get this working, I would be most grateful.

(Incidentally, for what it's worth, I'm using an iMac with OSX Leopard. I don't know if that makes a difference.)

Do you have a "boost/" subdirectory in boost_1_36_0/ ?

Celestar

Yes. Using "c++ -I ~/boost_1_36_0 example.cpp -o example" works. (This is the example from the boost page).

Anyway, I've now solved it. The make actually now works. What I had to do was copy the boost subdirectory from within boost_1_36_0 to /usr/local/include. Actually, I copied the entire contents of boost_1_36_0 to /usr/local/include, which I probably didn't need to do.