ideas for passengers classification

[gauthier]

1) the problem illustrated in attached picture. Passengers should be ranged down each other instead of next to each other, it makes huge long windows, it's unplayable !

2) in big maps, passengers should be ranged depending (and showing) the line they will take and not their destination.

[Combuijs]

I don't know what you mean exactly, but I would say that the second picture is indeed unplayable...

[z9999]

I think the picture is Francais translation problem.
"\n" is missing.

via %s\n
via %s

[gauthier]

ok ... Could someone fix that in Simutranslator ? I haven't acount on it.

[gauthier]

I don't want to be a pain but ... Could someone who have an account on Simutranslator fix the problem ?

[DirrrtyDirk]

Just an account isn't enough - it's got to be an account for French translations - or an Admin.

But I thought that simutranslator adds the necessary line breaks on its own? Maybe Frank has to have a look at this...

(and maybe some Mod or Admin could move this thread from extension requests to a more fitting place? Bug reports or translator would be my guess)

[prissi]

I added already a line break. Not sure, if translator ate it afterwards, though

[whoami]

1) the problem illustrated in attached picture. Passengers should be ranged down each other instead of next to each other, it makes huge long windows, it's unplayable !

Dynamic formatting of variable-length strings is on the wishlist (well, at least my wishlist). The function has been implemented for building descriptions. See http://archive.forum.simutrans.com/topic/04465.0/index.html.

2) in big maps, passengers should be ranged depending (and showing) the line they will take and not their destination.

In Simutrans, passengers etc. don't wait for a line (unlike e.g. Verkehrsgigant, where this may be due to different comfort and reliability ratings of lines), but for any vehicle that will go to the desired stop (discussed earlier, I just cannot find this in the forum archive).

You are right however, if there are few lines for a certain connection, and many lines on the whole map, a function like that would help the user a lot. Important questions are:
- resources needed to gather that information, and keep it current
- implementation effort, including future maintenance

But I thought that simutranslator adds the necessary line breaks on its own?

The translator cannot know where linefeeds are useful, not even at the end of a string. It handles only the replacement of \n.

(and maybe some Mod or Admin could move this thread from extension requests to a more fitting place? Bug reports or translator would be my guess)

(Problem with two small issues in one post.) If the formatting of the single french translation is OK now, the topic should rather stay here for the second part (topic needs to be renamed anyway). Maybe one of the patchers wants to give that a try?

[prissi]

As with lines: The are maybe different lines to the same destination or even ppeople play without lines => sorting with lines is not possible.

[DirrrtyDirk]

(Problem with two small issues in one post.) If the formatting of the single french translation is OK now, the topic should rather stay here for the second part (topic needs to be renamed anyway). Maybe one of the patchers wants to give that a try?

Ok, then first split the topic (should have been one request per thread anyway) and then move it. 

[gauthier]

As with lines: The are maybe different lines to the same destination or even ppeople play without lines => sorting with lines is not possible.

:'(

Is just possible to group same city destination ?

exemple : instead of this :
_ 123 passengers to Paris Gare de Lyon
_ 456 passengers to Paris Haussman St-Lazare
_ 789 passengers to Paris Gare du Nord

it couls show :
_ 1368 passengers to Paris

[vilvoh]

That's sorting by destination, isn't it?  I mean, I think it's already possible. I don't remember if the game considers the stop or the city as criteria when sorting by destination. That would be the point.

[prissi]

No, this is not possible either (and also not useful) since those passengers to Paris might go via very different routes to those stations. The revers lookup (from koordinates to town) is also very slow gamewise.

[gerw]

The revers lookup (from koordinates to town) is also very slow gamewise.

We could add a pointer to a town to each stop. This musn't be updated very often.

[prissi]

Yes, but this will not help for factories. And the problem with not using lines or different routes to different Stations will be still the same. I mean with via amout already all passengers going together are display merged. This extension request woud just add a to xyz to this line. (As a result there would be again more entries, and that was probably not what was intended by that?)

[whoami]

As with lines: The are maybe different lines to the same destination or even ppeople play without lines => sorting with lines is not possible.

It's true that an aggregation by line isn't possible, but for aggregation by transfer stop, matching lines could be given as a list.
However, that information needs data from all line schedules that touch both stops, and collecting that may take a lot of resources.

Let's see: connected lines are already listed in the stop details, so the lines could simply be derived from that data (common entries in both lists should be sufficient, unless asymmetric routing, 'no load' or other unusual circumstances applied). The connection information needs to be displayed only for open stop windows, and updated only when new goods packets arrive (not merged with existing ones), or when schedules/goods routing are refreshed.

[prissi]

Well, the request was for a more compact display.

How would you want to display? If there is more than one line to a destination, sorting by line name is pretty impossible or the list would get very long, and passengers are counted twice.

[gerw]

I'm also pleased with the current system. It is very difficult to present the waiting goods in such a way, that all people are happy and which fits to all circumstances.

[whoami]

Well, the request was for a more compact display.

The purpose behind it was probably (for my approach, it is) to get information about which lines don't provide enough capacity, if too many people are waiting at the stop. Getting this information out of the viewable data becomes rather difficult with large networks.

Additional ideas for my approach:
- the information could be made available on request (clicking on an aggregation item, or a button)
- the number of in-between stops could be shown, and the lines could be sorted by that number (lines with more stops in between tend to not load many passengers for the desired transfer stop)

[prissi]

Both informations are not there and need expensive reverse lookup. This is a lot of work; even more, since the goods are change very often. (Caching is already done, of course.)

[whoami]

(Removing dust from this topic...)

I just want to make sure if I was understood correctly.

Both informations are not there and need expensive reverse lookup.

My idea was not to go through all the schedules and look at common stops, but to use the existing code that collects the connected lines for a given stop (see stop details window), filter these by goods category (is that information stored/cached at line level?), then sort the list for fast comparation to another list of that kind (also sorted), in order to retrieve the entries that exist in both.

Additionally, if this information was collected for all aggregation items, we could get the number of passengers/etc. that are eligible for a certain line.

This is a lot of work;

Now that I went more into detail, it becomes apparent that my approach still relies on quite a few assumptions, so yes, it may be more work than I expect(ed).

even more, since the goods are change very often. (Caching is already done, of course.)

For that, I thought about collecting the information only on request (by clicking on the aggregation item, same for getting "passengers waiting for line X").

[prissi]

The problem for convois without lines and multiple connections still remains, though.

[gauthier]

For multiple lines, the game could show at each line :
_ in black the normal line : goods or passengers taking ONLY this line and no other
_ in yellow (for example) the multiple lines : each line if the food or passenger is shown in yellow, it can take an other line.

I think passengers and goods could plan to take only one line : the fastest to the destination.

[Sarrus]

I think passengers and goods could plan to take only one line : the fastest to the destination.

I thing this is good idea. But what about vehicles without line? If passengers choosed a line earlier (even whit longer trip), the bus will depart empty. Passengers can get on bus, but how they know its a better choice?

[whoami]

I think passengers and goods could plan to take only one line : the fastest to the destination.

That won't work well, unless timetables are introduced (which the player then has to actually fulfill), or another way of being able to tell when the next convoy of a certain line (and goods category) will arrive.

[gauthier]

 



It could be calculated with the frequency of trains on a line, their speed, their power.

...

Maybe better idea : first : take the shortest, second : if the shortest is overcrowded, take an other path, it seems to be useful in my savegames :p

[whoami]

There is some development effort going on regarding QoS (=quality of service - this can also include comfort rating, derived from cab class/level, age, utilization), maybe something is already present in ST-experimental.
Similar: rating of different routes.

[jamespetts]

Some element of quality of service rating is planned for Simutrans-Experimental, but not implemented yet. The only thing akin to it that currently exists is the system in which passengers choose private cars over the player's transport: that is partly influenced by the number of unhappy people at the origin stop.