Topic: 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.