The International Simutrans Forum

 

Author Topic: [patch] access charge record and improvement of line management dialog  (Read 3589 times)

0 Members and 1 Guest are viewing this topic.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
(´・ω・`)This is Ranran's patch #4. 春のらんらんパッチ祭第4弾

Overview:
This patch is roughly divided into three parts:

(1) revive of access charge record
This was discussed here.
It was included in the acceleration curve chart patch before, but its contents were extracted and became independent.


(2) Tabbed the right part of the line management dialog
The addition of the access charge chart resulted in an increase in the number of chart buttons, causing problems with the layout of the line management dialog.
So I made tabs as a measure.


(3) improvement of the line management dialog
As a result of tabbing, there is a need and room for improvement.
However, this time, tabbing is the main purpose, so I do not make major changes. (´・ω・`)
In the past, such discussions have been held. Regardless, another patch to complement this patch is currently in progress. ;)



Details:

(1a) Access charges chart added to the convoy dialog


(1b) Access charges chart added to the line management dialog


(1c) Chart button colors have been adjusted


(1d) The order of buttons has been changed so that charts in the same group are continuous.


(2a) Tabbed the right part of the line management dialog - chart tab and convoy list tab
(2b) The number of convoys belonging to the line is displayed on the tab label.




Above of the right tab:
(3A) Added line type symbol next to the line name edit box
(3B) Displays the symbol of the goods category that is handled by the line



(3C) The Livery selector pull-down list has been moved to the upper right to solve the unselectable issue.
(3D) The choices in the Livery selector list of the line management dialog now show only the livery scheme of the vehicles included in the line. This greatly slims down the options.



(3E) Symbolized line status. This allows multiple bad statuses to be indicated at the same time.
This symbol displays its meaning in a tooltip when the mouse hovers over it.

If the pakset has no symbols, only one text with the highest priority status will be displayed


(3F) You can add a symbol indicating missing scheduled slot to pakset
Code: [Select]
Obj=symbol
name=MissingScheduledSlot
(3G) To save space, clarify meaning, and make it easier for players to understand, some of the line statuses have been changed to display together with relevant content. For example, in the missing scheduled slot, the service frequency changes to a dark turquoise and a symbol is displayed.

:exclaim: Here is the source of the symbol sample
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/tree/MissingScheduledSlot-symbol


About the contents of the convoy tab:
(3H) Needless to say that the line to which the convoy of the line belongs is the line, so the display was deleted. This will reduce annoying text.
(3I) Symbol is now displayed on convoy where no load, replacing, and withdraw is set.
(3J) Alert symbol is now displayed on convoy that is stuck.



(3K) Added display mode switching function to convoy list. Press the button to switch the display mode.
- normal mode(default)
The display is the same as before, except that the meaningless line name has disappeared.


- payload display mode
This is useful for checking capacity and loading status.



- formation picture mode
This is useful for checking convoy's formation and vehicles health.





The times history window doesn't need to have a separate window, so you might think it would be better to tab it out here.
However, it has been postponed this time because it was not designed so and was likely to be troublesome. I think it should be done at the same time as adding a tab to the convoy dialog (because the times history button is also there) and it is easier to do it after incorporating the standard GUI changes.


This patch uses the function of the depot dialog improvement patch, so it is necessary to incorporate that patch first.



Translated words to be added:
Code: [Select]
cl_btn_general
cl_btn_payload
cl_btn_formation
EDIT(2nd April): Changed from sl_ to cl_ for commonization with other dialogs
(cl seems to be short for convoy list)

My github repository is here:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/improvement-of-linemanager-2


I hope this modification will improve your gameplay comfort.
I would be grateful if you could give us new feedback on these. Thank you. (´・ω・`)

EDIT:
Added link to my github repository for the sample of "missing scedules slot" symbol.
« Last Edit: April 02, 2020, 11:18:11 AM by Ranran »

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
It looks really good. But what is the meaning if yellow stars in formation display?

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
what is the meaning if yellow stars in formation display?
Don't bother it.  :-[
That symbol is displayed only in the debug mode and indicates that the vehicle is reversed.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for your work on this - this looks very interesting! I will have to finish flushing out all of the reported issues with private car routing before I can look at new patches at present, but I should be very grateful for others' feedback on this in the meantime, especially anyone who has had a chance to test this.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
I have now had a chance to test this. Some comments, in no particular order.

1. I am not entirely sure of the utility of the tabbed right hand pane. My initial impression is that it looks a little odd without a chart at the top in all cases, but perhaps there was a reason for this not immediately apparent? Is this intended to improve usability in very large games?

2. Similarly, I am not sure about the utility of the button selection for the different displays. Even in a fairly large game, this does not seem to be necessary to avoid information overload, and I suspect that it would be easier and clearer if all the information were together, but I should be grateful for others' views on this.

3. The livery scheme selector is much improved and this is a particularly good enhancement.

4. Using symbols in addition to colours for problems is definitely a usability enhancement.

5. In lines where upgrades to vehicles are available, the current text states that the line has obsolete vehicles, even when none of the vehicles are in fact obsolete. A vehicle having an upgrade does not necessarily mean that it is obsolete: some vehicles have upgrades to different contemporaneous types. I suggest that this text be modified.

6. The additions to the charts are most helpful.

7. The line filter is excellent - but it would be more user-friendly if it were case insensitive. Do not worry if this is an excessive amount of work, but it would be helpful.

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

Does anyone else have any views on these changes, incidentally?

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
5. In lines where upgrades to vehicles are available, the current text states that the line has obsolete vehicles, even when none of the vehicles are in fact obsolete. A vehicle having an upgrade does not necessarily mean that it is obsolete: some vehicles have upgrades to different contemporaneous types. I suggest that this text be modified.

Sure, that sounds confusing, and the word obsolete is not needed there. The important information is that an upgrade is possible, whether the vehicle is obsolete or not.  Moreover I think that for a good play, the vehicles that have a future upgrade, should not be obsoleted before the upgrade is available. Otherwise, players might be tempted to scrap them before they have chance to upgrade them. I think that also real world most vehicles were upgraded while still used (e.g. when they needed a major overhaul anyway). I think that there were not many cases when something not used for long time was used for an upgrade. Also in real world you can mothball unused stock, or just let it rust on dead end track, without any costs. You can't do that in simutrans - even things stored in depot cost you a lot in monthly maintenance (which was discussed several times).

Offline wlindley

  • Devotee
  • *
  • Posts: 1021
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
A splendid improvement!

As for James's #1 and #2:
  • I suggest moving the button-whose-legend-changes (General, Payload, Formation) up to the tab level so there are four tabs: ("Convoys (4)", "Payload", "Formation", "Chart") to reflect the actual tabbed contents.
The only wish I can imagine is: Is there a way to filter lines by the cargo types they carry? It would be wonderful to list only the lines that carry mail, for example.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for your feedbacks.

5. In lines where upgrades to vehicles are available, the current text states that the line has obsolete vehicles, even when none of the vehicles are in fact obsolete. A vehicle having an upgrade does not necessarily mean that it is obsolete: some vehicles have upgrades to different contemporaneous types. I suggest that this text be modified.
As suggested I have separated upgradeable and obsolete.
As a result, obsolete is considered to be a more problematic alert, so obsolete has a higher display priority.
Then, the upgradeable text color of the line name became easier to be hidden by another issue, but it is easy to check the formation picture "which vehicle" can be upgraded, so it is recommended to use it for confirm.


Quote
2. Similarly, I am not sure about the utility of the button selection for the different displays. Even in a fairly large game, this does not seem to be necessary to avoid information overload, and I suspect that it would be easier and clearer if all the information were together, but I should be grateful for others' views on this.
It should be noted that this list has a common design with the vehicle list.
I've been busy lately and it has been late to implement this. Now you can check it.


I think this list display is useful when there are many vehicles on one line.
And it is more convenient for the list to see more convoys at the same time.

Text colors and symbols tell the convoy upgrade or obsolete, but not "which vehicles" are upgradeable or obsolete.
Also when carrying multiple goods, it is not clear which category is full and which category has room.


I am planning of adding a button such as "spec" for the toggle button on the convoys tab.
For example, you can check the maximum speed, acceleration, axle weight, and comfort level.
Maximum speed and acceleration can help you find the convoy that is causing the delay.
Displaying the comfort level helps you find convoys that are reducing the average comfort level (travel time) of the line.
I think it might be better to focus on the first button for maintenance and fixed costs.
I believe that specializing the display content will improve convenience.




Quote
1. I am not entirely sure of the utility of the tabbed right hand pane. My initial impression is that it looks a little odd without a chart at the top in all cases, but perhaps there was a reason for this not immediately apparent? Is this intended to improve usability in very large games?
As I said above, I think it is more convenient to display many convoys at the same time without scrolling the convoy list.
On the other hand, in my opinion, the chart buttons take up a lot of space.
(I thought about collapsing this, but I thought it would be difficult to use it unless I saw the color legend.)
In addition to this, the number of buttons has increased by one, and the delivery selector has been moved to the right panel to avoid conflict.
As a result, more area is occupied by the chart and the area of the convoy list is reduced.


Quote
As for James's #1 and #2:
I suggest moving the button-whose-legend-changes (General, Payload, Formation) up to the tab level so there are four tabs: ("Convoys (4)", "Payload", "Formation", "Chart") to reflect the actual tabbed contents.
Right now there are only two tabs, but I plan on adding a new tab here in the future.

One tabs the times history I mentioned above.


Second, I plan to implement something like the smartphone app commonly used in Jalapagos.

This is currently in progress as a separate patch. The screen is still in the mock-up stage.
It would be more convenient to add more information here.
This is useful for seeing the operation status of the line.


Thirdly, I want to make statistics that are often used in the real railway industry.
It is called a transport density graph and records the amount of use between stations.


For these reason, I think it is better to switch the display of the first tab with a button instead of duplicating the tab as suggested by wlindley.




The only wish I can imagine is: Is there a way to filter lines by the cargo types they carry? It would be wonderful to list only the lines that carry mail, for example.
This seems to be a very attractive feature. As mentioned above, this is a common design with the vehicle list, so it is possible to narrow down, but in consideration of the time required for coding, I would like you to make a future plan instead of this time (´・ω・`)
Here, instead of opening another window and executing the filter, I hope that you can treat the category symbol like a button and turn on / off the refinement. I think that the function to make the symbol a silhouette has been added to the new GUI of standard.


Quote
7. The line filter is excellent - but it would be more user-friendly if it were case insensitive. Do not worry if this is an excessive amount of work, but it would be helpful.
This is a standard feature and I haven't made any changes.

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
For me it it is confusing to have a button, that changes what is displayed, like the "cl_btn_general" in vehicle list. I know that this is used in the vehicle list already now (e.g. ascending/descending), but I would prefer to avoid adding more such buttons, and even replace those existing. I would replace them with combo box / list, like the one in depot (append/insert/upgrade/sell) or livery selector. Or where appropriate (and if space is not an issue) with tabs. Buttons should be used only for actions (like withdraw, sell, send to depot), or for opening further windows (e.g. class manager)

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I would replace them with combo box / list, like the one in depot (append/insert/upgrade/sell) or livery selector.

Unfortunately I don't know how to solve this problem. (´・ω・`)


EDIT:
As I reported in another thread, overlapping pull-down lists seems to be an extended-specific bug.
« Last Edit: April 12, 2020, 11:50:59 AM by Ranran »

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: [patch] access charge record and improvement of line management dialog
« Reply #10 on: April 12, 2020, 10:39:01 AM »
You perhaps misunderstood me. I did mean the buttons that change their label after being pressed, like those marked with red dots in this picture:
These should be a combo box, or separate tabs (convoy profits, convoy payload, convoy formations, convoy locations, charts)

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Re: [patch] access charge record and improvement of line management dialog
« Reply #11 on: April 12, 2020, 10:53:41 AM »
You perhaps misunderstood me.
I don't think so, it's a pulldown list. (But the list is empty.)


What I wanted to say is that the below convoy information and the characters in the pull-down list overlap.
This is the same symptom as the current nightly build's livery select list. (´・ω・`)

Quote
separate tabs (convoy profits, convoy payload, convoy formations, convoy locations, charts)
I don't think splitting the convoy list by tabs is a good idea.
1) If the list is large, it is easy to lose track of the desired convoy
For example, I wanted to check the information of the 30th convoy in tab1. Then I need to scroll to the 30th after switching to tab2.

2) Adding a sorting and filtering function can be cumbersome in usability and coding.
Where do we control the filtering of lists on tabs except charts?
Do we make it outside tabs? It looks unnatural because of the chart tabs. (Similarly, the convoy location tab I want to add will not need the effect of the sorting.) Probably in a tab is good idea. Because it is clear that it affects the list in the tab.


EDIT:
As I reported in another thread, overlapping pull-down lists seems to be an extended-specific bug.
« Last Edit: April 12, 2020, 11:50:47 AM by Ranran »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for your work on this. I have now pulled and tested the latest version.

I do agree with Vladki that a button whose text changes with the changed state is not the ideal way of organising information: the suggestion of multiple tabs made by W. Lindley, would, I think, be clearer. I am still not sure of the benefit of splitting this information - can we not have all three datasets in the one window/tab? That would save players from having to switch between tabs/states to see multiple items of information.

Nonetheless, the symbols for obsolescence, missed slots, etc. are very useful and the change to the livery scheme selector and line filters are definitely worthwhile. I wonder whether some further consideration might be given to the general/formation/payload tabs?

I have merged the changes with the master branch on my line-dialogue-improvement branch; again, I force-resolved the Japanese translation text issues, so you may need to fix this.

Thank you again for your work on this so far: it is much appreciated.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for testing and incorporating.

Quote
I am still not sure of the benefit of splitting this information - can we not have all three datasets in the one window/tab? That would save players from having to switch between tabs/states to see multiple items of information.

I'm really struggling with a layout that is easy to see and use.
I agree with ideal not to use the toggle button.
On the other hand, I want to arrange as many convoys as possible at the same time. It improves the player's understanding of information.
Next I want the same information to be right next to each other. It is common in statistics and easy to compare. It's like a table.

Well it looks like it's seen in another game... (´・ω・`)

Also, when these are sorted, it is easier to see that they are vertically aligned.

Since there are many factors with large fluctuations in width, so I struggle with layout.
- The image of convoy largely depends on pak set size. Of course, the appearance of the vehicle is also one factor that identifies a unique vehicle.
- The convoy name and line name vary greatly depending on the language and player.
- The amount of formation information depends on the number of vehicles.
 However, I think that the order of vehicles and their shapes are useful for players to recognize their unique convoy.
 Also, it is easy to recognize that obsoleted vehicles are mixed in the convoy. It's also clear that certain categories are full or crowded.
- The amount of information in the goods category carried by convoy varies depending on the convoy.
 For example, the difference between a convoy carrying only one class of passengers and a convoy carrying multiple classes of passengers and multiple freight categories.


It is sandwiched between ease of use and layout and current specifications...
Is it better to create a tab exclusively for data?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Perhaps one way of solving this problem would be to have multiple tabs, but to have some information, including the convoy image and name and perhaps some other basic data (capacity, load, profit, perhaps), stay the same between the different tabs, so that only some of the less frequently accessed information is hidden by changing tabs. Perhaps the basic information could include a symbolic representation of things shown numerically in certain tabs, e.g. using a mini-graph in the basic information but giving the data numerically in one of the tabs.

Would this be workable, do you think?

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I have merged the changes with the master branch on my line-dialogue-improvement branch
This patch doesn't seem to be incorporated yet. I was aware of that, but I was waiting to avoid a revision number conflict. Now I've pushed the one that avoided those conflicts.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for that. I have attempted to merge this latest into my line-dialogue-improvement branch for further testing, but I get a fatal error when I attempt to load the pakset in the following terms:

Code: [Select]
FATAL ERROR: successfully_loaded() class skin_desc_t-object InputOutput not found"

I should be grateful if you could look into this so that I can test further.

Thank you for your work on this so far.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for confirmation. It was caused by not correctly resolving the conflict, but in my case I had the additional symbol pak so it was overlooked without the error.
This has been fixed on my branch now.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Splendid, thank you, this appears to solve the problem.

I realise that I made a slight error in my previous post in referring to tabs; I had confused the function of the tabs with the function of the new button ("General", etc.). I can understand the reasoning behind splitting convoys and chart into separate tabs, but I wonder whether the separation of the information with the button might be made easier for players by repeating some basic information for each of the options? Given that there is a large amount of horizontal space spare in most cases, this should be achievable as far as I can see. I wonder whether the information in "general" might be repeated so that "general" is no longer its own category, and all the information in the other button options would then appear to the right of the general information depending on the press of the button, the "general" information being fixed?

I should be grateful also for others' views on this functionality.

Aside from my reservations about the number of button clicks required to access information in the right hand tab of the line management window, this is really very helpful and adds splendid features, so it would be good if this one aspect might be looked into a little more.

Thank you again for your work on this.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
Aside from my reservations about the number of button clicks required to access information in the right hand tab of the line management window

If window classes could "remember" some of their state globally, like the opened tab and selections within that tab, the additional number of clicks will be negligible, as players are usually interessted in the same information from multiple objects.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for your feedback.

I wonder whether the separation of the information with the button might be made easier for players by repeating some basic information for each of the options? Given that there is a large amount of horizontal space spare in most cases, this should be achievable as far as I can see. I wonder whether the information in "general" might be repeated so that "general" is no longer its own category, and all the information in the other button options would then appear to the right of the general information depending on the press of the button, the "general" information being fixed?
The expression "General" may not be right here. This is a traditional display method, which focuses on convoy pictures.
Other than that, display profit, loading bar, and line name (or in depot).

I may not understand your order correctly.

Please note that the convoy list panel is used in common with the vehicle list.


For example, in the second option, a convoy with many types of goods may have a long second line, and a long Line name may have a long third line.


I'm thinking of creating a new "statistics tab" whose purpose is to display data.
Therefore, the first tab is enough to display 3 patterns using picture and symbol, and I want to keep this.


Quote
Aside from my reservations about the number of button clicks required to access information in the right hand tab of the line management window, this is really very helpful and adds splendid features, so it would be good if this one aspect might be looked into a little more.
If window classes could "remember" some of their state globally, like the opened tab and selections within that tab, the additional number of clicks will be negligible, as players are usually interessted in the same information from multiple objects.
I changed the convoy tab to remember the selected tab state and the state of the chart button so they are retained even if the dialog is closed.

I haven't created a statistics tab yet, but I appreciate your feedback on these.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
I haven't created a statistics tab yet
Well I mentioned stats because the access charge record is a stat.
Anyways, that's a more-or-less gneral thought.
Windows should also remember their state, so when another window of the same type gets opened, it will directly show the same kind of information.


Anyways, great it was added now :)

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
The patch is more beef up by aging  :-*


A sorting function has been added to the convoy list of line manager.  ;)

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Beef up occurred continuously today.

Next stop sort has been added to the sorting function to further increase fat.

To make effective use of this, I added the display of Next stop to the  Payload tab.
This is useful when you want to convert a convoy that is nearby from many convoys that are on the Line.


The mass of passengers was torn to class.  :thumbsup:

Ideally, each class would have symbols and coloring, but there is no such thing at the moment, so I pasted the class name for the time being and dealt with it.
Also standing passengers were also quarantined.

I think these changes have largely filled James's worried GUI margins.


I've intimated adding an additional stats tab, but I think it will take more time.

I think that the changes so far will be useful for server games, so I would like you to test it once and incorporate it.
After that, it would be helpful if you could give us another feedback.
Thank you.(´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you very much for this: I have now incorporated this. I have renamed the "General" button "Overview" to make its function clearer.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I have renamed the "General" button "Overview" to make its function clearer.
I didn't come up with a good word, but I think Overview is a good word. Thanks for fixing it.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
At first, this feature is great.

Second, there are two points I should have noted long ago, but I must admit I didn't follow this thread pretty much before.

The three state toggle between Overview, Formation and Payload is a little confusing, especially as there already is a tabbed window.
I'd suggest to create these as tabs instead, so there are 4 tabs instead of 2.
It should be easier to access that way and won't involve additional clicking, as the selected tab is remembered just as the state of the toggle.
Generally, I don't linke that toggle component pretty much, as it's unclear what kind of data is available and what will be the next.

There is a "Next stop" sorting, again using a toggle button. I'd rather use a dropdown here, but that's not the point.
The "Next stop" order will sort stops by lines stop index of the nex tstop.

That means, a line A-B-C-D with mirrored schedule will sort convoys the following way:
B->A
A->B
C->B
B->C
D->C
C->D

In many cases it might be preferable to sort them by the stop index of the mirror expanded line, that means
A->B
B->C
C->D
D->C
C->B
B->A

B->A is arguable, might insead be displayed first instead of last.


Further, please show the reversed state of vehicles in the list. Not sure if the current rather confusing display of [<<] , which is "will reverse at the next stop" is needed at all and why exactly it's displayed in the payload mode. I'd rather expect it to be displayed in overview mode or everywhere as it doesn't really match any of the other two categories.

In any case, great work!

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
It seems there is a bug that crashes when opening linemanagement dialog on linux. (´・ω・`)

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
Cannot confirm this to be generally related to Linux. On my Linux device it works fine.
« Last Edit: May 29, 2020, 04:37:36 PM by Freahk »

Offline Huitsi

  • *
  • Posts: 6
Specifically, I crash when trying to view some of my lines in the line management dialog. AFAICT these seem to be the lines with most convoys, like Wykstoke Ferry.
Code: [Select]
*** buffer overflow detected ***: /[--]/simutrans-extended terminated

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
I can now confirm this.
opening "Anningdale - Pyewater trunk ferry", which has 148 ships, crashed the game on Linux, the Windows build is fine with it.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Is it possible that the missing "missing schedule slot symbol" from the pak128.Britain is causing a crash in Linux?
Anyway, I pull-requested the symbol.


opening "Anningdale - Pyewater trunk ferry", which has 148 ships, crashed the game on Linux, the Windows build is fine with it.
Does Linux cause any problems due to the large number of convoys...?
« Last Edit: May 30, 2020, 09:22:21 AM by Ranran »

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
The three state toggle between Overview, Formation and Payload is a little confusing, especially as there already is a tabbed window.
Certainly this seems rather awkward as some have pointed out. I'm thinking of putting another tab inside a tab.
EDIT:
This may be a bit complicated with the addition of a sort button.
« Last Edit: May 30, 2020, 10:13:58 AM by Ranran »

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for that - now incorporated. I should be grateful if people could confirm with to-morrow's nightly build whether this fixes the crash.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
As to the three sort buttons, may I suggest you make two of them as comboboxes, and the "Ascending/descending" button a checkbox instead? I think that would help the clarity. Also, this is how the stop and convoy info window deals with the sorting of cargo.

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Hello. I'm looking at the new convoy management window. I like the new variants of convoy display, but I think the old way showing graphs and convoys together was more practical.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
As to the three sort buttons, may I suggest you make two of them as comboboxes, and the "Ascending/descending" button a checkbox instead?
What does the check box label look like? Does it mean "" (nothing)?

I think the old way showing graphs and convoys together was more practical.
But it is the same as the current standard. IMO, chart buttons occupy wasted space. And adding an access charge button made it more worse.
EDIT: Misunderstanding. I only saw prissi making such a suggestion, It didn't happen after all.

EDIT2:
And moved the broken livery scheme selector to the right. Because it is for convoys, not for stations.
« Last Edit: May 31, 2020, 02:39:13 AM by Ranran »

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I found a reproducible example of a crash, so I pull-requested a fix for it. Please check pull request #185.
I would appreciate it if you could confirm that it will not be reproduced on linux.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you: I have now integrated the fix. I should be grateful if Linux users could confirm whether this works.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
Quote
What does the check box label look like? Does it mean "" (nothing)?
Just a checkbox with a small text:
[ x ] Reverse sort order.

Then the player only have to look if it is checked, instead of having to read the text in the button.

I like the new layout, I dont see a need to have the graphs visible as they were previously.



The only other thing I miss with the sorting options of the vehicles, is to display the value that they are sorting after. This is already true for Name, Next stop*, and Income, Loading level*, but is not true for: Max speed, Value, and Average age.

It would be nice if they would be displayed when the specific sort option is selected.

* These values are only indirectly displayed, or displayed when changing display mode. It would be nice if these values where displayed also in the "main" displaymode when the specific sort option is selected. I know there might be lenght issues, especially with the "next stop", but a solution to that could simply be to omit the "Destination:", saving alot of space.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9989
  • Languages: De,EN,JP
Just a word of caution. If the new GUI will be ported to extended, then all these alignments (and also taking care of overly large text) will be taken care by the GUI. I am not sure, if this is planned, but a lot of work would be wasted then.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
Imho, ascending/descending is one of very few places where the toggle button is still viable.
A small arrow icon toggle would be better, but we don't have such yet.

In any case as with most GUI decisions, personal preferences do often play huge role as there often is no clearly best solutions, it's rather a matter of what people are used to.

Offline Huitsi

  • *
  • Posts: 6
I'm afraid the crash is still happening.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
According to freddy's report, it crashes in a nightly, but it cannot be reproduced in a debug build. I didn't know the cause, so I removed the display of the tooltip that caused the previous build failure and crash. I would like to see if this causes a crash. Please check pull request # 186.

If you still get a crash, please report more details. Freddy said that selecting the second from the top of the wykstoke ferry company's line list from above would cause a crash, but that line didn't have a lot of convoy. Other reliable reproduction examples will be materials for narrowing down the conditions.

EDIT:
Note: Changes has not been incorporated yet.
« Last Edit: June 02, 2020, 09:04:21 AM by Ranran »

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
If you still get a crash, please report more details. Freddy said that selecting the second from the top of the wykstoke ferry company's line list from above would cause a crash, but that line didn't have a lot of convoy. Other reliable reproduction examples will be materials for narrowing down the conditions.
That line did have 148 convoys when it caused the crash for me, which of course I could only find out using a debug build.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Quote
Just a word of caution. If the new GUI will be ported to extended, then all these alignments (and also taking care of overly large text) will be taken care by the GUI. I am not sure, if this is planned, but a lot of work would be wasted then.
Thank you for your advice. It's not that I didn't consider it.
When a new function is added, it often involves changing the GUI. So I already see many small differences.
I found the standard depot filter patch useful, so I tried if I could apply it to extended. But it was difficult because the code was different than I imagined. The file structure is different. So I gave up it.
Another problem I have reported to standard is that we cannot type Japanese(double-byte characters) properly in extended (This happens under certain conditions). This was also the same.
This is a serious problem for Japanese player because all Japanese characters are double-byte characters.

Certainly, unnecessary work will be reduced if the GUI overhaul is already incorporated.
But I wonder if it is worth stopping because there is no guarantee that what I can do now will do in the future.
I don't know how many months or years later it will be. However I think the sooner it is, the better.

@James - Could you tell us about the progress and outlook for the incorporating from standard that phystam is promoting?

(Also, the smaller the difference from the standard, the more likely I can make a standard patch. Previously I tried compiling standard with MSVC but gave up. (´・ω・`))

The way I think about overhauling GUIs (if they differ a lot) is to incorporate the standard GUI as "empty". Next, make a frame. Then reposition the parts.





BTW, I made a sort button experimentally.

This is a simple one that uses existing functionality.
I was wondering if I could make the button turn light blue and white, but that wasn't possible with the existing features. I think we need to define a new button to do that. (´・ω・`)
The issue is that the gray button seems to be unavailable.
I'm wondering if it's worth doing because it's functional enough.
What do you guys think about this?


Quote
The only other thing I miss with the sorting options of the vehicles, is to display the value that they are sorting after. This is already true for Name, Next stop*, and Income, Loading level*, but is not true for: Max speed, Value, and Average age.

It would be nice if they would be displayed when the specific sort option is selected.
I'm thinking of using the third line of empty.


Quote
I know there might be lenght issues, especially with the "next stop", but a solution to that could simply be to omit the "Destination:", saving alot of space.
Yes, that's exactly why I didn't show it on the empty third line.
We must specify the number of characters to cut off the display, not the width. That was troublesome. (´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you for that: I have now incorporated the changes; I should be grateful if anyone could test with to-morrow's nightly build whether this fixes the crash.

As to Phystam's work in incorporating changes from Standard, I am afraid that I know nothing more than is on the thread in the public forum regarding this; I had asked whether the work was compatible with the private car route finding code some months ago, and have not had an answer to this question and there appears to have been no progress since.

On a different topic, I do like the up and down buttons instead of the large button with the words "ascending" and "descending": this is clearer and easier, I think. I note that this is not in the latest commit to your branch, but perhaps it was not intended to be yet?

In terms of Japanese characters, I was not aware of this until now. Is this not an issue in Standard? If this has been resolved in Standard, it might be worth finding the specific resolution for this and backporting this as a higher priority than the general work, since it is a problem if Japanese speakers cannot type characters in Japanese properly.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
I like alot the combobox sort option, I wondered if it would also not be usefull to have a combobox ínstead of the right hand button as well (the one labeled cl_btn_general)?
Also interresting with the up and down arrows, had not thought of that idea!

Quote
I'm thinking of using the third line of empty.
Do you mean that  you consider doing it on the third line, or that you want it to remain empty?  :P

Quote
Yes, that's exactly why I didn't show it on the empty third line.
We must specify the number of characters to cut off the display, not the width. That was troublesome. (´・ω・`)
Have a look in the convoy info window for the line entry. I made my own character limiting display there, asuming that every character was five pixels wide, and then I added the rest of the characters needed (arrows, reverse symbol etc). I have since learned that there might be better options than to just assume a character to be 5 pixels, but perhaps that approach can be used?

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Quote
On a different topic, I do like the up and down buttons instead of the large button with the words "ascending" and "descending": this is clearer and easier, I think. I note that this is not in the latest commit to your branch, but perhaps it was not intended to be yet?
Yes, because I wanted to ask first if there was a problem with this style.
I have now pushed it to the same branch so you can check it working.

If there is no problem with this style, other dialogs can be replaced as well.


Quote
Is this not an issue in Standard? If this has been resolved in Standard, it might be worth finding the specific resolution for this and backporting this as a higher priority than the general work, since it is a problem if Japanese speakers cannot type characters in Japanese properly.
Yes, it was a standard issue solved in June 2018. The thread is here. It will be a long way incorporating from the standard in order. A particular problem is when entering double-byte characters in markers.


Do you mean that  you consider doing it on the third line, or that you want it to remain empty?
Meaning I'm considering doing it on the third line :-[

Quote
I wondered if it would also not be usefull to have a combobox ínstead of the right hand button as well (the one labeled cl_btn_general)?
I'm still thinking about what to do with this button, including tabbing, so I haven't started yet.


Quote
Have a look in the convoy info window for the line entry. I made my own character limiting display there, asuming that every character was five pixels wide, and then I added the rest of the characters needed (arrows, reverse symbol etc). I have since learned that there might be better options than to just assume a character to be 5 pixels, but perhaps that approach can be used?
At least one Japanese/Chinese/Korean is more than 5px wide. Also, font sizes will be variable with incorporating from standard.[

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Ranran - are you able to locate the individual commit on the SVN's Github mirror where the Japanese character fix occurs? I might be able to port this manually if this is not too heavily connected to code that has diverged fundamentally between Extended and Standard.

As to the dialogue improvement, this is much clearer and easier to use and I will incorporate this: thank you. One suggestion, however, is to add a tooltip text for the buttons to show "ascending" and "descending"; you can even re-use the text from the buttons so that no new translations should be necessary.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Ranran - are you able to locate the individual commit on the SVN's Github mirror where the Japanese character fix occurs? I might be able to port this manually if this is not too heavily connected to code that has diverged fundamentally between Extended and Standard.
Here it is.
https://github.com/aburch/simutrans/commit/b4849504fb4f7f123f674a377e6f0128e8c58056
Since it was two years ago, my memory may have been incorrect. Is it easy to incorporate this in?


One suggestion, however, is to add a tooltip text for the buttons to show "ascending" and "descending"; you can even re-use the text from the buttons so that no new translations should be necessary.
This was simply my miss. In addition to that fix, I made a pull request for the other ascend/descend buttons of other conboboxed list dialogs. Please check pull request #187.

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
The line info  windows shows Revenue: number, but in fact it is Profit:   Compare with graphs.
Revenue cannot be negative....

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Here it is.
https://github.com/aburch/simutrans/commit/b4849504fb4f7f123f674a377e6f0128e8c58056
Since it was two years ago, my memory may have been incorrect. Is it easy to incorporate this in?

Thank you very much for finding this. Fortunately, this was easy to incorporate and I have now incorporated this. I should be grateful if you could re-test.

Offline Huitsi

  • *
  • Posts: 6
It seems the crash has not gotten fixed yet. The two lines that cause the crash are "Wykstoke Ferry" and "Anningdale - Pyewater trunk ferry".

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
I've made a pull request that fixes a crash when clicking the livery selector (applicable to all combo-boxes) with no available liveries. I'm also looking at other oddities related to the livery selector.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
It seems the crash has not gotten fixed yet. The two lines that cause the crash are "Wykstoke Ferry" and "Anningdale - Pyewater trunk ferry".
Same with me. Ranran - the tooltips can't be the cause of this, so it would be good to have them back.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
It seems the crash has not gotten fixed yet. The two lines that cause the crash are "Wykstoke Ferry" and "Anningdale - Pyewater trunk ferry".
https://drive.google.com/file/d/13Iv6WdUnx6k0GErx1icZUXXdr8SND6tn/view?usp=sharing
https://drive.google.com/file/d/1r6zLgcEzjB-RflfJUf6xAUanjBmHShoK/view?usp=sharing
The reason seems to be that there are many convoys. Can these saves open the line management dialog?

Offline Huitsi

  • *
  • Posts: 6
Both crash when trying to look at the (1) line.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for confirmation.
Can you open the Vehicle list? They use a common view, and the Vehicle list shows more.

Offline Huitsi

  • *
  • Posts: 6
Yes, the vehicle list opens and works without crashing.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
I've submitted a pull request that fixes the crash, at least for linux. There might be something I was missing though, Ranran - for some reason you made 'char tmp_buf[5]' instead of directly formatting the label (which is what my pull request does). What was the purpose of this?

EDIT: the problem was that a char[5] is only enough to store 4 characters plus the end character. 2 characters were used for '(' and ')', so only 2 extra digits could be stored properly. It seems that linux is much more strict with memory, probably for the best, and did not allow this.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you - incorporated.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Thank you for finding it.
Quote
Ranran - for some reason you made 'char tmp_buf[5]' instead of directly formatting the label (which is what my pull request does). What was the purpose of this?
This was to avoid breaking the position where player click the tab and react if you do not fix the width of the character. Therefore, I tried to secure a 3-digit display so that the character length would not change.
For example, when the number of convoys changes from 1 digit to 2 digits and the character length changes, the tab position changes, but the place where the click responds does not change.
Therefore, clicking the tab sometimes did not seem to work.

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
Thank you for finding it.This was to avoid breaking the position where player click the tab and react if you do not fix the width of the character. Therefore, I tried to secure a 3-digit display so that the character length would not change.
For example, when the number of convoys changes from 1 digit to 2 digits and the character length changes, the tab position changes, but the place where the click responds does not change.
Therefore, clicking the tab sometimes did not seem to work.
I see, I just tested switching from a 1000-convoy line to a 1-convoy line and this indeed happens. I tried reverting to before my patch and changing tmp_buf[5] to tmp_buf[8] and %5s to %7s. The problem still occurs because the characters are not fixed width, so the spaces are much narrower than the digits. Would it be too much to re-compute the width of the tab every time the tab name changes?

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
We should not really be using limitations on memory storage to impose a restriction on the number of characters that can be displayed, as this is unstable: instead, an algorithm to truncate a string if necessary should be deployed.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
On top of that, abusing C-style char arrays, instead of std::string is highly deprecated in C++ because of such issues.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
On top of that, abusing C-style char arrays, instead of std::string is highly deprecated in C++ because of such issues.

Although much of the Simutrans codebase was written before this was widely understood.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
Yes, I'm not blaming anyone for such code to exist. It was simply usual to do it that way in old C times, and there still are some very rare cases where this might be preferable.

I just wanted to point out that there are very good reasons not to use char arrays in most scenarios, so new code should not stick to these old practices and in case of bugs cause by such, the bugfix should attemt to circumvent the use of very dangerous char arrays either. For sure, not at all costs.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9989
  • Languages: De,EN,JP
You are fighting a lot of bugs that Dwachs new autoscaling GUI code solved, by the way. Liek the combobox issue or truncating strings of there is not enough space and much more. Just an observation. Enabling the new GUI code does not require to change any old dialoge. But it offers the chance to make any new dialoge using the new scalable GUI and thus avoids double work.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
You are fighting a lot of bugs that Dwachs new autoscaling GUI code solved, by the way. Liek the combobox issue or truncating strings of there is not enough space and much more. Just an observation. Enabling the new GUI code does not require to change any old dialoge. But it offers the chance to make any new dialoge using the new scalable GUI and thus avoids double work.

If anyone would like to work on integrating this, it would be most welcome, although I suspect that it might be a lot of work.

Offline wlindley

  • Devotee
  • *
  • Posts: 1021
    • Hacking for fun and profit since 1977
  • Languages: EN, DE
Could the Withdraw All button perhaps be moved away from the other buttons?  It's all too easy to blitz a Line when you only wanted to change its livery

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
I initially started another pull request with various changes and fixes, and I see that James merged one of the individual commits from that branch. Admittedly, there were potentially controversial layout changes in that branch so I have replaced it with two separate pull requests, one for simpler fixes (https://github.com/jamespetts/simutrans-extended/pull/191) and one for larger changes(https://github.com/jamespetts/simutrans-extended/pull/192).

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
I initially started another pull request with various changes and fixes, and I see that James merged one of the individual commits from that branch. Admittedly, there were potentially controversial layout changes in that branch so I have replaced it with two separate pull requests, one for simpler fixes (https://github.com/jamespetts/simutrans-extended/pull/191) and one for larger changes(https://github.com/jamespetts/simutrans-extended/pull/192).

Thank you for that. Would you be able to explain the changes in more detail so that we can obtain feedback on them before considering integration?

Offline freddyhayward

  • Devotee
  • *
  • Posts: 224
  • Languages: EN
Thank you for that. Would you be able to explain the changes in more detail so that we can obtain feedback on them before considering integration?
#191is fairly straightforward: it fixes a bug where the line capacity bar would appear at position (0,0) when first selecting an empty line. It also fixes the the livery selector which displayed incorrect information.
#192 moves the stops list into a tab allowing the lines list to expand.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Since servers are the age of ships and horses, there are a large number of ships and horse lines. Almost no trains or trams.
On the other hand, TBH, the display area of the current station list of line management dialog is too small to be useful.
I think it is better than the current situation to include the list of stations in the tab.  :thumbsup:


Some suggestions for improvement:
The left line list is too big. I think it is good to enhance the filter function.
Add an option button to narrow down the line by goods category. For example, it is convenient to be able to extract only the line containing bulk from the line of many ships.
The station list will be displayed with priority given to the number of waits for the corresponding cargo.
We do not need information about the number of passengers waiting at station for the mail/goods line.

EDIT:
I haven't seen much about the region function yet, but can we narrow it down to specific regional lines?

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
@James - Please revert the commit number f0aca8786d7fdb7abf006b39793267d8ca0a4194 to re-enable tooltips that were temporarily removed.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
f0aca8786d7fdb7abf006b39793267d8ca0a4194

Now done.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Could the Withdraw All button perhaps be moved away from the other buttons?  It's all too easy to blitz a Line when you only wanted to change its livery
Check the pull request #193   ;)

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Ranran - are you able to locate the individual commit on the SVN's Github mirror where the Japanese character fix occurs? I might be able to port this manually if this is not too heavily connected to code that has diverged fundamentally between Extended and Standard
Quote
Thank you very much for finding this. Fortunately, this was easy to incorporate and I have now incorporated this. I should be grateful if you could re-test.
I apologize for the late confirmation. This issue has not been resolved yet. The symptoms are the same as before. I wonder if I missed a commit related to this. (´・ω・`)
But rest assured. Japanese people are calm and do not cause riots.

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
This is unfortunate.

If anyone can identify any other missing commits necessary for this to work, this would be most helpful.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
Could the Withdraw All button perhaps be moved away from the other buttons?  It's all too easy to blitz a Line when you only wanted to change its livery

The Withdraw all button has moved to the previous "change prices" buttons position, which is VERY dangerous, as one has gotten used to the location of each button. Ranran, could you move the button one further space right, so that the row of buttons looks like this:

[Change prices] [Times History]                       [Withdraw all]

I think the long term solution for this is to have another tab with all critical action buttons that you can do on the line as a whole. I know that currently it is only that one "withdraw all" button, but it would not be unrealistic to foresee new buttons in the future like: "Sell all immediatedly" "Set all to reverse" "Set all to nonreverse" "Set every second to reverse" "Upgrade all" etcetc.

However, for the moment, I think that the "withdraw all" button should just be moved to the far right, so as to minimize false actions.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I don't think small spacing is effective for people who do not read the button text.
I still think it's a little better than doing nothing.

A short-term solution is to change the color of the text or the background color of the button.

In the slightly troublesome plan, the button will not work unless you check the check button. But this may be difficult to understand without an explanation.

A future idea is to implement a type of button that can display symbols inside the button.
Also, the Journey time measurement button will be removed from this location by putting it in the tab.
Similarly, could the change price also fit in a tab?

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
This is definitely VERY dangerous!
I do still catch myself changing the "show" type of the vehicle list, when I want to enable the filter, because the enable filter button was in that place before.
Once you are used to an UI, you will just use it that way.

A small spacing is not effective for people that randomly click anything without reading, but it is very effective to not have the button located in a place where there had not been an other button in the past.

Similarly, could the change price also fit in a tab?
This sounds like a good idea to me.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
I would prefer buttons that one needs frequent and not being dangerous to press to be easily accessible, while the other more "dangerous" buttons can be hidden more away. Changing the color of the withdraw button will make the already busy window more busy, and if it remains in the position it is, it will still be a hazard area, not solving the current problem.

Solving this for the moment by moving the withdraw button to the far right is the best solution I can think of as it does two things:
1) It moves the button away to an area that is less dangerous and prone to misclicks, and
2) it changes the layout of the window, breaking our habits, making us pay attention to them
« Last Edit: June 10, 2020, 12:20:22 PM by Ves »

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
Sorry to double post, but I just reread this line from Freahk, and couldnt get my head around it:

Quote
but it is very effective to not have the button located in a place where there had not been an other button in the past.

Did you really mean that double negative sentence, so that empty space where there used to be empty space is what is very effective? Or the other way around, that a button in a place that used to be empty space is very effective? :o :P

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I changed it so that the withdraw button sticks to the right edge of the dialog, but it should be noted that the minimum width of this dialog's right part is 3 buttons. In that case there is only a small gap.
Sadly, the first mistake is that such a dangerous button was on the first (left). (´・ω・`)

Offline jamespetts

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19823
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Thank you - now incorporated.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
Just strike out one of the negations

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
If "withdraw all" is considered dangerous, wouldn't it be better to replace it with "retire all", which does not sell the vehicles, but sends them to depot? And/or to make it a switch - like on each vehicle, that will stop the action and return (remaining) convoys to normal operation?

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
Thank you Ranran  :D

Another thing I wondered if you would consider: Adding the distance to destination in the destination field. Combined with the "next stop" sort mode, this should make a very powerfull tool to be able to see the locations of ones convoys!

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
Another thing I wondered if you would consider: Adding the distance to destination in the destination field. Combined with the "next stop" sort mode, this should make a very powerfull tool to be able to see the locations of ones convoys!
Oh, I didn't think about doing multiple sorts. Can it be combined with reverse order?


I wanted to display such information in a dedicated GUI as explained earlier in this thread.
Second, I plan to implement something like the smartphone app commonly used in Jalapagos.

This is currently in progress as a separate patch. The screen is still in the mock-up stage.

It would be more convenient to add more information here.
This is useful for seeing the operation status of the line.
I sometimes check the freight line on the server from time to time, but it will be useful in such a case.
They are sometimes clogged in large numbers at the first station.
« Last Edit: June 13, 2020, 07:03:29 AM by Ranran »

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
I have understood Ves suggestion in a slightly different way: Don't show the distance in between stops in general but to show the distance to the next stop to each vehicle.
If that was the suggestion, I agree with it. Otherwise, I'm not sure about it.
In any case, the convoy location tab seems quite useful. It will immediately point out vehicles piling up somewhere :)

Does the yellow color of the arrows indicate vehicles waiting? It might be great to color-code driving for example in green, waiting for clearance for example in yellow and waiting at a stop (loading, waiting for schedule, waiting for load and so on) for example in blue.
Reversing might deserve a different arrow icon.

Offline Ranran

  • Devotee
  • *
  • Posts: 984
  • Languages: ja
I have understood Ves suggestion in a slightly different way: Don't show the distance in between stops in general but to show the distance to the next stop to each vehicle.
I knew it. It is displayed in the convoy information. The issue is that it represents proximity but may not be in the same position. There is a difference between going from A to B and going from C to B.


Does the yellow color of the arrows indicate vehicles waiting? It might be great to color-code driving for example in green, waiting for clearance for example in yellow and waiting at a stop (loading, waiting for schedule, waiting for load and so on) for example in blue.
Reversing might deserve a different arrow icon.
At first I tried to make the arrow so that it was in both directions, but when it overlapped on one block, the display was confused.
Also, it did not reflect the exact position.
Yellow was loading at the station, stack was orange, no route was red and out of service was gray, but that work was lost by accident and needs to be redesigned.
But it was a view-only UI. (´・ω・`)

I would like to make a UI that opens the vehicle info when clicked it.

Offline Freahk

  • Devotee
  • *
  • Posts: 1055
  • Languages: DE, EN
There is a difference between going from A to B and going from C to B.
Obviously there is a difference.
I'd assume A train moving from A to B to be in between A and B, ordered according to its distance to B and trains from C to B to be in between B and C, again ordered according to its distance to C, but showing the distance to A.
vehicles from B to A would be in the same location as A to B, again ordered by their distance to B, but showing their distance to A and using an arrow pointing upwards instead of downwards to make the direction clear.

Offline Vladki

  • Devotee
  • *
  • Posts: 3328
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
In any case, the convoy location tab seems quite useful. It will immediately point out vehicles piling up somewhere

Yes that would be useful.

Offline Ves

  • Devotee
  • *
  • Posts: 1793
  • Languages: EN, SV, DK
Wow, that convoy location tab looks awesome as well!

Yes Freahk was correct in his interpretation.
The comvoy location tab is perhaps just a mockup, but perhaps the distance to target can be displayed there?