Incorporating changes from Standard

[Ranran]

I have broken down the merge from the standard branch into multiple parts. I think the basic behavior has already been checked in the previous compiled patch.
Incorporate them in order and check the behivior especially in the network game.
If a problem occurs, it will be easier to identify than before. Also some suspicious commits have been skipped. It may be checked at the end. Or it is left to someone who is familiar with it.

It is divided according to the content to some extent. The following branches are currently completed: Please incorporate them in numerical order.


Pull request #402 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r9637
The main focus is on minor GUI modifications such as adjusting the font color of the theme. The revision number is incremented to 41.

Pull request #405 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r9650
The focus is on standard's changes up to r9713. There is no change to gameplay other than the convoy list supporting saving.

Pull request #407 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commits/std-r9714-new-sort-button
Changes centered around the new sort button. The corresponding GUI such as the list dialog is updated.

Pull request #410 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commits/std-r9757
Standard code changes and GUI minor modifications.

Pull request #411 
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r9796-toolbar-position
The focus is on changes related to standard's toolbar position patch.
The revision number is incremented to 42.

Pull request #412 
std-r9808-
The list dialog is saved. A text search is added to some list dialogs.

Pull request #414   
std-r9851
Commits from r9851 to r9918. This is the last of this series of patches. It has progressed to July 2021.


These branches are not completely contiguous, so merging only the last branch will result in missing commits. You need to merge them one by one in order.
The rest will be added as soon as they are ready for merging.

[freddyhayward]

I have now done a little further testing and incorporated this into the master branch - this will be available from to-morrow's nightly build.

What sorts of testing did you conduct? I was busy that week and didn't have time to test it.

[Ranran]

I made a pull request (#410) for next incorporating from standard branch, but to make it easier to figure out what's wrong, do it only after the server is stable. On the other hand, PR#409 can be an important fix.

[jamespetts]

Thank you for this. I have incorporated both pull requests - I suspect that the server stability issues are unrelated to this, but related to a matter reported elsewhere.

[Ranran]

Pull request #416 subdivides the bloated simvehicle.
However, the separation of vehicle_base_t (r9450) has postponed because it was not easy for me because of the difference from standard... (´・ω・｀)

[jamespetts]

Pull request #416 subdivides the bloated simvehicle.
However, the separation of vehicle_base_t (r9450) has postponed because it was not easy for me because of the difference from standard... (´・ω・｀)

Thank you for your work on this. Can I check before I merge this whether this causes any major compatibility problems with the vehicle-management-new branch? Such a major refactor could be problematic in this respect. Although I have not had a chance to work on this branch in quite some time, this is still something that needs to be done at some point.

[Ranran]

Can I check before I merge this whether this causes any major compatibility problems with the vehicle-management-new branch?

I think it probably matches the content of this thread,
from there earlier this year there is my branch with many modifications to the schedule UI.
I don't think this branch will cause any major problems as it has been successful in resolving conflicts with master until it recently had problems major merging from standards. (At least until the end of May. )
But since redo the merging, I need to check it again from there.

The r9450 branch just moved the contents of the simvehicle.cc/.h by way type. Therefore, the contents of the function have not changed.

EDIT:
When the separation was complete, I modified some formats compared to the standard code. (This is intended to reduce the possibility of conflicts when merging from standards.) But I don't think that will affect the merging of 15.0 branches so much. Probably the conflicts that occur are equivalent for all previous commits.

[jamespetts]

Thank you for your reply. The concern is not so much whether the function has changed but, if things that have been altered significantly in the 15.x branches have been broken up into different files, automatic merging will fail, and there will be an extremely large amount of very difficult work involved in manually re-merging all of the changes. Can I check whether you have tested merging in the vehicle-management-new branch to see whether this can be done without much difficulty?

[Ranran]

https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/ex15-dismantled-simvehicle
I succeeded in merging the dismantled simvehicle branch to the 15.x branch that I was updating the GUI.
The difference between them was small.

[jamespetts]

https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/ex15-dismantled-simvehicle
I succeeded in merging the dismantled simvehicle branch to the 15.x branch that I was updating the GUI.
The difference between them was small.

Thank you for this: this is most helpful.

I have pulled these changes into a testing branch, which I have pushed, using your branch name of std-r9450-tidyup-simvehicle. However, unfortunately, testing shows a problem with this: a client cannot stay in sync with a network server. I have tested this by launching two instances of this build, one running the current game from the Bridgewater-Brunel server (January 1785) and the other connecting to it as a client using the loopback interface (127.0.0.1). The client loses synchronisation immediately upon connexion to the server.

[Ranran]

I have pulled these changes into a testing branch, which I have pushed, using your branch name of std-r9450-tidyup-simvehicle. However, unfortunately, testing shows a problem with this: a client cannot stay in sync with a network server. I have tested this by launching two instances of this build, one running the current game from the Bridgewater-Brunel server (January 1785) and the other connecting to it as a client using the loopback interface (127.0.0.1). The client loses synchronisation immediately upon connexion to the server.

Thank you for confirmation.
Could you check if it happens even if revert the commit cf15286ac7cc52ef4ec10efca53433e0a8fa7dc8?
I suspect that the checklist_t separation is most related to desync. This has nothing to do with dismantling the simvehicle, but it's in the same branch.

[jamespetts]

Thank you for confirmation.
Could you check if it happens even if revert the commit cf15286ac7cc52ef4ec10efca53433e0a8fa7dc8?
I suspect that the checklist_t separation is most related to desync. This has nothing to do with dismantling the simvehicle, but it's in the same branch.

Thank you for this. May I ask whether there is a particular pull request to which this relates? I see that you have issued quite a number recently.

[Ranran]

May I ask whether there is a particular pull request to which this relates?

No, there are no pull requests related to this. But at my branch the commit cf15286 was reverted.

[jamespetts]

No, there are no pull requests related to this. But at my branch the commit cf15286 was reverted.

Thank you. Unfortunately, attempting to merge this results in compile errors as this code is not compatible with some of the other UI changes that I have merged in to-day. Would you be able to update this to work with the latest master? Thank you.

[Ranran]

Would you be able to update this to work with the latest master?

I think the conflict has been resolved.

Apart from that, pull request #424 has some small fixes. (r9982-9997)

Tab header size is a cramped issue.
Fix overlay display position. This is required for the signal indicator patch.

EDIT:
Add the option button on the banner by roboron

EDIT2:
Fixed city info dialog with strange vertical even expansion and contraction

[jamespetts]

Excellent - now incorporated. Thank you. Testing confirms that this can stay in sync with a server/client pair on the current Bridgewater-Brunel saved game, so the earlier problem has evidently been resolved.

[Ranran]

I couldn't playtest because I was busy watching Evangelion last weekend, but I think this bug and this bug have been fixed. (´・ω・｀)
Check pull request #428.

[jamespetts]

I couldn't playtest because I was busy watching Evangelion last weekend, but I think this bug and this bug have been fixed. (´・ω・｀)
Check pull request #428.

Now incorporated - thank you.

[Ranran]

I found some places where I was passing a color index even though the argument was PIXVAL, so the fix is included in pull request #457.
Also, when I changed the vehicle bar legend in the depot dialog to a new GUI component format drawing, it was wrong, so I fixed it.

[Ranran]

Pull request #458 is a set of small fixes up to r10164.

[jamespetts]

Excellent, thank you: now incorporated.

[Ranran]

Pull request #461 is some commits from the standard from r10136 to 10244. The contents are bug fixes and code changes.
This is mostly recent. However, I do not get the commitments (e.g., finger operation) to make it work on Android.

In addition, it was pointed out that Extended does not have Chinese fonts by default and Chinese is not available. Therefore, a Chinese font has been added.

[jamespetts]

Excellent, thank you: now incorporated.

My apologies for having taken so long to get around to this: I have been very busy/preoccupied lately.

[Ranran]

Pull request # 466 is some merge from the standard.
- The currently selected convoy in the minimap will be highlighted in magenta.
- Silence some warnings
- Some bug fixes
- Change invalid translation terms to valid translation terms
- Make the code common with standard (simsys_s2)

As I said before, I don't capture big or complex commits. (e.g. Scalability of depot dialog)
I don't know much about networks in particular. Anyone who is interested can help with it. (´・ω・｀)

[jamespetts]

Thank you very much for this. Unfortunately, on testing, I find that pakset translation texts seem to have stopped working. The untranslated names are shown instead of the translated names.

I have pushed the version as merged onto my merge-from-std branch - I should be grateful if you could look into this. Thank you.

[Ranran]

Unfortunately, on testing, I find that pakset translation texts seem to have stopped working. The untranslated names are shown instead of the translated names.

Thank you for testing.
It's a standard bug, and a commit to fix it was recently added in r10356, but I hadn't incorporated it yet.
I took it in and pushed it. Please check again.

[jamespetts]

Thank you for testing.
It's a standard bug, and a commit to fix it was recently added in r10356, but I hadn't incorporated it yet.
I took it in and pushed it. Please check again.

Excellent, thank you: fix confirmed. Now incorporated.

[Ranran]

Pull request #480 is a merge from the standard, focusing on r10377 to 10394 and r9922 to r9961.
There are no major changes, but mainly minor revisions.

[jamespetts]

Splendid, thank you: now incorporated.

[Ranran]

Pull request #485 is for standard's commits r9872 to r10076 related to translator and symsys coordination. and unification of formatting with standard,  also translation from amber to yellow.

[Ranran]

I do note that saving and reloading a game resets the player number.

This also standard's bug.
I'm guessing this may be related to the fact that autosave saves the state of the dialog, but we can't restore the dialog if we save it manually.

I happened to remember this issue and did research on it.
The points made by wlindley can be reproduced in the standard.

It will only take over the previous player from the save if the UI auto-restore is performed. (The process will be executed even if there is no opened dialog.)
In other words, auto-save automatically restores the UI, so the active player is also inherited, but if you load a save manually, the UI is not restored, so the active player is not restored.
I consider it a bug because I don't see the need for such a specification, the save correctly remembers the previous player.
But anyway, pull request #486 is to fix it.

EDIT:
I checked with extended before the big merge from standard on 2020, and as of extended 14.5, it was possible to carry over the active player before the save. Therefore, it seems that the feature was lost due to the incorporation from the standard. Therefore, I think the pull request is a reasonable fix.

EDIT2:
I checked the old code and it appears to be the same as the current master branch, so I'm confused as to why that functionality was lost. (´・ω・｀)

[ceeac]

Pull request #503 incorporates the "Heavy Mode" desync debugging mode and some fixes regarding desyncs. Hopefully there should be fewer of them now, but I could not test absolutely everything. Please check before merging the changes because the savegame version is increased.

EDIT: Windows CI is failing because

could not find any instance of Visual Studio.

[Ranran]

Windows CI is failing because

I received an email from github a week ago informing me of the following:
https://github.blog/changelog/2021-11-16-github-actions-windows-server-2022-with-visual-studio-2022-is-now-generally-available-on-github-hosted-runners/

I suppose this has happened since then.

[prissi]

I was unable to compile extended in MSVC due to the very strange way the libaries are set up.

I changed the project file to use vcpkg and also enabled parrallels build and large data for 32 bit. Still the makefiel is a mess.

However, on a new computer Install MSVC, github desktop, clone microsoft/vcpkg open commandline ther, run bootstrap.bat then copy instal-libariesx64.bat (or ...-x86.bat for 32 bit builds) and run it. That's it. You can delete the OpenTTD folder in utils, it will not be used any more.

That should also work if on wants to build on the github server. (I.e. clone vcpkg, run the boottraps.bat runt he isntall bat, and then run the build.

I attached a diff to the project build files, since I cannot submit a pull request, as it tries to pull also all mit chanegs from standard.

[Roboron]

Changing windows-latest to windows-2019 in the CI fix it. For some reason it is not able to find MSVC in windows-2022.