Topic: Passenger routing code?

[prissi]

The question is, if the sum should used instead?
Or that the capacity should be counted for the three categroies, i.e. passenger capacity, mail capacity and freight capacity?

[z9999]

No, using sum of each goods categories, - piece goods, bulk goods, etc.

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

[jamespetts]

It would make more sense to me for capacity to be counted per category - after all, passengers are not going to be dissuaded from using a station if its post office is overflowing with mail!

[isidoro]

You're right in my opinion.  The patch is a first approximation.  The only problem I see is that when you add a new platform or a new hotel, the capacity of the station is increased by a quantity.  It doesn't make a difference in present code whether you add passenger or goods thing.  Should there be three different capacities in a station or can we cope with the present system as an approximation?

[prissi]

I would like to have three different capacities for a station. At least for "Adavnced play".

[whoami]

I would like to have three different capacities for a station. At least for "Adavnced play".

Sounds good. On top of that, the different extension buildings could then dedicate their capacity to one area (needs to be displayed in tooltip).

[isidoro]

That would also change pak specification, wouldn't it?

[whoami]

As always, downwards compatibility would be achieved by keeping the traditional behaviour as the default.

Or use the existing parameters differently: the capacity of a station building would be distributed among the types that it also enables, and maybe split the capacity into three parts for those that don't enable any type.

[prissi]

I thaught like whoami: If a station enables post and freight, its capacity goes into those categories.

[Fabio]

even better, each station or addition should add x to passenger capacity, y to mail capacity and z to freight capacity, as specified in its dat (or, maybe, x level * const to passenger, y level * const to mail, etc...)

[jamespetts]

If this suggestion was implemented, certainly, there would have to be a new version of the .dat files allowing the pakset authors to specify themselves how much is added to each capacity. The GUI should also be changed to show in the toolstrip for the station extensions how much capacity is added to each category by each building (indeed, capacity is not shown in the toolstrip at all at present, which makes buying stations a rather hit and miss affair...).

[z9999]

Three type capacities is also good for "normal mode".

That would also change pak specification, wouldn't it?

I think current one is enough. It is simple enough and easy to understand for players
.
Only the problems are ...
Some stations like airstop have no P/M/G type.
It needs new cost/maintenance cost calculations according to sum of levels.

[VS]

Whoami's approach seems both intuitive and simple. Waiting hall does not usually increase capacity for coal, while on a plain concrete slab platform can stand people - or lie heaps of coal.

This also fits nicely the current usage: nothing-enabling pieces have low capacity anyway.

By the way: There are no buildings that enable all three classes. In fact all pak64 buildings enable only one class, and in pak128 the only combination used is psg+mail, otherwise all classes are enabled separately.

[z9999]

By the way: There are no buildings that enable all three classes.

Pak96.comic are. 

[sojo]

Pak96.comic are. 

That's true. In pak96.comic we have some goods at town. For example    vegetables and flour. This will delivered by a small truck. Nowhere will build a truck-stop for a short stopping truck.

I think a stop at an end user (factory) can accecpt all. Than the car supplies the factory not the stop.

[VS]

Well, in a comic land, everything is possible...

[ij]

This cargo stuff will open a possibility of a new kind of deadlock... If a transfer station gets full from input, the later-in-the-chain goods cannot (re)-enter there (if that would be necessary because of such routing layout) and eventually everything gets filled up in that cargo-loop and stops, which again might cause more deadlock since some trains can never leave a station.

It would be nice to have per station value to configure how large share of the cargo capacity a particular type of goods can take instead of 100% that gets now used.

[whoami]

It seems that one implementation went into the trunk (tested: r2368):

Code: ("simutrans/config/simuconf.tab") [Select]

# things to overcrowded destinations won't loaf if active (default off)
avoid_overcrowding = 0
I used an older, well-developed savegame with avoid_overcrowding=1 (also seperate_halt_capacities=1, discussed in this same topic), and found the change to work (detail: people who want to go exactly to the overcrowded station, seem to travel even in that case), but the overall result is rather unsatisfactory (in my opinion).

For example, I looked at two major backbone nodes, both a little(!) overcrowded: most of the time, nearly empty trains run between the two, because the people from the first node won't travel to the second, as it is already too full, and vice versa. This is a kind of deadlock, which in itself might eventually become resolved over a longer time. However, the leaf nodes of the network keep filling up with people waiting for the upper nodes to clear, so whenever those leave overcrowded state, they will return to it immediately, and the deadlock continues after a short interruption.

(One alternative suggestion in this topic had been to not route across full nodes, so alternative routes would first be used, and after that fails, people would decline to travel over the player's network at all.)

(edit: removed claim that this was my idea)

[jamespetts]

Interesting point about the deadlocks. I believe that Isidoro's original patch discarded passengers (and marked them as "no route") if the transfer stop was overcrowded. Perhaps this latest version should be modified to do the same thing?

(Incidentally, this version does have one major advantage over Isidoro's original, in that it respects the separate capacities of the station, so, if the station is overflowing with mail, for instance, it will not affect passengers).

[prissi]

No isidoros patch did not load and discarded them, if they were already loaded. However, the next version will get a difficulty settings were every users can do what they like. I run into the same problem between a harbour and a hub, sunce the harbour was immediately filled when a ship arrived.

(That people, who wants to go to an overcrowded stop still go there is intended: The do not care if the have no waiting space left.)

[jamespetts]

Perhaps a better way of addressing the whole overcrowded stop issue is for passengers, etc., to abandon the journey (and report as "unhappy" in the graph) if they have had to wait more than a certain amount of time at a station?

[z9999]

Discarding like the first patch is a bad idea. We will get many problem reports, like as we got for the new revenue system in v101.0.
At least people ride on a vehicle, they must pay.
We want to enjoy the process of the game, not the result of the game.

deadlock ? It's good, because people desired this kind of puzzled game, didn't they ? 

I want to enjoy to transport them instead of not to transport them.

[jamespetts]

Z9999,

I am having difficulty understanding your comment: why would there be more problem reports for a discarding system than an insoluble deadlock system? People must indeed pay for the part of the journey that they do take (and can pay just before they are discarded for their journey so far), but there is no reason why they should pay for the journey that they were planning to take but cannot because the station is too full?

I also have difficulty understanding your point about enjoyment: why would creating an insoluble deadlock make the game more enjoyable?

[whoami]

However, the next version will get a difficulty settings were every users can do what they like.

The current state (haven't checked the latest nightly, though) leads to situations where adding transport capacity cannot help, and adding storage capacity may only help to some extent, and there is a runaway effect in both directions (good and bad), so it is unstable by design.

I run into the same problem between a harbour and a hub, sunce the harbour was immediately filled when a ship arrived.

That's slightly different from the problem that I described: the stations should be large enough to handle the largest vehicle that uses them.

Regarding the alternatives:
Discarding is not so bad with passengers/mail (just let's say that these take different means of transport, like a taxi), but with goods, it may be very bad: the station may be full of cheap, useless stuff, but the arriving goods may be expensive, rare ones urgently needed for a complete production/transport chain.

To me, the approach of changing the routing to neglect overflowing stations appears more and more like the best way: it even allows for load-balancing between different connections and players.

[jamespetts]

Whoami,

changing the route will only help if there is an alternative route available; but, even then, that is likely significantly to increase computational cost. If there is no alternative route available, the deadlocks will persist.

[whoami]

changing the route will only help if there is an alternative route available;

Yes, that was part of the idea.

but, even then, that is likely significantly to increase computational cost.

That may be true, especially if there are alternative routes. However, if you have a strictly hierarchical network, it can even decrease CPU consumption, as the routing often gives up early.

But let me clarify what I meant:

If there is no alternative route available, the deadlocks will persist.

How? This was meant as a replacement to the current behaviour (which I consider broken), not as an addition. People+mail which cannot find a route over other stations should be put into unhappy, and refuse to enter my network (see first page of this topic). In case of goods, they wouldn't be put at my station, but remain at the output storage of the producer.

[Dwachs]

And if there is an alternative route present it could happen that people never reach their goal:

Code: [Select]

A --> B --> C -->D
         \              \
          E--->F --> G

At B people realize C is overcrowded, now they travel to E. But meanwhile F gets overcrowded and the situation at C has relaxed. People go back to B ....

[whoami]

And if there is an alternative route present it could happen that people never reach their goal:

That is because the number of vehicle switches isn't recorded in the goods packet.

At B people realize C is overcrowded, now they travel to E. But meanwhile F gets overcrowded and the situation at C has relaxed. People go back to B ....

True, there can be some bouncing also with this method. But I hope that the limited transport capacity stabilizes the situation.

[jamespetts]

Whoami,

ahh, I didn't realise that it was supposed to be a replacement. In that case, it makes more sense. What did you mean by a hierarchical network, though?

Dwachs,

presumably, that would only be a problem if the routing code did not check to see whether the alternative route could get the packets to their destinations?

[whoami]

What did you mean by a hierarchical network, though?

It means that the whole network is a tree, or at least has loops only on the highest level (and all stations on this level need to have direct connections between each other).

presumably, that would only be a problem if the routing code did not check to see whether the alternative route could get the packets to their destinations?

Another problem is that we can't store the preferred route into a goods packet, and it may change dynamically at any transfer station. Refusal to route across overflowing stations should indeed happen only at the origin station. But what happens later? The packets should be delivered, even if all nodes in between are overflowing. Here, the least overflowing node should be chosen (EDIT:) or use a routing malus, derived from the ratio occupied/capacity (I am sure that I have written about this before). If the overflowing status would be neglected completely during dynamic routing, the alternative routes would become useless.

[jamespetts]

Hmm, one cannot assume that players will always design their network in a particular way.

[prissi]

I think this problem affects only existing games; for new games plannign can be done in such way to avoid this deadlock. It is then up to the user, for instance to extend the stations capacity.

[jamespetts]

In my view, there should be no possibility of deadlocks of this nature at all - it is highly unrealistic, counter-intuitive, and likely to be extremely confusing and frustrating for players if they ever encounter it. What to do to solve it is not in the least obvious, since the behaviour of the goods/passengers in the game is not similar to the way in which they would behave in reality. That people have to plan to avoid these deadlocks is part of the problem, not the solution.

[whoami]

Hmm, one cannot assume that players will always design their network in a particular way.

Yes, but if you see it the other way round: by choosing the network design (and perhaps a simuconf.tab parameter), the player has the choice over this, too. The use of alternative routes (to avoid an overflowing station) is an addition inside that approach, it can also be omitted, but the players would prefer to have it, I think. Currently, the chosen route is rather random from the player's view if the transfer count is the same for several routes, (edit:) so hierarchical networks are already useful.

I think this problem affects only existing games; for new games plannign can be done in such way to avoid this deadlock. It is then up to the user, for instance to extend the stations capacity.

(My view:) The network would have to always provide a lot of excess capacity in both vehicles and stations, to make sure that the problem will never arise, because it is a self-increasing one. My savegame initially had only one overflowing (edit:) backbone station (the big central node), but the effect spread over the whole network due to what I already called "runaway effect". Once the situation is there, adding vehicles even in large numbers may not help (because passengers still refuse to enter them), even though a shortage in that regard caused the problem. Sure, the effect will not happen when starting a game, but complex games could suffer. Regarding station upgrades: especially in cities, space is limited.
So, if these concerns are true, I can only share jamespetts's opinion (previous post).

[prissi]

Then I would just not enable this option. It is off by default for a reason. See it as "very hard" difficulty setting.

The only other way out would exclude those stations from routing and leave everything as it is. Not difficult, but requires extra code in the mode time critical routine we have ...