Passenger routing code?

[jamespetts]

I am looking into the (probably rather complicated) task of modifying the code such that passengers will not route unless all the stops at which they need to change are not overcrowded (in code terms, not having the status COL_RED). However, the routing code is (predictably) quite intricate, and it would help me greatly if somebody familiar with the code could let me know where to start looking. I know that it will be somewhere in simhalt.cc - but is there a specific routine where passengers check for the crowding of a stop? If the stop is overflowing with mail, but has plenty of room for passengers, is there a way to distinguish that (and vice versa)?

[prissi]

The only way to do this is suche route, which is already called from step_passagiere and also everytime some goods arrive at a station and not other goods are waiting there. However, if goods are already waiting there, no route will be search but goods will simply joined.

[jamespetts]

The only way to do this is suche route, which is already called from step_passagiere and also everytime some goods arrive at a station and not other goods are waiting there. However, if goods are already waiting there, no route will be search but goods will simply joined.

Thank you for the information - I shall look into that :-) If a route search is not carried out when there are already goods at the station, is there a way to re-check the routes periodically to ensure that there are no overcrowded stops on the way? Or are the routes already periodically recalculated?

[prissi]

Routes are only recalculated when a schedule is changed or a stop is changed (or a factory pops up).

[jamespetts]

Routes are only recalculated when a schedule is changed or a stop is changed (or a factory pops up).

Thank you for the information :-) Do those events call suche route?

[isidoro]

After some private eye work, I've found out that suche_route is called whenever new passengers are generated and can, perhaps, return if any of the stations in the found route is overcrowded for the calling routine to decide if those passengers desist.

In uint32 haltestelle_t::starte_mit_route(ware_t ware), passengers packets are added to their station when created.  In uint32 haltestelle_t::liefere_an(ware_t ware), all packets (passengers or not) find next transfer when arriving to a transfer station.  I've programmed very easy patch in which passenger arriving to a transfer station in which the next transfer is crowded, will refuse travelling and become unhappy.

I've tested with a well developped game in which the yellow company deals with urban passenger transport and the red one with interurban passenger transport.  As you can see in the picture their profits go down as expected.  I'd like to test the patch with a fresh new game and see.  In the picture you can also see how a transfer station becomes uncongested and even with no unhappy passengers.

[gerw]

I'm currently reorganising the routing of goods (http://forum.simutrans.com/index.php?topic=1016.0). I will also include a caching system for the routes in order to decrease computation time. Thus a dynamical routing of passengers will make this impossible.

And I think, it's also not realistic:
If a passenger starts to travel, how can he know which stops are overcrowded and which aren't??

[jamespetts]

Grew,

the extreme overcrowding of some stops is a serious gameplay problem. In real life, 27,000 or so passengers do not accumulate at a railway station because the local 'busses can bring passengers there faster than the trains can take them to their destinations, yet this can regularly happen in Simutrans with larger towns.

What I suggest is not a system where passengers re-check their route on the fly and abandon their journeys half-way through, but a system where passengers check the entire route for overcrowded interchange stops on the way, and only add themselves to the route at all if none of the interchange stops are seriously overcrowded (behaving in the same way as if the origin station is overcrowded if any of the interchange stations are).

I do not know whether this will fit with your caching system, but it really is important to have it in the code somewhere, because the (sometimes absurdly) excessive overcrowding levels can seriously distort the game and have a substantial adverse impact on enjoyment.

[isidoro]

[...]
And I think, it's also not realistic:
If a passenger starts to travel, how can he know which stops are overcrowded and which aren't??

The check is done only when transferring, not while in the vehicle.  If the passenger arrives at a transfer station and get informed that the next transfer station is crowded, he becomes unhappy, refuses to travel and hire a private car (won't use collective transportation).  Just the same that is done on starting his journey if he knows the destination is crowded.

James is right in my opinion: what really makes no sense is some 20000 people waiting at a station...

[jamespetts]

Ahh, interesting. Isidoro, your approach is slightly different from mine in that I'd planned to set it so that only at the origin station is it checked whether the route is overcrowded (if that is done, then the transport company gets no money for transporting people part-way through their journies only to have to abandon them to hire a car or take a taxi...).  But if Isidoro's patch prevents the population of a medium sized town waiting at a single railway station, then it is certainly worthwhile...

[whoami]

Nice to see this happen (probably), but please don't limit the function to passengers (or mail). It should be used for all types of goods.
Checking for overflowing transit stations once (at the origin) will be sufficient to get the effect.

And I think, it's also not realistic:
If a passenger starts to travel, how can he know which stops are overcrowded and which aren't??

The mechanism isn't so realistic, but the result will be. In real life, people will fail to get reservations for their trains/airplanes, or read (in the news) about extended waiting times due to lack of capacity, and therefore choose to avoid the congested routes, or even the transportation company in question.

[jamespetts]

Whoami,

ahh, yes, both good points. One other thing that could stand to be added is a phased effect, so as to avoid the position where, if the station is 1 below capacity, 100% of passengers/goods will route, and if it is 1 above capacity, 0% of passengers/goods will route. In real life, stations can still work when they are overcrowded, but they become increasingly unpopular the more overcrowded that they are. I suggest a system whereby a weighted random proportion of passengers (etc.) refuse to route if the station is overcrowded, the weight being determined by taking the station's capacity, an overcrowded maximum specified for the purpose of this system, and taking the difference between the two divided by the maximum as the chance of failing to route to feed into the randomiser.

[isidoro]

I've been playing with the code patched and haven't noticed those effects.  As it is now is simple and:

• Stations get at maximum 110% capacity
• Building station adequate station premises plays an important role
• Playability:  I don't know.  The game seems nice to me, but I have not played the same game without the patch.  Some additional feedback would be great.

BTW, the original patch, though small, was wrong.  If the destination station is crowded, the passenger will not travel and become unhappy.  That case should be eliminated since that passenger will not wait at the station.  Here is the version updated and corrected.

[jamespetts]

Isidoro,

I have not had a great deal of time yet to look at your patch in detail, because I have been spending a very long time trying to set up a read-ahead for the speed limits in order to allow smoothed slowing for speed limits (I am still debugging my data structures). However, as I understand it, your patch means that, when passengers hit an overcrowded station (i.e., a station at >110% of capacity), none of them will continue on their journey; whereas, if passengers hit a station that is not overcrowded (i.e., a station >= 110% of capacity), all of them will continue on their journey. What I suggested was a system (which would also be simple) that set for capacities between, say, 100% and 130%, a certain proportion of passengers to continue, and a certain proportion to leave, depending on where between 100% and 130% that they are, which would make the impact of overcrowding less erratic and more realistic.

As to the point about the original patch: I thought that the idea of unhappy passengers is that they were registered when they arrived at a station and did not travel because they were unhappy: are you saying that the original did that and that the new one does not, or that the new one does that and the original does not? Certainly, if passengers arrive at a transfer station and find it overcrowded, and cease the rest of their journey for that reason, they should register as unhappy, since that is the same behaviour as for passengers arriving from the local area rather than from other forms of transport.

[whoami]

(...) cease the rest of their journey for that reason, they should register as unhappy, since that is the same behaviour as for passengers arriving from the local area rather than from other forms of transport.

Since the passengers' origin isn't known at that point, they would be counted the same way as unhappy people from the station's coverage area, and that would lead to misleading numbers. A new variable per stop would be advisable for this, also if the check is only done at the origin.

[jamespetts]

Since the passengers' origin isn't known at that point, they would be counted the same way as unhappy people from the station's coverage area, and that would lead to misleading numbers. A new variable per stop would be advisable for this, also if the check is only done at the origin.

Ahh, I see what you mean. Would it be possible to set it so that it checks at the origin station whether any of the stops en route are overcrowded, and for the passengers to count as unhappy and refuse to board at that stage if there are? That would solve that problem.

[isidoro]

It's not exactly as that.  When a passenger arrives at a transfer station, he checks if the next destination is crowded (100% crowded, not 110%).  If it is, he becomes unhappy and desists, unless the next station is destination, in which case, he does travel.

So unhappy people is counted at origin stations, not destination and makes sense.

@James: I'm for the simple case, all or nothing.  Even with your prevention, stations will get overcrowded, since there is local people trying to travel.

[jamespetts]

It's not exactly as that.  When a passenger arrives at a transfer station, he checks if the next destination is crowded (100% crowded, not 110%).  If it is, he becomes unhappy and desists, unless the next station is destination, in which case, he does travel.

So unhappy people is counted at origin stations, not destination and makes sense.

Will stations be able to become infinitely overcrowded with people whose destination is the next station, in that case?

@James: I'm for the simple case, all or nothing.  Even with your prevention, stations will get overcrowded, since there is local people trying to travel.

I'm not sure that I understand why simple is better when simulating reality which is far from simple - but the local people trying to travel, as I understand it, are already accounted for in the code: people arriving at an overcrowded station from the local area, not as transfer passengers, already desist from travelling if the station is overcrowded.

[isidoro]

I cannot make myself be understood.  :  The patch is so simple that I think it is better to explain it.  In simhalt.cc, there's a function called uint32 haltestelle_t::liefere_an(ware_t ware).  Whenever a new packet of goods/passengers arrives at a station, the function is called.  Following the source code, these steps are done:

• if next transfer or destination is invalid, return
• if the destination was this station: if factory, add cargo; if passengers, add pedestrians; return
• If there are other stuff with the same destination, merge with it, return
• Calculate next transfer
• if next transfer or destination is invalid, return
• (*) Here comes the patch
• If there are other stuff with the same destination, merge with it, return
• add the stuff to the station waiting list

And the patch says:
if(ware.gib_besch()==warenbauer_t::passagiere && ware.gib_zwischenziel().is_bound() && ware.gib_ziel().is_bound() && ware.gib_zwischenziel()!=ware.gib_ziel() &&  ware.gib_zwischenziel()->gib_ware_summe(warenbauer_t::passagiere)>ware.gib_zwischenziel()->get_capacity()) {
               ware.gib_zwischenziel()->add_pax_unhappy(ware.menge);
               return ware.menge;
       }


Translated to Shakespeare's language: if stuff is passengers and transfer is valid and destination is valid and transfer different from destination and passengers at transfer is greater that capacity at transfer, then add these passengers to unhappy count at transfer and return.

I'm not sure that I understand why simple is better when simulating reality which is far from simple

I'm fan of the Occam's razor.  Let's not forget this is a game.  You can be more precise or accurate in the calculations but the results may be the same, or quite similar and not worth the effort.  That's why I asked opinions about how is the patch felt for playability just now.  A sculpture should be balanced.  Not too much detail in one hand and a ball in the head.

Nice to see this happen (probably), but please don't limit the function to passengers (or mail). It should be used for all types of goods.

It should be quite simple to eliminate the condition "if stuff is passengers", but then those goods will disappear.  I don't know what is the procedure followed by factories and if they will order more...  I'll try.

[prissi]

Goods should not disappear. Otherwise I can built one giant oilrig serving thousand of oiltankers, because the connected power station is served by a single truck. For goods maybe whole route should be checked; alternatively, it should not unload (since the new system the convoi wil go filled between those two destinations and ear no money but costs a lot. Also simple to do this.)

[jamespetts]

Prissi,

ahh, the alternative suggestion is an ingenious one!

[isidoro]

Goods should not disappear. Otherwise I can built one giant oilrig [...]

Good point!  The alternative is a pretty hard one, though.  Some present running games, with low profit goods transportation would ruin at once   And surely someone would be tempted to ask for a wait until unloaded option like in OTTD, which I don't like too much.  There has to be an easy alternative...

Factories push goods to the transportation system and other factories pop goods.  If the intermediate buffers are full, no more goods should be allowed. Perhaps it can be done locally, a transfer station is no more than a "special factory"...  I have to think it a little more and a temperature is no good companion.

[prissi]

Well, if a full convoi runs between those station, the origin stations will be overcrowded soon and stop good acceptance. There is a delay but not too large, imho.

[isidoro]

That's true.  But the cost...  it's a question of trying and see.  Game will be harder, that's for sure.

I've thought of another possibility that seems pretty simple but for a small thing:

• When the next transfer of a loading vehicle is full, simply don't load.  If the vehicle is waiting for full load, keep waiting.  If not, continue travel unloaded.
• The small thing: when more free space appears at the transfer station, the waiting vehicles trying to go there should be warned to try lo load again.

That will not guarantee that there be no surplus, but wouldn't be very big.

Do you think it is worth trying?

[prissi]

Sounds better to me than full meaningless convois.

[isidoro]

I've come with a modification to the patch.  The modification is three lines long and took me two and a half days.  Frustrating...

With the patch:

• Transfering passengers or mail with next transfer overcrowded are discarded and, if persons, added to unhappy people at next transfer
• Goods with a full next transfer will refuse to load at origin until there is place at the transfer station.  This is not applied if next transfer is also final destination

Warning:  I've tried the patch with an old savegame and profit dropped enormously.  Care must be taken when designing stations with this patch.  I liked the experience at first glance, though.

[emaxectranspoorte]

Warning:  I've tried the patch with an old savegame and profit dropped enormously.  I liked the experience at first glance, though.

THIS IS EXACTLY THE SAME POINT I tried to make all this time. :

[jamespetts]

This looks very interesting - thank you Isidoro for putting so much work into this. I shall have to have a look at this one when I have finished with the various settings for corners and weight limits.

[isidoro]

Patch updated for r2118...

The test game I'm playing keeps interesting.  It is perfectly possible to get a decent profit with the patch, yet not having overfilled stations.  One of my favorite ways of gaining an easy and quick profit is trying to build a line in which trains transport cargo in both directions.  For example, if I connect A--B--C--D--E, with:

• B, factory, serving A and E
• D, factory, serving A and E
• C, transfer station, built because A,B and D,E heights differ.
  

I build two lines B--C and C--D and both trains get loaded in both directions and profit is big.  With the patch, it works, but hardly.  If producing factories B and D get overfilled, trains in the middle won't travel.

[jamespetts]

Another version - excellent! This patch is very worthwhile. I am somewhat sorry that I have not yet had more time to test it (I have been working on other patches instead), but it looks extremely promising. The overcrowded stations problem was a major drag to gameplay in Simutrans (and made things very confusing for newer players, too: I remember being confused about that when I was new) - this might make a really make a difference. Excellent work!

[prissi]

Maybei this should become something like "Advance Player mode" like "normal player mode" and "Beginner Mode"

[jamespetts]

I'm not sure about the advanced bit - the huge overcrowding of stations is actually quite overwhelming and confusing for newer players. Whilst it is harder in some respects to make a profit without mega-overcrowding being allowed, it makes for a better and more balanced game overall. New people to the game who try it first in "normal mode" might be put off by the excessive overcrowding, as I almost was when I first played Simutrans.

Edit: It is actually more fun and more relaxing to be limited in the game by not having enough money, rather than by not having enough time. Having overflowing coffers but not anywhere enough time to add enough capacity to deal with all the passengers (without often having to pause the game) makes the game not very fun to play.

[isidoro]

I'm now playing with the patch and I like it very much.  You have to be *very* careful when designing your network.  But I'm with Prissi in that it may be confusing for new players.

It usually happens that a vehicle is ready to load but it doesn't load with no apparent reason.  I know the reason is that the transfer station is full, but that is not clear for a beginner.  I, when beginner, got confused with station types (passenger, cargo, etc.) and took me some time to make the first line work.  Imagine if, once I get it, the trains stop for no apparent reason...

[colonyan]

Hum...... I'm kind of afraid to ask this but,,,, so we will have this problem solved soon?
From what I read, it seems like so.
If so, this will be included in next release with along the curving patch?

[z9999]

@isidoro
One question.

In simutrans, capacity of station is for each goods category.
So, overcrowded is also for each goods category.

Why do you use "sum_all_waiting_goods" ?


[edit] Very sorry. "Category" is not right. Not category but goods.
Each goods has its own capacity, station status bar above station name label shows this.

[attachment deleted by admin]