Skip to main content ↑ ↓
Topic: P****enger routing code? (Read 52751 times) previous topic - next topic

Re: P****enger routing code?

Reply #105 –
Quote from: jamespetts – on
can you tell me a little more about what you mean by route stability and bouncing here?
The optimum might rather be a situation where every ware_t instance would store the (preferred) route, which should only change if the network doesn't allow to finish this route at all. This is not possible (it requires much more space than any of the other ideas), so one important view onto this whole discussion is: can we simulate the static route? (We need something like that to prevent packets from getting stuck in loops.)

One approach is to have a decision algorithm whose result will hardly change over the whole route(!), even if the latter involves huge delays and network changes (which do not invalidate the original route). Using metrics that change very slowly is one way towards this goal, but "change slowly" is only relative to the actual difference of metrics among possible routes, so that difference should be rather large. I doubt that a metric algorithm like this is possible at all.

The suggested flag (any_route) is only a way of giving up, and it may not be able to cover all possible cases.
Recording the number of previous transfers in ware_t would be a better solution (e.g. 4 bits/16 values: allow 14 transfers maximum; 15 means: give up rerouting/don't try to avoid overflowing stops = same as the flag). I am fully aware that extensions of ware_t are extremely unlikely to happen. A comprehensive QoS solution will have more chance to get some data into ware_t.

I also mentioned the automatic deadlock/bouncing detection as a method to (globally) change the behaviour of routing.

Re: P****enger routing code?

Reply #106 –
Some feedback for r2382 with settings
Code: (simuconf.tab) [Select]
seperate_halt_capacities = 1
pay_for_total_distance = 1
avoid_overcrowding = 1
no_routing_over_overcrowded = 1

no_routing_over_overcrowded=1 improves the situation a lot, deadlocks are less likely to occur, and can be dealt with easily when they happen; overflowing stops are reduced by much. There are still some things:
1) the capacity limit is not applied for all goods together, but for goods grouped by type and next transfer stop (this behaviour might be limited to goods being released by a connected factory, routed goods might have other behaviour); it may be useful and intended, but it is still quite generous towards the player.
2) For goods, the input behaviour may now switch between full stop and full flow, depending on the state of transfer stops. When releasing goods, it might be a good idea to check for the remaining input storage capacity of the recipient, and limit the good's amount at the origin stop to that remainder, instead of filling it with as much stuff as possible; the same check could be done for transfer stops, to avoid a fast return of the transfer stop to overflowing state, even worse than before. However, if a vehicle is set to full load at the origin stop, this simple mechanism would be byp****ed, to another throttle method would be needed (e.g. control release rate).
3) certain hubs tend to nearly always stay in overflowing state because of 1) and 2) (together with transport delay); instead of yes/no decisions, randomization could be used, with a routing/acceptance probability depending on the grade of over-utilization. (Any call for a random number generator etc. would have to  happen outside of the routing code.)

Now after setting avoid_overcrowding to 0 (does this still have an effect anyway?): I still get some instances of the behaviour with this parameter set to 1: goods will not be loaded if the next transfer stop (the only possible one) is full, although the goods have already been released by the factory, and the recipient is not overflowing. So, the check seems to happen not only for the release of goods, but for in-transit routing, too.

I think that the code for no_routing_over_overcrowded is on the way to provide sufficient control against overcrowding, therefore the behaviour set by avoid_overcrowding (don't load if next transfer stop is full) is not necessary.

Re: P****enger routing code?

Reply #107 –
avoid_overcrowding will be saved already with a game. Setting it to zero after once saved it will not be resetted.

Re: P****enger routing code?

Reply #108 –
Quote from: prissi – on
avoid_overcrowding will be saved already with a game.
Why would this be necessary, let alone a useful and expectable behaviour?

EDIT: If this is meant for attaching the difficulty level to the savegame, it should still be changeable afterwards. The lowest state of each difficulty setting since start of the map (for use with a "hall of fame") and the current state should be saved (for a custom level, all settings; for a predefined level, only the level itself).

Re: P****enger routing code?

Reply #109 –
From what I understand, all settings affecting the simulation are saved with the save games, and have been for a few months. This is related, I think, to the future plans for network multiplayer gaming.
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.

Re: P****enger routing code?

Reply #110 –
"no_routing_over_overcrowded" don't solve the unrealistic overcrowding problems what jamespetts said.
If 10 p****engers arrived at a station and 9 p****engers left from that station, overcrowded will happen sooner or later.

The reason is not important. It might be a crossing trouble, or a traffic jam, or player slept.
If once this problem happened, player would lost interest to continue to play that game.

So, some kind of safety guard might be required.

[off-topic]
I often hear that some players want to change the values of max_hops, bits_per_month, p****enger_factor, or many kind of costs, and so on after starting the game.
Most of people don't play network game, and they want to play freely as before.

Re: P****enger routing code?

Reply #111 –
There is anGUI planned for this. It is the next thing on my todo list.

Re: P****enger routing code?

Reply #112 –
Quote from: z9999 – on
"no_routing_over_overcrowded" don't solve the unrealistic overcrowding problems what jamespetts said.
This solution isn't perfect, but it's a good feedback mechanism for self-regulation of the network. Overflowing can still happen, but usually not to extreme levels as before. In large networks, the transport delays may cause more extreme behaviour of the "full stop - full go" problem (see above), but in many cases, this may even be cancelled out by the spreading effect with regard to arrival times, also caused by those transport delays.

I already wrote suggestions for fine-tuning. The state of slight over-utilization is actually useful: the player gets to see a message and red spots on the map, and then may check for necessary capacity upgrades and network/routing changes.

Quote
If once this problem happened, player would lost interest to continue to play that game.
I don't see why, because the network keeps working. With blocked generation/release only, deadlocks cannot not happen for p****engers and mail (they are not delayed, but lost to the player). For goods, there are situations where the player has to intervene. The deadlocks that I mentioned are caused by avoid_overcrowding, which cannot be switched off any more for my recent savegames, so they are useless for further testing.

Quote
Most of people don't play network game, and they want to play freely as before.
Yes, please. Even more, as network games are not possible yet. Also, somebody (a game moderator) should be able to change settings even in a network game.

Quote from: prissi – on
There is anGUI planned for this. It is the next thing on my todo list.
OK - a generic list of all parameters would be a good way, so the dialog need not be changed every time a parameter is added or changed.

Re: P****enger routing code?

Reply #113 –
Some more feedback for the use of no_routing_over_overcrowded (here: with existing Pak64 savegames from earlier ST versions):
- the code seems to regulate overflowing stations very well; the stations' capacities have to accommodate the largest convoys that enter them.
- revenue/profit dropped steeply - this can be due to other recent changes in ST, but if no_routing_over_overcrowded is responsible, it means that the effect of overflowing backbones on feeder lines (lowering their utilization) really forces the player to maintain a good QoS, and have enough reserve capacity everywhere. Fast vehicles and high throughput will have real benefit even with the traditional revenue calculation.
- these effects may drastically lower the "exploding profit" symptom that makes the game so easy in later stages of map development.

I hope that I could exclude any influence from pay_for_total_distance and avoid_overcrowding by using older savegames.

Pak designers may have to repond to this change by allowing high-density stations (expensive, high capacity buildings for p****engers, mail and goods will be necessary, ****uming seperate_halt_capacities=1).

Re: P****enger routing code?

Reply #114 –
If zou used a game from 101.xx or later, it would have saved alreadz the change of the pay_for_distance in the savegame.

Re: P****enger routing code?

Reply #115 –
I have tried a savegame (dated 2007) from 99.14(?) in 100.0 and 102.0 (r2391); there is already a strong drop in revenue when continuing with 100.0 (probably due to the different behaviour of generators and the power network), then again some reduction in 102.0 if no_routing_over_overcrowded=1 (if =0, the values are similar to 100.0).

Simutrans has become harder in recent versions.