Project: cargodest

[Frank327]

Regarding the problem of passengers filling up stopping trains, and busstops being overcrowded, how about passenger transport being based on travel time? I don't know much about C++, so I don't know if this is possible, but what if openttd tracked passengers going from one station to the other, and registrating the total amount of time it got them to go there? Busstops wouldn't be overcrowded anymore, because it takes so much time to wait for being first in line for the bus, then taking a slow journey to the main station, and then going all the way to the destination.

The first calculations by the game could be made by calculating the travel time for all connections. No waiting in stations, just the time it takes for the vehicles to travel from one station to the other, and loading/unloading. This can turn into a network with stations being separated by travel times instead of distance. Then openttd finds the 5 fastest routes from one destination to the other, and follows a passenger going from one station to the other every day (this is for long connections, not simple bus routes). By taking the average travel time over the last ten passengers or something like that, openttd finds the best route to take, and maybe takes percentages of passengers going each route. (for example, the fastest route will get 70% of the passengers, while the second fastest gets some 20% too). Also, maybe the amount of passengers wanting to travel the route could be determined by distance, station size and travel time, so that inefficient routes aren't overcrowded (very long tram routes for example)

I don't know if this would all be possible in the first place, or if someone is working on this already, but this would give more realistic results in game probably.

EDIT: I just read page 14 (I wasn't there yet when I wrote the post), and the oscillation problems, and performance issues. A better idea then is taking the average travel time of the trains between stations. This is not dependent on the number of passengers, so there will be no oscillation. Also, because it's pretty static, you can do the calculation something like once per half year.

By the way, on the oscillation part, station ratings normally have the same effect. When the trains can't cope with the load, the ratings go down, and the load decreases, which causes trains to be able to cope, so it increases again etc. The reason they're pretty static is because it balances automatically. I do think that this would happen with the time it takes to travel a route, but I'm not sure.

[dbkblk]

OK.

Infrastructure Sharing (r14422, with through-stops fix), cargodest (h1b7af927 based off trunk r14361, with smallmap routes view change for IS), in trunk r14458.

.exe and English .lng

I know i might be boring but could you build the same build with french language ?

I tried to build it on win or lin (with your code modif') but i didn't manage to pass the "make" test

Thanks,

H.

[deepblue2k8]

how about passenger transport being based on travel time?

Just an idea of me, if passenger transport would be based on travel time, you couldnt only take travel time into account, but waiting time too. Since openttd has a timetable for each vehicle, it should be relativily easy to calculate an estimated time of arrival based on the last stop and last estimated travel time to the destination.

i think it would be realistic, when passengers would choose the slow bus from A to B over C rather then the fast train, because the train arrives long after the bus so the total travel + waiting time of the train would be longer than the one of the bus.
On the other hand the passengers would skip the bus, because the train would arrive in short time and arrive sooner than the bus.

[PhilSophus]

Since openttd has a timetable for each vehicle, [...]

That's just wrong, thus anything that follows from it. Every vehicle in OpenTTD can have a timetable, but it doesn't have to. You don't want to make timetables mandatory, do you?

[...] it should be relativily easy to calculate an estimated time of arrival based on the last stop and last estimated travel time to the destination.

And on the issue of dynamic metrics, I suggest you read the posts starting here.

BTW: I did such estimated arrival calculations just for display in the ITiM patch. Though, I didn't profile this, my impression is that if that was done in the core for calculating every route that would pose a performance issue.

[MJS]

Just a random thought: how about writing away these data only every time when a vehicle is serviced? That would limit and nicely spread the amount of writing done. Only problem is to decide the initial split, before any servicing has taken place. (The side-effect that changes in schedules will not have an immediate effect on passenger behaviour seems rather realistic to me.)

[Roujin]

Just a random thought: how about writing away these data only every time when a vehicle is serviced? That would limit and nicely spread the amount of writing done. Only problem is to decide the initial split, before any servicing has taken place. (The side-effect that changes in schedules will not have an immediate effect on passenger behaviour seems rather realistic to me.)

What if someone uses "breakdowns=none" and "disable servicing if breakdowns are set to none" ?

[PhilSophus]

Just a random thought: how about writing away these data only every time when a vehicle is serviced?

My vehicles are never serviced (breakdowns and automatic servicing disabled). (Edit: Roujin, you beat me on that )

My strong belief is (and I say this as being a perfectionist myself) that routing should only depend on easy to determine and easy to understand static metrics. Everything else will just lead to hard to find bugs, undesired properties of the model (complex models tend to develop kind of their own will) and false bug reports, because the player doesn't understand the behavior he sees.

We are not doing scientific simulation here and you would be astonished how good simple models often approximate realistic behavior as compared to a lot complexer models even for scientific purposes.

From a game development point of view it doesn't matter at all if the means you apply for your model are realistic, but whether the results the model produces looks believable (or "realistic" within the game reality).

That said, depending routing on maximum speed of vehicles might be a good idea, but I doubt that anything much complexer than that will be appropriate to achieve the goal.

[Tekky]

how about passenger transport being based on travel time?

Just an idea of me, if passenger transport would be based on travel time, you couldnt only take travel time into account, but waiting time too. Since openttd has a timetable for each vehicle, it should be relativily easy to calculate an estimated time of arrival based on the last stop and last estimated travel time to the destination.

i think it would be realistic, when passengers would choose the slow bus from A to B over C rather then the fast train, because the train arrives long after the bus so the total travel + waiting time of the train would be longer than the one of the bus.
On the other hand the passengers would skip the bus, because the train would arrive in short time and arrive sooner than the bus.

I made such a proposal over a year ago in this thread. I am still thinking about how this proposal would be best implemented. However, I still haven't been able to figure out how late trains should be penalized. Late trains must be penalized, otherwise it would be possible for a company to attract large amounts of passengers by providing very unrealistic timetables that promise to take passengers to the other end of the map within 5 seconds. Maybe the "station rating" should be redesigned so that it says how reliable a certain company is in keeping to their timetables?

[Yexo]

Cargodest patch against noai r14544. I hope the patch is correct, it should be the latest cargodest revision from hg as of today.

Edit: uploaded new diff with src/routing* included.

[deepblue2k8]

That's just wrong, thus anything that follows from it. Every vehicle in OpenTTD can have a timetable, but it doesn't have to. You don't want to make timetables mandatory, do you?

Ah sorry, I think I explained it wrong. What I was trying to say was that OpenTTD already has the functionality to track the trip time of each vehicle, maybe by a second internal timetable, which is updated at every station and which cooperates with a user timetable if existing.

But I read the whole thread now and your I see your point with the issue of a dynamic metric, hen a vehicle is suddenly late or early, which could lead to serious side effects and performance issues when updating the nodes connected to it.

Anyway, you already mentioned a good idea on page 14 of this thread by taking the vehicle velocity into account to get an average travel time. This would lead to passengers taking the plane to destination B even if the airport is not on the direct line of sight but still faster.

And maybe in another far away step you could penalize vehicles which are late, if there is a simple way to do that like reducing the vehicle rating or something like that @Tekky?

[dasy2k1]

Somone said earlier (i cant find the posty again to quote it directly)

that in simutrans on a train 1 A-B-C-D-E-D-C-B-A from A it will fill with passengers going to B then if there are none left passengers going to C then D then E...

if another train 2 runs A-C-E-C-A (a semi fast) then it will fill with passengers going to C then E

a passenger at A going to C will get the first one that has space and stops at C
This could be the semi fast or the Stopper, the passenger just gets on the first train they see with C on the destination list that isnt allready full.

This IMHO would be the best and most simple load ballanceing method and would mean that if I actually ran thease trains (suppose B isnt that populiar and C is) train 1 would not run empty all the time
with train 2 full (especially if there are many trains sharing train 1s orders and not many sharing train 2s)

of cource this method would result in passengers for E hardly moving but this could be solved with a train A-E-A non stop whereas you cant solve the current problems except by not having any expresses

[fonso]

Why not simply fill the train with a random selection of passengers going to (or via) one of the stations it passes. Then the passengers to E will move just as fast as the ones to other places and the express train will still find enough passengers.

Of course this contradicts the idea of completely predetermined routes which some peope seem to like better. But don't we have an NP-complete problem here? Multi-Commodity Flow (see for example http://en.wikipedia.org/wiki/Multi-comm ... ow_problem), isn't it? So I guess you have no chance to find an optimal solution anyway.

[dasy2k1]

i wonder how this was hendeled in the now defunct PAXDEST system where (before the new sysetm based on speed was introduced that was not very good) passengers would take whichever vichle came first with somthing to do with cost involved...

in cargodest station view with next hops expanded this would result in the totall of passengers in the next hops being greater than the total number waiting because using my previous exmple

a passenger from A to C would show in both nect hop B and next Hop C

[el koeno]

Why not simply fill the train with a random selection of passengers going to (or via) one of the stations it passes. Then the passengers to E will move just as fast as the ones to other places and the express train will still find enough passengers.

Of course this contradicts the idea of completely predetermined routes which some peope seem to like better. But don't we have an NP-complete problem here? Multi-Commodity Flow (see for example http://en.wikipedia.org/wiki/Multi-comm ... ow_problem), isn't it? So I guess you have no chance to find an optimal solution anyway.

Random is good enough for me. There's simply too much going on at busy stations for the player to fully know what's going on anyway.

[cmoiromain]

Is cargodest still being worked on? Is there any chance of it hitting trunk any time soon?

[alyr]

Is cargodest still being worked on? Is there any chance of it hitting trunk any time soon?

Since it's in the 0.7 roadmap so i'm pretty sure we'll see it in the game sooner or later .

[Acerbus]

Is cargodest still being worked on? Is there any chance of it hitting trunk any time soon?

Since it's in the 0.7 roadmap so i'm pretty sure we'll see it in the game sooner or later .

I don't think that the roadmap reflects anything official from the devs. It's mostly guesswork by players.

[Roujin]

Is cargodest still being worked on? Is there any chance of it hitting trunk any time soon?

Since it's in the 0.7 roadmap so i'm pretty sure we'll see it in the game sooner or later .

I don't think that the roadmap reflects anything official from the devs. It's mostly guesswork by players.

No. This page is locked for editing by anyone except devs/admins. The list currently seen on this page was put there a month ago by rubidium/glx. That pretty much makes it official. (though, not protected from future changes)

edit: the page also says "Major features that could possibly be in 0.7.0", not "Major features that will be in 0.7.0"

[fabca2]

Is cargodest still being worked on? Is there any chance of it hitting trunk any time soon?

Since it's in the 0.7 roadmap so i'm pretty sure we'll see it in the game sooner or later .

in the roadmap, celestar is the dev, but it makes long time CElestar did not post anything here...
and the last build if from september the 21st...

if celestar could leave us a quick message...

[PhilSophus]

The last update of the cargodest branch was less than a week ago:

changeset: 20101:63f84835344d
tag: tip
parent: 20083:6d6a2bc214d1
parent: 20100:44d201d223f9
user: vici@rivendell.site
date: Tue Nov 04 22:03:15 2008 +0100
summary: Merge from trunk

And on the same day a bug fix was committed. That looks pretty much alive to me.

So, don't panic, developers have a real life, too.