Incorporating changes from Standard

[Ranran]

I have this on my merge-from-standard-8434 branch. I appreciate that this is now a little behind Ranran's work, but it is better, I think, to stabilise this and get it working before moving forward to incorporate later changes, unless doing so is likely to fix problems in this version.

r8434 branch is intended as a branch to check if there are any problems with basic game operation because the library and character processing will change as you have struggled so far.
If possible, bring the r8192 branch into the master branch first and check if there is any problem with the operation before this. It makes it easier to find the location of the problem.

This is likely to require extensive testing. It would very much help to have a list summarising the areas where there are expected to be major differences so that I can test those specifically. One problem that I notice immediately is that the file names in the load dialogue are not clickable: I can only load games by typing file names manually.

This is one of the reasons I thought this branch should be used for operational testing instead of being built into the master branch.
Fixing this at this stage can be a lot of work. At least I'm not familiar with the code.
This issue is fixed in GUI over haul. Because this is due to the big difference between the extended and standard code.
That dialog is now formed by Bernd Gabriel's table code. It's old code, so it doesn't correspond to the theme. I couldn't handle the code well because of the change in the character passing process.
A table code was added to Standard in the GUI overhaul. Therefore, the table code is replaced with the standard code. Therefore, the functionality of that dialog has been repaired in later branches.
Originally the load add on function was broken, but by aligning the code with the standard, this function is also available. Thus it also improves maintainability, so I thought the effort of maintaining and maintaining Bernd Gabriel's table code was very wasteful. The standard took over a year to upgrade from 120.3 to 121.0. But we don't have to spend that time. We can shorten the time between the r8434 patch and the r8653 patch. In other words, we can skip it.
At least it's hard for me to fix it (in this version), so I need help if it has to be repaired.

This is likely to require extensive testing. It would very much help to have a list summarising the areas where there are expected to be major differences so that I can test those specifically.

I understand that it will be a long-term testing. The GUI overhaul patch modifies almost every dialog, so you need to check almost every dialog. I was planning to create a list, but the incorporating work itself is not finished yet. It's progressing little by little. Maybe there are still conflicting issues that I can't solve.
Some bugs may only be resolved by incorporating a lot from the standard. Such a loop is repeated...

EDIT:
The second reason why it's hard to get the r8434 patch into the master quality is that we have to adjust the GUI to look good at any font size.
The GUI overhaul patch(r8653) automatically adjusts the layout, minimizing that effort.
As mentioned above, we don't have to stay long in the r8434(120.3 to 121.0) patch, unlike standard. So I don't think a lot of effort is worth the effort for this version.
Thus I think this version is a preparatory patch to see if important changes are working and to test in parallel with the next version.
We may be able to avoid the second problem by making it impossible to change the font size, but the first problem needs to be resolved.

The big change in r8434 is that, as you know, the changes required for the build have changed (freetype and minupnpc). It now uses true type fonts and now supports unicode.
The theme is officially available. I don't know if the system that automatically builds and provides themes from source is built with extended.
You can select the theme and font size from the desplay setting.

EDIT2:
After the GUI overhaul(r8653), the GUI engine is almost the current version of standard, so new and recent commits may fix bugs. In fact, there were many bugs that I was having trouble fixing, but I solved them by aligning some of them with the latest standard code as much as possible.
I knew it would crash at startup due to the theme, and I finally got rid of them by making it almost the same as the standard's latest version. Therefore, it is up to date.

[prissi]

You can get larger font without freetype, just use a bigger BDF fonts. So there is no absolute requirement to ship with freetype.

[Ranran]

https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r8434-2
The problem of not being able to build on Linux may have been resolved.

also because an #ifndef NETTOOL is missing somewhere (nettool does not need to include simsys.h IIRC)

I'm not sure about this issue... (´・ω・｀)

[ceeac]

Try the attached patch for the std-r8434-2 branch. Nettool does not need zlib so the CMake target does not include zllib as a dependency, which caused issues when including simsys.h.

[Ranran]

Thank you for that. Both the std-r8434-2 branch and the std-r8653-2 branch now work correctly. 

[jamespetts]

Thank you both very much for your work on this (Ranran and Ceeac): this is very helpful. I have now incorporated the changes on the 8434-2 branch and tested it both with Visual Studio and the Bridgewater-Brunel build environment, and it works on both, including cross-compiling on the Bridgewater-Brunel build server.

The next step is to test the later versions as recommended.

[jamespetts]

I have now successfully merged 8653-2 and confirmed that I can build this both in Visual Studio and cross-compiled on the Bridgewater-Brunel build server. I can also confirm that the load dialogue issue has been resolved.

First of all, I should note that this GUI overhaul is a great improvement: I am very grateful to Ranran for all the work that has clearly gone into merging this; I should also acknowledge all the work of the Standard developers who worked hard to make this UI a reality in the first place. The dialogues are better looking and easier to use.

I will now deal with my testing results and a list of issues that need to be at least considered and probably resolved. These are in no particular order save perhaps the order in which I think of them.

* In Pak128.Britain-Ex, the query tool cursor shading colour has changed to red instead of the specified yellow. In fact, I think that this red colour seems to override all the pakset specified colours for the cursor shading for the query tool.
* The display settings dialogue needs some new translation texts (I anticipate that Ranran is already aware of this).
* The display settings dialogue needs to be wider by default to fit in all the tabs fully without horizontal scrolling.
* In the display settings dialogue, there appears to be an errant number next to the "show station names" setting (or is this intended? If so, this should be explained in the tooltip)
* The players dialogue does not update properly when creating a new player, requiring players to quit the dialogue and re-open it to edit a newly created player (and similarly with a player that has been taken over).
* In the Simutrans New theme, the loading bar colour has reverted to the Simutrans-Standard bright blue rather than the subtler shade preferred for Simutrans-Extended
* The TrueType fonts are generally not very readable, seeming not to scale well (but this may equally be an issue in Standard; this is not a priority, since the .bdf and .fnt fonts work without trouble).
* In the station information dialogue, there seems to be an overlap between the right arrow button for the sort combination box and the departure board button.
* In the convoy information dialogue, the tab named "freight" should be renamed to "payload", since "freight" implies that passengers and mail are not included, whereas this is not the case.
* Attempting to use the scroll wheel in the list of sort options in the convoy information dialogue scrolls the main dialogue rather than the list of sort options.
* In the "modern" theme, the yellow colour of the "transported" option in the convoy information graph is almost invisible against the white background.
* The text in buttons and the editable convoy name in the convoy information dialogue seem not to be centred vertically in their respective buttons/field, being slightly closer to the top than the bottom.
* Clicking on a location arrow in the times history dialogue sometimes needs to be repeated for the viewport to move to the intended location even though the button is highlighted indicating that the GUI has received this command.
* In the "modern" theme, the text in the buttons in the minimap window is too large for the buttons and cannot be shown in full. In the "Simutrans New" theme, it is shown in full, but is not quite centred in the buttons and overlaps the top and left edges slightly.
* In the minimap window, the the filter list for companies seems to be out of line (higher) than the other filter lists.
* In the minimap window, the text in the filter lists appears not to be centred, but rather slightly too high and slightly too far left.
* In the stop list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left.
* In the vehicle list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left.
* In the vehicle list, in the "modern" theme, the button under "Show:" is too short for the text contained in it under some settings.
* In the city list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left.
* In the city list, the "by_region" sort text needs an English translation (I imagine that Ranran is already aware of this).
* In the city list, the horizontal space given to city names is insufficient and some longer names (e.g. "St. James Puddingcaster") are truncated.
* In the "modern" theme, the light yellow "mail" graph in the chart tab of the city list dialogue is almost invisible.
* In the goods list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left (with the PropLatin2 font - this is correct with Prop and M+10r).
* In the industry list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left (with the PropLatin2 font - this is correct with Prop and M+10r).
* In the attraction list, the text in the sort selector appears not to be centred, but rather slightly too high and slightly too far left (with the PropLatin2 font - this is correct with Prop and M+10r).
* In the play online dialogue, using the "modern" theme the "query server" button is too short and does not fit in all of the text, leading to this being truncated.
* In the "modern" theme, the yellow "transported" graph in the finance dialogue is almost invisible against the white background.
*  In the finance dialogue, the text in the "show finances for transport type" selector appears not to be centred, but rather slightly too high and slightly too far left (with the PropLatin2 font - this is correct with Prop and M+10r).
* The default size for the finance dialogue in the "modern" theme is too narrow to show all the buttons without truncating the text, although they do un-truncate when manually expanding the dialogue.
* In the finance dialogue, the "Build HQ" button is too short, leading to cramped text in the "Simutrans classic" and "Simutrans new" themes and truncated text in the "modern" theme.
* In the theme selector, the "OK" and "Cancel" text appear to be higher than centre in the buttons (with the PropLatin2 font - this is correct with Prop and M+10r).
* In the message centre, the "copy to clipboard" button is too short, leaving the text to overlap slightly the edge of this button.
* In the line management dialogue with the "modern" theme, the yellow transported graph is almost invisible against the white background.
* In the "change prices" dialogue in the "modern" theme, the contents of the dialogue overlap with the top edge of the dialogue onto the window bar

I notice that the "modern" theme is now the default. However, since there are a number of problems specific to the "modern" theme, the hardest of which to solve are likely to be the problems with the yellow graphs, I wonder whether we should revert to having the "Simutrans (new)" theme as the default?

Those are all the issues that I can find at present - I should be grateful if others could test to see whether any other issues can be identified.

Thank you again to all those who have contributed to this - this is a very significant advance for Simutrans-Exended.

[Ranran]

Thank you for testing it. First of all, I have to inform you of the progress. I will post the GUI issues pointed out in the GUI thread. Because almost all GUIs have changed and require a huge amount of checking.
Some of the thematic questions were answered in the theme thread.

Most GUIs will be overhauled with this patch. Some GUIs have not yet been overhauled with standard. That is, automatic alignment is not performed.
The GUI will work if you adapt some variables correctly without such automatic alignment. (Tab content may not be the new GUI engine)

GUI that is not automatically aligned by default:
- depot dialog
- schedule list

The depot dialog is not automatically aligned. Therefore, there is a big problem when increasing the font size in extended. The layout is very messed up and the fonts stick out of the dialog. Until now, large font sizes have not been considered, so a lot of information is packed in, and magic numbers are often used to set the size.

The contents of the convoy list in the schedule list have been adjusted and are in the process of being worked on.


Dialog that overhaul could not be merged due to some problem:
(1) schedule dialog(schedule_gui and line_management_gui) - Could not resolve conflicts related to control tower
(2) halt info - Could not resolve conflicts related to time schedule. This dialog is tabbed, and the time schedule must be separated into tabs. However, the extended time schedule code seems to be very different from standard.
(3) player list - Many buttons have been added such as company take over, access permission, but I couldn't handle them well with the new GUI engine. Therefore, the changes that were incorporated in halfway once were reverted once.

* The players dialogue does not update properly when creating a new player, requiring players to quit the dialogue and re-open it to edit a newly created player (and similarly with a player that has been taken over).

This error may have occurred because this dialog has not been updated.

These (1)-(3) will still work for the game, but can affect the incorporating from the standard.



These have not been updated to the new GUI engine but these are extended specific and are not a big issue:
- Times history
- Vehicle class manager
- Line class manager

I think these dialogs can be tabbed and integrated. At that time, I think it can be replaced with a new GUI engine.


GUI that has not been updated yet:
- Convoi detail - This dialog is now an extended specific dialog as it has been tabbed and gone in a GUI overhaul.
- halt detail - This is almost the same as above, but the update work is in progress with halt-detail-plus-v2 branch in parallel.
- Factory list - The lower list part has not been updated yet
- Factory info
- setting dialog (setting_stats) - This could have been very conflicting


Known bug:
(4) When rotate the map, the city center is in the wrong position. Therefore, if you open city info after rotating the camera, it will crash. I'm not sure how this is caused.
(5) loadsave dialog issue - I've converted Bernd Gabriel's table code to standard code, but there are some issues. I'm having trouble getting extended-specific information from a saved game. it means no pakset information is retrieved from the newly saved game. But it seems to be saved correctly. Because the current nightly build gets the correct pakset information from that save.
Also, the display contents and order are the same as standard, but in the extended specifications so far, it must be displayed in the order of date, pakset info, standard save version, extended save version.
In Bernd Gabriel's code this dialog was split into 6 cols, but in standard it is made up of 3 cols. So now the date and version texts are integrated and not aligned.
Since this table is shared with other dialogs, extending cols is a bit tricky and postponed. (Before that, we have to solve the problem that the above pakset information cannot be gotten.)
Some old code remains commented out for this issue.

- As mentioned above, the depot dialog has a big problem with changing the font size.


Known issue:
(6)   A new Vehicle list has been added, but as I posted in the list dialogs thread, it is not optimized for extended. Because I couldn't incorporate the standard commit for updating this dialog. This may have the same problem with incorporating standard commit, which adds sorting functionality to the depot dialog. Because standard has changed to use some of its features in the sort feature of the vehicle list with a new change.
I merged only the parts it needed, but which could cause a crash. The standard is static slist_tpl <vehicle_desc_t const *>, but extended has the difference of static slist_tpl <vehicle_desc_t *>, which may be relevant.
You can check it in the std-r8903-depotlist branch. The sort function of the vehiclelist has changed in that branch, but it crashes when sorting with many vehicles. If you narrow down and then sort, it will not crash. However, this change is not incorporated into the r8653-2 branch. This can be postponed.
Anyway, because of this, the vehicle list hasn't been optimized for extended.


Regarding (1)-(6), it may be difficult or time-consuming for me to solve. There have been many other weird bugs in the past, but many have been resolved by incorporating them from the standard. There was a lot of work to do, and I'm sorry, but these were especially difficult for me and have been left behind.
I would be grateful if someone could help me with those.

Regarding (4), I may not have merged the standard commits correctly, but the relevant code does not seem to differ from the standard at first glance. At the bottom of rotate90 was the code added for extended, but I'm not familiar with it.

[jamespetts]

Thank you for your work on this: this is most helpful. I have responded to the theme issues in the appropriate themes thread.

Of the above issues, nos. 1, 2 and 3, it seems to me, are issues that need not delay the integration of this improved code into the master branch of Extended, and can be done later, although it would be lovely for these to be fully integrated one day.

Issue 4 is a critical issue and this branch cannot be integrated without this being solved.

Issue 5 is of moderate importance; we should at least be able to sort files by Extended version as well as Standard version, but the game is usable without this; it would be good to have this resolved before integrating, but not essential.

Issue 6 is perhaps a longer-term project and should not impact on integrating this good work in the shorter term. Perhaps some thought should be given to integrating this into the proposed vehicle manager?

Overall, the priority with this work is to update the Extended codebase to be compatible with the latest major changes in Standard so as (1) to bring the benefits of the Standard improvements to players of Extended; and (2) for development work on Extended not to create additional conflicts with newer Standard code. The second is what makes this work a higher priority, but this applies less to areas where the codebase between Standard and Extended is so different that the improvements to the equivalent area in Standard are mostly or wholly inapplicable to Extended. Thus, once we have reached the stage of merging the main UI system changes and changes to the main dialogues, and once the critical bugs have been fixed, we can merge this into the master branch and continue with development work on that branch.

Therefore, the priority at this stage is issue 4. Can I ask first of all for you to clarify what you mean by the city centre: do you mean the townhall road tile or something else?

[Ranran]

Therefore, the priority at this stage is issue 4. Can I ask first of all for you to clarify what you mean by the city centre: do you mean the townhall road tile or something else?

Code Select Expand

koord3d city_info_t::get_weltpos(bool)
{
return welt->lookup_kartenboden( city->get_center() )->get_pos();
}
I think it is the position to display in "view" at the top right of the dialog. Maybe it got an error trying to display the view. The city list doesn't crash, but after rotating the camera, clicking the pos button jumps to strange coordinates.

[jamespetts]

Thank you for that: that is most helpful. I believe that I have now fixed this; I should be grateful if you could re-test.

[Ranran]

Thank you for your feedback on the GUI. I would like to clean up the issues as much as possible before creating a thread about GUI changes.
Number them in the order they are pointed out.

#1, 6, 11, 14, 23, 27, 28, 30, 34, 35
These are about themes and I posted them in another thread. I think it has already been fixed.

#5 may be due to players dialog being an old GUI engine as described above.

#3

* The display settings dialogue needs to be wider by default to fit in all the tabs fully without horizontal scrolling.

I suggest merging the transparencies tab into other tabs. What do you think about integrating that tab with map view tab?

#4

* In the display settings dialogue, there appears to be an errant number next to the "show station names" setting (or is this intended? If so, this should be explained in the tooltip)

This came from the standard, but it's also fixed because it was fixed in the standard latest commit.

#8

* In the station information dialogue, there seems to be an overlap between the right arrow button for the sort combination box and the departure board button.

(1) The station information dialog has not been changed to the new GUI engine as already explained.
(2) It seems that this button arrangement is done by a GUI code written by Bernd Gabriel called floating_cursor_t, which seems to conflict with the theme and variable font size.
This code is used only by halt info, and I think you will not need this code when you replace this dialog with a new GUI engine.

This issue is expected to be resolved when this dialog is changed to the new GUI engine.


#10

* Attempting to use the scroll wheel in the list of sort options in the convoy information dialogue scrolls the main dialogue rather than the list of sort options.

I don't think I've changed the functionality associated with this, so I suspect this is due to the standard code.
In Extended, there are some places where such a sort switch combo box is arranged in the tab, but in standard, the button that switches each time it is pressed is used, so I think that the same situation can not be reproduced in standard.


#13

* Clicking on a location arrow in the times history dialogue sometimes needs to be repeated for the viewport to move to the intended location even though the button is highlighted indicating that the GUI has received this command.

I couldn't understand what you pointed out. Could you explain in detail?


#19

* In the vehicle list, in the "modern" theme, the button under "Show:" is too short for the text contained in it under some settings.

Changes to the vehicle list have been postponed due to the issue reported in (6) of the "known issue". In another branch it has been replaced by a combo box. However, it has not been merged due to a crash issue.



#15, 16, 17, 18, 20, 24, 25, 26, 29 - Issues with selector lists:
This was a bug where the size was changed after selecting the selector. I think I fixed it.



#31, #33

* In the finance dialogue, the "Build HQ" button is too short, leading to cramped text in the "Simutrans classic" and "Simutrans new" themes and truncated text in the "modern" theme.

* In the message centre, the "copy to clipboard" button is too short, leaving the text to overlap slightly the edge of this button.

I think I have fixed these.


#12, 32

* The text in buttons and the editable convoy name in the convoy information dialogue seem not to be centred vertically in their respective buttons/field, being slightly closer to the top than the bottom.

* In the theme selector, the "OK" and "Cancel" text appear to be higher than centre in the buttons (with the PropLatin2 font - this is correct with Prop and M+10r).

(1) Some fonts appear to be closer to top overall due to letters like the English lowercase "p" and "y". This also applies to standard. It may be noticeable with certain fonts and sizes. For example, Yu Mincho's 14pt.

(this image is in standard)

(2) In Extended, the button texts moves down 1px while the button is pressed. This looks just right in a theme where the buttons are drawn three-dimensionally. However, as far as standard is compared, extended does not mean that the text is displayed 1px above. It just moves down 1px when button is pressed.


#22

* In the city list, the horizontal space given to city names is insufficient and some longer names (e.g. "St. James Puddingcaster") are truncated.

Unfortunately this doesn't seem to work as I intended. The name is omitted even though the next label has been moved to the right by the length of the city name.

I will try to find out how to solve this.


About translation:
#9

* In the convoy information dialogue, the tab named "freight" should be renamed to "payload", since "freight" implies that passengers and mail are not included, whereas this is not the case.

This is from the standard. (The tabs in this dialog were placed by GUI overhaul)
Extended has a similar term in convoy detail, so I replaced it with that translatable term(cd_payload_tab). This will reduce the work of the translator.
Please check if there is any problem with this reuse.

#2, 21
I think the translatable words that come from the standard need to be imported from the standard. For example, added list windows(vehicle list, depot list), themes and font selectors, etc.
Since the signal box list is an extended-specific dialog, we need to prepare new help text. (signalboxlist.txt)
I think the other terms need to be listed in a separate thread.


EDIT: I restored the previous post from the remaining draft.

[jamespetts]

My apologies - for some reason, I edited rather than replied to your post and I can no longer revert to the original; I have quoted much of the replies here. I will ask Isaac whether your original can be saved. My apologies.

Thank you for your work on this. Individual feedback follows.

#3

* The display settings dialogue needs to be wider by default to fit in all the tabs fully without horizontal scrolling.

I suggest merging the transparencies tab into other tabs. What do you think about integrating that tab with map view tab?

This does seem sensible, as "transparencies" is probably not a sufficiently important category to warrant its own tab in any event.

#4

* In the display settings dialogue, there appears to be an errant number next to the "show station names" setting (or is this intended? If so, this should be explained in the tooltip)

This came from the standard, but it's also fixed because it was fixed in the standard latest commit.

Confirmed fixed - thank you.

#8

* In the station information dialogue, there seems to be an overlap between the right arrow button for the sort combination box and the departure board button.

(1) The station information dialog has not been changed to the new GUI engine as already explained.
(2) It seems that this button arrangement is done by a GUI code written by Bernd Gabriel called floating_cursor_t, which seems to conflict with the theme and variable font size.
This code is used only by halt info, and I think you will not need this code when you replace this dialog with a new GUI engine.

This issue is expected to be resolved when this dialog is changed to the new GUI engine.

Thank you for clarifying: this is helpful. In relation to changing the dialogue to the new GUI engine, I notice that you have a branch for a later merge version, std-r8903-depotlist; is this related to the new GUI engine, or is that work yet to come? Indeed, ought I to be testing this std-r8903-depotlist branch?

#10

* Attempting to use the scroll wheel in the list of sort options in the convoy information dialogue scrolls the main dialogue rather than the list of sort options.

I don't think I've changed the functionality associated with this, so I suspect this is due to the standard code.
In Extended, there are some places where such a sort switch combo box is arranged in the tab, but in standard, the button that switches each time it is pressed is used, so I think that the same situation can not be reproduced in standard.

Noted; thank you for testing - I wonder whether we should raise this as a bug report with Standard?

#13

* Clicking on a location arrow in the times history dialogue sometimes needs to be repeated for the viewport to move to the intended location even though the button is highlighted indicating that the GUI has received this command.

I couldn't understand what you pointed out. Could you explain in detail?

The problem was that, when I clicked one of the buttons next to the station names in the "Times history" dialogue, it would not immediately take me to the station, but would sometimes only do so after two presses. However, I can no longer reproduce this with the latest version.

#19

* In the vehicle list, in the "modern" theme, the button under "Show:" is too short for the text contained in it under some settings.

Changes to the vehicle list have been postponed due to the issue reported in (6) of the "known issue". In another branch it has been replaced by a combo box. However, it has not been merged due to a crash issue.

Thank you for letting me know.

#15, 16, 17, 18, 20, 24, 25, 26, 29 - Issues with selector lists:
This was a bug where the size was changed after selecting the selector. I think I fixed it.

This now appears improved - thank you.

#31, #33

* In the finance dialogue, the "Build HQ" button is too short, leading to cramped text in the "Simutrans classic" and "Simutrans new" themes and truncated text in the "modern" theme.

* In the message centre, the "copy to clipboard" button is too short, leaving the text to overlap slightly the edge of this button.

I think I have fixed these.

Confirmed - thank you.

#12, 32

* The text in buttons and the editable convoy name in the convoy information dialogue seem not to be centred vertically in their respective buttons/field, being slightly closer to the top than the bottom.

* In the theme selector, the "OK" and "Cancel" text appear to be higher than centre in the buttons (with the PropLatin2 font - this is correct with Prop and M+10r).

(1) Some fonts appear to be closer to top overall due to letters like the English lowercase "p" and "y". This also applies to standard. It may be noticeable with certain fonts and sizes. For example, Yu Mincho's 14pt.

(this image is in standard)

(2) In Extended, the button texts moves down 1px while the button is pressed. This looks just right in a theme where the buttons are drawn three-dimensionally. However, as far as standard is compared, extended does not mean that the text is displayed 1px above. It just moves down 1px when button is pressed.
[/quoted]
Noted - thank you for clarifying.

#22

* In the city list, the horizontal space given to city names is insufficient and some longer names (e.g. "St. James Puddingcaster") are truncated.

Unfortunately this doesn't seem to work as I intended. The name is omitted even though the next label has been moved to the right by the length of the city name.

I will try to find out how to solve this.

That is helpful - thank you for looking into this.

About translation:
#9

* In the convoy information dialogue, the tab named "freight" should be renamed to "payload", since "freight" implies that passengers and mail are not included, whereas this is not the case.

This is from the standard. (The tabs in this dialog were placed by GUI overhaul)
Extended has a similar term in convoy detail, so I replaced it with that translatable term(cd_payload_tab). This will reduce the work of the translator.
Please check if there is any problem with this reuse.

This works better - thank you.

#2, 21
I think the translatable words that come from the standard need to be imported from the standard. For example, added list windows(vehicle list, depot list), themes and font selectors, etc.
Since the signal box list is an extended-specific dialog, we need to prepare new help text. (signalboxlist.txt)
I think the other terms need to be listed in a separate thread.

Yes, it would be helpful to have a thread gathering together all of the different things for which I need to produce English texts arising out of this work.



Additionally, I have modified the "modern" theme by using the Pak128.Britain-Ex coloured query tool cursor overlay. It is a real pity that this cannot be pakset specific.

I wonder whether we also need some other changes to the modern theme - the lower bar, for example, is currently quite a bright blue, which does not go well with the grey backgrounds to the buttons on the upper toolstrip. I wonder whether we might revert this to grey or alternatively use a paler (i.e. less saturated) blue?
Thank you again for your work on this - it is excellent and much appreciated.

[prissi]

Almost any theme specific thing could be overidden by a setting in the the pak simuconf.tab or a pak in the man pak folder. Otherwise, add the setting in question to simuconf.tab, and then it can override the default.

[Ranran]

This does seem sensible, as "transparencies" is probably not a sufficiently important category to warrant its own tab in any event.

I have integrated the tabs and made some layout adjustments.

#22

* In the city list, the horizontal space given to city names is insufficient and some longer names (e.g. "St. James Puddingcaster") are truncated.

Unfortunately this doesn't seem to work as I intended. The name is omitted even though the next label has been moved to the right by the length of the city name.

I will try to find out how to solve this.

I think this issue has been fixed.

Noted; thank you for testing - I wonder whether we should raise this as a bug report with Standard?

I'm not sure it's a standard bug, but if you have a combobox inside a tab, it looks like the tab always has the priority of mouse scrolling.

Is it related to the order of declarations? Any advice on this is helpful as I have no idea what the cause is.

I notice that you have a branch for a later merge version, std-r8903-depotlist; is this related to the new GUI engine, or is that work yet to come? Indeed, ought I to be testing this std-r8903-depotlist branch?

This branch is for the purpose of merging standard commit which related to the standard vehicle list and optimizing the vehicle list for extended (such as adding display contents) after doing so. During testing, I found that when I performed a sort with many vehicles displayed, it crashed. I don't see such a crash on the r8653 branch's vehicle list. The code of sort has changed in the standard commit. I think the cause is that it was incorporated. So it was left unmerged.
I've noticed a difference in the code for slist_tpl, but I'm not sure if that's the cause. Not a little the code associated with this seems to have diverged for quite some time and I didn't know how to solve it, so it's stuck.
If the cause of the crash is resolved, updating the vehicle list will be able to proceed.

How to reproduce the crash, open the vehicle list and click the button labeled "...". This is displayed as "...", but it is a button to switch the sort order. Pressing this will crash.
However, if you switch the tab to a tab with few vehicles like tram and then execute it, it will not crash. (´・ω・｀)

EDIT:

#15, 16, 17, 18, 20, 24, 25, 26, 29 - Issues with selector lists:
This was a bug where the size was changed after selecting the selector. I think I fixed it.

Apart from my fix, there is a bug in the selector display position that came from standard.
I reported it to the standard board.

[jamespetts]

Thank you very much for this. I am glad that Ranran was able to restore the original post, as Isaac tells me that pre-edited copies are not kept. My apologies again for the error with this.

First of all, I note that Prissi indicates that it is possible to override the cursor colour in the pakset's simuconf.tab, but I find that this is not the case: with any theme with the cursor colour specified, this overrides the pakset's simuconf.tab settings. Does the theme need to leave the cursor colour unspecified, or is this a divergence from Standard?

In respect of Ranran's latest changes, the new layout in the display settings dialogue seems to be an improvement: thank you for that. I notice that, at the default width in the "modern" theme, the right hand end of the sort passengers/freight by combobox goes off the end of the convoy information dialogue, which should probably be addressed.

Also (and this may well have been an issue before), I notice that, in the signal information dialogue in the "modern" theme the word "details" in the button to open the dialogue for the signalbox is not long enough so that the end of the word is obscured as in "Deta...".

In relation to the city lists, a long name is no longer cut off, which is definitely an improvement: thank you for this. However, a long name will cause the numbers, symbols, etc. to be out of line with all the others; I wonder whether it is possible for all of the numbers, symbols, etc. to align with the alignment of the city with the longest name so that they are all in a consistent position and one can read them like a table in a column as intended?

In respect of the combobox/tab issue, this would appear to be a bug in the Standard code - it may well be worth reporting this as a bug in Standard; I am doubtful that this is what is intended.

In relation to the crash - can I clarify on what branch that this is reproducible?

Thank you again for your work on this.
Edit: Incidentally, one thing that I notice with the "modern" theme is that, in the city list dialogue, the blue up arrows are almost invisible against the background colour. I wonder whether these blue arrows could be re-coloured so as to make them stand out more?

[Ranran]

I notice that, at the default width in the "modern" theme, the right hand end of the sort passengers/freight by combobox goes off the end of the convoy information dialogue, which should probably be addressed.

Thank you for pointing out. I think I've fixed this.

Also (and this may well have been an issue before), I notice that, in the signal information dialogue in the "modern" theme the word "details" in the button to open the dialogue for the signalbox is not long enough so that the end of the word is obscured as in "Deta...".

This dialog was the one that I noticed and fixed the issue this week. The auto-aligned GUI does not allow to hack areas of text to display overlapping buttons as before.
Therefore, I had to rewrite the code for that part. After that, the size of the button that accesses the signal box automatically increased, and could not place small button like before, so I changed the arrangement of the button and placed the letters "detail".
It was caused by not initializing the size, and I've fixed it.

In relation to the city lists, a long name is no longer cut off, which is definitely an improvement: thank you for this. However, a long name will cause the numbers, symbols, etc. to be out of line with all the others; I wonder whether it is possible for all of the numbers, symbols, etc. to align with the alignment of the city with the longest name so that they are all in a consistent position and one can read them like a table in a column as intended?

Yes, I'm aware of this issue, but it's a bit complicated.
The current automatic align system is aligned on a component-by-component basis. However, since one row of the sort table is a component, it is automatically aligned in the row.
In other words, different rows are actually different tables, and I specify the minimum width so that they are in the same position as much as possible.
I will try to get the maximum width of name and adjust the width.

In relation to the crash - can I clarify on what branch that this is reproducible?

It's the std-r8903-depotlist branch.
(EDIT:) This is a branch for moving the vehicle list from the standard to extended specifications, and incorporating more standard commits, and does not immediately affect game play.

Incidentally, one thing that I notice with the "modern" theme is that, in the city list dialogue, the blue up arrows are almost invisible against the background colour. I wonder whether these blue arrows could be re-coloured so as to make them stand out more?

Yes.

Extended specific theme parameters:

Code Select Expand


gui_color_up_pointing_triangle = #00F3DE
gui_color_down_pointing_triangle = #FF8200


The default is the above color. Add that line inside the tab file to change the color specification.
EDIT: Changed to green and red in the modern theme.

[Ranran]

A potential problem with depot and replace dialogs is too much information (lines).
In particular, the vehicle information text at the bottom will display multi-line text, which must have a dialog background below in advance.
Otherwise, this text will be off the depot/replace dialog. That is why the depot / replace dialog requires a larger vertical size as the font size increases. (The standard is 7 lines, but extended currently requires a great many lines.)
I updated the acceleration curve chart branch which to be checked the physics chart from the depot along with this issue, in this weekend.
It would be helpful if you could check this once for problems and solutions in the depot / replace dialog.

As a future plan, I think the convoy class manager can be put in the tab of the convoy detail dialog. But I don't know if the task is easy. (´・ω・｀)

EDIT:
One of the problems is that display_multiline_text_rgb doesn't have characters sticking out next to the dialog, but at the bottom the characters may overflow the dialog.
But that text is only visible when you hover over the vehicle panel. Therefore, it is not possible to add a scroll bar.

[jamespetts]

Thank you for this. I have successfully merged your changes and will test the improvements in due course. I have also reverted some of the initial dialogue box text to its Simutrans-Extended text (albeit within the framework of the new GUI system), as this had been reverted to the Standard text.

In relation to that opening dialogue, however, I have found a problem: if the opening dialogue is kept open long enough that the scrolling text runs out, the game will crash. This does not appear to happen on the current master branch. I wonder whether you might look into this? Thank you.

[Ranran]

if the opening dialogue is kept open long enough that the scrolling text runs out, the game will crash.

"scrolling text" is this, right? If so, I've been playing this for a while, but running out didn't reproduce the crash.

What I was curious about is that Japanese characters do not seem to be displayed correctly even in a Japanese environment like me. Is it possible that this is affecting other environments?

The button text will display Japanese correctly. However, Phystam and other people's Japanese characters in the scrolling text are garbled.
The character code may be incorrect.

EDIT:
https://github.com/aburch/simutrans/commit/495b76c6fc275c4b650509656995e1c553db5576
I tried to incorporate this commit, but I couldn't resolve the conflict because I couldn't type the umlaut... (´・ω・｀)

[jamespetts]

Yes, that is the text in question. I am not sure what the problem is with the Japanese characters, and I do not notice any problems with English characters - but the crash occurs right at the very end of the scrolling text.

[Ranran]

I also pushed a standard commit (r9000) that modifies .editconfig but I'm not sure if that affects it. the character code of load_frame.cc has also changed.


EDIT:
I confirmed that this garbled character does not occur in the master branch. I'm not sure what the cause is because garbled Japanese characters occur even with m+10r font in r8653 branch.

EDIT2:

Code Select Expand


if (scrolltext[text_line + row * 2 + 1] == NULL)
{
break;
}

When I compared the code of banner.cc with standard, I found the above code in extended. Is this related?
It seems that it was added by the following commit. According to the commit message, the purpose of the fix is the same.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/50f6758dc7a8037d34647e26204d66c038e21ae0

EDIT3:
Removing this seems to crash at the end of scrolling text. However, it seems that the crash cannot be reproduced in my environment when this is restored.

[jamespetts]

Thank you for that. I can still reproduce the crash with the latest version, with the above code in place. The crash occurs in a different part of the code than this, in utf8_decoder_t::has_next() in unicode.cc, called from line 4603 of simgraph16.cc.

Some other observations follow from the latest build.

1. In the advanced settings dialogue (shortcut key "i" in Pak128.Britain-Ex), in the "modern" theme, a number of the texts for the options in various tabs are truncated with the "modern" theme even though there is ample horizontal space in the dialogue.
2. In the advanced settings dialogue in the "modern theme", there is overlapping text in the comfort impact limitations table in the Extended tab.
3. The width of the "details" button in the signal information dialogue has been fixed successfully.
4. In the city list dialogue, the names of the regions are not aligned consistently (in demo.sve, for example, Melchester's region name is further to the left than all the others, seemingly because it does not have a symbol indicating that town growth is disabled).
5. The arrow colour for showing population growth is now better in the "modern" theme and is clearly visible.
6. The tooltips for the buttons in the city list chart do not work.
7. In the depot window, the "+1" number next to "Vehicles:" is too light to be easily visible in the "modern" theme.
8. In the replace window, there is overlapping text near "replace cycle" (tested both with the "modern" and "Simutrans new" themes).

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

[Ranran]

Thank you for that. I can still reproduce the crash with the latest version, with the above code in place. The crash occurs in a different part of the code than this, in utf8_decoder_t::has_next() in unicode.cc, called from line 4603 of simgraph16.cc.

I think the symptom is similar to the error when removing the code above. Will this change improve it?

gui\banner.cc

Code Select Expand

@@ -223,7 +223,7 @@ void banner_text_t::draw(scr_coord offset)
color = color_idx_to_rgb(colors[0]);
}

- if (scrolltext[text_line + row * 2 + 1] == NULL)
+ if (scrolltext[text_line + row * 2] == NULL || scrolltext[text_line + row * 2 + 1] == NULL)
{
break;
}




Thank you for your testing.

1. In the advanced settings dialogue (shortcut key "i" in Pak128.Britain-Ex), in the "modern" theme, a number of the texts for the options in various tabs are truncated with the "modern" theme even though there is ample horizontal space in the dialogue.

6. The tooltips for the buttons in the city list chart do not work.

I think I've fixed these.

7. In the depot window, the "+1" number next to "Vehicles:" is too light to be easily visible in the "modern" theme.

This color has been changed to the same color as the increase and decrease of cities.
What do you think about the color of the bar should be the same?

2. In the advanced settings dialogue in the "modern theme", there is overlapping text in the comfort impact limitations table in the Extended tab.

Apparently, due to the GUI overhaul, the automatic alignment by Bernd Gabriel's table code is disabled. The advanced setting dialog does not have the GUI overhaul merged due to this conflict. Therefore, first aid must be taken.
This seems to be a code conflict between the new GUI engine and Bernd Gabriel's code. I don't know how to fix it at the moment. It may be easier to switch this dialog to a new GUI engine, but I think it will take a lot of work to update this dialog.
Bernd Gabriel's table code is used only in the extended tab of the setting dialog. Switching the GUI engine makes it completely unnecessary. (gui_component_table)

8. In the replace window, there is overlapping text near "replace cycle" (tested both with the "modern" and "Simutrans new" themes).

What do you think about narrowing the width of the four buttons and moving the replacement cost to the current "Clear" location?

4. In the city list dialogue, the names of the regions are not aligned consistently (in demo.sve, for example, Melchester's region name is further to the left than all the others, seemingly because it does not have a symbol indicating that town growth is disabled).

Reduced alignment discrepancies by occupying space even when the symbol is not visible. I think it's better than before.

[jamespetts]

Excellent, thank you for this.

First of all, unfortunately, the crash fix did not work: I can still reproduce the crash with a 64-bit Visual Studio debug build. Although the symptoms are superficially similar to the earlier crash, I do not think that it is quite the same, since it crashes in a very different part of the code.

Secondly, the city list chart tooltips are fixed: thank you for this.

As to the advanced settings dialogue, the ultimate solution would indeed be to replace the old tables with the new tables from Standard but we need something in the meantime to stop the text from being scrambled, I think.

I see that the replace dialogue has been fixed - excellent. I would not encourage spending too much time doing more than fixing bugs with this dialogue, as the intention is for this system to be modified very heavily in due course.

As to the city list alignment, this is indeed much better: thank you.

The customisability of the +1 colour by theme is a great improvement, and the "modern" theme version of this works well - thank you for this. I agree that it would make sense for the colour bar to use this same customisable colour, as the correlation in colours between the two is an important visual clue to the relationship between these things.

[Ranran]

First of all, unfortunately, the crash fix did not work: I can still reproduce the crash with a 64-bit Visual Studio debug build. Although the symptoms are superficially similar to the earlier crash, I do not think that it is quite the same, since it crashes in a very different part of the code.

Your fix for the previous crash has also been fixed by adding code that is not in standard.
I suspect there is some difference between standard and extended. I also wonder if it only happens on 64bit builds as I can't reproduce the crash on 32bit debug builds.
However, on the other hand, it is odd that Japanese characters are garbled only in scroll text. Unfortunately I have no idea of these causes.

As to the advanced settings dialogue, the ultimate solution would indeed be to replace the old tables with the new tables from Standard but we need something in the meantime to stop the text from being scrambled, I think.

I think I succeeded in solving this by making the advanced setting dialog into a new GUI engine.

The customisability of the +1 colour by theme is a great improvement, and the "modern" theme version of this works well - thank you for this. I agree that it would make sense for the colour bar to use this same customisable colour, as the correlation in colours between the two is an important visual clue to the relationship between these things.

I integrated with those colors. But I wonder if it would be nice to be able to set the text and bar colors separately.
For example, in the modern theme, green is easier to read in dark colors, but bar's may be better in light green.

[jamespetts]

Splendid, thank you for that. The advanced settings dialogue is now much better in its layout: this is a great improvement. However, I notice anomalous behaviour when pressing the simuconf.tab and default.sve buttons. This had previously not been working, but the buttons had been disabled to prevent anomalous behaviour. I will leave it to your discretion as to whether it is worth fixing these buttons or whether it is preferable simply to disable them again.

As to the crash, I believe that I have now fixed this by amending scrolltext.h.
Edit: I have also merged the depotlist branch and compiled this successfully, but I cannot find the menu item for the depot list itself; does this require a pakset modification?

[Ranran]

However, I notice anomalous behaviour when pressing the simuconf.tab and default.sve buttons.

Those buttons reset the values to those files have, and it looks like it's working as far as I can see.
Could you elaborate on the anomalous behavior?

As to the crash, I believe that I have now fixed this by amending scrolltext.h.

Thank you very much. It is very helpful.

I have also merged the depotlist branch and compiled this successfully, but I cannot find the menu item for the depot list itself; does this require a pakset modification?

The branch is named depotlist, but it's intended to incorporate the depotlist and vehiclelist, and then incorporate the standard commits associated with them.
So those dialogs already exist in the r8653 branch. A branch to update them.
However, it has not been merged due to a crash in the Vehicle list in that branch.

A total of 3 list dialogs will be added.
These can be registered in the tool menu and also in the shortcut key.

Code Select Expand

dialog_tool[32]=,^D
dialog_tool[33]=,^V
dialog_tool[128]=,^S
Therefore, it is advisable to have icons for these lists.
Since the signalbox dialog tool is unique to extended, it is registered at number 128.

This just adds a shortcut key. We need to make those icons. It's a pakset job.

Code Select Expand

toolbar[12][7]=dialog_tool[32]
toolbar[12][8]=dialog_tool[33]
toolbar[12][9]=dialog_tool[128]

For the time being, I attach a substitute for the existing icon. You can test it.
The three buttons to the right of the marker list icon.

[jamespetts]

Thank you for your work on this. I have now had a chance to begin work on testing the new lists.

First, as to the crash in the vehicle list: it is difficult to track this down, as this occurs entirely in code with which I am wholly unfamiliar. However, it appears to be related to sorting. For me at least, the crash only occurs when switching from sorting "ascending" to sorting "descending", and is preceded by an assertion failure. The problem appears to be that std::sort is being passed an invalid parameter. However, I do not know what counts as a valid parameter for these purposes nor in what respect(s) the parameter that it is being passed is invalid.

However, the crash is not the only problem with the sorting. In demo.sve, observe that, when sorting by power in "ascending", all the unpowered vehicles like carriages and steam locomotive tenders will be at the bottom, not the top where they should be (having a power of zero). Observe also that, when sorting in demo.sve by "capacity" (ascending), the list will appear to be largely corrupted, for example, the Waterloo & City Line centre appearing near the top despite its having a passenger capacity of 52, and all the locomotives, which have no capacity at all, appear near (but not at) the bottom of the list.

It appears as though sorting is thoroughly broken, but what the cause of this is is very difficult to tell without having a full understanding of how the sorting code is intended to work, which is not readily ascertainable simply by looking at the code.

I also note that the word "ascending" is truncated in this list in the "modern" theme. I wonder whether we could replace the button with text with the up/down arrow buttons used in the depot/signalbox list?

As to the advanced settings dialogue, the behaviour that I see when pressing the "simuconf.tab" button in "general" is that, instead of changing the settings, all the settings options are repeated at the bottom of the dialogue box every time that the button is pressed. This behaviour also occurs with the "Default.sve" button.

In the depot list, the filter does not appear to work as one would expect: instead of, e.g., the air button when pressed showing only air depots, when pressed, this button hides all the air depots, and the same applies to all the other types. Thus, the "All" button is useless, as it will always simply make the list blank.

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

[Ranran]

First, as to the crash in the vehicle list: it is difficult to track this down, as this occurs entirely in code with which I am wholly unfamiliar.

It appears as though sorting is thoroughly broken, but what the cause of this is is very difficult to tell without having a full understanding of how the sorting code is intended to work, which is not readily ascertainable simply by looking at the code.

Standard has added a sort function to the depot dialog (r8569). The commit couldn't be incorporated because of the large difference between the standard and extended code and the difficulty of merging it.
After the vehicle list was added in standard(r8912), the sorting code was shared with the sorting code for that depotlist (r8922).
I merged a part of r8569 and tried to merge r8922. However, it seems that the code for standard and extended such as slist_tpl <vehicle_desc_t *> is different for a long time.
The build was successful, but there were problems such as the sort function crashing. That's the current state of the depotlist branch.

So the vehiclelist on the r8653-2 branch is in the previous state of r8922.

At least now the vehicle list is not a parameter display for extended. You can get information about the future by ignoring the config setting that shows the future.
Is it better to ignore those commits(r8922+) and optimize for extended in the state of the r8653-2 branch?

I also note that the word "ascending" is truncated in this list in the "modern" theme. I wonder whether we could replace the button with text with the up/down arrow buttons used in the depot/signalbox list?

Yes, I intended to do so but stopped working after finding the crash.

As to the advanced settings dialogue, the behaviour that I see when pressing the "simuconf.tab" button in "general" is that, instead of changing the settings, all the settings options are repeated at the bottom of the dialogue box every time that the button is pressed. This behaviour also occurs with the "Default.sve" button.

Thank you for clarifying. I found this to be a standard bug and reported it to the standard board.

In the depot list, the filter does not appear to work as one would expect: instead of, e.g., the air button when pressed showing only air depots, when pressed, this button hides all the air depots, and the same applies to all the other types. Thus, the "All" button is useless, as it will always simply make the list blank.

I think you think of pressed and unpressed in reverse.
All are pressed when the dialog is opened. What you press again will be released.
If you want to narrow down to only one, press All to cancel and then select the button.
Unlike tabs, this button allows you to select multiple buttons at the same time.
Certainly these behaviors can be a bit confusing.

[jamespetts]

Standard has added a sort function to the depot dialog (r8569). The commit couldn't be incorporated because of the large difference between the standard and extended code and the difficulty of merging it.
After the vehicle list was added in standard(r8912), the sorting code was shared with the sorting code for that depotlist (r8922).
I merged a part of r8569 and tried to merge r8922. However, it seems that the code for standard and extended such as slist_tpl <vehicle_desc_t *> is different for a long time.
The build was successful, but there were problems such as the sort function crashing. That's the current state of the depotlist branch.

I suspect that the ultimate cause of the problem is that vehicles have more (and in some cases different) parameters in Extended than Standard, so sorting algorithms that assume that vehicles have certain parameters may well fail where those parameters are different.

It is difficult to be more specific about this without a very lengthy exploration of the Standard code, but one possibility is that the code is passing pointers in a particular order (perhaps without preserving so far as the compiler is concerned information about type at compile time - is there any void* in the sorting code, I wonder?) and assuming that the values pointed to will be of a particular type whereas in fact this is not the case. If you or anyone else wish(es) to look into this issue, this hypothesis might well be a good place to start.

So the vehiclelist on the r8653-2 branch is in the previous state of r8922.

At least now the vehicle list is not a parameter display for extended. You can get information about the future by ignoring the config setting that shows the future.

I had not realised that the vehicle list was already integrated into the 8653-2 branch - this is interesting. I note that the ascending/descending button (and indeed, the "sorted by" button) have truncated text in the "modern" theme in this window, however. I also note that future vehicles seem to be shown in this list even when show_future_vehicle_information is not selected; is this intended?

Is it better to ignore those commits(r8922+) and optimize for extended in the state of the r8653-2 branch?

Yes, I intended to do so but stopped working after finding the crash.

If the only problem is the crash when changing from ascending to descending, then I wonder whether a better alternative would simply be to disable the ascending/descending sort selection until someone can find a solution to this, as this is perhaps not the most important feature. However, if there are crashes in other circumstances, then this may well not be ideal.

Thank you for clarifying. I found this to be a standard bug and reported it to the standard board.

Interesting - thank you for noting this.

I think you think of pressed and unpressed in reverse.
All are pressed when the dialog is opened. What you press again will be released.
If you want to narrow down to only one, press All to cancel and then select the button.
Unlike tabs, this button allows you to select multiple buttons at the same time.
Certainly these behaviors can be a bit confusing.

Interesting - this seems to be an artefact of the "modern" theme. In that theme, the unpressed buttons are dark in colour whereas, pressed, they are light. In Simutrans New, the opposite is the case. In Simutrans Classic, the buttons are 3d shaded and it is clear.  However, in flat, modern and aero, the buttons all appear lighter when not pressed, and have no clear shading to indicate a depressed status, so this is somewhat confusing, as this is contrary to common design language in which a lighter shade indicates that the buttons are pressed.

I am not sure, however, whether anything can be done about this without a major redesign of these buttons given that the behaviour is opposite depending on the theme, and it is probably not worth a major redesign just for this.

[Ranran]

I had not realised that the vehicle list was already integrated into the 8653-2 branch - this is interesting. I note that the ascending/descending button (and indeed, the "sorted by" button) have truncated text in the "modern" theme in this window, however. I also note that future vehicles seem to be shown in this list even when show_future_vehicle_information is not selected; is this intended?

As mentioned above, the vehicle list on the r8653-2 branch was just a merge of the standards and no changes were made.

If the only problem is the crash when changing from ascending to descending, then I wonder whether a better alternative would simply be to disable the ascending/descending sort selection until someone can find a solution to this, as this is perhaps not the most important feature. However, if there are crashes in other circumstances, then this may well not be ideal.

Last week, I tried ignoring the commit r8922 and incorporating other commits, which seems to have worked. (And the vehicle list has undergone some changes.)
Extended doesn't yet have a sort feature in the depot dialog, so I don't think there is any benefit to merge this commit at this time.

I suspect that the ultimate cause of the problem is that vehicles have more (and in some cases different) parameters in Extended than Standard, so sorting algorithms that assume that vehicles have certain parameters may well fail where those parameters are different.

It is difficult to be more specific about this without a very lengthy exploration of the Standard code, but one possibility is that the code is passing pointers in a particular order (perhaps without preserving so far as the compiler is concerned information about type at compile time - is there any void* in the sorting code, I wonder?) and assuming that the values pointed to will be of a particular type whereas in fact this is not the case. If you or anyone else wish(es) to look into this issue, this hypothesis might well be a good place to start.

So if someone who interested in adding sort functionality to the depot window, there are many challenges as mentioned above. In addition to that, keep this in mind when merging.

As to the advanced settings dialogue, the behaviour that I see when pressing the "simuconf.tab" button in "general" is that, instead of changing the settings, all the settings options are repeated at the bottom of the dialogue box every time that the button is pressed. This behaviour also occurs with the "Default.sve" button.

I think this issue has been fixed.

* The players dialogue does not update properly when creating a new player, requiring players to quit the dialogue and re-open it to edit a newly created player (and similarly with a player that has been taken over).

The code in this dialog is still the old GUI code, and I compared the diffs, but nothing changed except the variable correspondence. So I'm not sure why this symptom is occurring.

Interesting - this seems to be an artefact of the "modern" theme. In that theme, the unpressed buttons are dark in colour whereas, pressed, they are light. In Simutrans New, the opposite is the case. In Simutrans Classic, the buttons are 3d shaded and it is clear.  However, in flat, modern and aero, the buttons all appear lighter when not pressed, and have no clear shading to indicate a depressed status, so this is somewhat confusing, as this is contrary to common design language in which a lighter shade indicates that the buttons are pressed.

I am not sure, however, whether anything can be done about this without a major redesign of these buttons given that the behaviour is opposite depending on the theme, and it is probably not worth a major redesign just for this.

Yes, as you pointed out, I think it's a design issue. Web and application design will be a good comparison. If the button that is not pressed already has a color(not plain), the darkening pressed button is not intuitive and unclear whether it is disabled or selected.
No problem if the presence of pressed (selected) is limited to only one, but it becomes difficult to distinguish when multiple simultaneous selections are possible. Especially when all are pressed as in that example.
These examples are typically brighter or complementary colors, as you pointed out.

in flat, modern and aero,

aero theme
I changed the color of the pressed button. This may have been the original color. Consistent with checkboxes and scrollbars.

flat theme
This issue has been pointed out in another thread. It's not my job.

modern theme
Colors that are too bright are not suitable because the text color of the pressed button is used in common with the colored button (that is, white for the modern theme).
I made an experimental work using complementary colors and attach to this post. Please try to test it.

I don't know in detail what the difference between roundbutton and button is.
However, the two have different image definitions, and I replaced the pressed roundbutton image.


EDIT:

* Attempting to use the scroll wheel in the list of sort options in the convoy information dialogue scrolls the main dialogue rather than the list of sort options.

This issue has been fixed by the standard developer.
However, if it is placed in a narrow tab, it may open upwards, which will break its display. I've tried adjusting the size, but it's not working at the moment... (´・ω・｀)

[prissi]

Button can be colored. Roundbutton not.

Also as stated in the dat files:

Code Select Expand


...
Image[35]=> button.3.7
# If the position of the colored area is different for a pressed button (i.e. protruding knobs)
# then here can come another nine mask images


[jamespetts]

Excellent, thank you very much for your work on this. That is most helpful.

As mentioned above, the vehicle list on the r8653-2 branch was just a merge of the standards and no changes were made.

Last week, I tried ignoring the commit r8922 and incorporating other commits, which seems to have worked. (And the vehicle list has undergone some changes.)

Excellent - this has worked well. I confirm that this now no longer crashes. Thank you for this.

Extended doesn't yet have a sort feature in the depot dialog, so I don't think there is any benefit to merge this commit at this time.

So if someone who interested in adding sort functionality to the depot window, there are many challenges as mentioned above. In addition to that, keep this in mind when merging.

Noted - this is not a high priority at present, but it is useful to have a record of this issue.

I think this issue has been fixed.

Excellent - thank you for this. This does indeed appear to work (although it also seems to override some theme settings, e.g., the title bar colour in the "modern" theme reverts to the orange of new/classic; is that intended?)

The code in this dialog is still the old GUI code, and I compared the diffs, but nothing changed except the variable correspondence. So I'm not sure why this symptom is occurring.

Oddly, I can no longer reproduce this.

Yes, as you pointed out, I think it's a design issue. Web and application design will be a good comparison. If the button that is not pressed already has a color(not plain), the darkening pressed button is not intuitive and unclear whether it is disabled or selected.
No problem if the presence of pressed (selected) is limited to only one, but it becomes difficult to distinguish when multiple simultaneous selections are possible. Especially when all are pressed as in that example.
These examples are typically brighter or complementary colors, as you pointed out.
aero theme
I changed the color of the pressed button. This may have been the original color. Consistent with checkboxes and scrollbars.

flat theme
This issue has been pointed out in another thread. It's not my job.

modern theme
Colors that are too bright are not suitable because the text color of the pressed button is used in common with the colored button (that is, white for the modern theme).
I made an experimental work using complementary colors and attach to this post. Please try to test it.

Thank you for this: that is helpful. I understand that you are not responsible for all the themes, so there is only so far that we can go with these; we will have to decide in due course on what is the most suitable default theme.

I have tested your changes to the modern theme; I am afraid that I do not think that the orange colour works well with this theme, and it is probably better to leave it as it is in respect of colour.

EDIT:This issue has been fixed by the standard developer.
However, if it is placed in a narrow tab, it may open upwards, which will break its display. I've tried adjusting the size, but it's not working at the moment... (´・ω・｀)

Thank you for incorporating this: this is helpful.

One other thing that I have noticed with the latest version of the code is that, in the stop information dialogue, in the "modern" theme, the right hand horizontal scroll arrow for the sort passengers/freight by combobox overlaps with the departure board button, and, in the "Simutrans new", "Simutrans classic" and "flat" themes, the "departure board" button has very little padding to the left such that the "D" almost touches the left edge of the dialogue box. In the "aero" theme, the "Departure board" button is truncated in text ("Departure boa...") and there is also an overlap of the arrows. I am not sure of the extent to which these issues are theme specific, but, given that there is an issue of some sort in all the themes, I wonder whether there is some more general horizontal spacing issues that needs to be addressed here?

More generally, may I ask whether you were intending as part of this project to merge the changes to Standard that incorporated zstd compression for saved games? I ask because zstd compression is likely to make a major difference to the performance of larger saved games (especially in multi-player games, where saving occurs more regularly), and it would help me to know whether it is best to wait for you to continue the planned work on Standard integration or whether I need to be looking into backporting this feature independently of your work.

[Ranran]

Changes from recently added standards:
The estimate cost is now displayed when creating a tunnel. This is useful because you know where you can build the (straight) tunnel.
However, the calculation is different from standard and is currently incorrect.
It seems that it is not just the sum of the total amount of the tunnel and the way. I would be grateful if you could help me with this.

I have tested your changes to the modern theme; I am afraid that I do not think that the orange colour works well with this theme, and it is probably better to leave it as it is in respect of colour.

Considering the existence of color buttons such as profit, white may be desirable for general buttons. (It turns light blue when pressed.)

One other thing that I have noticed with the latest version of the code is that, in the stop information dialogue, in the "modern" theme, the right hand horizontal scroll arrow for the sort passengers/freight by combobox overlaps with the departure board button, and, in the "Simutrans new", "Simutrans classic" and "flat" themes, the "departure board" button has very little padding to the left such that the "D" almost touches the left edge of the dialogue box. In the "aero" theme, the "Departure board" button is truncated in text ("Departure boa...") and there is also an overlap of the arrows. I am not sure of the extent to which these issues are theme specific, but, given that there is an issue of some sort in all the themes, I wonder whether there is some more general horizontal spacing issues that needs to be addressed here?

This I explained before. This dialog hasn't been updated yet, and its overlap is caused by a special code created by Bernd Gabriel.
The update for this dialog didn't fit the tab well because I'm not familiar with the timetable code.
I pushed the branch I tried to merge. Can you confirm this? I'm stumbling on the control tower process.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-haltinfo

After it works properly, I need to adjust the dialog to the extended spec.

More generally, may I ask whether you were intending as part of this project to merge the changes to Standard that incorporated zstd compression for saved games? I ask because zstd compression is likely to make a major difference to the performance of larger saved games (especially in multi-player games, where saving occurs more regularly), and it would help me to know whether it is best to wait for you to continue the planned work on Standard integration or whether I need to be looking into backporting this feature independently of your work.

I've broadly grouped commits by feature to get a rough view, and I probably know the commits about it. But it may not be an easy task, so I skipped it. I'm working a little now.