The International Simutrans Forum

 

Author Topic: Incorporating changes from Standard  (Read 5168 times)

0 Members and 1 Guest are viewing this topic.

Offline ACarlotti

  • *
  • Posts: 483
Incorporating changes from Standard
« on: May 06, 2018, 12:08:01 PM »
This is firstly a question, and then secondly an offer to try doing something about it (as time permits).

The question: What is the current process for incorporating bug fixes and features from Standard? As far as I can tell we've just been cherry-picking changes whenever we notice something we want, but are making no thorough attempt to include all relevant fixes/changes. This has become apparent from discussion/investigation relating to a tunnel/catenary graphics bug. From source control, I can see that there was last an explicit merge from Standard in February 2014, but my understanding is that it was subsequently decided that merges were not the way forward. So what's been happening since then?

The proposal (subject to discussion) is that someone (possibly me) attempts to go through the Standard revision history methodically up to point at which this was last done (potentially up to 1354 revisions and counting), to check for and incorporate any relevant revisions.

Offline Matthew gb

  • *
  • Posts: 318
    • Japan Railway Journal
  • Languages: EN, some ZH, DE & SQ
Re: Incorporating changes from Standard
« Reply #1 on: May 06, 2018, 02:37:30 PM »
I realize that your question is primarily directed at James as project lead, but it's great that you're considering contributing to the community in this way.

 :thumbsup:

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #2 on: May 06, 2018, 04:23:10 PM »
Initially, Extended ("Experimental" as then it was known) was just a patch with a few extra features from Standard: the changes from Standard were merged automatically. This automatic merging continued for a few years, but became unmanageable around 2012/2013 when Extended diverged too far from Standard for this to work effectively, with the amount of time and effort necessary to resolve automatic merge conflicts greatly exceeding the amount of time and effort necessary simply to merge changes manually.

Since then, changes have been merged manually, although some more complex changes (such as GUI theme support and additions to the scripting support) have not been merged owing to the amount of work that that involves.

If you would be able to assist with merging additional changes from Standard into Extended (I have not had chance to do any in the last few months), that would be extremely helpful, and it would be even more helpful if you were able, for example, to go back and merge in full GUI theme support and make this work with all of the Extended GUI.

Thank you very much for your offer to help with this: it is much appreciated.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #3 on: May 10, 2018, 07:42:41 PM »
I have now made a small start on this (about 8 standard revisions so far). Before going too much further, I would like to check that my approach is acceptable. Namely, my current workflow is to cherry pick any comments from Standard that are relevant and haven't yet been included in Extended. This creates a commit history that looks like this:

Code: [Select]
commit 2ad79548da4183d3d1f27b25852d7429635a7f06 (HEAD -> merge-from-standard)
Author:     Dwachs
AuthorDate: Wed Feb 19 19:19:36 2014 +0000
Commit:     Andrew Carlotti
CommitDate: Thu May 10 20:32:29 2018 +0100

    FIX problem with scrollbar offset in line selector of depot window - take two
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7074 8aca7d54-2c30-db11-9de9-000461428c89

commit 4731fa931d52f2e8c8662884589874fd11d36d3e
Author:     Dwachs
AuthorDate: Sun Feb 16 12:12:19 2014 +0000
Commit:     Andrew Carlotti
CommitDate: Thu May 10 20:26:21 2018 +0100

    FIX problem with scrollbar offset in line selector of depot window
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7072 8aca7d54-2c30-db11-9de9-000461428c89

commit aa44f5e8e6f065021c377bcf89f9b622e0c81888
Author:     Dwachs
AuthorDate: Sat Feb 15 15:58:41 2014 +0000
Commit:     Andrew Carlotti
CommitDate: Thu May 10 20:19:01 2018 +0100

    squelch compiler warning
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7070 8aca7d54-2c30-db11-9de9-000461428c89

commit 66ab44890619c391d9d6d23e52a7e20690786021
Author:     Dwachs
AuthorDate: Sat Feb 15 15:57:10 2014 +0000
Commit:     Andrew Carlotti
CommitDate: Thu May 10 20:17:31 2018 +0100

    (eipi) documentation in hausbauer
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7069 8aca7d54-2c30-db11-9de9-000461428c89

commit 7eddff2d9ae8573c012aa9d2c5017b41c14d50f7
Author:     Dwachs
AuthorDate: Sat Feb 15 15:38:31 2014 +0000
Commit:     Andrew Carlotti
CommitDate: Thu May 10 18:07:50 2018 +0100

    delete wrong comment
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7068 8aca7d54-2c30-db11-9de9-000461428c89

commit 5d705385301ea49ec448a53f23691d0295c6c2e0 (upstream/master, upstream/HEAD, master)
Author:     James E. Petts
AuthorDate: Tue May 8 23:21:50 2018 +0100
Commit:     James E. Petts

Does anyone (especially James) thing this is the wrong way of doing things, or that I could be doing things better (e.g. adding text to the original commit messages)?

Offline O01eg

  • *
  • Posts: 79
  • Languages: EN, RU
Re: Incorporating changes from Standard
« Reply #4 on: May 10, 2018, 08:04:34 PM »
Long ago I tried to merge them but without tests and knowledge of the code its impossible to solve conflicts.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #5 on: May 11, 2018, 11:00:43 PM »
Splendid, that is very helpful: thank you. I cannot see these commits on your branch; I assume that you have not pushed them yet?

When I merge commits from Standard, what I usually do is to make some standardised alterations and additions to the text of the commit. So, for example, if the original commit message was,

Quote
FIX problem with scrollbar offset in line selector of depot window - take two

The amended version would be

Quote
FIX: Problem with scrollbar offset in line selector of depot window - take two (Dwachs, from Standard)

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #6 on: May 11, 2018, 11:54:39 PM »
I am aware of that (and have previously made commits like that myself). If you would like, I can add that info. However, when using a cherry-pick workflow (as opposed to manually copying a patch), all that information is automatically available - the git-svn-id line included in the commit message implies that it's from Standard, and the original author is preserved as the author of the commit (along with the author date; only the commiter and commit date reflect that I am applying these changes now). When there are no conflicts, the commit is made immediately without me ever touching the commit message.

Another thing that I have encountered are places where I have made non-trivial changes to resolve conflicts. In these cases I have been adding my own comments to the original commit messages, as shown below. (This also shows what "git log" returns without specifying "--format==fuller", or similar.)
Code: [Select]
commit 715550271750076e106f91b62302418ae4c5d087 (HEAD -> merge-from-standard)
Author: Dwachs <dwachs@gmx.net>
Date:   Sat Feb 22 14:53:28 2014 +0000

    sqapi: export lines
   
    ACarlotti: Commented out new functions using WAYTOLL
   
    git-svn-id: svn://tron.homeunix.org/simutrans/simutrans/trunk@7081 8aca7d54-2c30-db11-9de9-000461428c89
I have considered moving the added line(s) to below the git-svn-id, but I think it would make little difference either way.

You assume correctly that I have not pushed them yet; I saw no value in doing so at this stage, and having them only stored locally means I can go back and directly amend the commits I have already made without all the issues that can arise once those commits are public. My plan at the moment is to check almost all commits to see that they build, and to check that the game seems to run fine at regular intervals, including before pushing to Github. Once I've made significant progress (e.g. ported a major feature), then I'll start asking people to tell me what I've broken.

So, given the above information, would you still like the commit messages amended as you state above? I think there is still a distinction to be made between bulk import of Standard features (as I'm doing now), compared to manual transfer of patches (as has otherwise been happening in the past four years). I don't intend to remove the git-svn-id line, which includes the Standard release number, so the commit messages would already look different to those for manually transferred patches. A further (minor) disadvantage is that manually editting all the commit messages would mean a small increase in workload.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #7 on: May 12, 2018, 10:25:11 AM »
Ahh, now I understand: my apologies, I did not realise that you were using an automated workflow. If you are using an automated/cherry pick workflow, then you need not add this information manually. The additional comments on your modifications also seem to make sense.

Thank you very much for this: this is most helpful.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #8 on: May 15, 2018, 01:02:17 PM »
I've now pushed the first set of changes. These incorporate changes in r7068 (Feb 15th 2014) thru r7127 (Mar 31st 2014), with changes incorporated from 42 of these 60 revisions (the other revisions covered changes that were either already fully ported to Extended, or applied to code that was replaced by Standard). There are also a few additional fixes that I have made to related code while merging.

The major new feature so far is the ability to filter the transport network display in the minimap by player, goods type and vehicle type. I imagine this will be particularly useful in the server game.

James: I think it is probably best that you merge each set of changes as I upload and post about them; that way they will be less likely to break things horribly all at once, and it will be easier to fix any bugs I accidentally introduce as they arise. Unless I think I *have* broken something, in which case I'll ask for a bit more testing first.

Finally, a code comment (by James) that demonstrates perfectly why this is long overdue.
"It is not clear why this is necessary in Extended but not in Standard, ..." (Answer: Because an equivalent fix in the same location was already in Standard - and had been for almost three years)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #9 on: May 15, 2018, 01:12:04 PM »
Thank you - that is exceedingly helpful. I will incorporate and test this when I get home this evening.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #10 on: May 16, 2018, 12:02:48 AM »
I have now had a chance to look at this, but I am getting "unresolved external symbol" errors when I try to compile. Specifically, I get the following two errors:

Code: [Select]
>------ Build started: Project: Simutrans-Extended, Configuration: Debug (open GL) x64 ------
1>git : Not a git repository warning GitNR1: Git output not valid! Check if the folder is actually versioned. A revision file already exists and its revision number won't be updated. Make sure the revision number is correct or you won't be able to play online with this build.
1>  libbz2.lib(bzlib.obj) : MSIL .netmodule or module compiled with /GL found; restarting link with /LTCG; add /LTCG to the link command line to improve linker performance
1>LINK : warning LNK4075: ignoring '/INCREMENTAL' due to '/LTCG' specification
1>export_objs.obj : error LNK2001: unresolved external symbol "void __cdecl export_line(struct SQVM *)" (?export_line@@YAXPEAUSQVM@@@Z)
1>script.obj : error LNK2001: unresolved external symbol "void __cdecl export_include(struct SQVM *,char const *)" (?export_include@@YAXPEAUSQVM@@PEBD@Z)
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 2 unresolved externals

Am I missing a new library/include somewhere?

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #11 on: May 16, 2018, 11:36:16 AM »
I forgot to add the new files to the Extended .vcxproj. If this happens in future, I recommend checking the diff for the Standard .vcxproj to see if I've missed anything. In any case, I've corrected this on Github; hopefully that will fix it now.

Incidentally, the history of these two files (api_line.cc and api_include.cc) is a bit strange. You copied them to Extended at some point, I think believing you'd accidentally failed to commit them, when what had actually happened is that the changes that introduced them in Standard hadn't been transferred to Extended. So at the moment I've actually reverted them to an earlier version, consistent with the rest of the scripting stuff.

Another thing I forgot to mention: It is possible that I've broken any scripts that try to use Standard's waytolls. I suspect scripts are probably somewhat broken in Extended anyway, although I've never actually tried using them.

Offline O01eg

  • *
  • Posts: 79
  • Languages: EN, RU
Re: Incorporating changes from Standard
« Reply #12 on: May 16, 2018, 04:21:23 PM »
It would be useful to use AppVeyor CI and Travis CI to test commits and PRs.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #13 on: May 16, 2018, 09:58:42 PM »
Thank you very much for that: now incorporated. That is extremely helpful.

Scripting has not been maintained or developed so far in Extended, and was confirmed to be broken some time ago, so do not worry about breaking any scripts that there might be as I believe that there are none.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #14 on: May 30, 2018, 01:06:33 AM »
I have uploaded another batch of changes, incorporating revisions 7129 to 7161. The main things to note:
1. This includes the fix to allow compiling in gcc 8.
2. It might now be possible to load standard savegames with save version 120.0; I have only tested the latest standard version, which doesn't load yet. The relevant change in save format will be included in extended saves as well when the save version is incremented above 13.5 (no need to do that now though).
3. There are some changes involving way_height_clearance, including reverting a reversion of pak_height_conversion_factor->way_height_clearance (the original revert was apparently because elevated roads were built at the wrong height, but I cannot reproduce this). There is a small possibility of regressions in this code, though the only change I'm aware of is that it is no longer possible to build an elevated road along a road crossed by a low bridge.
4. I have discovered a number of bugs relating to way_height_clearance, many of which are also present in Standard. Since they don't appear to be particularly urgent, I intend to fix them after merging the remaining Standard changes (or at least all of the ones that touch relevant code).

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #15 on: May 30, 2018, 10:09:19 PM »
Excellent, thank you very much: now incorporated.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #16 on: July 14, 2018, 06:37:34 AM »
I've pushed some more changes; I don't think there's anything particularly significant in this batch.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #17 on: July 14, 2018, 10:17:40 AM »
Splendid, thank you: now incorporated.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #18 on: August 14, 2018, 05:40:10 PM »
A longer bath of changes this time, covering a period from May 7 to Oct 12 2014.

The main things of note are:
There were changes relating to the pakselector in Standard that I only partly ported because Bernd Gabriel rewrote the selector for Extended back in 2013. Since I don't think there are any differences to the functionality requirements, this seems like an example of a change that (in my opinion) shouldn't have been made only in Extended (cf. Code Quality thread).

I have reverted an accidental overwrite of readme.txt (in the repository root) with a file relating to help texts. I have also now added an initial section relating to Simutrans Extended.

I have also added a commit applying the translation of komp->comp to the OTRP code.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #19 on: August 14, 2018, 07:24:34 PM »
Thank you very much for this - reviewing the code, I see that this is a very substantial amount of work. I have now committed this, and a further commit removing redundant instances of CACHE_TRANSIT so that accidentally defining this does not cause incorrect behaviour.

These changes should appear in to-morrow's nightly build.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #20 on: September 17, 2018, 06:52:34 AM »
I've now uploaded another set of changes. These include (among other things) a lot corrections to comments; a bug fix for (I think) handling changing goods connections when changing a station auxillary building; and random commit to remove some accidentally duplicated code that I spotted.

Progress is now up to r7395 from December 3 2014.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #21 on: September 18, 2018, 08:17:39 PM »
Thank you very much - now incorporated.

Offline Ranran jp

  • *
  • Posts: 659
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #22 on: December 27, 2018, 09:19:21 AM »
I threw a pull request for fixing this bug from standard (by prissi). (´・ω・`)

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #23 on: December 28, 2018, 01:23:37 PM »
Splendid, thank you: now incorporated.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #24 on: January 08, 2019, 12:03:57 PM »
I started to merge standard code, following A. Carlotti-san's work.

There was too many conflicts due to translation from German to English, including the file or directory names. (e.g. descriptor is known as "besch")
I solved them and pushed to my repository (merge-from-standard branch), and send a pull-request. This pull-request contains changes from Dec. 4 2014 to Dec. 7 (from r7395 to r7408).
If this way is correct, I will continue to work this.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #25 on: January 08, 2019, 11:28:52 PM »
Thank you very much for that. I have now incorporated these. I did have to comment out one part of the code relating to the scripting API (setting text labels) as this would not compile in Visual Studio. This is not a high priority issue as the scripting API is not currently supported, and I do not know what has caused this specific issue, but it would be helpful if you could look into this at some point.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #26 on: January 09, 2019, 03:00:24 AM »
Phystam: You have just duplicated some work that I have already done but hadn't yet uploaded. I think it would be difficult to coordinate multiple people trying to systematically port changes at the same time.

In any case, this makes it clear that an update on my work is needed. I haven't made much further progress on incorporating changes since September, for two different reasons. Firstly, I was a little busier than previously, so had less time available (although not so little that I couldn't have continued incorporating changes). However, the second issue that I am reluctant to add major changes to the code wholesale while we are still trying to debug the current desync issue. This is partly because I perceived that such changes would receive less testing at present, and partly because I think there is a risk of masking the desync-causing bug by making other changes to the codebase. Perhaps neither of these concerns is particularly justifiable - if that is the case then I will probably begin merging new changes soon.

Anyway, while I appreciate your effort in trying to incorporate changes yourself, I don't feel that it is particularly helpful, given that my workflow typically consists of merging several weeks of changes of the course of a few weeks, and then uploading them all as a batch. (I also avoid pushing WIP to Github so that I can safely amend commits as required when I inevitably make mistakes).

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #27 on: January 09, 2019, 07:34:11 AM »
jamespetts-san,
Thank you so much :) Can we skip merging changes related with sq api?

A. Carlotti-san,
Yes, I also think that changing code while debugging desync issues is a little bit dangerous. But we can work separately, using another branch. If you push WIP to your github branch, it will be our benefit -- we can check your important progress.
And when I follow your workflow of incorporating, can we accept and follow our works each other?
Anyway sorry for duplicated works --- my apologies.

I have already merged changes from Dec. 8  to Feb. 9 2015 (r7525). From previous pull-request, almost all commits have already merged previously, so there were few commits to merge.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #28 on: January 09, 2019, 11:04:07 PM »
A few observations:
Some of your commit messages consist mostly of a long list of merge conflicts. I don't know why those are present - by default I thought those commented lines were ignored in generating the commit messages. In any case, I think they are unhelpful and shouldn't be there, so it's probably worth checking your configuration to see why they are appearing.
In many cases rebasing or amending past commits is bad. However, there are also times when it is very useful. In this cases, rather than making a new commit to revert your accidental creation of simwerkz.cc/.h, I think it would have been better to amend your past commits to remove the original commit from the branch. Since you spotted your mistake after only half an hour, and almost certainly noone else will have downloaded your past commits by that point, then the tidier option is probably better.
There's are several instances where, for no reason I can tell, you didn't incorporate a change accurately, resulting in a completely unnecessary difference from the standard codebase.
There are some changes that you didn't transfer for some reason.

I've now gone through and applied my more accurate changes on top of yours. However, this essentially required doing a couple of hours of work that wasn't previously necessary, and means that the commit history will now be somewhat more confusing. To avoid me having to repeat this work on more of the Standard changes, could I ask that you(/James) don't merge any more of your changes for now, at least until I've had a chance to sort out the above changes I'd already ported, and upload them (by which I mostly mean rebase onto the new branch point and check it all still works).

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #29 on: January 10, 2019, 07:36:14 AM »
I've pushed changes up to the beginning of January (including some bits that Phystam missed). Getting much further than that will take a little while because there are a lot of big commits in there.

Phystam, given that you claim to have got through changes from Dec 8 to Feb 9 relatively quickly, I think that you have been far less thorough than I am. As well as porting any functional changes and bug fixes, I am also trying to minimise the differences to Standard in general. Furthermore, I don't trust James to have merged changes correctly (unfortunately) - I have found many minor errors where he hasn't done a merge correctly.

As an example (from the next really large commit, which I am part way through porting): Did you notice that simwerkz-dialogs.h was effectively copied instead of renamed? And that's one of the biggest mistakes present. (I'll upload the fix once I've done the rest of that commit, and probably the next few. Most of these sorts of changes won't affect functionality at all so almost certainly won't intefere with the desync).

So, for consistency and soundness of mind, I would like to work through all these changes myself (at least for the moment).

January 2015 had a load of translations, which means lots of big changes which don't merge easily (and so are more likely to have errors/inconsistencies). So I think getting through that month will be quite slow, but things will be quicker afterwards because there will be fewer translation conflicts.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #30 on: January 10, 2019, 10:02:33 AM »
Thank you very much for your work on this. It is difficult keeping on top of a large number of different coding issues when this is essentially a hobby, so my apologies for the manual merging in the past not being always to the highest standard. Co-ordinating different people's contributions is also a difficult task leading to surprisingly complex decisions about what would be preferable in many cases, and any system or protocol that can assist reliably in the long-term (i.e. consistently over the course of many years, withstanding unpredictable changes in which people take responsibility for which aspects of development) of which anyone can think would be most helpful.

Can I check - did you want me to merge your latest changes on this branch now or await further work on attempting to fix the loss of synchronisation bug?

Thank you again for your work on this.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #31 on: January 10, 2019, 10:27:09 AM »
Given that I don't think there are any major or particularly relevant changes, and fills in gaps in what Phystam has ported, then I think it may as well go in now.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #32 on: January 10, 2019, 11:38:13 AM »
Splendid, thank you.

Do you think it sensible to hold off further merging until the loss of synchronisation issue has been identified?

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #33 on: January 10, 2019, 06:27:54 PM »
I think that the next chunk of work to do is mostly tidying up translation commits, which should have virtually no impact on functionality. But then after that it would perhaps be sensible to wait again - it depends on exactly what is coming up.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #34 on: January 10, 2019, 06:46:17 PM »
Splendid, thank you for clarifying.

Offline Ves

  • Devotee
  • *
  • Posts: 1737
  • Languages: EN, SV, DK
Re: Incorporating changes from Standard
« Reply #35 on: January 17, 2019, 03:23:19 PM »
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.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #36 on: January 17, 2019, 04:34:12 PM »
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).

Offline Ves

  • Devotee
  • *
  • Posts: 1737
  • Languages: EN, SV, DK
Re: Incorporating changes from Standard
« Reply #37 on: January 17, 2019, 04:57:33 PM »
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.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9709
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #38 on: January 20, 2019, 02:04:41 PM »
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.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #39 on: April 12, 2019, 02:54:40 AM »
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).

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #40 on: April 12, 2019, 11:08:33 AM »
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.

Offline ACarlotti

  • *
  • Posts: 483
Re: Incorporating changes from Standard
« Reply #41 on: May 06, 2019, 11:51:17 PM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #42 on: May 09, 2019, 12:00:06 AM »
Thank you very much for this, and my apologies for the delay in responding: I have now incorporated this.

This is most helpful.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #43 on: December 05, 2019, 03:09:35 AM »
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)


Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #44 on: January 28, 2020, 05:19:50 AM »
In case that A. Carlotti will not appear again, this important project will eternally be lost. May I do this project again?

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #45 on: January 28, 2020, 10:13:30 AM »
Yes, if you would like to take this on, do feel free. Thank you.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #46 on: January 28, 2020, 01:10:18 PM »
The last commit by A. Carlotti is trunk r7479. I will start the work from there.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #47 on: January 28, 2020, 01:13:19 PM »
The last commit by A. Carlotti is trunk r7479. I will start the work from there.

Excellent, that is very helpful - thank you.

Offline Ves

  • Devotee
  • *
  • Posts: 1737
  • Languages: EN, SV, DK
Re: Incorporating changes from Standard
« Reply #48 on: January 28, 2020, 02:24:25 PM »
That is great news, thank you!

Offline Freahk

  • *
  • Posts: 583
  • Languages: DE, EN
Re: Incorporating changes from Standard
« Reply #49 on: January 28, 2020, 06:01:33 PM »
Really great news! Thanks a lot!

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #50 on: January 30, 2020, 12:46:41 PM »
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.
« Last Edit: January 30, 2020, 01:12:12 PM by Phystam »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #51 on: January 30, 2020, 01:14:39 PM »
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.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #52 on: January 30, 2020, 01:25:27 PM »
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?
« Last Edit: January 30, 2020, 11:56:25 PM by Phystam »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #53 on: January 31, 2020, 12:04:24 AM »
Thank you for this. Yes - unless you want to implement the scenario scripting fully, you can ignore all of the scripting.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #54 on: January 31, 2020, 01:46:02 AM »
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?

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #55 on: January 31, 2020, 05:24:26 AM »
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.
« Last Edit: January 31, 2020, 05:39:15 AM by Phystam »

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2805
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #56 on: January 31, 2020, 06:21:10 AM »
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.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #57 on: January 31, 2020, 07:39:41 AM »
Thank you for your comment. So, I do not have to merge "JIT2"-related features, right?

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2805
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #58 on: January 31, 2020, 09:58:34 AM »
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.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #59 on: January 31, 2020, 11:12:39 AM »
Dr. Supergood,
Thank you for clarifying.

Offline Ranran jp

  • *
  • Posts: 659
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #60 on: January 31, 2020, 11:54:26 AM »
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.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #61 on: January 31, 2020, 12:44:29 PM »
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.

Offline Ranran jp

  • *
  • Posts: 659
  • Languages: ja
Re: Incorporating changes from Standard
« Reply #62 on: January 31, 2020, 05:05:06 PM »
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.
« Last Edit: January 31, 2020, 05:20:19 PM by Ranran »

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #63 on: January 31, 2020, 05:20:24 PM »
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)

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #64 on: January 31, 2020, 06:20:03 PM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #65 on: February 01, 2020, 12:41:21 AM »
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.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #66 on: February 01, 2020, 03:57:17 AM »
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.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #67 on: February 01, 2020, 10:12:26 AM »
I'm willing to try these on Stephenson Siemens game.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #68 on: February 01, 2020, 10:25:47 AM »
Vladki - thank you. I believe that it works well ;)

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #69 on: February 01, 2020, 10:29:33 AM »
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.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #70 on: February 01, 2020, 10:59:34 AM »
Vladki - thank you: that is helpful. Note that it is not necessary to use an actual client and server for desync testing: connecting to a server running on the same machine is usually sufficient. Also, only a cross compile build on Windows will stay in sync with a Linux server: a Visual Studio build will not.

As to which parts of the code have caused loss of synchronisation problems, this is not confined to one area of the code, but can arise anywhere that client and server could in any way diverge affecting the simulation itself.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #71 on: February 01, 2020, 11:45:50 AM »
Using it on real game will bring more testers

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #72 on: February 01, 2020, 12:09:42 PM »
Using it on real game will bring more testers

This is true - and one thing that does also need to be tested is whether it compiles with the command line server build, as there is a problem with that in the current nightly builds.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #73 on: February 01, 2020, 12:20:59 PM »
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.
I tried to compile this branch on Linux and failed

In file included from bauer/brueckenbauer.cc:30:0:
bauer/../descriptor/building_desc.h: In member function ‘bool building_desc_t::is_transport_building() const’:
bauer/../descriptor/building_desc.h:300:117: error: ‘decoration_stop’ cannot be used as a function
  bool is_transport_building() const { return (type > headquarters  && type <= flat_dock) || is_type(decoration_stop(); }
                                                                                                                     ^

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #74 on: February 01, 2020, 12:42:56 PM »
I have fixed the above bug - in the last line should be
Code: [Select]
is_type(decoration_stop); And compiled both client and server: http://list.extended.simutrans.org/phystam-binaries/
But it cannot load the new pakset - same error as mentioned here: https://forum.simutrans.com/index.php/topic,19430.msg184393.html#msg184393

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #75 on: February 01, 2020, 12:45:27 PM »
Yes, decoration_stop is my another developing branch...
And, you should start the server with OLD pakset. NEW pakset has Ranran's newly introduced features, so there is no compatibility.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #76 on: February 01, 2020, 12:52:02 PM »
OK, I noticed that I was compiling your master branch instead of merge-from-standard120-1-3-fix
Regarding the pakset - which is the latest commit that I can use? The nightly is not usable, so I need to compile myself.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #77 on: February 01, 2020, 12:57:39 PM »
Which platform do you use? I can compile makeobj for only linux and the executable for linux/Windows both. If it works, I can provide it to you.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #78 on: February 01, 2020, 01:01:02 PM »
Linux 64-bit. If it is only about recompiling the pakset with the right makeobj, then it is no problem. I'll just need a windows client for other players to join.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #79 on: February 01, 2020, 01:04:42 PM »
You can download from Here.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #80 on: February 01, 2020, 01:07:54 PM »
I have compiled my own makeobj from your sources. I just need to know if I just have to compile the latest pakset sources with your makeobj, or do I need to use some older version of the pakset?

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #81 on: February 01, 2020, 01:11:21 PM »
I did not touch any descriptor/writer codes, so you can use the old version directly (probably).

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #82 on: February 01, 2020, 01:13:56 PM »
old version of what ? pakset or makeobj? I'm asking about which pakset version is compatible with your simutrans version

Offline Freahk

  • *
  • Posts: 583
  • Languages: DE, EN
Re: Incorporating changes from Standard
« Reply #83 on: February 01, 2020, 01:15:38 PM »
If I understand this correctly, any pakset sources compiled with the given makeobj should be compatible to that version of simutrans as dat files did not change.

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #84 on: February 01, 2020, 01:17:50 PM »
The pakset compiled with Makeobj version 60.01 for simutrans 120.2.1 Extended Nightly development build 14.7 or lower.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #85 on: February 01, 2020, 02:57:46 PM »
Linux 64-bit. If it is only about recompiling the pakset with the right makeobj, then it is no problem. I'll just need a windows client for other players to join.

I should note that you will need a cross-compiled Windows client (or, at leas, one built with MinGW or similar), or clients will not be able to stay in sync.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2906
    • My addons, mostly roadsigns, pak128.cs
  • Languages: EN, CS
Re: Incorporating changes from Standard
« Reply #86 on: February 01, 2020, 04:38:04 PM »
Can you provide such build?

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #87 on: February 01, 2020, 05:04:36 PM »
For Windows 64bit (mingw build): here ^^

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9709
  • Languages: De,EN,JP
Re: Incorporating changes from Standard
« Reply #88 on: February 02, 2020, 12:46:36 PM »
If there is a sync issue between MSVC and Mingw compilation, I highly suggest looking for the use of long as sint64 (because it remans and sint32 in MSVC).

Offline Phystam jp

  • *
  • Posts: 383
  • Pak256.Ex developer
    • Pak256 wiki page
  • Languages: JP, EN, EO
Re: Incorporating changes from Standard
« Reply #89 on: February 05, 2020, 08:44:03 AM »
Now I am trying to incorporate the following patch:
https://forum.simutrans.com/index.php/topic,16536.0.html
This patch moves the system colors to 16bit.
Almost all parts including the changes in Extended are replaced, but in some reason, simutrans cannot load the system colors from simuconf.tab, such as cursor color, window title bar color, etc.
I temporary pushed the current progress of the work to https://github.com/phystam/simutrans-extended/tree/merge-from-standard120-2-2

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 19276
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Incorporating changes from Standard
« Reply #90 on: February 08, 2020, 08:24:54 PM »
Phystam - I should be grateful if you could check compatibility with this work and the master branch after the incorporation of the private car routing feature into the master branch.