News:

Simutrans Sites
Know our official sites. Find tools and resources for Simutrans.

[Bug] A large number of passenger masses appear around the big cities

Started by Ranran(retired), May 31, 2020, 08:45:52 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

You should sometimes see strange sights on the server.
Occasionally a large number of passenger masses appear around the big cities. They appear at the same time and disappear at the same time.
It seems they are going to the next city.
It is often found at my bus stop between St. james Milham and Pondton.
I sometimes catch it and try to squeeze money, but the mass suddenly disappears and warps to another stop. They confuse my network.  ::-\
Exactly I'm on the server now fighting a group of 1600 middle class. So far I have defeated them about 200.

EDIT:
They seem to want to go to the St. James dock, but back and forth the pondton gates.

EDIT2:
The destination seems to be changed. They changed their destination to a windmill when they moved to the next bus stop. I got caught in the trap.  ::'(
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

Although it is difficult to be sure of what is occurring without a precise reproduction case of the phenomenon from its inception, I believe that it is likely that this is an instance of a known phenomenon that is an unavoidable side-effect of necessary features.

What occurs is that, if the number of passengers at a transfer stop become so great that they arrive at a faster rate than they can be transported, the waiting time of that transfer stop to the passengers' next transfer stop increases to such a point where the passengers calculate that they can more quickly get to their destination by taking a different route from their current position to their ultimate destination. This re-routing is performed periodically and is necessary to deal with changing networks. Because only one route to each destination from each origin is possible with the routing system, all passengers re-route at once, and attempt to transfer to their new intermediate destination. Because there are a large number of them, the waiting time to this destination also increases because they cannot all be transported on the first vehicles to arrive, and the process repeats. Sometimes, the passengers' next transport option is a walk to a nearby stop, so they can often transfer on foot and appear at a different stop to that which they recently left.

This has been discussed in the past, and the only means of preventing this involve causing even greater problems, such as unacceptable computational load, unlimited numbers of passengers accumulating, passengers not routing based on time or similar.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Those anomalies are quite disruptive to consider a slight modification of the current system:
It might be a solution to not consider those overcrowding related additional transfer times when calculating the best route, but to apply these after a route was found and before judging if the pasenger would prefer to walk or to take the private car instead.

From a real-world standpoint that seems reasonable to me.
These days, in the real-world, public transport routes are usually calculated by using some piece of software.
That software will consider vehicles to be punctual, not overcrowded and will consider a minimum required time for transfers.*
Passengers will not know before actually arriving at an overcrowded station or attempting to enter an overcrowded vehicle, that it is overcrowded, so they won't consider this in their calculations.
Such situations will, however result in a bad reputation of public transportation, thus they might consider to take the private car, bike or walking instead the next time.
Apart from that effect being more immediate than actually reputation does behave in the real-world, it would get rid of the annomalies, representing real-world behavior reasonably.

Just my thoughts. I am quite sure there will be a proxy for whatever discussion going on.
I do believe the only proxy in here might be current overcrowding as a measure for something like service quality.
There might be a better system to measure such but in any case, I don't think people do care about overcrowding when calculating routes, as that information is simply not available to them.
Until we might get a better measure for service quality, using overcrowding as such might be a good approximation.
If this is experienced to cause any kind of anomalies, considerations of a better system can still be done.
In any case, it should be by-far more realistic than those Barbarian Invasions.


*Some modern system do attempt to take care of live situations and predictions of crowding and delays, but simmulating these would be very difficult, especially as that would require passengenger route recalculations to be much more responsive than the background calculations.

jamespetts

Quote from: Freahk on May 31, 2020, 02:59:56 PM
Those anomalies are quite disruptive to consider a slight modification of the current system:
It might be a solution to not consider those overcrowding related additional transfer times when calculating the best route, but to apply these after a route was found and before judging if the pasenger would prefer to walk or to take the private car instead.

This is not possible without a ground-up rewrite of the routing system, since the current system simply produces one journey time figure per route.

Also, this is undesirable, as it prevents effective competition between players on the basis of service frequency, which would fundamentally undermine a very important mechanic and make the simulation less real in significant ways and ways that would be perplexing and incomprehensible to players.

Quote...I do believe the only proxy in here might be current overcrowding as a measure for something like service quality.
There might be a better system to measure such but in any case, I don't think people do care about overcrowding when calculating routes, as that information is simply not available to them.
Until we might get a better measure for service quality, using overcrowding as such might be a good approximation.
If this is experienced to cause any kind of anomalies, considerations of a better system can still be done.
In any case, it should be by-far more realistic than those Barbarian Invasions.

A general "service quality" measure will not do the same thing as the current system, and, again, would require a ground-up rewrite of the whole passenger/goods/mail routing system. That is because the weight for each edge in the pathfinding algorithm is based entirely on time. This is necessary because the time is used both for determining which is the fastest route and also for determining whether a given time is with passengers' journey time tolerance. No other means of weighting the edges could do this with a single integer. Any means not using a single integer in this way would require a totally different system than that currently used and would be likely to be very significantly more computationally intensive.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

It's not even a general service quality measure but a route specific service quality measure based on the current situations.
It's exactly the same as the current system apart from applying overcrowding related waiting times after selecting a specific route, instead of applying these when calculating shortest routes.

The only change that should be required in backgorund calculations of shortest routes is not applying these aditional waiting times there. The only change that should be required in passengers route search within the precalculated network is applying current waiting times to the selected route to determine if that specific route is currently better than taking any other mode of transport.

Service frequencies were not mentioned in any way nor do they differ in any way.
The only competition that might actually be negatively affected is a player whose network got a very good service in theory but a very bad reputation (that means much overcrowding) will still either attract those passengers or get passengers to use their private car.
Still much better than Barbarian Invasions.

In any case, I see you like those Barbarian Invasions. I guess it's best to not waste time on such thoughts anymore. I'll concentrate on seeking and reporting bugs when I'm in mood to do so.

jamespetts

Quote from: Freahk on May 31, 2020, 04:48:13 PM
It's not even a general service quality measure but a route specific service quality measure based on the current situations.
It's exactly the same as the current system apart from applying overcrowding related waiting times after selecting a specific route, instead of applying these when calculating shortest routes.

The only change that should be required in backgorund calculations of shortest routes is not applying these aditional waiting times there. The only change that should be required in passengers route search within the precalculated network is applying current waiting times to the selected route to determine if that specific route is currently better than taking any other mode of transport.

Service frequencies were not mentioned in any way nor do they differ in any way.

That is the very change that is not possible with the current routing system as explained. The only data that the routing system gives is (1) the total journey time (a mix of travelling and waiting); and (2) the next transfer. Whether there is a route at all is indicated by whether the journey time is less than the maximum possible value for an unsigned 32 bit integer. It does this from an input of (1) the starting stop; and (2) the type of goods/mail/passengers (and, where applicable, class).

This information is obtained from the single database of routing data. There is no way of taking into account waiting times for some purposes and not others: the waiting times are all part of the single total journey time statistic in the routing database.

In any event, this would be undesirable, as explained above: service frequencies are relevant, since these affect waiting times. There is no way of distinguishing waiting times caused by low service frequencies and those caused by overcrowding. Waiting times from any given stop to any given stop are represented by a single integer.

Edit: I see that you edited the message whilst I was typing the above.

QuoteThe only competition that might actually be negatively affected is a player whose network got a very good service in theory but a very bad reputation (that means much overcrowding) will still either attract those passengers or get passengers to use their private car.

The trouble with this is that it leads to anomalies: if we have two public transport routes between point X and Y, one of which (route A) has a slightly faster journey time but a much, much longer waiting time than the other (route B), with the proposed system, passengers would all attempt to take the first and ignore the second. This would mean:
(1) passengers would use private cars or walk even when the private car or walking journey is much, much longer than route B;
(2) passengers unable to use their private cars or walk to Y would not travel to Y if route A exceeded their journey time tolerance even if route B did not (and even if route B was a long, long way beneath it); and
(3) those passengers for whom route A is within their journey time tolerance and who cannot take a private car or walk to Y would use route A, even if this takes, e.g. 10 hours and route B takes only 1 hour; this would lead to unconstrained overcrowding on route A if overcrowding is the cause of the problem in the first place. It would also mean that passengers would always choose route A over route B even if route A has one service every 6 hours and takes 10 minutes but route B has one service every 15 minutes and takes 12 minutes. This would obviously be a perverse outcome.

The large numbers of transferring passengers that can occur in some circumstances are unfortunate, but all alternatives of which anybody has thought so far are even worse.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: jamespetts on May 31, 2020, 05:02:49 PMThe only data that the routing system gives is (1) the total journey time (a mix of travelling and waiting); and (2) the next transfer.
The next transfer, where again a next transfer can be obtained until the destination is reached, which is the whole route, of which overcrowding related waiting times need to be summed up and added to pre-calculated time of that route.

Quote from: jamespetts on May 31, 2020, 05:02:49 PMThe trouble with this is that it leads to anomalies
Which is the price to get rid of a much worse anomaly without introducing some likely extremely complex overhaul of that system.

As pointed out already, waiting times are not meant to be handled differently in any way.
10 minutes journey time + 6 hour frequency results in 3:10
12 minutes journey time + 15 hour frequency results in 0:27

Passengers will not always prefer the first route, in fact they will never even attempt to use it (except for passenger "stealing" if both lines serve the exact same stops)

jamespetts

Quote from: Freahk on May 31, 2020, 05:24:43 PM
The next transfer, where again a next transfer can be obtained until the destination is reached, which is the whole route, of which overcrowding related waiting times need to be summed up and added to pre-calculated time of that route.

This would involve actually extrapolating underlying routing data for every attempted passenger trip, rather than just using a single pre-calculated figure, which would be excessively computationally intensive. Remember, on the last Bridgewater-Brunel saved game, the passenger routing algorithm was by far the most computationally intensive part of the game, so any addition at all to the computational insensitivity of retrieving routes for passengers has the potential very significantly to reduce performance on large and well developed games.

Quote
Which is the price to get rid of a much worse anomaly without introducing some likely extremely complex overhaul of that system.


I do not agree that the current anomaly is worse than the totality of all those that I describe; may I ask how you arrive at that conclusion?

Quote
As pointed out already, waiting times are not meant to be handled differently in any way.
10 minutes journey time + 6 hour frequency results in 3:10
12 minutes journey time + 15 hour frequency results in 0:27

Passengers will not always prefer the first route, in fact they will never even attempt to use it (except for passenger "stealing" if both lines serve the exact same stops)

In which case, I am afraid that I do not understand exactly how your proposed algorithm would actually work.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

QuoteAlthough it is difficult to be sure of what is occurring without a precise reproduction case of the phenomenon from its inception, I believe that it is likely that this is an instance of a known phenomenon that is an unavoidable side-effect of necessary features.
A kind system detects abnormal congestion at the beginning of the moon and informs me of it.  :warning:
It could be seen in many cities before people #stayhome.

Despite being a big city, Pondton is not in contact with the sea, so its residents try to head to the sea.
On the west side, the canal was maintained by the efforts of the player. However, due to the rugged terrain on the east side, this was not possible. And the depression came.  :-|
Coach transport is so poor that hundreds to thousands of passengers every month appear at the bus stops on the edge of the city and teleport between several bus stops.
That's why you can still see it on my Pondton's coach network at all times.
They don't always move forward. Sometimes it retreats from the destination. So it appears to me like it's teleporting the bus station randomly. And they come together and come to act together like a mob.
Even if I send a lot of coaches to that bus stop, they are teleporting to another bus stop next month. That way the passengers mass disturbs my network.
One of the reasons this may happen is that I have a parallel route from Pondton to St. James port. They teleport to the other line and escape when I run a lot of coaches on one line.
There used to be a lot of coaches on those lines, but because of the depression, the number of passengers decreased, so it was streamlined.
Sometimes it's gone for a moment, but it's only moving internally. Immediately rush to another stop.
Once James sees the symptom, I plan to change the origin of those lines to the edge of the pondton.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

jamespetts

The only stop that I can see being crowded in Pondton is South East Gate no. 2 with 317 passengers all heading to St. James Milham Central port.

The "very crowded stop" is disused and not served by any lines. The behaving "like a mob" occurs because passengers from any given point to any given point have only one route, and thus they will all take the same route.

It seems very likely that the cause of the issue reported is that which I described above.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Mariculous

Quote from: Ranran on June 01, 2020, 10:24:11 AMThat way the passengers mass disturbs my network.
That's exactly the reason why I consider this issuue to be much worse than passengers not choosing a generally worse route, that is actually currently better due to congestion.
The first cannot be handled at all by players and will disrupt networks.
The second is a little unfortunate, but can be handled by players and it's roughly the behavior of real-world people before the digital age anyway.

In the digital age, there seems to be an increasing amount of crowding and delay prediction systems, based on live data and guesses, although I do not think this is too relevant to simutrans.

jamespetts

Quote from: Freahk on June 01, 2020, 11:37:48 AM
That's exactly the reason why I consider this issuue to be much worse than passengers not choosing a generally worse route, that is actually currently better due to congestion.
The first cannot be handled at all by players and will disrupt networks.
The second is a little unfortunate, but can be handled by players and it's roughly the behavior of real-world people before the digital age anyway.

In the digital age, there seems to be an increasing amount of crowding and delay prediction systems, based on live data and guesses, although I do not think this is too relevant to simutrans.

I do not think that this is an accurate analysis of the relative merits of the two theoretically possible alternatives. This is because the current situation is transient and occasional, and does not have a significant or long-term effect on what constitutes the optimum strategy for a player. The effects that I described above would have a permanent and serious effect on player strategy and introduce permanent and inexplicable anomalies.

In any event, as already explained, the proposed solution would be excessively computationally intensive.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ranran(retired)

Quote from: jamespetts on June 01, 2020, 10:58:12 AMThe only stop that I can see being crowded in Pondton is South East Gate no. 2 with 317 passengers all heading to St. James Milham Central port
It was down to 900 yesterday, so I guess they were arrested little by little or went home. They may have been wandering around there from before stayhome. In that case mob will converge tomorrow.
I'll wait without doing anything because increasing the convoy on that route will lead to a deficit.
As far as I can see, there is not much flow of passengers in the opposite direction.

However, I think that such a situation will occur again as the age group advances and the lower class uses public transportation.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)