Improvement of the station detail dialog

[Ranran(retired)]

Ranran tried to reform the Station detail window. This is one of the "More graphical symbols! Project" that Ranran is promoting.
However, because of my immaturity, it was not completed. (´・ω・｀)Sigh, really sigh. はあまじはあ
I hope somebody can help this.   

I tried to separate the information into three tabs so that the player could check the information in more detail.
Added class information and added graphical symbols and made the window slim to make it easy to understand the information. I also added information that seems useful.
The new window is a graphical dialog, not a notepad style dialog.
It will help the player by organizing the information.

But I could not make the button work. It does not respond to clicks. (´・ω・｀)

I tried some methods with reference to the code of other windows, but it did not solve after all.
So now this is just like a design proposal. Currently I have placed a dummy button.


You can check the mock-up. This is from the demo.sve of Britain-Ex. 

Tab1:


Tab2:


Tab3:



The waiting bar fluctuates in real time like this.



The github branch is here.
You can test this ruined dialog.
As I interrupted my work, I did not adjust the details. There may still be meaningless variables for placing the button.
You need new symbol.pak for the new GUI. A stopwatch, a time schedule, an hourglass and a walking symbol have been added. You can download it from this post.
These symbols are intended to be used with the help text clearly indicating that the unit is minutes. It will reduce unnecessary text and save space.

Issues are in halt_detail.cc and halt_detail.h.
Maybe there is a mistake with my configuration. 
It may take some time to check this in detail and correct mistakes. So I think it might be easier for me to make a framework and rearrange parts based on that.
I do not know which solution is good, but I would like to thank you very much for your help.

This is not expected to be completed at the moment, so the explanation is omitted. (However, I think that the design is easy to understand without explanation.)
It may be useful as a design proposal.
The connection display for each class is not a finished design but a temporary display for confirmation. I interrupted my work, but I thought that it was better to display at the leftmost and use color coding and symbols.

[jamespetts]

Thank you for your work on this: this does look good. Sorry that you are having trouble.

May I ask to which button that you are referring that is not working?

[Ranran(retired)]

May I ask to which button that you are referring that is not working?

All buttons:
- Line schedule open button
- to move to the station location button
- to move to the factory location button

It was not possible to display the button with the previous code after separating the tabs, so I arranged the button by imitating code such as factory list dialog, but I could not make it work.
So I think my approach is wrong. I do not know the correct passing method of the button from tabs.

[Matthew]

Ranran, this looks great!  Thank you for your efforts.

Although you may feel frustrated that it is not quite finished  sharing your incomplete code with the community is a helpful way forward.

[jamespetts]

I believe that Ranran has done so at the link to the Github branch here.

I have not had a chance to look over the code at this stage, and doing so would take some considerable time, as I am not very familiar with the GUI code, since I have tended to make only minimal changes to the GUI. From what I understand, the problem is that the little black on white arrow buttons are not working. Am I right in understanding that you have changed the dialogue type? There may be an issue as to the compatibility of this type of button with this type of dialogue in the not entirely well organised Simutrans GUI code. Alternatively, there may be an issue as to how the dialogue detects that there has been a press of this button.

I do not know how much that you have had a chance to look into this, but what I suggest that you do next is analyse in more detail how these buttons work when they do work (if you have not done this already), and use a debugger to follow the execution path of the code when a player clicks on one of these buttons (the "action_triggered" method is usually important in this context, so you will need to see whether the code gets this far with your buttons or not). You should then be able to analyse at what stage of this process that this fails in the case of the buttons that you have added. This is the process that I should have to go through if I were to assist with this, since, as written above, I am really not very familiar with the GUI code in any depth.

I hope that this is of at least some help.

[Ves]

Wow, this is simply amazing!!  This is how a proper detailed window should look like IMO!

I tried to compile the code, but it fails with a bunch of errors in the halt_detail.cc. Alot of the errors looks like some functions have been modified to take more calls than original, and it also looks like you have added some new parameters to haltestelle_t, but forgot to commit all those changes.

Code Select Expand


'get_transferring_goods_sum_by_class': is not a member of 'haltestelle_t'
'get_ware_summe_by_class': is not a member of 'haltestelle_t'
'haltestelle_t::get_connexions: function does not take 3 arguments'
etc...


As to the problem with the buttons, I solved a similar case in the "vehicle_class_manager.cc" and "line_class_manager.cc". It is another approach than in the industry supplier list, but it seems to work as it should and no one have pointed it out yet. Those windows (especially the vehicle_class_manager) are initially created by duplicating the "convoy_detail.cc" and altering everything to become the window it is now.
In that window, instead of buttons, it is comboboxes, but the principle should be the same.

I have some suggestions! 

Tab1:
In the summary, instead of "242/ 130" make it "242 (max: 130)"

Tab2:
In the second section, it looks very "busy" when the different good category color squares are not aligned vertically. Either you could start by meassuring which factory entry would be the longest, and them put them all so no one would interfere with the entry, alternatively you could put the color squares before the name

Tab3:
A) In the upper section, I have always missed sorting by waytype in this section, with proper icons. It could be something like:

[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3

[Train icon]
Train line 1
Train line 2

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically. You could consider having the distance before the name, since that is something that probably would never change. Additionally, the entries could sort by distance in each category as well instead of the current kind of random order.


But I do really think the window looks really amazing already, thank you for coding it!!

[ACarlotti]

Code Select Expand


'haltestelle_t::get_connexions: function does not take 3 arguments'


That will be a merge conflict with my recent changes - get_connexions previously needed to be passed 'max_classes' as a consequence of it exposing implementation details directly. It looks like it has been present throughout several of Ranran's commits.

Ranran: Did you actually try building that code? In general, you should always check that your code builds before commiting (or if you forget, then you can do it immediately afterwards and amend your commit if you made a mistake). This includes merge commits - in this case the merge might appear to run cleanly because the conflicting changes are in different parts of the code base.
(If you did successfully build and run the code, then I'm confused about how it managed to run.)

Tab2:
In the second section, it looks very "busy" when the different good category color squares are not aligned vertically. Either you could start by meassuring which factory entry would be the longest, and them put them all so no one would interfere with the entry, alternatively you could put the color squares before the name

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically.

This alignment stuff might be made easier when the recent gui changes in Standard make it into Extended.

[Ranran(retired)]

Thank you for your feedback. 

I tried to compile the code, but it fails with a bunch of errors in the halt_detail.cc. Alot of the errors looks like some functions have been modified to take more calls than original, and it also looks like you have added some new parameters to haltestelle_t, but forgot to commit all those changes.

Oh, I'm sorry. Unfortunately for some reason the upload failed and it seems that I have accidentally overwritten the file and lost what I changed. (´・ω・｀)
I rewrote the lost function but I do not know whether it was the same before. And I also changed the transferring bar. Now you can test it. The problem with the button has not been solved yet.

Tab1:
In the summary, instead of "242/ 130" make it "242 (max: 130)"

I wonder if "max" is correct as it can be crowded beyond this number.

Tab3:
A) In the upper section, I have always missed sorting by waytype in this section, with proper icons. It could be something like:

[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3

[Train icon]
Train line 1
Train line 2

I originally planned to put the icon on the left edge, but I canceled it because the icon size was large. Since grouping seems wise, I implemented it. However, I am hesitant about how to handle lineless convoy.

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically. You could consider having the distance before the name, since that is something that probably would never change.

This issue is somewhat complicated. The names of routes, stations, and convoys have a large difference between long and short ones. If the margins are large, blank spaces will be noticeable and the width of the window will be wide.
And the big issue is the language difference. Japanese and Chinese tend to have a small number of characters, which can create very wasteful margins. It is the most difficult problem in the layout of the table. Symbolize can reduce this difference.
As ACarlotti mentioned, I think that it will be solved easily if html table like GUI is imported from standard and a fluid table can be made.

Additionally, the entries could sort by distance in each category as well instead of the current kind of random order.

I think this is the order of registration. I wanted to sort it by distance, but I do not know how to sort this.

[Ves]

Thank you for your feedback. 
Oh, I'm sorry. Unfortunately for some reason the upload failed and it seems that I have accidentally overwritten the file and lost what I changed. (´・ω・｀)
I rewrote the lost function but I do not know whether it was the same before. And I also changed the transferring bar. Now you can test it. The problem with the button has not been solved yet.

Thanks it works now!

I wonder if "max" is correct as it can be crowded beyond this number.

Other places it states that the capacity of a station is this and this, for instance in the station window and also in the icon tooltips. IMO, "max" in this sense is just a synonym for "maximum capacity", but I am not english speaker so I might be wrong. In any way, spelling it out I think looks better.

I originally planned to put the icon on the left edge, but I canceled it because the icon size was large. Since grouping seems wise, I implemented it. However, I am hesitant about how to handle lineless convoy.

THANK YOU!
I tend never to use lineless convoys, and on the bridgewater brunel game, I have only seen the odd lineless convoy. One way to do it could be to add within each waytype section textline "lineless convoys:" and then list the convoys benieth.

Something like:
[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3

(Lineless convoys:)
Airplane 1
Airplane 2

[Train icon]
Train line 1
Train line 2
Train line 3

(Lineless convoys:)
Train 1
Train 2

I dont know if it would look better to have it not in brackets or in brackets as in my example. I think I would prefer having them sorted by the waytype instead of having them separate below all the line lists.

I think this is the order of registration. I wanted to sort it by distance, but I do not know how to sort this.

I tried to do it, but I failed due to my lack of knowledge of handling "static" things in the code.
What I did was that I put all halts for the given good categories in a vector_tpl. Then I sent it via the std::sort function to be sorted in a "compare_halt" which I also created.
The "compare_halt" looks like this:

Code Select Expand


bool halt_detail_line_t::compare_halt(halthandle_t halt1, halthandle_t halt2)
{
sint32 result = 0;
const uint32 tiles_to_halt1 = shortest_distance(halt->get_next_pos(halt1->get_basis_pos()), halt1->get_next_pos(halt->get_basis_pos()));
const uint32 tiles_to_halt2 = shortest_distance(halt->get_next_pos(halt2->get_basis_pos()), halt2->get_next_pos(halt->get_basis_pos()));
if (tiles_to_halt1 != tiles_to_halt2) // Distances are different, sort by distance
{
result = tiles_to_halt2 - tiles_to_halt1;
}
else // Distances are same, sort by name
{
result = strcmp(translator::translate(halt1->get_name()), translator::translate(halt2->get_name()));
}
return result < 0;
}

but the "halt" values gets a red underscore with the error:
"a nonstatic member reference must be relative to a specific object"

[ACarlotti]

I tried to do it, but I failed due to my lack of knowledge of handling "static" things in the code.
What I did was that I put all halts for the given good categories in a vector_tpl. Then I sent it via the std::sort function to be sorted in a "compare_halt" which I also created.
The "compare_halt" looks like this:

Code Select Expand


bool halt_detail_line_t::compare_halt(halthandle_t halt1, halthandle_t halt2)
{
sint32 result = 0;
const uint32 tiles_to_halt1 = shortest_distance(halt->get_next_pos(halt1->get_basis_pos()), halt1->get_next_pos(halt->get_basis_pos()));
const uint32 tiles_to_halt2 = shortest_distance(halt->get_next_pos(halt2->get_basis_pos()), halt2->get_next_pos(halt->get_basis_pos()));
if (tiles_to_halt1 != tiles_to_halt2) // Distances are different, sort by distance
{
result = tiles_to_halt2 - tiles_to_halt1;
}
else // Distances are same, sort by name
{
result = strcmp(translator::translate(halt1->get_name()), translator::translate(halt2->get_name()));
}
return result < 0;
}

but the "halt" values gets a red underscore with the error:
"a nonstatic member reference must be relative to a specific object"

Where is halt defined? It looks to me as though you might be trying to call methods of the halt object you are currently inside a method of, in which case you would probably need to e.g. get_next_pos instead of halt->get_next_pos. However, I'm not totally sure whether you can use object methods as comparators in std::sort.

There are also a couple of other minor issue with this approach. Firstly, this code will result in the distance to each halt being computed a number of times (probably logN times where N is the number of halts you're sorting). I don't think this is likely to be an issue, but it's probably better to compute all the distances before doing any sorting (perhaps creating a temporary struct of distance and halt reference for each halt), especially as computing distance to nearest points could be quite computationally expensive.

Secondly, there are probably cases where this will overestimate the shortest distance to another halt (imagine two long parallel halts with basis_pos at opposite ends. I don't know how bad it would be to use potentially inconsistent distances in these circumstances.

[Matthew]

I believe that Ranran has done so at the link to the Github branch here.

I meant to praise Ranran for contributing his imperfect code to the community. Apologies to both of you, as I obviously failed to communicate that.

[jamespetts]

Thank you for your work on this. I have tried the version 2 of this: it does look good, although there is some overlapping text in the first tab. I notice that you have not been able to get the arrow buttons working still; I am afraid that, as explained above, I am not likely to know anything more than you about how to get these working, as I have never looked into the GUI in this sort of detail.

As to the design, this is definitely a good improvement; I do like your work on the GUI generally: it has much improved Simutrans-Extended. I think that we perhaps need some more clarity as to the waiting times and the classes: perhaps a menu to choose which class's waiting time to display? The same should also apply to the journey time.

In any event, thank you again for your work on this: this is appreciated.

[Matthew]

Ranran, you have already made great contributions to Extended and this project would definitely improve the game a lot.

Now it seems that you are stuck because you can't make the arrow buttons work.

But nobody here can help you, because Extended devs don't know the GUI code (and people like me don't know any code).

Maybe you could ask a specific question about the arrow buttons in Standard's Patches & Projects forum? I think the GUI code is the same in both Standard and Extended (except themes), so I guess some of the Standard devs must know the GUI code well.

Though I guess prissy may be on a plane back from Tokyo this week? 

[jamespetts]

I notice that this has stalled for over 6 months because of the issue with the jump to location arrow buttons. It would be a shame for all this work to go to waste, I think. Can I ask for people's views on whether this patch would still be worthwhile if those buttons were omitted entirely (perhaps commented out until somebody can find a fix for them)?

Ranran, would you be able to disable the non-working buttons and deal with the more minor issues (e.g. the overlapping text) in this so that it can be incorporated? This is a very nice improvement on the current windows even without the jump to location buttons, I think.

[prissi]

The GUI is now totally different to allow scalable buttons everywhere and easier use on a tablet. Also a lot of functionality was repaired. I think the GUI is one of the major differences between experimental and standard now too.

[Matthew]

I notice that this has stalled for over 6 months because of the issue with the jump to location arrow buttons. It would be a shame for all this work to go to waste, I think. Can I ask for people's views on whether this patch would still be worthwhile if those buttons were omitted entirely (perhaps commented out until somebody can find a fix for them)?

Ranran, would you be able to disable the non-working buttons and deal with the more minor issues (e.g. the overlapping text) in this so that it can be incorporated? This is a very nice improvement on the current windows even without the jump to location buttons, I think.

This is a great patch even without the buttons. 100% support incorporating it with buttons commented out.

[Mariculous]

Absolutely! it would be a shame to scrape it for this little issue.

Nevertheless, as prissi mentioned, it is indeed kind of sad that extended-gui will also neccessarily diverge from standard now, as the improvements are based on the old GUI "framework", so it can't be backported to standard.
Merging the GUI changes from standard to extended will require a lot more effort now, however, as work at the improved station UI seems to be nearly finished, scraping it for that reason now would be a shame.

Before starting any further GUI improvement projects, we should try to merge in the new GUI framework from standard, being aware that it would now also include a near rewrite of the station and convoy window.

Edit: Note that the non-working arrow buttons may or may not have been your fault. It seems sometimes they don't work on time history window and current station detail window either.

[jamespetts]

Ideally, it would be excellent to merge the GUI changes from Standard, as those seem to be a real improvement. However, if there are not dedicated coders willing to do this, then it is best not to hold up other UI projects (such as this one) on account of that. The most important thing is to enhance the functionality of the game.

And I am very much of the view that this feature would be worthwhile even if we have to cancel the idea of having jump to location buttons as originally intended.

[Phystam]

I think that Ranran or Ves who are working on the GUI improvements can incorporate the Standard GUI changes.
Furthermore, it is very excellent if you can incorporate the Font support and skin selector at the same time.

[Ranran(retired)]

Thank you for your feedback. I reviewed the button placement code again, but it didn't work. (´・ω・｀)
I think that the standard's gui_aligned_container_t class can do this easily, so I plan to make this work after the standard GUI improvements are incorporated.

[Ranran(retired)]

I proceeded with the work left over and put it into a usable form for the time being. This time the button is sane. You can test it now.
Some implementations have been omitted. But I think it has evolved from the existing ones. This is the first step in enhancing this UI.

The github branch is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/tabbed_halt_detail

[jamespetts]

Excellent - I am testing this now: this looks very interesting.

One or two queries at this stage, if I may. First of all, can I ask for clarification on the meaning of the small dark grey bar underneath the larger bars representing the different colours of freight types in the "freight" tab?

Secondly, I notice that your mockups show a number of additional symbols under the "services" tab which do not appear in my version, and this tab looks just like the equivalent part of the halt detail dialogue in the current master branch. Is this intentional, is it an error in the code, or do I need to merge in some additional symbols in the pakset in order for this to work? I should note that I do see these symbols in industry dialogues, so they are not missing entirely.

[Ranran(retired)]

Thank you for testing.

can I ask for clarification on the meaning of the small dark grey bar underneath the larger bars representing the different colours of freight types in the "freight" tab?

There are two types of transhipment: inward and outward.
In other words, the difference between heading to the station and heading to the destination from the station.
Transfers heading to the station will join the waiting bar over time. So it's gray and sticks to the waiting bar.
On the other hand, the transfer from the station to the destination disappears when it arrives at the destination.
This difference is expressed not only in cargo but also in passenger and mail.
In the case of passengers, this external transfer may show passengers walking from station to station by foot movement. This is not strictly a station user.
On the other hand, in the case of freight, it seems that outward transfer is also used to judge the overcrowding of the station as judged from the code.
For the above reasons I decided to use such a representation to distinguish them.

I notice that your mockups show a number of additional symbols under the "services" tab which do not appear in my version

Some implementations have been omitted.

That's what I said I omitted the implementation.

this tab looks just like the equivalent part of the halt detail dialogue in the current master branch.

Therefore its appearance is the correct form currently implemented. But then I made further changes to organize the line list by waytype.

Is this intentional, is it an error in the code, or do I need to merge in some additional symbols in the pakset in order for this to work?

This is intended. Currently, no additional symbols are needed.

This time the main purpose was to match this UI to the changes in the UI of the factory list.
However, since it is a problem that the button does not work properly, I prioritized not losing the function of the button.

Currently the line list is made to draw two layers of text and button (and label) at the same position.
It turns out that the buttons are turned on and off by the owner, so it takes a lot of work to function properly in a mockup-like design.


Next, regarding route information:
I know from experience with big games on servers that this needs improvement. However, this requires adding information for each class, and is a major change in work, so it will be proceeded as a separate project. (The class display in the mockup didn't look very good either. )

[jamespetts]

Splendid, thank you for this: now incorporated. I have also updated the help file. I notice that there is also a "tabbed halt detail plus" branch, but I have not incorporated this since I assume that this is not ready at this stage, not having had any information about it yet.

[Mariculous]

After some time of using the new detail window, I do really like it.

However, the topmost information in that window is rather a general brief information.
As such, I'd rather expect it in the main station window.
It would also be nice to have a visual indication of "over capacity", though that's not too important eye candy.


Is there any particular reason why the very first line (amount of lines of a specific type plus company) was not added to stops main window?

The lines below (capacity + in station + in transit) is less detailled than the passenger list either.
That given, I'd slightly reorganise the order of the passenger/main/goods list in stations main window and add the bars there.
Something like


Passengers: |___|__|___| 115+40 / 599
  In station:
  50 > King's cross
  48 > Waterloo
  ...

  Transit in:
  13 > Queens's cross
  7 > Waterloo

  Transit out:
  42 > whatever

Mail: |_________> 5634 / 10

[Ranran(retired)]

This patch implements only the first step and the rest are pending.

Is there any particular reason why the very first line (amount of lines of a specific type plus company) was not added to stops main window?

I've always been aware that there are two station dialogs, and I've been thinking about restructuring.
But this is due to the View issue I sometimes mention. In the main window, there is a dialog layout destructive god "View".
This view is very confusing to the GUI layout as it varies in size depending on the pakset size.
I designed the top of this dialog (station capacity display) to be compact and useful for monitoring, and to be minimized to display just that.
You can keep a lot of such compact dialogs open and monitor the situation, especially in simulation games where I find the GUI design to be good.

For example you know that my company on bridgewater server made some mail terminals. Keep the dialog for monitoring such terminals open at all times. Then use the shortcut keys to open and close the tabs to operate the tabs.


This will be used in conjunction with the locking feature proposed in another thread. The translucent bar reduces annoyance.
(Shortcut keys for tab operations once became the current specifications due to conflicts. This needs to be adjusted again.) It's not difficult to add a window minimization shortcut key, so I plan to add it.

Ideally we may still be able to hide the transfer time display.

In another example, it can also be used when you want to monitor the newly created cargo network so that it does not overflow or accumulate cargo.

Initially, there was no indication of the number of service lines, but without it, some said it inconvenient because there was not enough information to show the characteristics of those stations. So it was added there. (But for some reason it's broken after the GUI overhaul. It was repaired once but seems to be broken again. (´・ω・｀))

However, this direction may differ from what standard is aiming for.

Also, when thinking about reconstruction from another point of view, I think the main view has a chart and a rating bar in the foreground, which means it has a "statistics" -specific element. On the other hand, the time table and the number of waits are real-time information.
I'm sure these two dialogs are somewhat confusing as such.
The standard combined those dialogs into tabs and finally merged them into one dialog.
But I don't think it's suitable for Extended. Extended is a lot of information, and I think that both statistical information and real-time information need more accuracy and more information.
Therefore, these dialogs are not integrated in branches that are being more incorporated from the standard.

The currently pending patch will add more new tabs and station area information. It may be necessary to organize them comprehensively.

And unfortunate news. The halt_info dialog has a big difference between standard and extended, and the GUI overhaul patch cannot be merged. This is not due to the changes I made to the GUI, but to the time table code. I'm not familiar with this code. So it can't be merged and is on hold.

EDIT:
Now that the keys 1-9 have been released, they may be used for tab operations, etc.

[Mariculous]

That seems quite reasonable and the improvement is relly great already.
I am not sure anymore if anything in the detail window should better be moved to the basic station window. Imho, their distinction is not static vs statistical data, but the level of detail shown.
The detail window should show all the details, whils tthe basic station window should show the most frequently used informations as well as further informations in a minimalistic way, which can clearly indicate "you might want to have a look into the details", if there might be something wrong.

I just took some time to write down my thoughts about the basic station window, which came up when reviewing the station detail window due to these being closely tied to each other.
Some thoughts are related to the detail window, but most of those are specific to the basic station window, so I opened a new thread:
https://forum.simutrans.com/index.php/topic,20471.0.html

[Mariculous]

*dig*
I just noticed that waiting times in the station details have a related "waiting speed". This is weird and feels quite wrong to me.

[Ranran(retired)]

I'm not an English speaker, but I find "waiting speed" a very strange expression. I don't think I use such expressions. Judging from that, I think you do not understand the meaning of that display correctly.
Please refer to some examples in the game to understand the meaning.
I'm not confident in English expressions, but can they be communicated at Expected movement speed?
That's an important value, at least in light of the extended spec. For example, if it is slower than walking speed, you are offering a very poor service and people will travel on foot without using your service.

[Mariculous]

No, a waiting speed is actually nonsense. That's the point.
As can be seen in the attached image, there are two times related to a "direct route" in the "Group by destination" tab.
The pointer watch and the hourglass, both stating a time and a speed.
From my understanding, the pointer watch is the icon of the the journey time, whilst the horglass is the icon of the waiting time with a "waiting speeed" in braces.

[Ranran(retired)]

I'm sorry, I don't understand your claim.
Can you understand what it means by adding a "+" sign in front of the hourglass?

[Mariculous]

You mean the total time is travel time plus waiting time?
Well people should know this but it's a fair addition to explicitly point this out in the UI.

Anyways, it's not the point I'm describing.
It feels weird to have a speed assigned to waiting as in
2:36 (41 km/h), especially as this speed cannot be compared against walking time due to the fact that total time is wait + travel

[Matthew]

Three thoughts.

Firstly, Ranran, the building and station info displays are GREAT! Increased prettiness and graphics with no drawbacks.

Secondly, Freahk, if you don't like the 'waiting speed' you can always just use "Group by category" and forget "Group by destination" exists!  This is actually what I did. It took me ten minutes to realize what this conversation was about.

Thirdly and more seriously, I agree that the 'waiting speed' display is a little confusing. Two ideas. Firstly, we could just explain in the help file, which is now badly outdated anyway. Secondly, maybe don't show the 'waiting speed'. Instead compare the 'waiting speed' with walking speed for Passengers only. If 'waiting speed' =< walking speed, add a warning icon (like the yellow triangle with !) and a tooltip to warn players that passengers will prefer walking.

[Ranran(retired)]

The walking time example is just one example. I don't know if it will affect the use of private cars. However, it is used for comparison with competitors. If you are providing poor service, other players will take passengers from you. Players can refer to it because it is actually used for that index. Unfortunately, which player and which route offers the best service is only displayed in debug mode.

Again, it's not "waiting speed". Without it, if the player wants to know it, he will be forced to calculate the distance and estimated travel time in his head, making things hard to grasp. Group by category has less display space, so it only appears in debug mode.
Note that the one on the left is the rating of convoy and the one on the right is the rating of line. speed is an important indicator in both cases.

In any case, it is recommended to use the helpfile as it exists for such cases.
Simutrans has used a lot of hard-to-understand displays, such as numbers in a blanket of factory information, which the help file has explained.

It may be possible to improve the display like the + display in the precedent.

[Vladki]

Well, I think that it would be enough to explain what the numbers in the screenshot from Freahk mean?
Can anyone correct and complete my guesses?

Direct routes / Group by destinations

[stopwatch icon] time1 (speed1) - that is (I guess) the travel time and average speed for given destination and cargo
[hourglass icon] time2 (speed2) - that is (I guess) the waiting time - but what is the speed? Is it average speed including the wait time?  I.e. speed1 = distance/time1, while speed2 = distance/(time1+time2) ?

[Mariculous]

Again, it's not "waiting speed"

So what else is it?
A Virtual speed abstraction of the waiting time?

[jamespetts]

Do I understand that the so-called "waiting speed" is the average speed for the whole journey, including the waiting time? If so, then perhaps the issue is that this could be clearer; perhaps a tooltip on hovering over the icons would help?

[wlindley]

Waiting equals not moving; "waiting speed" is a contradiction.  Does this mean, "Effective travel speed based on estimated total journey time for waiting passengers" ?  (Yes, some concepts are difficult to express in English.)

[Mariculous]

Yes, that's obviously a contradiction, which is the point.
There's a speed assigned to waiting.

The question is: "Does that "speed" relate to the average speed needed to travel the specific distance in the given waiting time?" or "Does that speed relate to the average speed needed to travel the specific distance in the given waiting plus journey time?"

Besides assigning any speed to waiting being difficult to understand, the above is not clear to the user.
Given the calculates numbers is actually seems to relate to waiting plus journey time, in which case this number at least has a practical use.
But again, this is entirely unclear to any user and really needs some clarification.

[jamespetts]

The issue seems to be not that the display actually refers to a "waiting speed" (which does not make sense), but rather that, while it refers to something that makes good sense and is useful, viz. the journey speed when waiting time is taken into account, this might be misinterpreted and cause confusion. Again, I believe that this can be resolved relatively simply by adding a tooltip and should not require any fundamental change.

[Ranran(retired)]

So what else is it?

Expected movement speed?

I have already tried to explain it. And I gave an example of vs walking and also showed that it is the value used for route selection. I also encouraged you to see some examples in-game. You should be able to notice the distance display on the left and the sum of the two times and their association. Nevertheless, it's strange to think of it as "waiting speed". Did you think there is km/h to wait at the station? Sure there is time to transfer, but that is irrelevant. Because it has a distance of 0, speed cannot be calculated. Cargo is just charged a transfer time inside the station.
I'm talking about just a matter of expression, but I just thought you did so because you still don't understand what it is.

A Virtual speed abstraction of the waiting time

Maybe incorrect (´・ω・｀)


The time and speed in the four are statistical values.
Let me give you some short expressions about these four. Maybe it can help you understand what it means. I'm not an English speaker so it may be incorrect. It's up to Dr. Google translate of my ghost translator.

From left to right
(1) Average travel time of convoy to this destination / Estimated travel time if depart immediately / Expected travel time excluding waiting time / 所要時間 in Japanese
(2) Average "travel" speed of convoy to this destination / Convoy's speed evaluation to that destination / 表定速度 in Japanese
(3) Average departure interval for that "route" / Average waiting time at the station when heading to this destination / Average departure interval of convoy to this destination
(4) Convert the expected time to get there to speed / Convert average travel time between stations to speed / Expected movement speed to this destination / Evaluation speed of this "route" / Estimated speed of this route / Evaluation speed for cargo to select a route

I saw the English translation of "表定速度" as scheduled speed, but I don't know if it is correct because there are few examples. However, it is a very common concept and word in Japan.


Next, I explain them from the perspective of statistics used in the game.
(1) Almost worthless value. In the process of calculating (2) and (4). Or to make it look like the real world.
　However, I think this display is necessary for consistency with the walking time display. It doesn't take up much space. It's better to have it than not in my opinion.

(2) This shows how much loss is occurring with respect to the maximum speed of convoy. Acceleration performance, braking performance, stops between destinations, detour routes, traffic jams, speed limits, slopes, all possible causes. Theoretically, the maximum speed of convoy is the limit value. You could improve it by taking steps such as changing to a faster vehicle, replace with high speed way, improving acceleration, straightening the route, eliminating intersections, eliminating hills, and skipping stops along the way.
It also shows the theoretical limits of this route evaluation. In other words, if you depart convoy at intervals as close as possible to 0 seconds, the route evaluation(4) will be close to this value. This value differs from the average speed of convoy in that it also calculates the time it takes to stop at a station along the way.

(3) This is the average waiting time for passengers to arrive at this station and for the train to their destination to depart. This value is, of course, taken into account when calculating the estimated travel time for passengers and selecting routes.
This is greatly affected by frequency. It's like the real world. You will want to take advantage of the frequent public transport when you go shopping nearby.
Note that this is the sum of all lines and convoys that have the same direct route.
That is, if there is a line of 1 convoy/hour and a line of 2 convoy/hour, it is considered as 3 convoy/hour. In other words, the average waiting time is evaluated as 20 minutes. Thus, this is closely related to the individual line/convoy service frequency and will be helpful in deciding them.

(4) This value is the most important. This is the value most relevant to passengers/cargoes deciding the route. Because they choose the fastest route.
(1)-(3) are just values in the calculation process of (4), cargo choose the route by (4), and does not care what values (1)-(3) are. .. It's actually the fastest "time" route between "two points"(distance), but it can be replaced by one "speed".
In other words, the route with the fastest speed will be the winner. Win passengers from parallel routes. The faster this speed is, the more likely it is that your network will be able to attract passengers, and the slower the speed, the more likely passengers will give up on the starting a trip and evaluate your transportation network "too slow" and they will say your train is as fast as a snail. 🐌


From a code point of view, the numbers (1) + (3) are actually used to calculate the travel time, but we have no way of knowing the entire journey of the traveler, so getting it is not possible. It doesn't make much sense. And they don't carry out their trips as they decide. After you depart, you just have to choose the best method at the point. If the time limit is exceeded, they will give up their trip and refund.

This is the big difference between standard and extended. Since standard determines the route based on the route cost, it is very important that the times of exchanges is little.
However, it should be noted that change trains at the station adds the waiting time to the travel time that determines the route in extended.
So how can players know it, look at its stats, and improve it?
Yes, this is one of those pieces of information.
Even if you use a 300km/h vehicle, it is a pure fact that passengers rate it as such if it is 30km/h in (4). It may be useless to bother to use such a fast vehicle. You may get the same result if you operate a slow vehicle frequently.
The display tells the player that fact. Do you think it is correct to name this (4) "waiting speed"? I'm not an English speaker, but it sounds quite different.
Without this, the information would be scattered in a very vague and more difficult to grasp form.


The first step I have to take is to make the display understandable.
I noticed that I forgot to push the Japanese translation which ranran made before. And I checked it and fixed it a bit. You may be able to refer to it when making an English translation.

Do I understand that the so-called "waiting speed" is the average speed for the whole journey, including the waiting time If so, then perhaps the issue is that this could be clearer; perhaps a tooltip on hovering over the icons would help?

That's correct. It's like a barometer of service frequency and travel time, an indicator of route convenience. I couldn't come up with a short proper English expression. Even Japanese expression is difficult.

I understand that the relationship between (1) and (2) and the relationship between (3) and (4) are not the same. But, unfortunately, I can't think of any other good suggestions.

Again, I believe that this can be resolved relatively simply by adding a tooltip and should not require any fundamental change.

I added a tooltip. But I think you need to edit it because I'm not confident in the English notation in the default text.

[Vladki]

Ranran, you used too much word to describe something quite simple. So I ask for simple YES/NO answer if I understand correctly:

#1 - average time (without waiting) to get to given destination
#2 - average speed (without waiting) to given destination (i.e. #2 = distance / #1)
#3 - average waiting time for service to given destination
#4 - average speed (including wait times) ... #4 = distance / (#1 + #3)

And for routing decision the average time including waiting is used (#1 + #3)

If that is so then the display could be:
[stopwatch] time (speed) ... [hourglass] time ... [stopwatch + hourglass] time (speed)
That would be IMHO quite enough, and perhaps a tooltip on stopwatch: "average moving/travel time" and on hourglass "average waiting time"

[Mariculous]

No, don't rename it as "waiting speed" please. It was just an abstract name being used as its effect was not clearly known and in the UI, it's simply a speed related to the hourglass (waiting time) icon.

I guess a tooltip might indeed clarify this. It would be best to introduce a new icon, so players can clearly see "it's not a speed related to waiting, it's a speed related to the total time."

Edit: What Vladki suggested is also fine.

[Ranran(retired)]

No, don't rename it as "waiting speed" please

Who used the word "waiting speed"? You are the first.
Who recommended using the word "waiting speed"? I'm not. I have repeatedly explained that it is wrong.

Certainly we needed a guide to avoid such misunderstandings. It has already been incorporated.

[Mariculous]

Uhm?
Using the word does not mean that I recommend using that word ingame.
I did never ever recommend this.
The only thing I said is that a speed related to waiting feels weird.
Something like "waiting speed" is what comes in mind because, well, it's a speed related to the stopwatch icon, which usually represents waiting.

To make this relation clear, I support Vladkis idea.

[Ranran(retired)]

I think adding more symbol is not necessary.

And we have to consider the symbolless pakset. But I recommend using the same britain pak rather than leaving the symbol unprepared.

[freddyhayward]

I don't have a solution to this problem, but the stopwatch and hourglass icons both represent the same concept - they are not useful in distinguishing travel time from waiting time. Perhaps the icon for travel time could be an arrow, truck, locomotive, or something else.

[Ranran(retired)]

Both represent time, but there is a difference between waiting without doing anything and moving time, so I think hourglass is appropriate for time when nothing is done (not moving).
I think hourglass fits well with the word "waiting".

[wlindley]

 Lots of words are confusing, but after reading Vladki's explanation, Ranran's latest screenshot made me instantly understand. Once there are tooltips, the stopwatch and hourglass are logical. (IMHO)

[Mariculous]

I agree with Freddy, the distinguishon in between the stopwatch and hourglass is not intuitively clear. I guess I just got used to it, so if there is a better alternative, we should consider it, but I'm also not sure what that alternative might be.

I guess adding another symbol related to the total time, for example a plus, is even better to understand, but the solution now already is much better than it was before.

[jamespetts]

There are many cases where it is not easy or even possible to convey a complex or subtle distinction with a symbol alone. However, using a symbol together with tooltip text can be very effective: players who may not initially understand the distinction can learn quickly what it means, and, once they have learnt, the display is much clearer for symbols being used than if it were entirely made of text.