Consolidated station information?

[wlindley]

Thanks to all for the excellent recent improvements.  (Not sure whether how or whether this might pertain to Standard so, moderators, feel free to move the topic.)
With the additional information in the Details box, and the rearrangement of the tabs in the ordinary station box, do we in fact need the "Details" button and a separate dialogue?  Or could the little extra header information there, and the tabs in it, be placed in the ordinary (and then single) station information dialogue, perhaps as shown?  (Transferred header sections circled)  Thoughts / preferences, anyone?

[Matthew]

I have been thinking exactly the same thing all week. I would strongly support this, provided that the window is still slim enough to fit in our players' display width. A very high proportion of my visits to stations are to use the 'Services' tab and the 'Details' button is just an extra click.

[Mariculous]

The number of lines per waytype and company feature is a display I'd prefer in the "normal" window anyways.
I totally support this.

[zook2]

Ditto here.

One other thing: it's the same issue with the convoy window. Many unnecessary clicks. If the details button were to disappear, could we have the Withdraw, Retire, Sell buttons there? Perhaps just (W) (R) (S) buttons with a tooltip. Move to Depot could be grouped with those, too.

[Mariculous]

If the details button were to disappear, could we have the Withdraw, Retire, Sell buttons there?

Imho, such tabbed windows should remember the last used tab and open up new windows of the same type with that tab selected.
That will save a lot of clicks in many cases.
Picking up the Witdraw/retire/sell example, instead of four clicks: "mainWindow -> detailsWindow -> maintenanceTab -> retireButton", there will only be two: "mainWindow -> retireButton" in case of mass retirement.

[Ranran(retired)]

Thank you for your feedback. I must report that there have been improvement plans for these dialogs for some time, but they have been slow in coming.
However content about Convoy dialogs is not appropriate for discussion in this thread.
I will post individual replies on different themes in consideration of splitting, but please forgive me.
I reply only about convoy dialogs first, but admins should separate the threads if possible.


First of all, I don't really like the idea of integrating these dialogs in that there are too many tabs in extended. And it probably causes problems.
Since extended has too much information, it needs to be somewhat distributed, which is also done from the depot dialog.
For example, currently, you can access the physical information tab of the detail dialog from the depot dialog.
In the new patch, which is currently stalled, the class manager is planned to be integrated into convoy detail. And this will also be directly accessible from the depot dialog.
The convoy dialog will be closed when it returns to the depot. That's a feature inherited from the standard, but I believe the behavior is correct because all the information there is not needed when it is in the depot.


Secondly, I think those dialogues are divided by roles.
In a management simulation game like simutrans, the player switches between several roles.
At times, the player is in charge of corporate strategy, extending the railroad. The Accounting Manager will often check the line management window. He will also use charts and finance windows a lot. And you command yourself to crush the deficit line.
At times, the player will be the operation commander, monitoring the convoy. It may be a conductor or an accountant. The convoy information is there for them.
At other times, I am in charge of vehicle management and maintenance, monitoring the condition of the vehicles. The convoy detail is there for them. It also contains information that the conductor will need.
As such, these have separate roles. As explained before, convoy info is mainly focused on the entire convoy, while convoy detail is focused on being able to see each of the vehicles that make up the convoy in detail.

Many unnecessary clicks. If the details button were to disappear, could we have the Withdraw, Retire, Sell buttons there? Perhaps just (W) (R) (S) buttons with a tooltip. Move to Depot could be grouped with those, too.

Thirdly, In my opinion, those buttons are somewhat perverse buttons.
I don't like the idea of abbreviating buttons; it's hard to understand the difference from the button labels about the difference in behavior between Retire and Withdraw.
https://wikidiff.com/content/withdraw-vs-retire-whats-difference-0
It's a difficult button to explain how it works succinctly. The Japanese translation of this is a bit confusing and not very good too.
For the sell now button, we need to focus at why it was placed in the detail dialog instead of the convoy info dialog even in the standard.
Some once complained about the withdraw all button that on the line management dialog, saying it should not be easy to press because it looks like a nuclear launch button. It is especially important to note that the Withdraw All button waits for the passengers to escape, while the Sell now button kills all passengers immediately. In that respect, this button can be more dangerous than withdraw all. In light of the real world, the train operator's order to return to the depot should essentially be sufficient. According to the original procedure, the sale of the convoy should be done after returning to the depot. I suppose that's why in standard it has been placed in a separate dialog and annotated with a tooltip saying "Use with care!". (However, it is now tabbed and placed in the same dialog, making it easier to press than before.)



As for the tab structure, in the convoy detail overhaul patch that was once in progress, there was a consolidation of tabs and the maintenance tab was planned to be the first tab. Unfortunately, a lot of patches were added to the queue and the work was interrupted. This is because Ranran has only four feet. (´・ω・｀)

[Ranran(retired)]

Regarding the integration and layout of Halt dialogs:

IMO, players tend to make requests from a single point of view, but developers have to assume all possible examples.
(1) Languages
(2) Font sizes
(3) paksets (base pixel size)
(4) Use at the limit possible value/state

I have explained these several times in the past.
To get to the point first, I believe that the proposed changes would exacerbate the response to these. So I did not do that.

The main purpose of the last update of halt information was to change the old dialog to the new system. Santa Claus gave up on sending it off last winter because it had a very big conflict in the departure board. After spending some time understanding the departure board code, I finally took a step forward. This was a necessary change to accommodate changes in font size.

The reason for the duplicate display (three capacity bars) in halt info and halt detail is that there was no alternative that satisfied the requirements at that time.

Note that the waytype symbol has a different meaning in halt info and halt detail.
The halt info indicates the facility. halt detail indicates the line type.
However, as I pointed out before, I think that waytype of facility is not very useful because it can be false.
For example, I put a staging post on the road next to the dock because I want to use mail at the dock, but road vehicles never use it.

I don't think the number of routes per waytype can be stored in that area.
A maximum of 16 players may have eight different waytypes with three-digit numbers. "Auto aligned GUIs" like to push windows around, and it takes a lot of effort to deal with it.
And some players use very long company names, as described above for languages and fonts.
The presented image already has a lot of dead space in the bottom tab, which would be even more if it was a 256 size pakset.
This should stretch the entire GUI as it expands to its full width, but this did not work well. First of all, the behavior is basically that it expands evenly. This means that the cells that can be expanded will be the same width, which creates a strange space. That was the drawback of the auto-align GUI.
Adjusting the width of the top and the width of the content in the tab was also a reason for many bugs. I've been fighting this for a long time and I'm very tired. (´・ω・｀)


Also, as previously explained in halt detail thread, the ideally minimal state of a simulation game is to display only the information that is really needed.
It is sometimes more convenient to keep many compact station information windows open than one large station information window. halt detail tried the layout with that in mind. It would take a lot of work to integrate the two dialogs and make it happen.
In the halt info dialog, the station name already exists in the title bar, and the owning player can know by the color of the title bar. The status is just a collection of three capacity bars and may no longer make sense.
Too many tabs require scrolling the tab header to select the desired tab, which is a bit inconvenient.


I hope it will improve little by little from now on. As already explained, a change to the new GUI style was necessary. Anyone can help improve.

[wlindley]

I have been studying halt_info and halt_detail (.h, .cc) and while there is some overlap, it is as you say far from simple.

The detail window has a listener so the line list can update whenever the current-player changes, for example.  Mostly I wonder whether it is possible to clean up the design of the code to make UI changes more obvious how to create?