Skip to main content
Topic: ideas for p****engers cl****ification (Read 14859 times) previous topic - next topic

ideas for p****engers cl****ification

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

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

Re: ideas for p****engers cl****ification

Reply #1
I don't know what you mean exactly, but I would say that the second picture is indeed unplayable...
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Re: ideas for p****engers cl****ification

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

Quote
via %s\n
 via %s



Re: ideas for p****engers cl****ification

Reply #5
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)
  
***** PAK128 Dev Team - semi-retired*****

Re: ideas for p****engers cl****ification

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

Re: ideas for p****engers cl****ification

Reply #7
1) the problem illustrated in attached picture. P****engers 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.

Quote
2) in big maps, p****engers should be ranged depending (and showing) the line they will take and not their destination.
In Simutrans, p****engers 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.

Quote
(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?

Re: ideas for p****engers cl****ification

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

Re: ideas for p****engers cl****ification

Reply #9
(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.  ;)
  
***** PAK128 Dev Team - semi-retired*****

Re: ideas for p****engers cl****ification

Reply #10
Quote
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 p****engers to Paris Gare de Lyon
_ 456 p****engers to Paris Haussman St-Lazare
_ 789 p****engers to Paris Gare du Nord


it couls show :
_ 1368 p****engers to Paris

Re: ideas for p****engers cl****ification

Reply #11
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.

Re: ideas for p****engers cl****ification

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

Re: ideas for p****engers cl****ification

Reply #13
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.

Re: ideas for p****engers cl****ification

Reply #14
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 p****engers 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?)

Re: ideas for p****engers cl****ification

Reply #15
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.

Re: ideas for p****engers cl****ification

Reply #16
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 p****engers are counted twice.

Re: ideas for p****engers cl****ification

Reply #17
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.

Re: ideas for p****engers cl****ification

Reply #18
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 p****engers for the desired transfer stop)

Re: ideas for p****engers cl****ification

Reply #19
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.)

Re: ideas for p****engers cl****ification

Reply #20
(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 p****engers/etc. that are eligible for a certain line.

Quote
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 ****umptions, so yes, it may be more work than I expect(ed).

Quote
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 "p****engers waiting for line X").

Re: ideas for p****engers cl****ification

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

 

Re: ideas for p****engers cl****ification

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

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

Re: ideas for p****engers cl****ification

Reply #23
I think p****engers 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 p****engers choosed a line earlier (even whit longer trip), the bus will depart empty. P****engers can get on bus, but how they know its a better choice?

Re: ideas for p****engers cl****ification

Reply #24
I think p****engers 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.


Re: ideas for p****engers cl****ification

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

Re: ideas for p****engers cl****ification

Reply #27
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 p****engers choose private cars over the player's transport: that is partly influenced by the number of unhappy people at the origin stop.
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.