[patch] split the station waiting bar into classes

[Ranran(retired)]

Ranran built a mail network in the western continent on the bridge-water server to deliver the thoughts of ancient lovers. 
But mailing is not a charity. My company has to make a profit. So I need to get more money from a rich man who wants to deliver in a hurry. 

I can see mails higher than the clock tower are piled up at big bases such as ports.   It would be useful to separate this into classes and see how many rich guy's mails there are.
Then I will drive the horse there urgently. Because it is a money tree! 
Of course, this also applies to passengers. Until the latter half of the 20th century, it was common for upper-class humans to hate being in the same room as lower-class humans. So you can get a lot of money instead of fulfilling their wishes. This benefits both parties.


This patch simply divides it into the number of classes. I thought that it would be difficult to understand by individual color coding. Know its class by position. It is a higher class to the right.
This patch will laterally expand the entire bar at the passenger and mail stations. However, IMO it would be much more useful than a lot of unnecessary bars for piece goods.


Note that this image has the bar of the email changed to yellow according to the color change proposal presented in another thread.

It's a small change so I've already made a pull request, but here's the github branch.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/classes-waiting-bar
EDIT:
See new post

[jamespetts]

Thank you for this: this is very interesting. One thing that I wonder is whether there might be some benefit in grouping class based bars in a way that makes it clearer that they are all subdivisions of the same sort of thing, rather than treating a class of passengers in exactly the same way as a category of goods. However, I am not sure whether there is a workable way of doing this or not.

It would be useful to have feedback on this question from others, as well as to have an idea from Ranran as to whether he can think of any way of making this clearer.

I should also be interested to know others' thoughts on this generally.

[Ves]

Hello,

I think this is a really usefull feature, thank you for coming up with it and coding it.
You mentioned that the higher classes are to the right of lower classes, but I think that the expectations from players is that the higher classes is to the left of the lower classes. That would mean that the leftmost bar is the very high class.

From the picture Ranran provide, I must say that I find it quite easy to identify the 5 bars, as it will be a block of the same color. Maybe it could be a display setting to display the individual classes, or display it like it currently is, one bar for passengers and one bar for mail.

[Vladki]

I think that the expectations from players is that the higher classes is to the left of the lower classes.

Same for me. Highest class on left. Otherwise I really like it. Just wonder that the bars are not uniform pink/yellow but also some grey, what is that?  Transfers?

[Mariculous]

About the order, I'd actually expect it to be in

I think that the expectations from players is that the higher classes is to the left of the lower classes.

In which case I am not a player
I'd actually expect it the way Ranran implemented this. I have no idea where that expectation comes from.

[jamespetts]

I am intrigued as to the chiral differences here. I tend to agree that Ranran's ordering would the the most obvious: the normal sequence is low to high, left to right.

[Ranran(retired)]

Certainly, it may be normal for the 1st class to come to the far left. However, I think it is difficult to understand if it is not written with symbols or characters.
I simply incremented in the order recorded, from 0 to max_classes.

EDIT:

Just wonder that the bars are not uniform pink/yellow but also some grey, what is that?  Transfers?

I think it's just the color degradation due to the gif image. The value being transferred is not displayed.
But it is possible to add a display.

EDIT2:
As Acarlotti pointed out before, it should be noted that there are differences between fare class, accommodation class and wealth class.
I used the phrase "1st class" at the beginning of this post but it means fare class.
What the additional split bars represent is a wealth class. In this case, I think that the left side is low and there is no problem.

[Ves]

Well, I guess you are right that this might individual taste. 
Why I would expect it to be the highest to the left is because that is the most important bit of information. The reason Ranran implemented this feature in the first place, he says, is because he wanted specifically to know how many of the higher class passenger and mail was waiting. Having the higher classes on the right, towards the middle of the (potential very long) bar, makes it more difficult to read at a glance which bars is the "high" and "very high" class passenger. However, it would be very easy to read status of the bars for "low" and "very low"...

In which case I am not a player

Did say think

[wlindley]

First-degree burns are the least type, while first-degree murder is the strongest type. 

We could put First Class first (on the left as in Western script) or we could put it at the highest value on a graph (rightmost on a number-line). 

In matters of semantics, we need only be consistent.   Ranran's proposal seems the best, and most consistent, here.  Looks like a good addition.

[Ranran(retired)]

This patch has been sublimated as a derivative patch for GUI overhaul.

The GUI overhaul patch tabs the display setting dialog. I've added an option in that setting to choose whether to split the waiting bar by class.


This should be merged after the r8653 patch. Github brunch is here
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/classes-waiting-bar-v3

Please note that you may have to revise the version number at the end of environment.cc depending on when merge it.
I also think that the added text needs to be proofread.

EDIT: Fix branch URL

[freddyhayward]

I wonder if goods types can be similarly configured? They are currently split but it would also be nice to also view them merged (e.g. coal, iron ore, clay -> bulk goods).

[Ranran(retired)]

The question is what color to set those colors to. The individual goods have a color definition, but the category does not have a color definition. (The current specification is to display a small amount of color when it is 0.)
If it stack them vertically, it will not be able to see the color of the cargo above if it exceed the capacity.
It may be possible if the whole is shortened on a scale...
Theoretically it seems possible.

[freddyhayward]

The question is what color to set those colors to. The individual goods have a color definition, but the category does not have a color definition. (The current specification is to display a small amount of color when it is 0.)
If it stack them vertically, it will not be able to see the color of the cargo above if it exceed the capacity.
It may be possible if the whole is shortened on a scale...
Theoretically it seems possible.

The colours can come from the category icons, then changed wherever conflicts need to be resolved. But even with conflicts, I still think it's cleaner than the status quo.

[Mariculous]

If it stack them vertically, it will not be able to see the color of the cargo above if it exceed the capacity.

Just an idea, instead of truncating bars at stations capacity, could we draw borders around the bars indicating the maximum capacity but let the bars exceed these borders, if the capacity is exceeded?
That would allow us to stack cargoes of the same group without losing information about the cargo types when the capacity is exceeded.
As a useful sideffect, we get an idea of how much the capacity is exceeded.

About category colors, grouping by categories will save some space, so we can use a little more width per category, which will allow us to display the category icon above or underneath the bar. That kind of information is much more intuitive than any coloring.

[Ranran(retired)]

The category symbol may not have it in pakset and there is no alternative here. In other GUIs, it's exists with its text or replaced by its text.

Freddy's idea reminded me of what I felt when I was a simutrans noob.
(´・ω・｀)The bar at the station that handles freight (especially piece goods) is too wide! Change to diet coke!

In network games, each player could play a role, and in the bridge water server, many players were devoted to transporting passengers.
For them, the freight waiting bar is just annoying information. So I added an option to combine it into one. It can be one brown bar. (That color came from the brown pile.)
Of course, Freddy's proposed category bar is also an option. It is almost the same as the display in the current halt detail.
The difference is that, as I said in the previous post, the percentage of goods in the category is scaled according to the height limit.
I also don't understand exactly what it means to pick a color from the category symbol. But it seemed misleading because something else seemed to be waiting a bit. So in the category view there is no bar if you are not waiting for anything.

Demo:



I don't think it's a problem to port it to Standard as display is an option that players can choose without being forced.
I am convinced that this is a very useful option for players as the categories are tied to the type of wagon they require.
But unfortunately the code around here is different from standard, I can't confirm it, and I'm getting lost in the incorporating from standard labyrinth so I wouldn't do that.
Also, it should be able to become a smart guy because similar processing is currently done in 3 parts (options).

The classes bar option is independent of the freight bar option, but standard should remove it.
It would be helpful if someone interested in it could do it.

And I never speak English, so now it's written in google Janglish and I would appreciate it if someone could proofread the newly added text. (´・ω・｀)
It's okay to change the variable name to something that is easier to understand.

[Mariculous]

The category symbol may not have it in pakset and there is no alternative here.

In which case it will simply be missing. That's trotally fine! Incomplete paksets should not constrain the GUI design.

In case of the passenger success stats in the stations, incomplete paksets simply won't show any icons too, and that's fine.
Pakset authors should add such icons to make use of such usability improvements.

If you don't know what exactly I'm talking about, see the attached image. It's a screenshot of that window in pak192.comic, where these icons are yet missing.


In any case, the work done here so far already is a huge improvement, I am just struggling with the coloring. I have really no idea what these colors indicate without reading the detail window.

[freddyhayward]

I did not mean to suggest dynamically taking the colour from the icon. I meant picking a colour by hand - as they currently are - using the icons as inspiration. Where there is no icon, use your imagination!