Incorporating changes from Standard

[Ves]

Hello ACarlotti,
I know that you are putting these things a bit on the hold due to the sync-issues, but I was wondering how far of the GUI stuf you have ported as of yet, more specifically the gui_convoy_assembler? I am asking since I was planning on using that for the new features of Extended, and therefore I would need to fundamentally alter some parts of it. However, I suspect that it might make future merge conflicts more severe the more I alter that window. Already it is quite a bit altered (mostly in the information section) than from Standard, but it feels like a bit of waste of time and effort if you (or james for that matter) would have to work through even more conflicts that could have been avoided.

[ACarlotti]

more specifically the gui_convoy_assembler?

It seems (at a glance) that there haven't been that many changes to the relevant code in Standard (which is still in gui/depot_frame.[cc/h]) - in particular there were only a couple of commits that weren't just translations up until 2017. Unless you're aware of any significant changes that are likely to be substantially more problematic, then I think you should just do whatever you need to and not worry too much about make merges harder (beyond normal things like not making unnecessary changes to thing like spacing).

[Ves]

Thanks.
What I want to do is to add new conditions, "is_consist_order_frame", similar to the existing "is_depot_frame" and "is_replace_frame". Since we need to create wildcard vehicles, I need to create associated GUI features to control those, therefore I dont know how much I will be messing up the code.

I know that Standard updated their depot window not so long ago according to this thread:
https://forum.simutrans.com/index.php/topic,17470.70.html
which I believe among other things added sorting.

[prissi]

The combobox in standard was mostly broken, and the depot was most affected by it (with two of them). I am not sure where else Extended uses Comboboxes, but the old code really stuggled to handle two of them in one dialoge, or overlapping ones.

[ACarlotti]

Right, I have a few more changes up on Github. There are very few functional changes in this, but a lot of minor changes to variable names, comments, etc. to bring us a bit closer to Standard.

There is, however, a backwards incompatible change to reading xml saves; this reverts an accidental backwards incompatible change made when James originally applied spieler->player to Extended. The change concerns whether "spieler" or "player" is the name of the xml tag in xml saves. I think it's simplest just to make a breaking change since I think xml saves are only really used by people wanting to run analysis on a save using an external tool (there's no other reason I can see to change the default). If this does cause problems, however, it should be possible to write some extra code to accept both versions (during loading).

[jamespetts]

Thank you - that is most helpful. I have now reviewed and incorporated these. I do not think that there is any significant usage of the XML saves, so I doubt that this is an issue.

[ACarlotti]

I've pushed a few more commits. The first fixes some incorrect code (I'm not sure if it actually broke anything), the second is some comment updates/corrections drawn from a number of Standard commits, and the third fixes a bug which effectively allows a player to get free income. The bug is that when a signal/sign preview was deleted, the maintenance cost would be deducted from the player's total maintenance costs, even though the sign/signal never had maintenance charged in the first place.

[jamespetts]

Thank you very much for this, and my apologies for the delay in responding: I have now incorporated this.

This is most helpful.

[Phystam]

How does this project go? Now so many main features have been implemented in the Standard (theme selector/fonts/automatic GUI/speed up of slice view/...)
Considering the release of 121.1 version, I think that we have to restart this work (maybe mainly by A.Carlotti)

[Phystam]

In case that A. Carlotti will not appear again, this important project will eternally be lost. May I do this project again?

[jamespetts]

Yes, if you would like to take this on, do feel free. Thank you.

[Phystam]

The last commit by A. Carlotti is trunk r7479. I will start the work from there.

[jamespetts]

The last commit by A. Carlotti is trunk r7479. I will start the work from there.

Excellent, that is very helpful - thank you.

[Ves]

That is great news, thank you!

[Sirius]

Really great news! Thanks a lot!

[Phystam]

I have incorporated until r7753, the release point of v120.1.3. github: https://github.com/Phystam/simutrans-extended/tree/merge-from-standard-by-phystam
the main features are:
configurable compass for minimap, rotation tool, and main screen
- this is partially incorporated but I have not seen it before
allow self-defined way tools,
last used player tools,
and some sqapi functions.

Some bugfixes are not possible to incorporate, since the codes (in vehicle, convoi and others) are fully changed.
other commits are bug-fix or already merged feature/bug-fix.
I have incorporated new citylist for new list windows (r7653) once, but it causes a severe crash when clicking sort buttons. I reverted it finally.

And also, I incorporated slice view improvement by Dr. Supergood. (r8561)

I believe that it works well.

[jamespetts]

Excellent, thank you very much for this. It would be very helpful if our intrepid self-compilers could test this for stability (including network games remaining in sync) before I incorporate it.

Incidentally, the whole scenario scripting is not working at all in Extended at present and will need some significant adaption to make it work, so I am not sure quite what effect that the sqapi changes have.

Edit: I notice from this commit that there is some reference to multi-goods carrying vehicles; this is a feature not currently in the master branch of Extended. Have you incorporated this feature itself? If so, this will need especially stringent testing, since this will impact on the path explorer in very complex ways.

[Phystam]

The next goal is v120.2.1. Then finally we can say that Extended is based on Simutrans-Standard v120.2.1. ^^

James,
I couldn't find where these changes should be, so I didn't change anything except for that.
Original addition is a very large commit.

Edit:
Can I ignore sqapi features?

[jamespetts]

Thank you for this. Yes - unless you want to implement the scenario scripting fully, you can ignore all of the scripting.

[Phystam]

I tried to merge r8024 ( Big power network and JIT2 revision. (DrSuperGood) git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@8024 8aca7d54-2c30-db11-9de9-000461428c89 ) and some related bugfixes, but I couldn't since there are a lot of changes in the factory(simfab.cc) code (City cannot accept any power in Standard).
However, I think that this is an important change. can anyone help me?

[Phystam]

I finally reached v120.2.1. Almost all changes have previously been incorporated. I incorporated only 20 commits which have not yet been incorporated. I skipped checking all translation commits, since after that james translated all of German words into English which are changed in Standard.
note that I did not incorporate r8024 -- since simfab.cc is quite different from Standard code.
—
Seeing the following commits, it seems that there are possible conflicts against ranran's patch. The Standard code (r8134) improved color display, but ranran did use old functions.

[DrSuperGood]

JIT2 is to not be merged into extended. Extended industry has access to estimated travel times which allows for possibly a better solution to the problem that JIT2 was designed to solve.

[Phystam]

Thank you for your comment. So, I do not have to merge "JIT2"-related features, right?

[DrSuperGood]

Thank you for your comment. So, I do not have to merge "JIT2"-related features, right?

Yes you do not have to merge JIT2 related features. Extended industry operates very differently from standard.

[Phystam]

Dr. Supergood,
Thank you for clarifying.

[Ranran]

Thank you for your work on this - Phystam.

Seeing the following commits, it seems that there are possible conflicts against ranran's patch. The Standard code (r8134) improved color display, but ranran did use old functions.

Specifically, which part?

I don't think the code related to this should be removed. Characters cannot protrude from the dialog.

[Phystam]

Please see r8134. In this change, display_text_proportional_len_clip, display_proportional and these functions without _rgb suffix are deleted, and an_dz newly introduced _rgb suffix functions.
Such bug can be fixed by that commit.

[Ranran]

Did I use display_text_proportional_len_clip?
I suppose display_proportional can be simply replaced by display_proportional_rgb.
And it needs to be converted to PIXVAL as well as others.

[Vladki]

Hi, thanks for good work. About incorporating changes did you already come over these:?

https://forum.simutrans.com/index.php/topic,19268.msg182956.html#msg182956

From standard:
- platform (or even building) rotation tool: https://forum.simutrans.com/index.php/topic,17914.0.html
- merge station tool: https://forum.simutrans.com/index.php/topic,18674.0.html

These also use conflicting IDs for menuconf.tab (IIRC one of them has the same tool number as tool for reconecting signals from one signalbox to another)
So the conflict should be solved at the same time, probably by reassigning extended specific tools to some higer number (>128)

[Phystam]

Ranran - Yes, you are right. From the consequences, probably the bug has been fixed at a certain time in Standard, but not incorporated to Extended.
_rgb function enables us to use more colors than previous -- the bit number is extended.

Vladki - I have not yet come there -- I will consider it when I face it.

[jamespetts]

Thank you for your work on this. It will take a long time to test thoroughly whether each change causes any problems, so I suggest that, in order to make it easier to test smaller batches of changes, that each set of changes (e.g. up to a Standard version number) be put on its own branch, and each later set of changes be put on a separate branch derived from the earlier branch. That way, I and others can test in the changes batches to narrow down any particular problems.

For this to be workable, we are going to need several testers, as my testing alone is unlikely to be enough. Would anyone like to volunteer to do some testing?

One particular thing that we need to test extremely thoroughly is whether there are any losses of network synchronisation, as this sort of problem can be so difficult to track down that there have been occasions where many months of intensive work were spent doing nothing else. We need to test very well developed games to make sure that there are no features which are unused by a particular saved game which, if used, would cause a loss of synchronisation.

All works in testing this will be very much appreciated.

[Phystam]

until 120.1.1 --> https://github.com/Phystam/simutrans-extended/tree/merge-from-standard120-1-1 based on extended version 14.7.
until 120.1.3 (and slice view improvement) --> https://github.com/Phystam/simutrans-extended/tree/merge-from-standard120-1-3-fix based on extended version 14.7.

By the way, which part of the code had the desync problem? I can try not to touch there.

[Vladki]

I'm willing to try these on Stephenson Siemens game.

[Phystam]

Vladki - thank you. I believe that it works well

[Vladki]

Can you prepare binaries that you want tested?
Windows and linux 64 bit clients and linux 64 bit server?
At least the windows binary. I can compile for Linux myself if you tell me the exact source to use.