P****enger routing code?

Topic: P****enger routing code? (Read 52656 times) previous topic - next topic

Re: P****enger routing code?

Reply #35 – January 07, 2009, 10:40:14 am

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

Re: P****enger routing code?

Reply #36 – January 07, 2009, 10:46:40 am

~~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.

Re: P****enger routing code?

Reply #37 – January 07, 2009, 11:03:48 am

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

Re: P****enger routing code?

Reply #38 – January 07, 2009, 07:59:19 pm

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 p****enger or goods thing. Should there be three different capacities in a station or can we cope with the present system as an approximation?

Re: P****enger routing code?

Reply #39 – January 07, 2009, 08:20:12 pm

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

Re: P****enger routing code?

Reply #40 – January 07, 2009, 09:22:32 pm

Quote from: prissi – on January 07, 2009, 08:20:12 pm

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).

Re: P****enger routing code?

Reply #41 – January 08, 2009, 03:23:30 am

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

Re: P****enger routing code?

Reply #42 – January 08, 2009, 04:21:44 am

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.

Re: P****enger routing code?

Reply #43 – January 08, 2009, 10:58:35 am

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

Re: P****enger routing code?

Reply #44 – January 08, 2009, 11:03:18 am

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

Re: P****enger routing code?

Reply #45 – January 08, 2009, 11:37:58 am

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...).

Re: P****enger routing code?

Reply #46 – January 08, 2009, 11:53:42 am

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

Quote from: isidoro – on January 08, 2009, 03:23:30 am

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.

Re: P****enger routing code?

Reply #47 – January 08, 2009, 12:12:02 pm

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 cl****es. In fact all pak64 buildings enable only one cl****, and in pak128 the only combination used is psg+mail, otherwise all cl****es are enabled separately.

Re: P****enger routing code?

Reply #48 – January 08, 2009, 12:20:05 pm

Quote from: VS – on January 08, 2009, 12:12:02 pm

By the way: There are no buildings that enable all three cl****es.

Pak96.comic are.

Re: P****enger routing code?

Reply #49 – January 08, 2009, 12:29:27 pm

Quote from: z9999 – on January 08, 2009, 12:20:05 pm

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.

Re: P****enger routing code?

Reply #50 – January 08, 2009, 12:30:43 pm

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

Re: P****enger routing code?

Reply #51 – January 21, 2009, 09:30:21 pm

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.

Re: P****enger routing code?

Reply #52 – March 06, 2009, 01:12:22 pm

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)

Re: P****enger routing code?

Reply #53 – March 06, 2009, 05:58:00 pm

Interesting point about the deadlocks. I believe that Isidoro's original patch discarded p****engers (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 p****engers).

Re: P****enger routing code?

Reply #54 – March 06, 2009, 09:08:06 pm

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.)

Re: P****enger routing code?

Reply #55 – March 06, 2009, 11:52:55 pm

Perhaps a better way of addressing the whole overcrowded stop issue is for p****engers, 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?

Re: P****enger routing code?

Reply #56 – March 07, 2009, 10:33:06 am

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.

Re: P****enger routing code?

Reply #57 – March 07, 2009, 11:08:33 am

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?

Re: P****enger routing code?

Reply #58 – March 07, 2009, 07:19:42 pm

Quote from: prissi – on March 06, 2009, 09:08:06 pm

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.

Quote

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 p****engers/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.

Re: P****enger routing code?

Reply #59 – March 07, 2009, 08:38:37 pm

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.

Re: P****enger routing code?

Reply #60 – March 07, 2009, 08:49:05 pm

Quote from: jamespetts – on March 07, 2009, 08:38:37 pm

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

Yes, that was part of the idea.

Quote

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:

Quote

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.

Re: P****enger routing code?

Reply #61 – March 07, 2009, 08:49:35 pm

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 ....

Re: P****enger routing code?

Reply #62 – March 07, 2009, 08:56:46 pm

Quote from: Dwachs – on March 07, 2009, 08:49:35 pm

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.

Quote

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.

Re: P****enger routing code?

Reply #63 – March 07, 2009, 08:57:35 pm

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?

Re: P****enger routing code?

Reply #64 – March 07, 2009, 09:10:11 pm

Quote from: jamespetts – on March 07, 2009, 08:57:35 pm

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).

Quote

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.

Re: P****enger routing code?

Reply #65 – March 07, 2009, 09:17:07 pm

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

Re: P****enger routing code?

Reply #66 – March 07, 2009, 09:31:57 pm

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.

Re: P****enger routing code?

Reply #67 – March 07, 2009, 09:37:24 pm

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/p****engers 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.

Re: P****enger routing code?

Reply #68 – March 07, 2009, 10:15:55 pm

Quote from: jamespetts – on March 07, 2009, 09:17:07 pm

Hmm, one cannot ****ume 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.

Quote from: prissi – on March 07, 2009, 09:31:57 pm

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 p****engers 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).

Re: P****enger routing code?

Reply #69 – March 07, 2009, 10:25:05 pm

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 ...