The International Simutrans Forum

Simutrans Extended => Simutrans-Extended development => Simutrans-Extended major projects => Topic started by: ACarlotti on May 06, 2018, 12:08:01 PM

Title: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: Matthew 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:
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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:


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)?
Title: Re: Incorporating changes from Standard
Post by: O01eg 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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)
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.)

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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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)
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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:


>------ 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?
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: O01eg on May 16, 2018, 04:21:23 PM
It would be useful to use AppVeyor CI and Travis CI to test commits and PRs.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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).
Title: Re: Incorporating changes from Standard
Post by: jamespetts on May 30, 2018, 10:09:19 PM
Excellent, thank you very much: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on July 14, 2018, 10:17:40 AM
Splendid, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on September 18, 2018, 08:17:39 PM
Thank you very much - now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 27, 2018, 09:19:21 AM
I threw a pull request (https://github.com/jamespetts/simutrans-extended/pull/98) for fixing this bug (https://forum.simutrans.com/index.php/topic,18650.0.html) from standard (by prissi). (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 28, 2018, 01:23:37 PM
Splendid, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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 (https://github.com/jamespetts/simutrans-extended/pull/100). 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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).
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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).
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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?
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 10, 2019, 06:46:17 PM
Splendid, thank you for clarifying.
Title: Re: Incorporating changes from Standard
Post by: Ves 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti on January 17, 2019, 04:34:12 PM
Quote from: Ves on January 17, 2019, 03:23:19 PMmore 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).
Title: Re: Incorporating changes from Standard
Post by: Ves 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 (https://forum.simutrans.com/index.php/topic,17470.70.html)
which I believe among other things added sorting.
Title: Re: Incorporating changes from Standard
Post by: prissi 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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).
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: ACarlotti 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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)

Title: Re: Incorporating changes from Standard
Post by: Phystam 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?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 28, 2020, 10:13:30 AM
Yes, if you would like to take this on, do feel free. Thank you.
Title: Re: Incorporating changes from Standard
Post by: Phystam on January 28, 2020, 01:10:18 PM
The last commit by A. Carlotti is trunk r7479. I will start the work from there.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 28, 2020, 01:13:19 PM
Quote from: Phystam on January 28, 2020, 01:10:18 PM
The last commit by A. Carlotti is trunk r7479. I will start the work from there.

Excellent, that is very helpful - thank you.
Title: Re: Incorporating changes from Standard
Post by: Ves on January 28, 2020, 02:24:25 PM
That is great news, thank you!
Title: Re: Incorporating changes from Standard
Post by: Mariculous on January 28, 2020, 06:01:33 PM
Really great news! Thanks a lot!
Title: Re: Incorporating changes from Standard
Post by: Phystam 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 (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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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 (https://github.com/Phystam/simutrans-extended/commit/006ab81fcb7de5dec49b4c5f01e4599fdfa0939f) 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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?
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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?
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: DrSuperGood 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam on January 31, 2020, 07:39:41 AM
Thank you for your comment. So, I do not have to merge "JIT2"-related features, right?
Title: Re: Incorporating changes from Standard
Post by: DrSuperGood on January 31, 2020, 09:58:34 AM
Quote from: Phystam on January 31, 2020, 07:39:41 AMThank 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam on January 31, 2020, 11:12:39 AM
Dr. Supergood,
Thank you for clarifying.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 31, 2020, 11:54:26 AM
Thank you for your work on this - Phystam.
Quote from: Phystam on January 31, 2020, 05:24:26 AMSeeing 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 (https://forum.simutrans.com/index.php/topic,18660.msg184296.html#msg184296) should be removed. Characters cannot protrude from the dialog.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) 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.
Title: Re: Incorporating changes from Standard
Post by: Vladki 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)
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam on February 01, 2020, 03:57:17 AM
until 120.1.1 --> https://github.com/Phystam/simutrans-extended/tree/merge-from-standard120-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 (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.
Title: Re: Incorporating changes from Standard
Post by: Vladki on February 01, 2020, 10:12:26 AM
I'm willing to try these on Stephenson Siemens game.
Title: Re: Incorporating changes from Standard
Post by: Phystam on February 01, 2020, 10:25:47 AM
Vladki - thank you. I believe that it works well ;)
Title: Re: Incorporating changes from Standard
Post by: Vladki 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: Vladki on February 01, 2020, 11:45:50 AM
Using it on real game will bring more testers
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 01, 2020, 12:09:42 PM
Quote from: Vladki on February 01, 2020, 11:45:50 AM
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.
Title: Re: Incorporating changes from Standard
Post by: Vladki on February 01, 2020, 12:20:59 PM
Quote from: Phystam on February 01, 2020, 03:57:17 AMuntil 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(); }
                                                                                                                     ^
Title: Re: Incorporating changes from Standard
Post by: Vladki on February 01, 2020, 12:42:56 PM
I have fixed the above bug - in the last line should be 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
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: Vladki 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: Vladki 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam on February 01, 2020, 01:04:42 PM
You can download from Here (https://cdn.discordapp.com/attachments/514739526330220547/673151533915045888/makeobj-extended.zip).
Title: Re: Incorporating changes from Standard
Post by: Vladki 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?
Title: Re: Incorporating changes from Standard
Post by: Phystam 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).
Title: Re: Incorporating changes from Standard
Post by: Vladki 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
Title: Re: Incorporating changes from Standard
Post by: Mariculous 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.
Title: Re: Incorporating changes from Standard
Post by: Phystam 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 01, 2020, 02:57:46 PM
Quote from: Vladki 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.

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.
Title: Re: Incorporating changes from Standard
Post by: Vladki on February 01, 2020, 04:38:04 PM
Can you provide such build?
Title: Re: Incorporating changes from Standard
Post by: Phystam on February 01, 2020, 05:04:36 PM
For Windows 64bit (mingw build): here ^^  (https://cdn.discordapp.com/attachments/514739526330220547/673211915295522830/Simutrans-Extended.zip)
Title: Re: Incorporating changes from Standard
Post by: prissi 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).
Title: Re: Incorporating changes from Standard
Post by: Phystam 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 (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 (https://github.com/phystam/simutrans-extended/tree/merge-from-standard120-2-2)
Title: Re: Incorporating changes from Standard
Post by: jamespetts 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on March 18, 2020, 12:15:47 AM
Quote from: jamespetts 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.

Were you ever able to check this in the end? I do want to get this integrated if I can.
Title: Re: Incorporating changes from Standard
Post by: Milko on April 14, 2020, 01:59:47 PM

Hello

Does the nightly version already incorporate?

Giuseppe
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 15, 2020, 11:23:35 AM
The current nightly version does not incorporate these latest changes, as I am awaiting confirmation that this does not conflict with the new private car routing and that this has been tested and is stable without loss of synchronisation in network mode.
Title: Re: Incorporating changes from Standard
Post by: Phystam on June 10, 2020, 08:08:42 AM
I have merged the Standard changes upto 120.1.3 (r7753). There's no conflicts around the private car code.
The conflicts are mainly the "headers" that show the license. It is Hajo's name removal.
Github branch: https://github.com/Phystam/simutrans-extended/tree/merge-from-standard120-1-3-fix (https://github.com/Phystam/simutrans-extended/tree/merge-from-standard120-1-3-fix)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 10, 2020, 04:46:13 PM
Thank you for your work on this. I have merged this into my merge-from-standard-june-2020 branch, but I am afraid that I cannot compile this. In Visual Studio, I get the following errors:


Severity Code Description Project File Line Suppression State
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file dataobj\scenario.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file network\network_cmd_scenario.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_city.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_city.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 139
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_const.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 100
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_gui.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_gui.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 139
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_obj_desc.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_obj_desc.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 139
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_obj_desc.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 100
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_player.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 122
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_player.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_player.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 139
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_scenario.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_schedule.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_settings.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_simple.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 100
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_simple.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 144
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_tiles.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_tiles.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 53
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_world.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.h 122
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_world.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\api\api_world.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 139
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *' to 'const SQChar *' (compiling source file script\dynamic_string.cc) Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_function.h 99
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char *const ' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\api_param.cc 176
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [11]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 480
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 109
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 409
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 414
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 428
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 432
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 543
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 560
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 575
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 577
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 602
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 604
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [17]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 630
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [6]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 105
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [6]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 380
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [6]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 463
Error C2664 'void sq_pushstring(HSQUIRRELVM,const SQChar *,SQInteger)': cannot convert argument 2 from 'const char [7]' to 'const SQChar *' Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\script\script.cc 101
Title: Re: Incorporating changes from Standard
Post by: Phystam on June 12, 2020, 10:15:57 AM
I can successfully compile it with my environment (mingw64 compiler). Since I do not have the visual studio environment, I cannot debug it...
the type SQChar is defined at sqconfig.h:104 in #else statement of #ifdef _WIN32. it seems that there is no path when compling with VS environment.
Title: Re: Incorporating changes from Standard
Post by: prissi on June 12, 2020, 01:36:32 PM
I compile standard all the time on MSVC, so this should work. Line 104 is compile on MSVC too.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 13, 2020, 11:11:35 AM
I have looked into this a little further: the problem is complex and intractable. The definition in use is actually not the one at line no. 104 of sqconfic.h, but the one at line 58 of sqconfig.h, since SQUINCODE is defined at line 59 of squirrel.h.

This means that SQChar is actually defined as a wchar_t, which is, in turn, incompatible with all the places in the code which assume that it is a plain char type, for example, line 29 of api_include.cc. Changing const char* in that line to const wchar_t* prevents there from being a compile error in respect of that specific line, but many other compile errors remain.

Undefining SQUINCODE creates other errors and is thus also not the solution.

I do not understand how this code is intended to work, so I am not in a position to fix it within any reasonable amount of time. Does anyone who knows this code have a clearer idea of how this is supposed to work?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 13, 2020, 11:21:37 AM
Could it be the same reason I got stuck trying to compile standard on MSVC with extended's libraries?
I found that I was missing some libraries, so I added them, but there may be other differences.
After all, I didn't know the cause, so I gave up. (´・ω・`)

In the case of extended, the required library can be picked up from the James's repository, but in the case of standard, I didn't know.
Title: Re: Incorporating changes from Standard
Post by: prissi on June 13, 2020, 12:52:29 PM
Could it be that extended compile as wide char by default?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 13, 2020, 02:06:59 PM
This does not look like a library problem, as these are compiler errors rather than linker errors. It may be that there is an incorrect version of a header file somewhere, but that is not quite the same,.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 15, 2020, 11:15:58 AM
I also tried to compile it, but got as many errors as james. However, copying the standard squirrel folder seems to greatly reduce errors ? (´・ω・`)
1>simview.obj : error LNK2019: 未解決の外部シンボル "public: __thiscall rect_t::rect_t(class koord,class koord)" (??0rect_t@@QAE@Vkoord@@0@Z) が関数 "public: void __thiscall main_view_t::display(bool)" (?display@main_view_t@@QAEX_N@Z) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: __thiscall rect_t::rect_t(class koord,class koord)" (??0rect_t@@QAE@Vkoord@@0@Z)" は未解決です。
1>simview.obj : error LNK2019: 未解決の外部シンボル "public: __thiscall rect_t::~rect_t(void)" (??1rect_t@@QAE@XZ) が関数 "public: void __thiscall main_view_t::display(bool)" (?display@main_view_t@@QAEX_N@Z) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: __thiscall rect_t::~rect_t(void)" (??1rect_t@@QAE@XZ)" は未解決です。
1>simworld.obj : error LNK2001: 外部シンボル ""public: __thiscall rect_t::~rect_t(void)" (??1rect_t@@QAE@XZ)" は未解決です。
1>simview.obj : error LNK2019: 未解決の外部シンボル "public: void __thiscall rect_t::mask(class rect_t const &)" (?mask@rect_t@@QAEXABV1@@Z) が関数 "public: void __thiscall main_view_t::display(bool)" (?display@main_view_t@@QAEX_N@Z) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: void __thiscall rect_t::mask(class rect_t const &)" (?mask@rect_t@@QAEXABV1@@Z)" は未解決です。
1>simview.obj : error LNK2019: 未解決の外部シンボル "public: void __thiscall rect_t::discard_area(void)" (?discard_area@rect_t@@QAEXXZ) が関数 "public: void __thiscall main_view_t::clear_prepared(void)const " (?clear_prepared@main_view_t@@QBEXXZ) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: void __thiscall rect_t::discard_area(void)" (?discard_area@rect_t@@QAEXXZ)" は未解決です。
1>simview.obj : error LNK2019: 未解決の外部シンボル "public: bool __thiscall rect_t::operator!=(class rect_t const &)const " (??9rect_t@@QBE_NABV0@@Z) が関数 "public: void __thiscall main_view_t::display(bool)" (?display@main_view_t@@QAEX_N@Z) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: bool __thiscall rect_t::operator!=(class rect_t const &)const " (??9rect_t@@QBE_NABV0@@Z)" は未解決です。
1>viewport.obj : error LNK2019: 未解決の外部シンボル "public: __thiscall rect_t::rect_t(void)" (??0rect_t@@QAE@XZ) が関数 "public: __thiscall viewport_t::viewport_t(class karte_t *,class koord,short,short)" (??0viewport_t@@QAE@PAVkarte_t@@Vkoord@@FF@Z) で参照されました。
1>gui_world_view_t.obj : error LNK2001: 外部シンボル ""public: __thiscall rect_t::rect_t(void)" (??0rect_t@@QAE@XZ)" は未解決です。
1>simworld.obj : error LNK2001: 外部シンボル ""public: __thiscall rect_t::rect_t(void)" (??0rect_t@@QAE@XZ)" は未解決です。
1>export_objs.obj : error LNK2019: 未解決の外部シンボル "void __cdecl export_control(struct SQVM *)" (?export_control@@YAXPAUSQVM@@@Z) が関数 "void __cdecl register_export_function(struct SQVM *)" (?register_export_function@@YAXPAUSQVM@@@Z) で参照されました。
1>simworld.obj : error LNK2019: 未解決の外部シンボル "public: unsigned int __thiscall rect_t::fragment_difference(class rect_t const &,class rect_t * const,unsigned int)const " (?fragment_difference@rect_t@@QBEIABV1@QAV1@I@Z) が関数 "public: void __thiscall karte_t::prepare_tiles(class rect_t const &,class rect_t const &)" (?prepare_tiles@karte_t@@QAEXABVrect_t@@0@Z) で参照されました。
1>simworld.obj : error LNK2019: 未解決の外部シンボル "public: bool __thiscall rect_t::operator==(class rect_t const &)const " (??8rect_t@@QBE_NABV0@@Z) が関数 "public: void __thiscall karte_t::prepare_tiles(class rect_t const &,class rect_t const &)" (?prepare_tiles@karte_t@@QAEXABVrect_t@@0@Z) で参照されました。
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 9 件の未解決の外部参照


I also tried this but it had no effect.
https://git.k-4u.nl/koenk/openttd/-/commit/dcc2da107ac878b6852ead60377b09228d59d6fd
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 19, 2020, 03:15:46 PM
I think it was stuck because it was difficult to understand the cause of the problem because it was carried out all at once.
I thought it would be worthwhile to move forward little by little, so I did it a bit. Because stopping for a long time again creates a lot of competition.

I'm using MSVC, so I might be able to proceed to where the previous problem occurred.

The branch is below.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-7556

The compilation completed successfully in my environment. However, the code check on github shows an error as follows. (´・ω・`)
https://github.com/Ranran-the-JuicyPork/simutrans-extended/runs/1003607665

Does anyone know about this issue?


EDIT:
I found some errors in Phystam's commit and fixed it. The compile error in my post above looks like the same. (simview error may be another issue)
Title: Re: Incorporating changes from Standard
Post by: Matthew on August 19, 2020, 03:56:54 PM
Quote from: Ranran on August 19, 2020, 03:15:46 PM
The compilation completed successfully in my environment. However, the code check on github shows an error as follows. (´・ω・`)
https://github.com/Ranran-the-JuicyPork/simutrans-extended/runs/1003607665

Does anyone know about this issue?

I know nothing about C++ or Github Actions.

But it says that it is a code check and that it is looking for trailing whitespaces.

And all the "-" lines that I studied end with a trailing whitespace or are an empty line beginning with a tab:

(http://i.imgur.com/rBcJXRp.png)

These trailing whitespaces exist in Ranran's std-7556 branch, but not in James' master branch.

I guess that maybe it's because Windows line endings have been changed to Linux line endings or something similar???

Maybe you can just delete those trailing whitespaces and tabs in empty lines?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 19, 2020, 04:40:39 PM
@Matthew-Thanks, it seems to work fine.
Title: Re: Incorporating changes from Standard
Post by: ceeac on August 19, 2020, 04:47:22 PM
For Visual Studio, there are some extensions like this one (https://marketplace.visualstudio.com/items?itemName=MadsKristensen.TrailingWhitespaceVisualizer) which automatically removes trailing whitespace on save.
(The fact that, as far as I know, a full-blown IDE like Visual Studio does not ship with an option to automatically remove trailing whitespace is a major WTF in itself, imo.)
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 26, 2020, 02:59:22 PM
I think I've identified and resolved a problem that didn't compile. Please check pull request #268.


1) You changed the function type in the header file, but not the cc file.
I'm wondering if this didn't give an error in mingw.

2) New files were added but it couldn't compile with MSVC as you only updated the Makefile and the project file for standard. (r7811)


Almost I just imported Phystam's commits as is, but I think you can merge the previous import work up to r8125.
Thanks to Phystam for his work so far.

I happened to notice that Phystam didn't incorporate the commit that saves the opened dialog even if quit the game by exit (r7642), and I incorporated it, but basically I just picked commits by Phystam and resolve conflicts and fixed errors.  So note that I did almost no such checking.



Quote from: Phystam on February 05, 2020, 08:44:03 AMNow 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
EDIT:
I'm currently working on resolving r8134 conflicts. I think it's easier to convert only when displaying than to attach color_idx_to_rgb to all.
This is likely to be time consuming as it requires testing with a huge amount of changes.

EDIT2:
It looks like it was still in the works and I get over 1000 errors on compilation. There were many color variables and misspellings that weren't replaced yet. (´・ω・`)

EDIT3:
r8134 is a major change and must be incorporated separately later. It turns out that this change requires the save to be distinct and the version number to be incremented.
Title: Re: Incorporating changes from Standard
Post by: Phystam on August 27, 2020, 07:18:46 AM
Thank you, ranran.
Quote from: Ranran on August 26, 2020, 02:59:22 PM
EDIT:
I'm currently working on resolving r8134 conflicts. I think it's easier to convert only when displaying than to attach color_idx_to_rgb to all.
This is likely to be time consuming as it requires testing with a huge amount of changes.
Probably your solution is better than the original one. Is it okay for making differences in the code between Standard and Extended? (but no differences when executing, right?)
Title: Re: Incorporating changes from Standard
Post by: prissi on August 27, 2020, 01:10:28 PM
The color... was then done by search and replace and then the few occasions where it is not possible, were put back.

But anything than a release may have serious errors, although not 1000 ;)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 27, 2020, 01:17:38 PM
Thank you very much for your work on this, Ranran: this is extremely helpful. I am a little wary of incorporating such large changes before the issue relating to the losses of synchronisation can be tracked down, since, if this merge introduces any new loss of synchronisaiton error, it would make both that error and the original error orders of magnitude harder to track down; and given the presence of the existing error, there is no reliable way of testing whether this introduces any new error, since we do not know whether any loss of synchronisation is caused by the existing or new error.

I am not sure whether Freddy, Freahk, Ceeac or any others who have worked on loss of synchronisation errors in the past have any views on this in particular; it would be helpful to have input on this question, since I am keen on making use of this work, but do not want to risk making the loss of synchronisation error harder to find.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on August 27, 2020, 02:19:07 PM
Though I cannot say for sure, I support these changes in principle and don't think they should make synchronisation errors harder to find.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 27, 2020, 02:38:11 PM
Quote from: freddyhayward on August 27, 2020, 02:19:07 PM
Though I cannot say for sure, I support these changes in principle and don't think they should make synchronisation errors harder to find.

The particular problem is if these changes introduce a new synchronisation error: it is not possible to test for this without first fixing the existing error, as we cannot know whether any given loss of synchronisation is caused by the existing error or a new error.

Similarly, if this were to introduce a new loss of synchronisation error, a step taken to change the code either to try to fix the current error or temporarily to disable a part of the code to narrow it down may not result in a noticeable change if these changes were to introduce a different loss of synchronisation error undetected.

Merging changes from Standard is immensely complex and has been the cause of loss of synchronisation errors in the past. Are you able to see any specific way of ameliorating the specific problems set out above to allow us to integrate these changes earlier than we fix the loss of synchronisation?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 27, 2020, 02:44:36 PM
Is the sync error currently occurring only on the bridgewater server?
If so, another server will be able to see the desync if this change is the cause.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 27, 2020, 02:46:39 PM
Quote from: Ranran on August 27, 2020, 02:44:36 PM
Is the sync error currently occurring only on the bridgewater server?
If so, another server will be able to see the desync if this change is the cause.

I believe that there has been a report on the Discord channel of the loss of synchronisation happening also on the Stepehenson-Seimens server.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on August 27, 2020, 02:54:00 PM
Quote from: jamespetts on August 27, 2020, 02:46:39 PM
I believe that there has been a report on the Discord channel of the loss of synchronisation happening also on the Stepehenson-Seimens server.
Phystam has also reported a number of synchronisation errors on his server.
Title: Re: Incorporating changes from Standard
Post by: Mariculous on August 27, 2020, 03:43:31 PM
I agree with James thoughts.
If those changes introduce any additional desyncs, it will take much longer to realise this.

Anyway, imho this should not slow down the progress of incorporating changes from standard.
In general, changes from standard are usually rather well-tested, so it is unlinkely those introduce new issues on their own.

I clearly support incorporating these changes.

Quote from: jamespetts on August 27, 2020, 02:46:39 PMI believe that there has been a report on the Discord channel of the loss of synchronisation happening also on the Stepehenson-Seimens server.
I do not think so. It was noticed that the desyncs are likely related to "no route" vehicles, so Freddy tested this with an old stephenson-siemens save, where a lot of such convoys existed as a result from introducing the light rail electrification constraint.

Stephenson-siemens server seems to run very stable with barely any desyncs.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 27, 2020, 04:26:32 PM
Quote from: Freahk on August 27, 2020, 03:43:31 PM
Stephenson-siemens server seems to run very stable with barely any desyncs.

"Barely any" suggests that there are some; if this server simply has the condition that causes these losses of synchronisation occur much less frequently, which would not be surprising, as this is a much smaller game world, then, given that the losses of synchronisation are in any event quite infrequent, it is not unexpected they would be extremely infrequent on the Stephenson-Seimens server, and therefore conform to the description of "barely any", especially as that server seems to be played less at present. Thus, that there are at least some losses of synchronisation on the Stepenson-Seimens server means that we cannot be sure that the losses of synchronisation are caused by anything that is present on the Bridgewater-Brunel server (and Phystam's server) but not on the Stephenson-Seimens server.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 28, 2020, 03:25:30 AM
I reduced r8134 merging compilation errors to 140, but those errors seem to be due to files unrelated to this commit.
The error is similar to the error reported by james in post #95 in this thread.
Quote from: jamespetts on June 10, 2020, 04:46:13 PMIn Visual Studio, I get the following errors:
This error was due to additional files related to sqapi not being registered in the project file. Therefore I suspect Pyhstam may have missed sqapi-related commits this time as well. (´・ω・`)

At least r7844 has greatly reduced this error.


EDIT:
Currently, the file related to api_command exists in the master branch, but it seems to be just sanity because it is not described in Makefile or project file. This means that a set of features doesn't work like standard, but if you include it, it won't compile with an error.
The incorporating and maintenance related to this seems to have been omitted. I wonder if it's useless to maintain this feature if it doesn't fix it.
Title: Re: Incorporating changes from Standard
Post by: Phystam on August 28, 2020, 05:19:48 PM
Sqapi is not maintained so far, so it is already almost broken. James and Acarlotti said that, so my work does not include the changes in sqapi functions from a certain commit.
And I do not use the VS and I cannot understand the configure files of VS. I'm sorry if I missed it.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 29, 2020, 11:17:54 AM
Phystam is correct - because of the very large amount of work to incorporate the scripting API into Extended and because this is not a core feature of the intended open-ended Extended gameplay, this has not been fully integrated and currently does not work. I have not removed it entirely in case somebody might want to make it work in Extended, but that would be a large job and I am not sure how worthwhile that that would be in terms of the resulting gameplay quality. I wonder whether there should be some code comments in Extended to this effect?
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on August 29, 2020, 01:31:02 PM
Quote from: jamespetts on August 29, 2020, 11:17:54 AM
Phystam is correct - because of the very large amount of work to incorporate the scripting API into Extended and because this is not a core feature of the intended open-ended Extended gameplay, this has not been fully integrated and currently does not work. I have not removed it entirely in case somebody might want to make it work in Extended, but that would be a large job and I am not sure how worthwhile that that would be in terms of the resulting gameplay quality. I wonder whether there should be some code comments in Extended to this effect?
I don't see the purpose in retaining the code in extended. It makes development more complex for no benefit at all, and if somebody wanted to integrate it in the future, they could simply copy the code from standard. That would likely be far easier than attempting to resurrect the current mess.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 29, 2020, 02:09:52 PM
Quote from: freddyhayward on August 29, 2020, 01:31:02 PM
I don't see the purpose in retaining the code in extended. It makes development more complex for no benefit at all, and if somebody wanted to integrate it in the future, they could simply copy the code from standard. That would likely be far easier than attempting to resurrect the current mess.

Thank you - that is a helpful suggestion. Can I check what others' views of this are, especially those who contribute to coding?
Title: Re: Incorporating changes from Standard
Post by: Phystam on August 29, 2020, 02:27:00 PM
1. almost everyone wants to compete with real players instead of AI players.
2. no one can/wants to make scenario files currently.
So I agree that we remove Sqapi scripting features from Extended.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 29, 2020, 02:43:56 PM
Quote from: Phystam on August 29, 2020, 02:27:00 PM
1. almost everyone wants to compete with real players instead of AI players.
2. no one can/wants to make scenario files currently.
So I agree that we remove Sqapi scripting features from Extended.

That is helpful - thank you. No. 1 certainly reflects my own preferences and project aims for Extended. Real humans are much more complex and fun than any AI that anyone is realistically likely to be able to write for Simutrans-Extended in the foreseeable future.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 30, 2020, 03:36:35 PM
I'm trying to merge r8303 - "Unicode support with long path, DSG flavor", but I suspect it lacks the required libraries. Any information on this?
Title: Re: Incorporating changes from Standard
Post by: ceeac on August 30, 2020, 04:52:01 PM
If you mean the build failures, you can check the build logs:

simsound.cc:196:68: error: cannot pass object of non-trivial type 'std::string' (aka 'basic_string<char>') through variadic method; call will abort at runtime [-Wnon-pod-varargs]
          dbg->warning("midi_init()","can't open file '%s' for reading.", full_path);
                                                                          ^

You need to use full_path.c_str().


===> LD  ../build/default/makeobj-extended/makeobj-extended
/usr/lib/gcc/x86_64-w64-mingw32/9.2.1/../../../../x86_64-w64-mingw32/bin/ld: ../build/default/utils/log-makeobj-extended.o:log.cc:(.text+0x75b): undefined reference to `dr_fopen(char const*, char const*)'

You need to use fopen() instead dr_fopen() in log.cc. This error was fixed in r8308 (commit 14e70ca0ef). I believe something similar is required for Nettool.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 31, 2020, 12:05:44 PM
I'm currently merging standard120.3, but I don't know how to set the correct Makefile for each compiler, so I'm not sure how to fix it. It seems that it is useless even if it is the same as standard except the link. (´・ω・`)
I would appreciate any help with this. Thank you in advance.


It compiles correctly with my MSVC. However, new files for miniupnpc and freetype are required.

github branch is here
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r8434-TT-fonts

EDIT:
Currently only mingw can't build

EDIT2:
Ceeac solved this problem. Thank you very much.  :)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on September 02, 2020, 09:29:13 PM
Thank you to both of you for this - this is much appreciated.

As noted, we have an unfortunate problem with merging this at present, which is the need to track down the loss of synchronisation issue before merging in changes that have a non-zero chance of introducing an independent loss of synchronisation problem, and thus making the existing one exponentially harder to find.

The difficulty is that the current loss of synchronisation issue has so far proven intractable, and is thus likely to take an extremely long time (many, many months) of intensive work to resolve: because the time to reproduce the issue is currently many hours, I can only test one small change a day to narrow down the issue, and, given that many hundreds of small changes need to be tested to narrow down the issue effectively, the amount of time that it will take to resolve this may be quite extreme.

If anyone is able to help with the loss of synchronisation issue (including finding a faster reliable reproduction of the loss of synchronisation on a local server/client), that might greatly expedite the ability to merge in the excellent work that is being done here in relation to incorporating the changes from Standard.

Thank you all for your work on this.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on September 13, 2020, 06:22:22 AM
As I reported in another thread, I'm currently working on a standard's commit merge with a GUI focus.
I leave a post so I don't forget, as there will be so many changes in the end. Because I don't remember much about these anymore. (´・ω・`)

Quote
There will be three changes in the GUI coding in the near future.

(1) r8134(120.2.2) - The color definition is extended from 8bit to 16bit.
Therefore, it is necessary to deal with the change of variables and functions. This is what I am working on now and is almost complete.

(2) r8434(120.3) - Support for truetype fonts and large fonts.
Players will be able to select their favorite font in settings. You can easily change the font from the setting dialog.
This will require revising the layout and variables.
Now that the basic import is complete, I'll pick up the related commits.

(3) r8653 - GUI overhaul
This requires a rewrite of the all GUI code. Create a GUI to place components in tables and cells. This requires a lot of work and an extended-specific GUI can require a lot of work. This is why some people advised to wait until this stage for making a new GUI.
The patches are roughly divided into the above three parts.

The ones before r8134 are repairs of what phystam was previously doing.
Here is the one that incorporates the commits related to GUI and drawing from (1) to (2) and (3) regardless of (2).
The standard version is 120.2.2. It's ready to merge.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r8134-fix

This hasn't changed much in appearance, and I don't think there are any major problems at the moment.


Release of 120.1.2: (r7720 on 7-Jan-2016):
ADD: configurable compass for minimap, rotation tool, and main screen

Release of 120.2: (r8077 on 12-Feb-2016):

Release of 120.2.2: (r8163 on 31-3-2017):
FIX: Combo boxes now work much more reliable
ADD: All configurable colors now rgb internally

The standard version corresponds to 120.2.2.
With a small change, the UI layout is reloaded when restarting even with auto save. (For some reason it is not listed there.)
Phystam may be more familiar with the changes in this patch.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on September 13, 2020, 07:35:57 AM
After (1)r8134, as already explained, In order to reach the GUI overhaul, I am mainly focusing and merging on commits related to GUI and drawing.
The commits related to system and sqapi are omitted. However, at first glance it seems that something important is often already captured by A Carlotti.
I would be grateful if Phystam or someone interested in doing this would do the leftover commits.
However, in the end, many commits were incorporated because incorporating is unavoidable if it affects them. (´・ω・`)

It should be noted that sqapi related files are corrupted from the beginning with extended, and incorporating changes related to them may make compilation impossible. That was the reason why phystam got stuck last time, and it happened once after that. This can be related to multiple major changes.



Quote
(2) r8434(120.3) - Support for truetype fonts and large fonts.
Players will be able to select their favorite font in settings. You can easily change the font from the setting dialog.
This will require revising the layout and variables.
Now that the basic import is complete, I'll pick up the related commits.

github branch is here:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r8434-TT-fonts
This includes commits just before the GUI overhaul (r8653). It contains a great many changes. I think we need to check carefully.
Many network-related changes have been incorporated.
You will need freetype.dll and miniupnpc.dll to build it.


Release of 120.3 (r8503 on 15-June-2018):
ADD: new blue-white theme
ADD: Support Truetype fonts on windows up to 19 pts. For MAC and Linux support there is a way needed to find the font path.
ADD: Server can be now started at the UI when loading a game.
ADD: switch -easyserver on commandline to host a game with dynamic IP behind a router
FIX: added Unicode file path support for Windows builds

Release of 120.4 (r8588 on 17-Sep-2018):
FIX: properly handle dualstack servers by using both IPv4 and IP6 addresses (if no symbolic name is available)


Regarding themes, many themes other than the above will be added. Also, the existing folder contains a broken theme that needs to be removed. It can cause a crash.





What I haven't taken:
CHG: pedestrian movement, new dat parameter:
offset (of pedestrian image relative to right tile boundary, 0..255, default 20, 0 = on the right edge of tile, 128 = on center line of tile

(r8254, 8255) This may be related to the strange pedestrian movement we reported earlier. But there are already many differences between extended and standard. There will also be changes to makeobj.



ADD: (HyperSim) sorting vehicles in depot
ADD: sorting in depot (HyperSim)

The structural difference is too big for me to merge. We have to write the code almost on your own...



ADD: (THLeaderH) option to hide the revenue income messaging at stops

This will be done after the incorporation of r8843 from the viewpoint of saving time and effort.  :done: EDIT: Merged into r8653 branch.



ADD: More factory locations (shore, river, forest) to the existing city, water, land

This adds new location requirements to the industry. The industry is complicated and involves various factors, which can be difficult and was not incorporated.


OPT: significantly improved the performance of changing underground mode/slice when playing on very large maps

(r8561) I don't know much about these codes because of the large amount of changes.
The underground display on the bridge water server took a long time, but will that be improved?
According to Freddy this was already merged into the master branch.





The font size is selectable, but some dialogs don't handle this correctly.
For example, the line spacing may be too narrow, or the symbol position may be displayed upwards.
standard has stayed in this version for a long time, but we don't have to stay in this version for a long time. So I think it's useless to spend a lot of time fixing it.
Therefore, this patch is incomplete.

And there is one more broken part. The buttons on the save / load screen do not work. Therefore, you have to enter the text directly. (´・ω・`)
I don't know how to fix this, but the reason it was caused is that the structure of this screen is very different between standard and extended.
The code has been rewritten by Bernd Gabriel and this dialog is tabulated.
In pakselector, as I pointed out earlier, the broken load addons button was repaired with incorporating from standard, but on the other hand, in the loadsave dialog, the file button is now broken.
Many GUIs will be tabulated by the GUI overhaul that comes after this. So I thought Bernd Gabriel's table code would be useless anymore, so I didn't fix it at this stage.

I would appreciate it if you could check this patch and the next patch and let us know what you think.


merged commit lists up to r8500. It does not include what is already merged.

7611
7844 7865 7870 7908 7911 7932 7937 7939
8075 8123 8125 8134 8138 8151 8154 8159 8169 8176 8181 8187 8193 8197
8200 8203 8204 8205 8207 8210 8213 8217 8221 8223 8231 8271 8279 8287
8305~09 8312 8314 8315 8316 8317 8319~21 8324 8325 8335 8338 8343 8345 8365 8373 8379 8382 8384 8386 8396 8399
8400 8401 8402 8403 8405 8423 8428 8431 8433 8434-44,8447-50 8451 8453~55 8457 8459~61 8465 8466 8474 8476 8477 8478 8484 8488 8489 8490 8495 8496

Title: Re: Incorporating changes from Standard
Post by: freddyhayward on September 13, 2020, 08:36:46 AM
Quote from: Ranran on September 13, 2020, 07:35:57 AMThe underground display on the bridge water server took a long time, but will that be improved?
I had already merged that patch. It improved performance quite a lot, but introduced a new visual bug. Somehow, your branch seems to have improved the performance as well, but I'm not sure.
I have tested your branch and there are many visual bugs: stop labels, UI text (until theme is changed), and cursor are all discolored. Windows are too large and UI elements have too much spacing. I hope these and other issues can be resolved as this branch will be very valuable in the long-term.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on September 13, 2020, 09:16:19 AM
Thank you for testing it.
Quotecursor are all discolored.
Can I ask what the cursor is pointing to?

EDIT:
The tile cursor is specified by cursor_overlay_color for each theme. The default (undefined) is red.
I don't know where the source for the extended standard theme is, but it's probably due to the theme settings.
(EDIT2) That dat file seems to be missing.

Quotestop labels, UI text (until theme is changed). Windows are too large and UI elements have too much spacing.
Can you explain these? Extended's standard theme settings may be corrupted (slate blue one). I don't know where the source is. I don't think extended has supported the theme properly so far.
(EDIT2) The processing at the first startup may not be correct.

It also certainly looks like there is no color correspondence for Bernd Gabriel's table code.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on September 13, 2020, 12:18:54 PM
here are some screenshots:
(https://i.imgur.com/zBSCKSA.png)
(https://i.imgur.com/EUaHCYq.png)
(https://i.imgur.com/RCUZeyF.png)
(https://i.imgur.com/2ac7RSF.png)
(https://i.imgur.com/oW15OlB.png)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on September 13, 2020, 02:22:58 PM
Thank you for your work on this - I have been working on test merging this. I have been able to merge some of the earlier changes successfully, and these have been pushed to my merge-from-standard-september-2020 branch for testing. Initial testing suggests that this is stable.

However, I have not been able to compile any later version than this. I have tried merging the latest version into the merge-from-standard-september-2020 branch, but the result is uncompilable. In particular, I seem to be missing two header files, miniupnpc.h and upnpcommands.h.
Title: Re: Incorporating changes from Standard
Post by: Roboron on September 13, 2020, 02:56:06 PM
Quote from: jamespetts on September 13, 2020, 02:22:58 PMIn particular, I seem to be missing two header files, miniupnpc.h and upnpcommands.h.

You need libminiupnpc. If compiling with MINGW, you will need to compile libminiupnpc yourself (it seems to be broken). Otherwise install libminiupnpc-dev/miniupnpc/miniupnpc-devel if you are on Debian/Arch/Fedora&OpenSUSE.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on September 13, 2020, 03:06:23 PM
Quote from: Roboron on September 13, 2020, 02:56:06 PM
You need libminiupnpc. If compiling with MINGW, you will need to compile libminiupnpc yourself (it seems to be broken). Otherwise install libminiupnpc-dev/miniupnpc/miniupnpc-devel if you are on Debian/Arch/Fedora&OpenSUSE.

On my development system at home, I use Visual Studio; I notice that the continuous integration builds on Github also fail with this branch, so something will need to change somewhere to allow these to work.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on September 13, 2020, 03:10:25 PM
Quote from: jamespetts on September 13, 2020, 02:22:58 PMI seem to be missing two header files, miniupnpc.h and upnpcommands.h.
I'm not sure if it needs all or some of the attached files.

And after r8434 branch, work is still in progress.
There are 8134 branches that appear to be stable, 8434 and 8653 that have incorporated many changes and need to be checked, and 8653 is in the works. The 8434 has some problems as explained above.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on September 13, 2020, 03:14:32 PM
Thank you for that. Can I check what the licence is for miniupnpc so that I know whether these files can be incorporated into the Github repository?

Edit: It appears that, even with that .zip file, the file miniupnpc_declspec.h is still missing.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on September 13, 2020, 03:24:19 PM
MiniUPnP Project
Copyright (c) 2005-2017, Thomas BERNARD
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

    * Redistributions of source code must retain the above copyright notice,
      this list of conditions and the following disclaimer.
    * Redistributions in binary form must reproduce the above copyright notice,
      this list of conditions and the following disclaimer in the documentation
      and/or other materials provided with the distribution.
    * The name of the author may not be used to endorse or promote products
  derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

You can download it from here.
http://miniupnp.free.fr/files/


EDIT:
The problem Freddy pointed out seems to be that the color of the cursor is rewritten when the setting dialog is opened.
EDIT2:
It was because Phystam was ignoring some lines in the first merge operation.
I have not yet investigated the line spacing size of the display setting dialog and scrolled_list.
EDIT3:
The size of the display setting dialog is a standard's new specification, not a bug.
Opens a window with the default size. This dialog will change significantly in the near future after all.
Under the new specifications, the font size will change, so fixed dialog sizes will not match.
Also, the r8653 patch has completely redesigned the display setting dialog.


The missing file may be in this
https://simutrans-germany.com/files/upload/miniupnpc.zip
Title: Re: Incorporating changes from Standard
Post by: prissi on September 14, 2020, 02:20:56 AM
Easiest to obtain minupnpc is using the script from the standard technical documentation for MINGW64. Apart from downloading, it also compiles the lib files for MSVC and has all the h files.
https://forum.simutrans.com/index.php/topic,20271.0.html

However, minupnpc is only relevant if someone wants to set up a server at home behind a router and does not want to set up port forwarding by hand. With the large extended savegame size, ADSL is not very well suited for that, so one could as well set USE_PNP=0 and postpone this for normal development.

The github built for standard also contain provisions for freetype see here (Librotli is also broken on Mingw, and this is needed by freetype):
https://github.com/aburch/simutrans/tree/master/.github
Title: Re: Incorporating changes from Standard
Post by: Mariculous on September 14, 2020, 11:20:14 AM
Imho, the server build should usually be built without upnpc. It's simply unusual to run a headleass server at home and even if someone wanted to do this, he will most likely know how to setup port forwarding.

In case, nightlies of the client should be compiled with it.
Many home internet connections got 50 Mbit/s upstream, which is still more than enough, given we got players with much less downstream playing actively on bridgewater.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 10, 2020, 12:29:10 PM
Thank you for this. I have now managed to get the miniupnpc working, but I am missing a freetype dependency, freetype.lib. May I ask where you obtained the freetype.lib file so that I can find this easily?

Thank you for your work on this so far.
Title: Re: Incorporating changes from Standard
Post by: Mariculous on October 10, 2020, 04:43:48 PM
From the simutrans repository on git (https://github.com/aburch/simutrans):
QuoteThe following are also recommendend, but optional
libfreetype (http://www.freetype.org/)
libminiupnpc (http://miniupnp.free.fr/)

Thus, I believe https://www.freetype.org/download.html (https://www.freetype.org/download.html) is the official download source.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 10, 2020, 05:41:20 PM
Quote from: Freahk on October 10, 2020, 04:43:48 PM
From the simutrans repository on git (https://github.com/aburch/simutrans):
Thus, I believe https://www.freetype.org/download.html (https://www.freetype.org/download.html) is the official download source.

The download that I found there did not include the Windows .lib file; is this not available anywhere pre-compiled?
Title: Re: Incorporating changes from Standard
Post by: Andarix on October 10, 2020, 05:46:32 PM
https://github.com/Andarix/simutrans/tree/master/libs (https://github.com/Andarix/simutrans/tree/master/libs)

windows libs compile msvc 2019

miniupnpc not compile on my Windows 10 2004 and msvc 2019
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 11, 2020, 12:35:48 AM
Andarix - thank you for that. I shall investigate this to-morrow.

One potentially extremely challenging problem that I foresee with adding new libraries is the need to obtain working cross-compilation libraries to allow the nightly builds to work: Windows builds are compiled on a Linux server. I recall spending a truly vast amount of time a few years ago struggling with this issue for the existing libraries.

Has anyone managed to get cross-compiling to work with these new libraries?
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on October 11, 2020, 02:02:28 AM
Quote from: jamespetts on October 11, 2020, 12:35:48 AM
Andarix - thank you for that. I shall investigate this to-morrow.

One potentially extremely challenging problem that I foresee with adding new libraries is the need to obtain working cross-compilation libraries to allow the nightly builds to work: Windows builds are compiled on a Linux server. I recall spending a truly vast amount of time a few years ago struggling with this issue for the existing libraries.

Has anyone managed to get cross-compiling to work with these new libraries?
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?
Title: Re: Incorporating changes from Standard
Post by: Matthew on October 11, 2020, 04:33:34 AM
Quote from: freddyhayward on October 11, 2020, 02:02:28 AM
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?

The Github Actions configurations that ceeac kindly made are all using Ubuntu. So if they are used as a base, using Github CI is cross-compiling, isn't it?

My sim-mingw-debug branch is an attempt to do that. It is very much work-in-progress; at the moment I am still learning how makefiles work, especially in conjunction with James' shell script.

Github does offer Actions using Windows, with the MSYS2 distribution of MinGW available in the default image. However, I believe GCC and MSVS builds of Simutrans are not interoperable. I don't know whether using MSYS2 to build on Windows would be easier than cross-compiling or not.
Title: Re: Incorporating changes from Standard
Post by: Andarix on October 11, 2020, 04:37:02 AM
Quote from: freddyhayward on October 11, 2020, 02:02:28 AM
I can't help with cross-compiling, but couldn't you switch to using the github CI builds?

see https://github.com/Andarix/simutrans/blob/master/.github/workflows/windows.yml (https://github.com/Andarix/simutrans/blob/master/.github/workflows/windows.yml)

I create the builds with Git action.
https://github.com/Andarix/simutrans/releases (https://github.com/Andarix/simutrans/releases) not all testet

[EDIT]
Compiling miniupnpc itself is not the problem. Only the created lib cannot be linked to Simutrans.

https://simutrans-germany.com/files/upload/miniupnpc.lib.zip (https://simutrans-germany.com/files/upload/miniupnpc.lib.zip) (to 9 dec 2020)

Quote1>miniupnpc.lib(minissdpc.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__GetBestRoute@12".
1>miniupnpc.lib(minissdpc.obj) : error LNK2001: Nicht aufgelöstes externes Symbol "__imp__GetIpAddrTable@12".

(https://forum.simutrans.com/index.php?action=dlattach;topic=18156.0;attach=29301;image)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 11, 2020, 10:43:54 AM
Thank you for that. I am getting the same sorts of errors as Andarix now that I have linked to the supplied Freetype libraries. My errors in Visual Studio are:


Severity Code Description Project File Line Suppression State
Error LNK2001 unresolved external symbol FT_Init_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Init_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Done_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Done_FreeType Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_New_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_New_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Done_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Done_Face Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol FT_Set_Pixel_Sizes Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Load_Glyph Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Render_Glyph Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Get_Char_Index Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\font.obj 1
Error LNK2001 unresolved external symbol FT_Get_Char_Index Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\loadfont_frame.obj 1
Error LNK2001 unresolved external symbol __imp_freeUPNPDevlist Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_upnpDiscover Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_GetValidIGD Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_FreeUPNPUrls Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_GetExternalIPAddress Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_AddPortMapping Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK2001 unresolved external symbol __imp_UPNP_DeletePortMapping Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\network.obj 1
Error LNK1120 15 unresolved externals Simutrans-Extended C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe 1
Title: Re: Incorporating changes from Standard
Post by: prissi on October 11, 2020, 01:27:56 PM
FT_xxx missing  means missing freetype library ... You need to specify freetype.lib as library somewhere.

The __imp_ xxx come linking to a DLL. I am sending you my libd and includes.
Title: Re: Incorporating changes from Standard
Post by: Andarix on October 11, 2020, 03:37:15 PM
Quote from: prissi on October 11, 2020, 01:27:56 PM
FT_xxx missing  means missing freetype library ... You need to specify freetype.lib as library somewhere.

The __imp_ xxx come linking to a DLL. I am sending you my libd and includes.

libd is debug

I compile release. Debug-dll not exist by not install MSVC
Title: Re: Incorporating changes from Standard
Post by: prissi on October 12, 2020, 12:11:08 AM
Well, I use static libs.
Title: Re: Incorporating changes from Standard
Post by: Roboron on October 12, 2020, 06:25:47 PM
Quote from: Matthew on October 11, 2020, 04:33:34 AMMy sim-mingw-debug branch is an attempt to do that. It is very much work-in-progress; at the moment I am still learning how makefiles work, especially in conjunction with James' shell script.

I've wanted for a long time to cross-compile Simutrans on my system, and only recently (and after dealing with mingw on windows, too) I learned how to do it. I've documented what I've learned cross compiling Simutrans on the wiki (https://simutrans-germany.com/wiki/wiki/en_Cross-Compiling_Simutrans). You may find it useful.
Title: Re: Incorporating changes from Standard
Post by: Matthew on October 13, 2020, 11:39:41 AM
Quote from: Roboron on October 12, 2020, 06:25:47 PM
I've wanted for a long time to cross-compile Simutrans on my system, and only recently (and after dealing with mingw on windows, too) I learned how to do it. I've documented what I've learned cross compiling Simutrans on the wiki (https://simutrans-germany.com/wiki/wiki/Cross-Compiling+Simutrans). You may find it useful.

Thank you for this suggestion and for kindly documenting it on the wiki, Roboron. It's so helpful when Simutransers document the things they've learned for others to use!

It seems that your strategy uses MXE, which is a makefile to cross-compile the libraries from source. That approach makes sense for you since you're already self-compiling most of your software on Arch. But it's an awkward fit with Github Actions, which start with a clean Ubuntu installation (or MSYS2 on Windows). Compiling the whole of MXE after every (Simutrans) commit seems like using a sledgehammer to crack a nut. But I will bear it in mind while I continue watching Andarix's experiments.
Title: Re: Incorporating changes from Standard
Post by: Roboron on October 13, 2020, 11:49:39 AM
Quote from: Matthew on October 13, 2020, 11:39:41 AMIt seems that your strategy uses MXE, which is a makefile to cross-compile the libraries from source.

I think you didn't read the article well enough. I suggested two approachs:

QuoteFor installing mingw64 on a GNU/Linux machine, you generally have two options: install from your distribution repositories or install the MXE enviroment

1. Cross-Compile using mingw64 from your system repositories (I only have listed packages for Fedora and and extra repositories for Arch Linux - I don't know what mingw64 packages are necessary on Ubuntu).
2. OR Cross-Compile using mingw64 from MXE (if you can't get mingw64 from your distribution!).

Also, you don't need to compile all the MXE software if you don't want to, I said that in the wiki page too...

QuoteThis will build all necessary dependencies. If you don't want to compile them (it will take a while), you can also download binaries from https://pkg.mxe.cc/
Title: Re: Incorporating changes from Standard
Post by: prissi on October 13, 2020, 02:10:12 PM
Ubuntu has a mingw64 cross compiling (at least debian has)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 16, 2020, 05:56:16 PM
Thank you very much for all your feedback and especially to prissi for sending me the library and include files. I have now put the files that Prissi has sent into my respective include and lib directories, but I am afraid that I am still getting the same errors. Since this is a linker error (LN2001: unresolved external symbol), this means that there is a series of method/variable names referred to in header files that are not actually defined in the library files linked.

This is very odd, since I have put the library files in the some directories that I have set up (one for freetype and the other for miniupnpc), and then added these locations to the list of library files for the relevant build. Moreover, I know that the problem is not that I have mis-specified a directory somewhere, since, if I rename freetype.lib, I get a different error, "cannot open freetype.lib", which reverts to the linker errors as described above when I revert the name change.

I am wondering whether there might be some mismatch between the include and library files? If anyone has any idea what is happening, I should be very grateful, as I am keen to progress this.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 16, 2020, 06:13:36 PM
I think the library is different for 64bit and 32bit. I only use 32bit for debugging...
I have successfully compiled using MSVC2017.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 16, 2020, 06:28:09 PM
Quote from: Ranran on October 16, 2020, 06:13:36 PM
I think the library is different for 64bit and 32bit. I only use 32bit for debugging...
I have successfully compiled using MSVC2017.

That might explain it. I debug with 64 bit builds. Prissi - can I check whether the files that you sent were 64 bit or 32 bit? Does anyone know where one might find 64 bit libraries?
Title: Re: Incorporating changes from Standard
Post by: Roboron on October 16, 2020, 06:34:23 PM
Quote from: jamespetts on October 16, 2020, 06:28:09 PMDoes anyone know where one might find 64 bit libraries?

Not long ago I used https://github.com/Microsoft/vcpkg for that. I think all libraries Simutrans needs are available there, but i've never compiled Simutrans in MVSC, so I don't know for sure if they work.
Title: Re: Incorporating changes from Standard
Post by: ceeac on October 16, 2020, 08:20:47 PM
Quote from: Roboron on October 16, 2020, 06:34:23 PMNot long ago I used https://github.com/Microsoft/vcpkg for that.
That's also the approach I went with in my CMake build support branch that has just been merged by James. The goal is to auto-download, build and auto-update all the dependencies when generating MSVC project files with CMake, although this is not yet 100% finished because the merge caught my by surprise. :) I'll try to create a separate thread this weekend outlining how to build using CMake + Visual Studio.
Title: Re: Incorporating changes from Standard
Post by: prissi on October 16, 2020, 11:22:29 PM
My libaries are 32 bit, since community edition can only build 32 bit programs (at least in the 2015 version I use). I never built 64 bit on MSVC. But it is quite forward to build freetype.lib

Title: Re: Incorporating changes from Standard
Post by: Matthew on October 17, 2020, 08:45:46 AM
Quote from: ceeac on October 16, 2020, 08:20:47 PM
That's also the approach I went with in my CMake build support branch that has just been merged by James. The goal is to auto-download, build and auto-update all the dependencies when generating MSVC project files with CMake, although this is not yet 100% finished because the merge caught my by surprise. :) I'll try to create a separate thread this weekend outlining how to build using CMake + Visual Studio.

I would definitely be interested in using such a workflow and would need a tutorial to do so. I suspected was the dependencies that defeated my last attempt to use Visual Studio.

There's no hurry, but hopefully it will be good to know that your efforts will be used.  :thumbsup:
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 17, 2020, 03:31:44 PM
I have made some progress with this, but am still unable to get it to compile.

I have built my own Visual Studio 64 bit versions of Freetype and Miniupnpc. The Freetype build worked without difficulty, but the Miniupnpc build has had some trouble. I had to create a new x64 configuration in Visual Studio for this; this apparently worked, but I had the same errors as before. I realised that I had to add the MINIUPNP_STATICLIB preprocessor definition to the Simutrans project to allow this to work.

Having done this, I then had to rebuild bzip.lib as it complained about this being made with an older version for some reason. I was able to do this successfully, but now I get new and mysterious linker errors apparently relating to miniupnpc:


Severity   Code   Description   Project   File   Line   Suppression State
Error   LNK1120   4 unresolved externals   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe   1   
Error   LNK2001   unresolved external symbol __imp_perror   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)   1   
Error   LNK2001   unresolved external symbol __imp__memicmp   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)   1   
Error   LNK2001   unresolved external symbol __imp_GetAdaptersAddresses   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(minissdpc.obj)   1   
Error   LNK2001   unresolved external symbol __imp_GetBestInterfaceEx   Simutrans-Extended   C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(minissdpc.obj)   1   


If anyone has any idea what is going on and how to go about trying to fix this, I should be most grateful.

Edit: I have reduced those errors by recompiling miniupnpc with the static linker option, but I still get these errors:
Severity    Code    Description    Project    File    Line    Suppression State
Error    LNK2001    unresolved external symbol __imp_perror    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)    1   
Error    LNK2001    unresolved external symbol __imp__memicmp    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\miniupnpc.lib(miniwget.obj)    1   
Error    LNK1120    2 unresolved externals    Simutrans-Extended    C:\Users\James E. Petts\Documents\Development\Simutrans\simutrans-extended-sources\simutrans\Simutrans-Extended-debug.exe    1   

Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 17, 2020, 04:07:06 PM
https://github.com/seredat/karbowanec/issues/38

Is this relevant?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 17, 2020, 04:54:37 PM
Quote from: Ranran on October 17, 2020, 04:07:06 PM
https://github.com/seredat/karbowanec/issues/38

Is this relevant?

I suspect not, sadly - the significance of that is changing from a DLL build to a non-DLL build, but my Visual Studio builds are not DLL builds (albeit they are debug rather than non-debug versions of these builds).

May I ask - do you use Visual Studio for your debug builds? If so, how were you able to get this to work?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 17, 2020, 05:54:38 PM
Quote from: jamespetts on October 17, 2020, 04:54:37 PMdo you use Visual Studio for your debug builds?
Yes.
I think I'm using an older version as it was added to standard a few years ago. The version that uses the dll.

Debug builds can be built using these. It may be the same as provided by prissi...
https://drive.google.com/file/d/1_Xr2-jiILN1nHTHWV4BrDJmyYNa_-Dwu/view?usp=sharing
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 18, 2020, 01:06:03 PM
Quote from: Ranran on October 17, 2020, 05:54:38 PM
Yes.
I think I'm using an older version as it was added to standard a few years ago. The version that uses the dll.

Debug builds can be built using these. It may be the same as provided by prissi...
https://drive.google.com/file/d/1_Xr2-jiILN1nHTHWV4BrDJmyYNa_-Dwu/view?usp=sharing

Thank you for those. However, given that I use 64 bit debug builds, this unfortunately will not assist me, as I presume that these are 32-bit libraries?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 25, 2020, 01:39:21 PM
I have finally succeeded in making this work. The error had been that I had been compiling a .dll version of miniupnpc. I thought that I had changed this to static, but it transpires that I had become confused with the "upnpc static" project in the Visual Studio file which is, in fact, unrelated to miniupnpc, and had changed the settings on that instead of the miniupnpc library. Recompiling the library as static allows this to compile. I had also added IPHlpApi.Lib to the linker's list of input libraries.

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.

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.

I should be very grateful for testing by anyone who can compile this, as, given the number of things that have changed, the more testing, the better.

The next challenge, which might well be very difficult, is to get this version working with cross-compiling for the nightly build server. Can I check whether anyone has managed this yet? How does this branch work with CMake? I notice that I have had error messages from the CI builds sent to me complaining of compile failures whenever I update this branch on Github.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on October 25, 2020, 03:15:10 PM
I can't compile this using cmake or regular make:
In file included from /usr/include/c++/10/bits/stl_iterator_base_types.h:67,
                 from /usr/include/c++/10/iterator:61,
                 from bauer/../utils/../utils/for.h:10,
                 from bauer/../utils/../simtypes.h:13,
                 from bauer/../utils/log.h:12,
                 from bauer/../simdebug.h:21,
                 from bauer/brueckenbauer.cc:8:
/usr/include/c++/10/type_traits: In instantiation of 'struct std::is_move_constructible<sparse_tpl<short unsigned int> >':
/usr/include/c++/10/type_traits:138:12:   required from 'struct std::__and_<std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> > >'
/usr/include/c++/10/type_traits:143:12:   required from 'struct std::__and_<std::__not_<std::__is_tuple_like<sparse_tpl<short unsigned int> > >, std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> > >'
/usr/include/c++/10/type_traits:2195:11:   required by substitution of 'template<class ... _Cond> using _Require = std::__enable_if_t<std::__and_< <template-parameter-1-1> >::value> [with _Cond = {std::__not_<std::__is_tuple_like<sparse_tpl<short unsigned int> > >, std::is_move_constructible<sparse_tpl<short unsigned int> >, std::is_move_assignable<sparse_tpl<short unsigned int> >}]'
/usr/include/c++/10/bits/move.h:189:5:   required by substitution of 'template<class _Tp> std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = sparse_tpl<short unsigned int>]'
bauer/../obj/../tpl/sparse_tpl.h:240:15:   required from 'class sparse_tpl<short unsigned int>'
bauer/../obj/../simcity.h:180:21:   required from here
/usr/include/c++/10/type_traits:960:52: error: static assertion failed: template argument must be a complete class or an unbounded array
  960 |       static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
      |                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc: In static member function 'static void bridge_builder_t::build_bridge(player_t*, koord3d, koord3d, koord, sint8, const bridge_desc_t*, const way_desc_t*, overtaking_mode_t)':
bauer/brueckenbauer.cc:855:40: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  855 |    const slope_t::type hang = start_gr ? start_gr->get_weg_hang() :  slope_t::flat;
      |                               ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc:909:34: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  909 |    const slope_t::type hang = gr ? gr->get_weg_hang() :  slope_t::flat;
      |                               ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc:998:35: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
  998 |     const slope_t::type hang = gr ? gr->get_weg_hang() :  slope_t::flat;
      |                                ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bauer/brueckenbauer.cc: In static member function 'static void bridge_builder_t::build_ramp(player_t*, koord3d, ribi_t::ribi, slope_t::type, const bridge_desc_t*, const way_desc_t*, overtaking_mode_t, bool)':
bauer/brueckenbauer.cc:1118:33: warning: enumerated and non-enumerated type in conditional expression [-Wextra]
1118 |   const slope_t::type hang = gr ? gr->get_weg_hang() : slope_t::flat;
      |                              ~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make: *** [common.mk:56: build/default/bauer/brueckenbauer.o] Error 1
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 25, 2020, 03:40:47 PM
Interesting - this appears to be a syntax error in an included header file. This would suggest that the CMake build settings are targetting a different language subversion. I am not sure how this would work, since I am not familiar with CMake. Is there a way of explicitly forcing CMake to expect C++11?
Title: Re: Incorporating changes from Standard
Post by: ceeac on October 25, 2020, 05:29:11 PM
Quote from: jamespetts on October 25, 2020, 03:40:47 PMIs there a way of explicitly forcing CMake to expect C++11?
It already does expect C++11; see the beginning of CMakeLists.txt (https://github.com/jamespetts/simutrans-extended/blob/master/CMakeLists.txt#L37-L40).
For fixing the error, see my reply in the CMake thread (https://forum.simutrans.com/index.php/topic,20425.msg191999.html#msg191999).
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on October 25, 2020, 08:36:32 PM
Quote from: jamespetts on October 25, 2020, 03:40:47 PM
Interesting - this appears to be a syntax error in an included header file. This would suggest that the CMake build settings are targetting a different language subversion. I am not sure how this would work, since I am not familiar with CMake. Is there a way of explicitly forcing CMake to expect C++11?
Again, this also occurs with regular make.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 25, 2020, 09:55:53 PM
QuoteI 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.

QuoteThis 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.

QuoteThis 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.
Title: Re: Incorporating changes from Standard
Post by: prissi on October 26, 2020, 01:59:38 AM
You can get larger font without freetype, just use a bigger BDF fonts. So there is no absolute requirement to ship with freetype.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 28, 2020, 11:43:23 AM
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.

Quotealso because an #ifndef NETTOOL is missing somewhere (nettool does not need to include simsys.h IIRC)
I'm not sure about this issue... (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: ceeac on October 28, 2020, 04:36:59 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 29, 2020, 03:23:14 PM
Thank you for that. Both the std-r8434-2 branch and the std-r8653-2 branch now work correctly.  :)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 31, 2020, 02:18:42 PM
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 31, 2020, 03:54:05 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 01, 2020, 12:24:29 PM
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.
Quote* 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 01, 2020, 01:58:34 PM
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?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 01, 2020, 02:16:11 PM
Quote from: jamespetts on November 01, 2020, 01:58:34 PMTherefore, 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?
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 01, 2020, 02:45:13 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 02, 2020, 06:36:13 PM
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
Quote from: jamespetts on October 31, 2020, 03:54:05 PM* 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
Quote* 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
Quote* 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
Quote* 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
Quote* 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
Quote* 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
Quote* 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.
Quote* 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
Quote* 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.
Quote* 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.
(https://i.imgur.com/6LsH5ub.png)
(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
Quote* 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.
(https://i.imgur.com/YacNGfF.png)
I will try to find out how to solve this.



About translation:
#9
Quote* 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 03, 2020, 05:41:27 PM
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.
Quote

#3
Quote from: jamespetts on October 31, 2020, 03:54:05 PM* 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.

Quote
#4
Quote* 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.

Quote
#8
Quote* 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?


Quote
#10
Quote* 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?

Quote
#13
Quote* 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.


Quote
#19
Quote* 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.
Quote




#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.

Quote
#31, #33
Quote* 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.
Quote* 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.

Quote
#12, 32
Quote* 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.
Quote* 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.
(https://i.imgur.com/6LsH5ub.png)
(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.

Quote
#22
Quote* 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.
(https://i.imgur.com/YacNGfF.png)
I will try to find out how to solve this.
That is helpful - thank you for looking into this.
Quote



About translation:
#9
Quote* 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.

Quote
#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.
Title: Re: Incorporating changes from Standard
Post by: prissi on November 04, 2020, 12:59:26 AM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 05, 2020, 03:54:11 PM
Quote from: jamespetts on November 03, 2020, 05:41:27 PMThis 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.


Quote
#22
Quote* 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.
(https://i.imgur.com/YacNGfF.png)
I will try to find out how to solve this.
I think this issue has been fixed.


QuoteNoted; 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.
(https://i.imgur.com/m9GFaJT.gif)
Is it related to the order of declarations? Any advice on this is helpful as I have no idea what the cause is.


QuoteI 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:
Quote#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. (https://forum.simutrans.com/index.php/topic,20495.msg192381.html)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 07, 2020, 12:54:10 PM
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?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 07, 2020, 01:43:06 PM
Quote from: jamespetts on November 07, 2020, 12:54:10 PMI 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.

QuoteAlso (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.


QuoteIn 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.

QuoteIn 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.

Quote
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.
Quote from: Ranran on November 01, 2020, 06:09:26 AMExtended specific theme parameters:

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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 08, 2020, 06:06:34 AM
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 (https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/accel-curve-chart-v2) 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 08, 2020, 01:03:46 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 08, 2020, 01:37:55 PM
Quote from: jamespetts on November 08, 2020, 01:03:46 PMif the opening dialogue is kept open long enough that the scrolling text runs out, the game will crash.
(https://i.imgur.com/Saf5MvG.png)
"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?
(https://i.imgur.com/Q4O5hSq.png)
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... (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 08, 2020, 01:53:38 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 08, 2020, 02:01:54 PM
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:

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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 08, 2020, 05:19:41 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 08, 2020, 06:44:22 PM
Quote from: jamespetts on November 08, 2020, 05:19:41 PMThank 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
@@ -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.

Quote1. 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.
Quote6. The tooltips for the buttons in the city list chart do not work.
I think I've fixed these.


Quote7. 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?


Quote2. 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)


Quote8. 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?


Quote4. 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 12, 2020, 10:32:25 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 14, 2020, 04:21:41 PM
Quote from: jamespetts on November 12, 2020, 10:32:25 PMFirst 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.

Quote from: jamespetts on November 12, 2020, 10:32:25 PMAs 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.


QuoteThe 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 15, 2020, 12:10:09 PM
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?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 15, 2020, 12:59:52 PM
QuoteHowever, 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?

Quote from: jamespetts on November 15, 2020, 12:10:09 PMAs to the crash, I believe that I have now fixed this by amending scrolltext.h.
Thank you very much. It is very helpful.

Quote from: jamespetts on November 15, 2020, 12:10:09 PMI 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.

Quote from: Ranran on September 27, 2020, 04:59:03 PMA total of 3 list dialogs will be added.
These can be registered in the tool menu and also in the shortcut key.
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.
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 15, 2020, 02:25:40 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 15, 2020, 03:30:34 PM
Quote
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?


QuoteI 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.


QuoteAs 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.


QuoteIn 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 18, 2020, 05:07:39 PM
Quote from: Ranran on November 15, 2020, 03:30:34 PM
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.

QuoteSo 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?

Quote
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.

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

Interesting - thank you for noting this.

Quote
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 23, 2020, 11:15:14 PM
QuoteI 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.


QuoteIf 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.


QuoteI 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.


QuoteAs 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.


Quote* 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.


QuoteInteresting - 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.

Quotein 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:
Quote from: jamespetts on October 31, 2020, 03:54:05 PM* 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... (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: prissi on November 24, 2020, 12:51:16 AM
Button can be colored. Roundbutton not.

Also as stated in the dat files:

...
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
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 24, 2020, 12:30:07 PM
Excellent, thank you very much for your work on this. That is most helpful.

Quote from: Ranran on November 23, 2020, 11:15:14 PM
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.

QuoteExtended 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.

QuoteI 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?)

Quote
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.

Quote
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.

Quote

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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 24, 2020, 02:35:58 PM
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.


QuoteI 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.)


Quote from: jamespetts on November 24, 2020, 12:30:07 PMOne 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.


Quote from: jamespetts on November 24, 2020, 12:30:07 PMMore 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 24, 2020, 03:52:11 PM
Quote from: Ranran on November 24, 2020, 02:35:58 PM
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.

In Extended, the cost of building a tunnel is: (1) the cost of tunnelling (represented as the cost of the tunnel object); (2) the cost of the way; (3) the forge cost (only if building a new tunnel, not upgrading an existing tunnel, and halved if building parallel with an existing tunnel); and (4) the cost of the wayleave (1/5th of the cost of the land unless the player already owns the land above).

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

White would fit the theme better than orange, but would it not be clearer for them to be blue when not pressed and white when pressed?

Quote
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.

My apologies: I had forgotten that this had already been dealt with: there are a great many things that have been discussed so far in this thread, so it is not difficult to lose track of one of them.

I have tested this branch, but, unfortunately, the halt information dialogue does not work: I get an infinitely repeating assertion failure at line 33 of gui_image.cc.

Quote
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.

That is extremely helpful, as this has a potential to make a big difference to the online games. There is not any fundamental difference in the compression code between Standard and Extended, so I anticipate that the most difficult aspect of this will be setting up the necessary libraries.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 24, 2020, 11:20:48 PM
QuoteExcellent - 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?)
Can you elaborate on this?

As for the cursor color, it seems to inherit the value of the previous theme if theme doesn't specify it. This behavior is the same as standard.


Quotebut would it not be clearer for them to be blue when not pressed and white when pressed?
The text color of the pressed button is the same for the colored button and the normal button. So for modern themes, the text color of the pressed button is all white.
Based on prissi's advice, it seems possible to lighten the background color of the pressed color button, in which case we need to swap the color of the text button and background color of the color button image.


QuoteI have tested this branch, but, unfortunately, the halt information dialogue does not work: I get an infinitely repeating assertion failure at line 33 of gui_image.cc.
The departure board code is very different from the standard and it is difficult for me to port it correctly. Therefore it remains broken. It is possible to open a station where convoy does not arrive and depart, but if you run convoy with the dialog open, it will crash.
In the new GUI, GUI parts must be contained in components.

EDIT:
I noticed that halt info was broken at the time of the standard's first commit. The issue of crashing when picking up a commit that fixes it has been fixed.
So the current problem is that I can't change the departure board from the standard form to the extended form.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 25, 2020, 09:28:14 AM
The work of incorporating zstd has advanced and stucked. Σ(´・ω・`)  [ Stuck ]
You can sample this in here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-zstd
All build attempts on guihub seem to be able to build, but MSVC fails to build on my PC. This may be the reason why I've been knocked down by standard builds so far.
We need to prepare a new file related to zstd. So I have tried many versions from 1.3.3 to 1.4.5 but all have failed.

1>loadsave.obj : error LNK2019: 未解決の外部シンボル _ZSTD_compressStream2 が関数 "private: void __thiscall loadsave_t::flush_buffer(int)" (?flush_buffer@loadsave_t@@AAEXH@Z) で参照されました。
1>libzstd_static.lib(fse_decompress.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(zstd_v04.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(zstd_v07.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(zstd_v05.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(zstd_v06.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(huf_compress.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(fse_compress.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(hist.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(huf_decompress.o) : error LNK2001: 外部シンボル "___chkstk_ms" は未解決です。
1>libzstd_static.lib(fse_compress.o) : error LNK2019: 未解決の外部シンボル ___udivdi3 が関数 _FSE_normalizeCount で参照されました。
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 10 件の未解決の外部参照


Did I fail to set up the project file? (´・ω・`)はぁまじ

I would appreciate any help in this regard.

EDIT:
__imp__ was not seen when building debug builds.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 25, 2020, 11:39:58 AM
Thank you for your work on this.

The __imp__ prefixes in the linker errors suggest that the zstd library that you have compiled has been compiled to be dynamically rather than statically linked. Was that what you intended? If not, this is a possible source of at least part of this error.
Title: Re: Incorporating changes from Standard
Post by: prissi on November 25, 2020, 11:48:51 AM
This is a common problem. The zlib library was compiled using the dynamic runtime library. The easiest fix is to compile zstd lib by hand using static linking. Becasue the rtl is different between different MSVC version, it is most easy to compile it with the version you are using.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 25, 2020, 12:31:59 PM
@prissi
Thank you for your accurate advice.  :hat:
I downloaded the 1.4.5 source from the zstd official website, compiled the lib and dll myself, and used it, and it built correctly.   :)


Now you can test the zstd branch for extended.
In my verification work, the save size is about 30% smaller than zipped, and the zstd option seems to be working properly.

EDIT:
Save and setting file is not compatible with the r8653-2 branch because I have not changed the revision number.
The sound settings dialog has been updated in zstd branch. This is because they are implemented in parallel in standard and I have incorporated them together to avoid conflicts and reduce the overall workload.

EDIT2:
From now on, what the zstd branch should update is the content of <a href="https://forum.simutrans.com/index.php/topic,20488.0.html">this thread</a> (r9406 and later). But that's the latest change that has happened in the last week. The opinions of experts on what to do about this are helpful.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 30, 2020, 05:25:33 PM
Thank you very much for your work on this. I have now managed to get the zstd branch working. Two points in relation to that: first of all, the saved game format is not compatible with the latest master branch saved game format, as this has incremented recently; you may need to look into this. Secondly, this merges the new Standard sound distance/volume system, which I suspect clashes with code with a similar intention already present in Extended; it may be necessary either to remove the Extended implementation or the new Standard implementation, whichever is the less satisfactory of the two (I have not tested extensively yet).

As to zstd itself, at compression level 6, using the Bridgewater-Brunel saved game from 1940, loading using the existing Zlib took 33 seconds, whereas loading with the zstd took 1:23 minutes. Saving with zstd took 4:23 minutes. At compression level 3, that was only modestly better at 3:16 minutes. Zlib saved the same game in 35 seconds at compression level 3. The saved game size with zstd compression level 3 was 396MB, whereas for zlib compression level 3, it was 474MB. At compression level 6, zlib took 1:13 minutes to save this game, and produced a file 429MB in size. The file being loaded from the Bridgewater-Brunel server and then immediately re-saved was 484MB, suggesting an even lower compression level used there.

These results are disappointing and confusing (although I do not blame Ranran for this, who has very helpfully ported the Standard implementation of this): TurfIt's tests last year suggested the possibility for a very significant speed improvement in using zstd over zlib, but current tests show this not to be possible, although instead suggesting that reducing the compression level may help significantly (and the ability to adjust the compression level is also new in this code, so this work will still be worthwhile even if the zstd compression is not used in the end).

If anyone who is able to give any insight into why the improvements demonstrated by TurfIt last year may not have been realised in this implementation, that would be very helpful.

In the meantime, it would be helpful if Ranran could look into the two smaller issues set out above. I will have to investigate setting up the build server to have the right libraries to work with zstd to make sure that this version can build.

I should note that I should very much like to be able to get these changes merged into the master branch by the 19th of December this year if possible, and I think that we are getting very close with the UI work.

Thank you again to Ranran for all the work in this regard.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 30, 2020, 10:12:10 PM
Quotefirst of all, the saved game format is not compatible with the latest master branch saved game format, as this has incremented recently; you may need to look into this.
Certainly it causes problems as I missed that the revision of the master branch was incremented.
Is it okay to change the version number to 15.0 because the amount of integration from the standard is huge?


QuoteSecondly, this merges the new Standard sound distance/volume system, which I suspect clashes with code with a similar intention already present in Extended; it may be necessary either to remove the Extended implementation or the new Standard implementation, whichever is the less satisfactory of the two (I have not tested extensively yet).
I haven't looked in detail at whether its function has been broken or if it can coexist.
But at least the new standard feature, which allows player to adjust the volume of the sound individually, seems like a big improvement.


Quoteinstead suggesting that reducing the compression level may help significantly
I tried saving with a large map in standard and I think this is correct. The low compression zipped is much faster than the high compression zstd.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 30, 2020, 10:29:18 PM
Quote from: Ranran on November 30, 2020, 10:12:10 PM
Certainly it causes problems as I missed that the revision of the master branch was incremented.
Is it okay to change the version number to 15.0 because the amount of integration from the standard is huge?

No, this is probably not sensible, as 15 is reserved for the vehicle-management branch, integration and completion of which is the next major step after integrating the work on this merging.

QuoteI haven't looked in detail at whether its function has been broken or if it can coexist.
But at least the new standard feature, which allows player to adjust the volume of the sound individually, seems like a big improvement.

Yes, the ability to alter the individual levels is a worthwhile thing indeed; it may well be that Standard's sound distance system may be worth adopting, but this will need further testing.

QuoteI tried saving with a large map in standard and I think this is correct. The low compression zipped is much faster than the high compression zstd.

Thank you for confirming. It is odd that this is so different to the results of TurfIt's tests last year.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on November 30, 2020, 11:30:58 PM
Of course high compression zstd is much slower than low compression zipped.  3 times slower for a 30% smaller file per January's tests.
But at default compression, both produce the same size file with zstd 10 times faster, or zstd 2 times faster than the fastest zip setting.
However that was using the wrapper. Would appear the non-wrapper implementation is non-performant.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 30, 2020, 11:31:17 PM
Extended zstd branch may be making some difference as the progress bar is not smooth.
Uncompressed zstd with seve_level = -10 is slower than zipped with save_level = 1....
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 12:48:17 AM
Quick test with standard:  zstd wrapper performs identical to zstd non-wrapper (prissi's implementation). Not a factor.
zstd level 6 compresses in 1/3 the time of zlib level 6 producing identical sized file. About expected.

SimEx remains unlinkable so can't test anything with it...
Title: Re: Incorporating changes from Standard
Post by: prissi on December 01, 2020, 02:05:27 AM
zstd gained very little head in most test games in standard, unless using very high levels (and thus being slow). Hence it was not set a default server format. I would use zstd (and then with very high settings) only when transfer speed becomes an issue, either on ADSL hosting or indeed with GB sized games.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 02:20:30 AM
I've never seen a large enough game that Standard has any issue with saving in a reasonable time  (unless using bzip2 - that's slow!).
zstd makes a noticeable improvement percentage wise, but the absolute time is so quick it doesn't really matter.  Eg. Save the yoshi test game - zlib 680 ms, zstd 250 ms. Both level 6 yielding same filesize.
EDIT: tried an old game 'dom28.sve'. No idea where from.... zlib 8400 ms, zstd 2250 ms. Getting worth it...
Title: Re: Incorporating changes from Standard
Post by: prissi on December 01, 2020, 07:04:45 AM
But zlib at level 3 is way way faster than zstd with files about 10% larger. And bzip2 was not much slower than zstd in my tests. Apparently it strongly depends on the actual zlib lib one was using ... (I had to use own compiled zlib for MSVC, maybe that is the reason.)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 11:36:39 AM
Ranran and TurfIt - thank you for testing: that is helpful. TurfIt - what linking problems are you having with Extended?

It remains unclear why TurfIt's tests from last year seem inconsistent with the results that we are seeing now in Extended. However, one issue is that I am not sure how the compression levels compare. Is zstd at level 3 equivalent to zlib at level 3 or is there some conversion to be applied? Note that my tests above were using level 3 on both, as reported (aside from the instances where I used the default level of 6, also noted).
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 01, 2020, 12:40:51 PM
# zip and zstd allow for finetuning their packaging versus speed with and additional
# compression level parameter.
# Zip form 1(fastest) to 9(smallest) with 6 a good compromise
# zstd goes form -10 to 30 or so. Meaningful are mostly single digit values
save_level = 6
autosave_level = 1

I don't think the same setting value for different compression formats has the same compression ratio.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 12:49:53 PM
Quote from: Ranran on December 01, 2020, 12:40:51 PM
# zip and zstd allow for finetuning their packaging versus speed with and additional
# compression level parameter.
# Zip form 1(fastest) to 9(smallest) with 6 a good compromise
# zstd goes form -10 to 30 or so. Meaningful are mostly single digit values
save_level = 6
autosave_level = 1

I don't think the same setting value for different compression formats has the same compression ratio.

Yes, this is an inference from the different ranges (although this is not entirely certain). Does anyone know what values are equivalent between the two? TurfIt wrote earlier about using both with default values, but I am not sure what those are (unless TurfIt meant the Simutrans default value as in the supplied simuconf.tab?)
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 01:47:13 PM
Quote from: prissi on December 01, 2020, 07:04:45 AM
But zlib at level 3 is way way faster than zstd with files about 10% larger. And bzip2 was not much slower than zstd in my tests. Apparently it strongly depends on the actual zlib lib one was using ... (I had to use own compiled zlib for MSVC, maybe that is the reason.)
MSVC vs MinGW is perhaps the problem.  Question is do you have an abnormally fast zlib, or slow zstd?
For versions, mingw-w64-x86_64-bzip2 1.0.8-1, mingw-w64-x86_64-zlib 1.2.11-7, mingw-w64-x86_64-zstd 1.4.5-1.

I see the dom28.sve I have came from your collection, so I repeated tests with it. Times are the average of 5 saves. What results do you get?
   bzip2,        14382 ms to save, 29.2 MiB savefile size.
   zlib level 6,  8464 ms,             49.8 MiB
   zlib level 3,  3376 ms,             55.8 MiB
   zstd level 6, 2235 ms,             47.9 MiB
   zstd level 3, 1507 ms,             49.7 MiB


Quote from: jamespetts on December 01, 2020, 12:49:53 PM
Yes, this is an inference from the different ranges (although this is not entirely certain). Does anyone know what values are equivalent between the two? TurfIt wrote earlier about using both with default values, but I am not sure what those are (unless TurfIt meant the Simutrans default value as in the supplied simuconf.tab?)
Defaults for the libraries are both '6', same as Simutrans default. There is no direct equivalent, depends on the data being compressed. Sometimes level 6 for both give identical sizes, sometimes one or the other is bigger for a given savefile. Generally 6 is balanced, above trades time for size, and below better speed for bigger.


Quote from: jamespetts on December 01, 2020, 11:36:39 AM
Ranran and TurfIt - thank you for testing: that is helpful. TurfIt - what linking problems are you having with Extended?

It remains unclear why TurfIt's tests from last year seem inconsistent with the results that we are seeing now in Extended.
What times do you get with Standard and dom28.sve?  (Presumably prissi can point you where it is if you don't have.)
Would be interesting if you could compare a self built MSVC with the release on sourceforge too? (or any GCC build). I roughly repeat my results above when using the sourceforge vs self built  (stop watch times rather than ingame, subjectively release is 20% slower than self built - debug build maybe...)
I used this for timing:

Index: simworld.cc
===================================================================
--- simworld.cc (revision 9461)
+++ simworld.cc (working copy)
@@ -4696,6 +4696,8 @@
void karte_t::save(const char *filename, bool autosave, const char *version_str, bool silent )
{
DBG_MESSAGE("karte_t::save()", "saving game to '%s'", filename);
+uint32 zzz=dr_time();
+
        loadsave_t  file;
        std::string savename = filename;
        savename[savename.length()-1] = '_';
@@ -4727,6 +4729,7 @@
                reset_interaction();
        }
        display_show_load_pointer( false );
+printf("Save took %u\n", dr_time()-zzz);
}




As for MinGW building SimEX:

R:/build/bauer/brueckenbauer.o:brueckenbauer.cc:(.text+0x55ee): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/brueckenbauer.o:brueckenbauer.cc:(.text+0x560b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/tunnelbauer.o:tunnelbauer.cc:(.text+0x3d56): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/tunnelbauer.o:tunnelbauer.cc:(.text+0x3d78): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x7213): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for route_t::MAX_STEP'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x7265): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x726f): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for karte_t::marker_index'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x72e4): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for route_t::max_used_steps'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x73bd): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for route_t::max_used_steps'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x73d7): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for route_t::max_used_steps'
R:/build/bauer/wegbauer.o:wegbauer.cc:(.text+0x7615): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
make: *** [common.mk:27: /r/build/Simutrans-Extended.exe] Error 1

A brief look into possible causes was enough to no no no nope. Not going there.
It worked in January when I did the original zstd testing, so something broke. Until it either self fixes, or someone else fixes, no SimEX for me.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 01:58:55 PM
TurfIt - I do not use MinGW, but rather either MSVC for my home debugging builds or GCC for the automated server builds. I am not sure why you are getting those odd linker errors (which suggest some 32/64 bit incompatibility somewhere; are you trying to build a 32- or 64-bit version? If the former, I suggest trying a 64-bit build, as this is necessary for the level of memory consumption of larger games in any event).

I have not tried loading/saving the Standard saves, mainly because the case that I specifically want to test is loading/saving a large amount of path explorer data, which is what Zlib has trouble with in particular. Saved games not containing these data are thus of only limited value for testing.

I should note that I use MSVS's performance profiler for timing purposes, as the CPU utilisation graph makes it very obvious when loading/saving begins and ends (a very long, single-threaded section of steady CPU utilisation characterises loading/saving, compared to a spiky, semi-multithreaded section for the running game).

The information as to the defaults is useful - thank you. It does seems as though it is worth exploring reducing the compression levels to see whether this improves performance.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 02:16:59 PM
I'm aware standard does not have path explorer data to save, and this data is what appears to choke zlib saving, at least when tested in January.

I suggested testing with Standard since prissi is reporting zstd slow in Standard, same as you reporting zstd slow in Extended. Yet I see very tangible improvements in both (albeit back in January for Extended since I currently can't compile it). Phystam also reported a good improvement with Extended back in January.

If you test Standard from sourceforge and get slow results, then I don't know. If you roughly match my results, and then you try with a MSVC built Standard showing slow zstd, then there's the problem. I wouldn't call that 'limited value for testing'.  Or, since you are using GCC for automated server builds, test with them.  (Are your nightlies from GCC? If so, can you make a nightly run with the zstd branch? [then I could try that...])
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 04:52:51 PM
Results with Extended, merge-from-standard-zstd branch, bb-17-jan-2020.sve:
  bzip2, 382453 ms,   958 MiB
  zlib 6, 227670 ms, 1162 MiB
  zlib 3,   71905 ms, 1308 MiB
  zstd 6,  41733 ms, 1164 MiB
  zstd 3,  24686 ms, 1150 MiB  (yes smaller than 6)

1. This branch will not load the current Bridgewater savefile - presume a versioning issue. Stuck in first call to stadt_t::rdwr(loadsave_t* file).
2. SDL2 crashes after pakset selection. GDI working. (I remember this problem from January too...)
3. Branch makefile for ZSTD doesn't work.  Typo ZSRD, and if USE_PNP where it don't belong. Results in zstd not being included - defaults to bzip2 saving when set saveformat=zstd. Fix makefile, zstd works.
4. Relocation truncated "solved" with linker flag fuckery: "LDFLAGS = -Wl,--image-base -Wl,0x10000000". Apparantely you've managed to get the code/static allocations over 2GiB.
5. bb-17-jan-2020.sve is sucking down 14.5 GB memory usage when loaded. Once OS overhead involved, even players with 16GB system ram will be in bad shape.

EDIT:
6. Loading takes 27 seconds. All compression formats the same.
7. Save progress bar should probably take saving the path explorer data into account - once regular data is saved, progress bar is at the end where it appears the saving process is frozen while it saves the PE data.

EDITEDIT:
Results with gzbuffer 64K, and LS_BUF_SIZE 8M
  zlib 3,   65211 ms, 1308 MiB
  zstd 3,  23856 ms, 1150 MiB

8.  zlib definitely likes more than 8K buffer space.  zstd in diminishing returns already, could try different sizes, but note this will be system dependent for optimal.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 01, 2020, 05:33:04 PM
Quote from: TurfIt on December 01, 2020, 04:52:51 PMTypo ZSRD
It was due to a standard commit. It was brought in r8888 and fixed in r8905, but I missed it because it looked like a completely irrelevant commit...
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 05:35:00 PM
Thank you very much for this. I was going to have a go at compiling this branch on the server to test how well that zlib cross-compiling works, but you have managed to get it working before I had time to do that.

These results are interesting (and odd in so far as compression level 3 is better than 6 for zstd, but it at least shows that there is no advantage to increasing the ratios). Testing with a GCC cross-compile build is in order, I think, when I have the time to set this up.

As to 1, the incompatibility is a known issue, discussed above, which should be resolved before deployment. In relation to 2, I have not experienced this myself nor had any other reports of this, so I am not sure how to reproduce this to look into it.

3 - thank you for pointing out the error; this will need to be fixed.

4 - interesting. I am not sure why this is so large.

5 - yes, that is why we moved to a smaller number of towns and slower town growth for the current game.

6 - I am not sure how this is consistent with the findings above - perhaps I am misunderstanding?

7 - I can see that this would be preferable, resources permitting.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 05:47:51 PM
See my EDITEDIT  re buffers.

6. You'd stated "loading using the existing Zlib took 33 seconds, whereas loading with the zstd took 1:23 minutes."  For me, I load the bb-17-jan-2020.sve savegame in 27 seconds regardless of whether the file is in bzip2 format, zlib format, or zstd format.


Quote from: Ranran on December 01, 2020, 05:33:04 PM
It was due to a standard commit. It was brought in r8888 and fixed in r8905, but I missed it because it looked like a completely irrelevant commit...
Actually not fixed until 8910. And I agree annoying these stowaway fixes.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 06:40:10 PM
Quote from: TurfIt on December 01, 2020, 05:47:51 PM
See my EDITEDIT  re buffers.

My apologies: that crossed with my reply, I think.

Quote
EDITEDIT:
Results with gzbuffer 64K, and LS_BUF_SIZE 8M
  zlib 3,   65211 ms, 1308 MiB
  zstd 3,  23856 ms, 1150 MiB

8.  zlib definitely likes more than 8K buffer space.  zstd in diminishing returns already, could try different sizes, but note this will be system dependent for optimal.

That is very interesting. There is not a currently implemented simuconf.tab option to modify the buffer size; is this a parameter that can be passed to a function somewhere? If so, it would help to know what it is so that I can look into adjusting this.

Thank you again.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 06:52:26 PM
No simuconf.tab for these, hardcoded.
LS_BUF_SIZE is a constant at top of loadsave.cc
gzbuffer is added to loadsave_t::wr_open: 

if(  is_zipped()  ) {
// using zlib on servers, since 3x times faster saving than bz2
char compr[ 4 ] = { 'w', 'b', (char)('0' + clamp( level, 1, 9 )), 0 };
fd->gzfp = dr_gzopen(filename_utf8, compr );
gzbuffer(fd->gzfp, 65536);
}
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 07:03:37 PM
Thank you for that. Which of the parameters comprises the buffer size - is it the compr parameter passed to gzfp, which object is in turn passed to gzbuffer?
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 01, 2020, 07:12:06 PM
65536 is buffer size. 8192 is default if no call made to gzbuffer() after gzopen().


/ buffer size for read/write - bzip2 gains up to 8M for non-threaded, 1M for threaded. binary, zipped ok with 256K or smaller.
// zstd need their own buffer size ...
//#define LS_BUF_SIZE (1024 * 1024)
#define LS_BUF_SIZE (8192 * 1024)

and 1M or 8M here for the simutrans buffers (which zstd has hijacked too...)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 01, 2020, 07:40:31 PM
Excellent, that is very helpful, thank you. I shall have to experiment when I have time.
Title: Re: Incorporating changes from Standard
Post by: prissi on December 02, 2020, 12:54:36 AM
So it seems like zstd is something of a sweet spot? Because zlib in all my trials were like 10-20% bigger but twice as fast. Of course on my computer, so things may vary a bit. (I am not sure how well zstd is supporting threads. The slow test computer had only a deliberately slow dual core ancient CPU. Also instruction set may greatly speed up compression.)
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 02, 2020, 02:36:22 PM
https://forum.simutrans.com/index.php/topic,20492.html
The above thread function has been incorporated. It is useful for pakset authors to update the menuconf to make this feature available.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 02, 2020, 07:14:43 PM
Thank you very much for that.I have now managed to build the zstd version on the Bridgewater-Brunel version, including cross-compiling a 64-bit Windows build, which can be downloaded for testing here (http://bridgewater-brunel.me.uk/downloads/Simutrans-Extended-zstd.exe).

However, there is still an incompatiblity with saved game versions from the latest master branch: see here (http://bridgewater-brunel.me.uk/saves/bb-nov-2020.sve) for an example, which is the game that I have been using for testing.

Brief tests show that zipped with compression level=3 is much, much, much faster than zstd with compression level=3 (tens of seconds as opposed to several minutes; I have not at this stage done any actual timing, as it is more difficult to do this when not running in the debugger), and even with zipped level 6, this appears faster than zstd level 3, although this is not as obvious.

In any event, given the improvements that being able to specify the level of compression has, it is probably worthwhile moving towards integrating the latest set of changes as soon as possible. Further testing as to the optimum setting can be done after integration. The main things that will need to be done first, so far as I can make out, are (1) fixing the saved game incompatibility issue; and (2) dealing with the translation texts.

Ranran - can I check that all the necessary texts that I need to translate for the new UI work are listed in this (https://forum.simutrans.com/index.php/topic,20490.0.html) thread?

Also, can I check whether you think that there is anything else that needs to be done before integrating the UI improvements together with the zstd work into the master branch?

Thank you again for all your work on this - it is much appreciated.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 02, 2020, 08:47:53 PM
Quote from: jamespetts on December 02, 2020, 07:14:43 PM
Thank you very much for that.I have now managed to build the zstd version on the Bridgewater-Brunel version, including cross-compiling a 64-bit Windows build, which can be downloaded for testing here (http://bridgewater-brunel.me.uk/downloads/Simutrans-Extended-zstd.exe).

ERROR: loadsave_t::rd_open: Compiled without zstd support!

Oops. Note, in this case, if your testing was with this exe, when you select saveformat=zstd, you actually get bzip2 which is very very slow...



Using my exe, and bb-nov-2020.sve I get:  (on an I7-6700K - previous timings above were on a 2700X)
   zlib 6, 81509 ms, 424 MiB
   zlib 3, 30017 ms, 506 MiB
  zstd 6, 18105 ms, 401 MiB
  zstd 3, 13553 ms, 401 MiB

And with bb-17-jan-2020.sve:  ( for a point of comparison 6700K vs 2700X)
   zlib 3, 74311 ms, 1310 MiB
  zstd 3, 23726 ms, 1150 MiB
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 03, 2020, 12:24:05 AM
Quote from: jamespetts on December 02, 2020, 07:14:43 PMHowever, there is still an incompatiblity with saved game versions from the latest master branch: see here for an example, which is the game that I have been using for testing.
Only the conflicts in the 8653-2 branch were fixed and the conflict in the zstd branch was not fixed. I think I fixed it.

Quote from: jamespetts on December 02, 2020, 07:14:43 PMRanran - can I check that all the necessary texts that I need to translate for the new UI work are listed in this thread?
Some translated text has been added by a recent change in the sound setting dialog built into the zstd branch. I updated the list.
Some help files also need to be added or reviewed.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 03, 2020, 12:41:05 AM
Quote from: jamespetts on December 02, 2020, 07:14:43 PMAlso, can I check whether you think that there is anything else that needs to be done before integrating the UI improvements together with the zstd work into the master branch?
I don't know whether the issue of many text colours such as for stop names having a dark bluish tint has been resolved.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 03, 2020, 12:55:06 AM
Quote from: freddyhayward on December 03, 2020, 12:41:05 AMsuch as for stop names having a dark bluish tint has been resolved.
It looks like just a public player color, not a bug.
I think it's due to a change in the standard related to the theme. At least the same as standard.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 03, 2020, 01:09:00 PM
TurfIt - thank you for checking that. It seems that I had omitted to modify the makefile to support ZSTD. I have now done this and installed zstd-dev, but I am afraid that I am now unable to compile on the Bridgewater-Brunel server. Attempting a basic Linux graphical client, I get the following errors:

root@438242:/usr/share/games/nightly/simutrans-experimental# make
expr: syntax error
===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc:199:2: error: âZSTD_inBufferâ does not name a type
  ZSTD_inBuffer zin;
  ^
dataobj/loadsave.cc:200:2: error: âZSTD_outBufferâ does not name a type
  ZSTD_outBuffer zout;
  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::set_buffered(bool)â:
dataobj/loadsave.cc:248:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = NULL;
          ^
dataobj/loadsave.cc:249:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = 0;
          ^
dataobj/loadsave.cc:250:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:252:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = fd->zbuff;
          ^
dataobj/loadsave.cc:253:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:254:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc:257:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = fd->zbuff;
          ^
dataobj/loadsave.cc:258:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:259:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:261:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = NULL;
          ^
dataobj/loadsave.cc:262:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = 0;
          ^
dataobj/loadsave.cc:263:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc: In member function âbool loadsave_t::rd_open(const char*)â:
dataobj/loadsave.cc:370:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = 0;
       ^
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^
dataobj/loadsave.cc:557:68: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                                                    ^
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:672:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.src = "";
        ^
dataobj/loadsave.cc:673:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.size = 0;
        ^
dataobj/loadsave.cc:674:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.pos = 0;
        ^
dataobj/loadsave.cc:676:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.dst = fd->zbuff;
        ^
dataobj/loadsave.cc:677:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.size = LS_BUF_SIZE;
        ^
dataobj/loadsave.cc:678:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:682:9: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fd->zout.pos = 0;
         ^
dataobj/loadsave.cc:683:49: error: âstruct file_descriptors_tâ has no member named âzoutâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                 ^
dataobj/loadsave.cc:683:62: error: âstruct file_descriptors_tâ has no member named âzinâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                              ^
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^
dataobj/loadsave.cc:683:80: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                                ^
dataobj/loadsave.cc:684:17: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                 ^
dataobj/loadsave.cc:684:34: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:860:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                          ^
dataobj/loadsave.cc:860:40: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                                        ^
dataobj/loadsave.cc:862:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.src = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:863:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = buf_pos[ buf_num ];
       ^
dataobj/loadsave.cc:864:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.pos = 0;
       ^
dataobj/loadsave.cc:866:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
               ^
dataobj/loadsave.cc:866:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
                             ^
dataobj/loadsave.cc:867:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:868:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                ^
dataobj/loadsave.cc:868:61: error: âstruct file_descriptors_tâ has no member named âzinâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                             ^
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^
dataobj/loadsave.cc:868:83: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                                   ^
dataobj/loadsave.cc:869:16: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                ^
dataobj/loadsave.cc:869:33: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                 ^
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:966:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.dst = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:967:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.size = LS_BUF_SIZE;
       ^
dataobj/loadsave.cc:968:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.pos = 0;
       ^
dataobj/loadsave.cc:972:16: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                ^
dataobj/loadsave.cc:972:30: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                              ^
dataobj/loadsave.cc:972:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                ^
dataobj/loadsave.cc:972:63: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                               ^
dataobj/loadsave.cc:973:56: error: âstruct file_descriptors_tâ has no member named âzoutâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                        ^
dataobj/loadsave.cc:973:67: error: âstruct file_descriptors_tâ has no member named âzinâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                   ^
dataobj/loadsave.cc:973:71: error: âZSTD_decompressStreamâ was not declared in this scope
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                       ^
dataobj/loadsave.cc:975:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
          ^
dataobj/loadsave.cc:975:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
                          ^
dataobj/loadsave.cc:979:13: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
             ^
dataobj/loadsave.cc:979:28: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
                            ^
dataobj/loadsave.cc:980:29: error: âstruct file_descriptors_tâ has no member named âzinâ
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                             ^
dataobj/loadsave.cc:981:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.pos = 0;
         ^
dataobj/loadsave.cc:982:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.size = r;
         ^
dataobj/loadsave.cc:985:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
               ^
dataobj/loadsave.cc:985:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                             ^
dataobj/loadsave.cc:985:47: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                               ^
dataobj/loadsave.cc:985:62: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                                              ^
dataobj/loadsave.cc:986:11: error: âstruct file_descriptors_tâ has no member named âzoutâ
   r = fd->zout.pos; // number of bytes decompressed
           ^


It is not clear why or how these errors do or can occur in circumstances where I have the zstd-dev package installed. Has anyone managed to get ZSTD support working with a GCC/Linux build? If so, what other than libzstd-dev needed to be installed?
Edit: Testing on my local system, Ranran's fix for the file version numbering seems to work - thank you to Ranran for that.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 03, 2020, 01:25:11 PM
Quote from: Ranran on December 03, 2020, 12:55:06 AMIt looks like just a public player color, not a bug.
I think it's due to a change in the standard related to the theme. At least the same as standard.
Does it still look like this? If so, that is a bug. That does not look like public player at all. And it doesn't matter whether it's related to themes or not.
Quote from: freddyhayward on September 13, 2020, 12:18:54 PM
here are some screenshots:
(https://i.imgur.com/zBSCKSA.png)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 03, 2020, 01:32:42 PM
I am not sure that I follow - the new colour for public player station names and town names is the public service player's primary colour (I have tested this, and, if one changes the public service player's primary colour, the text colour changes to match).

In the current master branch and older versions of Standard, this text was white.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 03, 2020, 01:45:19 PM
Quote from: jamespetts on December 03, 2020, 01:32:42 PM
I am not sure that I follow - the new colour for public player station names and town names is the public service player's primary colour (I have tested this, and, if one changes the public service player's primary colour, the text colour changes to match).

In the current master branch and older versions of Standard, this text was white.
The left image shows the bluish text on the merge branch. The public players primary colour is unchanged, as is clearly visible in the station and stop images.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 03, 2020, 02:41:19 PM
Quote from: freddyhayward on December 03, 2020, 01:45:19 PM
The left image shows the bluish text on the merge branch. The public players primary colour is unchanged, as is clearly visible in the station and stop images.

The public player's primary colour has indeed not been changed, but the text was formerly not based on the public player's primary colour, but was white. The new code uses the public player colour rather than white. The text in the image is grey rather than blue, which is the public player's default colour.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 03, 2020, 03:39:56 PM
Regretfully I'm not familiar with Makefile. Therefore, the resolution of the conflict may be omitted.

https://github.com/aburch/simutrans/commit/a83ca95932f44cca97f7d5452c34d8d1a38cc411
The change from line 193 to line 195 in r8910 has been overlooked, is this relevant?
The change in the upper part is irrelevant here as it has been changed again in r8915.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 03, 2020, 07:14:06 PM
Quote from: Ranran on December 03, 2020, 03:39:56 PM
Regretfully I'm not familiar with Makefile. Therefore, the resolution of the conflict may be omitted.

https://github.com/aburch/simutrans/commit/a83ca95932f44cca97f7d5452c34d8d1a38cc411
The change from line 193 to line 195 in r8910 has been overlooked, is this relevant?
The change in the upper part is irrelevant here as it has been changed again in r8915.

Thank you for that. I have incorporated that and tested it, but, unfortunately, I still get the same errors on a basic native Linux build:


===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc:199:2: error: âZSTD_inBufferâ does not name a type
  ZSTD_inBuffer zin;
  ^
dataobj/loadsave.cc:200:2: error: âZSTD_outBufferâ does not name a type
  ZSTD_outBuffer zout;
  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::set_buffered(bool)â:
dataobj/loadsave.cc:248:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = NULL;
          ^
dataobj/loadsave.cc:249:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = 0;
          ^
dataobj/loadsave.cc:250:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:252:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = fd->zbuff;
          ^
dataobj/loadsave.cc:253:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:254:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc:257:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.src = fd->zbuff;
          ^
dataobj/loadsave.cc:258:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.size = LS_BUF_SIZE;
          ^
dataobj/loadsave.cc:259:10: error: âstruct file_descriptors_tâ has no member named âzinâ
      fd->zin.pos = 0;
          ^
dataobj/loadsave.cc:261:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.dst = NULL;
          ^
dataobj/loadsave.cc:262:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = 0;
          ^
dataobj/loadsave.cc:263:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.pos = 0;
          ^
dataobj/loadsave.cc: In member function âbool loadsave_t::rd_open(const char*)â:
dataobj/loadsave.cc:370:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = 0;
       ^
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^
dataobj/loadsave.cc:557:68: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                                                    ^
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:672:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.src = "";
        ^
dataobj/loadsave.cc:673:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.size = 0;
        ^
dataobj/loadsave.cc:674:8: error: âstruct file_descriptors_tâ has no member named âzinâ
    fd->zin.pos = 0;
        ^
dataobj/loadsave.cc:676:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.dst = fd->zbuff;
        ^
dataobj/loadsave.cc:677:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.size = LS_BUF_SIZE;
        ^
dataobj/loadsave.cc:678:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:682:9: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fd->zout.pos = 0;
         ^
dataobj/loadsave.cc:683:49: error: âstruct file_descriptors_tâ has no member named âzoutâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                 ^
dataobj/loadsave.cc:683:62: error: âstruct file_descriptors_tâ has no member named âzinâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                              ^
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^
dataobj/loadsave.cc:683:80: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                                ^
dataobj/loadsave.cc:684:17: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                 ^
dataobj/loadsave.cc:684:34: error: âstruct file_descriptors_tâ has no member named âzoutâ
     fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                  ^
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:860:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                          ^
dataobj/loadsave.cc:860:40: error: âstruct file_descriptors_tâ has no member named âzoutâ
   gzwrite( fd->gzfp, fd->zout.dst, fd->zout.pos );
                                        ^
dataobj/loadsave.cc:862:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.src = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:863:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.size = buf_pos[ buf_num ];
       ^
dataobj/loadsave.cc:864:7: error: âstruct file_descriptors_tâ has no member named âzinâ
   fd->zin.pos = 0;
       ^
dataobj/loadsave.cc:866:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
               ^
dataobj/loadsave.cc:866:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  ) {
                             ^
dataobj/loadsave.cc:867:8: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fd->zout.pos = 0;
        ^
dataobj/loadsave.cc:868:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                ^
dataobj/loadsave.cc:868:61: error: âstruct file_descriptors_tâ has no member named âzinâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                             ^
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^
dataobj/loadsave.cc:868:83: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                                   ^
dataobj/loadsave.cc:869:16: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                ^
dataobj/loadsave.cc:869:33: error: âstruct file_descriptors_tâ has no member named âzoutâ
    fwrite( fd->zout.dst, 1, fd->zout.pos, fd->fp );
                                 ^
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:966:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.dst = ls_buf[ buf_num ];
       ^
dataobj/loadsave.cc:967:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.size = LS_BUF_SIZE;
       ^
dataobj/loadsave.cc:968:7: error: âstruct file_descriptors_tâ has no member named âzoutâ
   fd->zout.pos = 0;
       ^
dataobj/loadsave.cc:972:16: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                ^
dataobj/loadsave.cc:972:30: error: âstruct file_descriptors_tâ has no member named âzinâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                              ^
dataobj/loadsave.cc:972:48: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                ^
dataobj/loadsave.cc:972:63: error: âstruct file_descriptors_tâ has no member named âzoutâ
    while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  ) {
                                                               ^
dataobj/loadsave.cc:973:56: error: âstruct file_descriptors_tâ has no member named âzoutâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                        ^
dataobj/loadsave.cc:973:67: error: âstruct file_descriptors_tâ has no member named âzinâ
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                   ^
dataobj/loadsave.cc:973:71: error: âZSTD_decompressStreamâ was not declared in this scope
     size_t ret = ZSTD_decompressStream( fd->dctx, &fd->zout, &fd->zin );
                                                                       ^
dataobj/loadsave.cc:975:10: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
          ^
dataobj/loadsave.cc:975:26: error: âstruct file_descriptors_tâ has no member named âzoutâ
      fd->zout.size = fd->zout.pos;
                          ^
dataobj/loadsave.cc:979:13: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
             ^
dataobj/loadsave.cc:979:28: error: âstruct file_descriptors_tâ has no member named âzoutâ
    if(  fd->zout.pos < fd->zout.size  ) {
                            ^
dataobj/loadsave.cc:980:29: error: âstruct file_descriptors_tâ has no member named âzinâ
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                             ^
dataobj/loadsave.cc:981:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.pos = 0;
         ^
dataobj/loadsave.cc:982:9: error: âstruct file_descriptors_tâ has no member named âzinâ
     fd->zin.size = r;
         ^
dataobj/loadsave.cc:985:15: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
               ^
dataobj/loadsave.cc:985:29: error: âstruct file_descriptors_tâ has no member named âzinâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                             ^
dataobj/loadsave.cc:985:47: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                               ^
dataobj/loadsave.cc:985:62: error: âstruct file_descriptors_tâ has no member named âzoutâ
   while(  fd->zin.pos < fd->zin.size  &&  fd->zout.pos < fd->zout.size  );
                                                              ^
dataobj/loadsave.cc:986:11: error: âstruct file_descriptors_tâ has no member named âzoutâ
   r = fd->zout.pos; // number of bytes decompressed
           ^
common.mk:55: recipe for target 'build/default/dataobj/loadsave.o' failed
make: *** [build/default/dataobj/loadsave.o] Error 1
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 03, 2020, 08:37:07 PM
ZSTD_inBuffer was added in zstd 0.8.1. You must have older...  Current release is 1.4.5.


EDIT:
Ahhh, now we be cooking.... err threading...
Back to 2700X and bb-17-jan-2020.sve:
  binary, 1T=17434 ms,                                                                    4021 MiB
  zstd 3, 1T=23792 ms, 2T=17934 ms, 4T=18070 ms, 8T=18102 ms, 1150 MiB
  zstd 6, 1T=41689 ms, 2T=24499 ms, 4T=19144 ms, 8T=19333 ms, 1164 MiB
  zstd 9,                                              4T=36967ms, 8T=28007 ms, 1016 MiB,    16T=30320 ms (SMT no go.)

Threading already built into library, just turn it on.

ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_nbWorkers, 16 );


Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 04, 2020, 03:57:37 AM
Quote from: jamespetts on December 03, 2020, 02:41:19 PMThe public player's primary colour has indeed not been changed, but the text was formerly not based on the public player's primary colour, but was white. The new code uses the public player colour rather than white. The text in the image is grey rather than blue, which is the public player's default colour.
This is incorrect because a) it affects all players, not just the public player, b) the original (on right) was clearly also grey, corresponding to the public player's colour, and c) ranran investigated the problem further in this thread: https://forum.simutrans.com/index.php/topic,20560.msg193016/topicseen.html#msg193016
Title: Re: Incorporating changes from Standard
Post by: prissi on December 04, 2020, 06:18:38 AM
Test in standard on a four core CPU using a variant of the DOM game using Mingw64 default zstd on a non-debug build.
binary   zstd(6)  zstd(9)  bzip2     zip       zstd(6)1thread  zstd(6)2thread
4665 ms  9174 ms  24464 ms 44263 ms  28389 ms  16919 ms        10796 ms
386MB     101MB   88MB     58MB      102MB

So using a proper buffer and more than one thread I am sold on speed for zstd finally. bUnfourtunately all my server just have single core ...
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 04, 2020, 01:50:25 PM
There was an error merging a commit for Makefile. I've fixed it so please check zstd branch again.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 05, 2020, 01:07:47 PM
Ranran - thank you for that.

Thank you also to TurfIt for having spotted the cause of the compile problems set out above: I was indeed using an older version of libzstd. I have now upgraded the Linux distribution on the server, and am running libzstd-dev version 1.3.3.

I am now getting a different compile error, again with a basic native Linux x64 graphical build:

expr: syntax error
===> CXX dataobj/loadsave.cc
dataobj/loadsave.cc: In member function âbool loadsave_t::wr_open(const char*, loadsave_t::mode_t, int, const char*, const char*, const char*, const char*)â:
dataobj/loadsave.cc:557:37: error: âZSTD_c_compressionLevelâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^~~~~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:557:37: note: suggested alternative: âZSTD_decompressStreamâ
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
                                     ^~~~~~~~~~~~~~~~~~~~~~~
                                     ZSTD_decompressStream
dataobj/loadsave.cc:557:3: error: âZSTD_CCtx_setParameterâ was not declared in this scope
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
   ^~~~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:557:3: note: suggested alternative: âZSTD_CCtx_sâ
   ZSTD_CCtx_setParameter( fd->cctx, ZSTD_c_compressionLevel, level );
   ^~~~~~~~~~~~~~~~~~~~~~
   ZSTD_CCtx_s
dataobj/loadsave.cc: In member function âconst char* loadsave_t::close()â:
dataobj/loadsave.cc:683:68: error: âZSTD_e_endâ was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^~~~~~~~~~
dataobj/loadsave.cc:683:68: note: suggested alternative: âZSTD_DDictâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
                                                                    ^~~~~~~~~~
                                                                    ZSTD_DDict
dataobj/loadsave.cc:683:11: error: âZSTD_compressStream2â was not declared in this scope
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
           ^~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:683:11: note: suggested alternative: âZSTD_compressStreamâ
     ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_end  );
           ^~~~~~~~~~~~~~~~~~~~
           ZSTD_compressStream
dataobj/loadsave.cc: In member function âvoid loadsave_t::flush_buffer(int)â:
dataobj/loadsave.cc:868:67: error: âZSTD_e_continueâ was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
                                                                   ^~~~~~~~~~~~~~~
dataobj/loadsave.cc:868:10: error: âZSTD_compressStream2â was not declared in this scope
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
          ^~~~~~~~~~~~~~~~~~~~
dataobj/loadsave.cc:868:10: note: suggested alternative: âZSTD_compressStreamâ
    ret = ZSTD_compressStream2( fd->cctx, &(fd->zout), &(fd->zin), ZSTD_e_continue );
          ^~~~~~~~~~~~~~~~~~~~
          ZSTD_compressStream
dataobj/loadsave.cc: In member function âint loadsave_t::fill_buffer(int)â:
dataobj/loadsave.cc:980:36: warning: cast from type âconst void*â to type âvoid*â casts away qualifiers [-Wcast-qual]
     r = fread( (void *)(fd->zin.src), 1, LS_BUF_SIZE, fd->fp );
                                    ^
common.mk:55: recipe for target 'build/default/dataobj/loadsave.o' failed
make: *** [build/default/dataobj/loadsave.o] Error 1


This appears to be trying to use Zstd calls or parameters not supported. I am not sure whether even version 1.3.3 is too old for the code, or whether there is some other sort of error. Any enlightenment would be appreciated.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 05, 2020, 07:31:19 PM
Too old. You've 'upgraded' all the way to a 2017 version of zstd. Come a little further to 2018 with 1.3.8, and you might get it to work (these functions are still in the experimental section at that time - need manual enablement). 1.4.0 is when the API is declared stable, so likely works there. But really, if use of the library was added in 2020, why not use a version of the library from 2020....   As said before, 1.4.5 is the current release, and is what I tested with.
Title: Re: Incorporating changes from Standard
Post by: Andarix on December 05, 2020, 07:36:50 PM
zstd 1.4.4 works by me on GitHub
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 05, 2020, 07:47:53 PM
I have been using the package that comes with the Ubuntu distribution that the server uses. I have recently upgraded that from 16.04 to 18.04 (do-release-upgrade does not appear to take it all the way to 20.04). I will need either manually to install a later package or upgrade the server distribution again.

Thank you for this, however: it is most helpful to know what the problem is.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 06, 2020, 05:03:42 PM
I have now managed to upgrade to 20.04, which includes version 1.4.4 of libzstd-dev. This has fixed the libzstd compile errors. However, I am now encountering freetype related linker errors:


===> LD  build/default/simutrans-extended
/usr/bin/ld: build/default/gui/loadfont_frame.o: in function `loadfont_frame_t::check_file(char const*, char const*)':
loadfont_frame.cc:(.text+0x22e): undefined reference to `FT_New_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x241): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: loadfont_frame.cc:(.text+0x29c): undefined reference to `FT_Done_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x30a): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: build/default/gui/loadfont_frame.o: in function `loadfont_frame_t::fill_list()':
loadfont_frame.cc:(.text+0x633): undefined reference to `FT_Init_FreeType'
/usr/bin/ld: loadfont_frame.cc:(.text+0x6af): undefined reference to `FT_New_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x706): undefined reference to `FT_Done_Face'
/usr/bin/ld: loadfont_frame.cc:(.text+0x724): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: build/default/display/font.o: in function `font_t::load_from_freetype(char const*, int)':
font.cc:(.text+0xeca): undefined reference to `FT_Init_FreeType'
/usr/bin/ld: font.cc:(.text+0xee6): undefined reference to `FT_New_Face'
/usr/bin/ld: font.cc:(.text+0xefd): undefined reference to `FT_Set_Pixel_Sizes'
/usr/bin/ld: font.cc:(.text+0x1017): undefined reference to `FT_Get_Char_Index'
/usr/bin/ld: font.cc:(.text+0x1030): undefined reference to `FT_Load_Glyph'
/usr/bin/ld: font.cc:(.text+0x104a): undefined reference to `FT_Render_Glyph'
/usr/bin/ld: font.cc:(.text+0x10ac): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: font.cc:(.text+0x1305): undefined reference to `FT_Done_Face'
/usr/bin/ld: font.cc:(.text+0x130f): undefined reference to `FT_Done_FreeType'
/usr/bin/ld: font.cc:(.text+0x135e): undefined reference to `FT_Done_Face'
/usr/bin/ld: font.cc:(.text+0x1368): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/default/simutrans-extended] Error 1



This looks like I am missing a library reference somewhere, as I have installed the freetype2 dev package. I cannot find any freetype folders in /usr/lib, and I am not sure where I should be looking for these. Any assistance would be appreciated.
Title: Re: Incorporating changes from Standard
Post by: R1dO on December 06, 2020, 08:00:45 PM
Even though i have now idea how your compiling workflow is you might benefit from the discussion over here: https://forum.simutrans.com/index.php/topic,19011.msg180232.html#msg180232
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 08, 2020, 08:36:35 PM
I have now managed to get the basic graphical client in Linux to compile, after finding that I needed manually to specify the library files for Freetype.

However, I am now having a separate compile problem with the server build:


===> CXX utils/log.cc
utils/log.cc: In member function 'void log_t::doubled(const char*, const char*)':
utils/log.cc:238:75: error: expression cannot be used as a function
  238 |    syslog( LOG_WARNING, "Warning: object %s::%s is overlaid!", what, name );
      |                                                                           ^
utils/log.cc: In member function 'void log_t::fatal(const char*, const char*, ...)':
utils/log.cc:274:22: warning: format not a string literal and no format arguments [-Wformat-security]
  274 |   ::syslog( LOG_ERR, buffer );
      |                      ^~~~~~
utils/log.cc: In constructor 'log_t::log_t(const char*, bool, bool, bool, const char*, const char*)':
utils/log.cc:419:35: warning: format not a string literal and no format arguments [-Wformat-security]
  419 |    ::syslog( LOG_NOTICE, greeting );
      |                                   ^
make: *** [common.mk:56: build/server/utils/log.o] Error 1


This appears to be an error with the logging function; I know very little about the logging code. May I ask whether Ranran knows what has changed here so that we can begin the process of tracking down the cause of this problem?

The cross-compile builds are the thing to deal with after this; they will need a vast amount of work, as I will need to download and build cross-compile libraries for freetype2, miniupnpc and zstd. I recall that producing cross-compile libraries was a long and difficult struggle on the last occasion that I attempted it.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 08, 2020, 10:02:18 PM
Quote from: jamespetts on December 08, 2020, 08:36:35 PMThis appears to be an error with the logging function; I know very little about the logging code. May I ask whether Ranran knows what has changed here so that we can begin the process of tracking down the cause of this problem?
I think it was because r8584 wasn't merged.
I would appreciate it if you could try it again.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 08, 2020, 10:51:19 PM
Quote from: Ranran on December 08, 2020, 10:02:18 PM
I think it was because r8584 wasn't merged.
I would appreciate it if you could try it again.

That works - excellent, thank you for the fix.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 01:50:53 AM
I have made some significant progress with this this evening - I have managed to get a 64-bit Windows build running on the merge-from-standard-zstd branch and working without the crash reported in to-day's nightly builds (I will post more on that in the other thread shortly).

There is one problem at present, however, which is that I cannot get the miniupnpc integration working. The problem is that I have been unable to compile a statically linked cross-compile library for miniupnpc; attempting to do so will give rise to the linker errors associated with attempting to link to a dynamic library instead of a static library. I spent some time trying to solve this without success. I am not sure how important that miniupnpc is, as the game will compile satisfactorily without this feature and the current master branch also does not have this feature.

I should be grateful for feedback on this question, and, if it is an important enough issue to solve, some assistance in solving it.

The next step will be testing the new build. The version that I have compiled this evening can be found here (http://bridgewater-brunel.me.uk/downloads/Simutrans-Extended-zstd-mingw64.exe). Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.

As many people as possible testing the zstd compression speed as against the zlib compression speed would also be very helpful.

Thank you to all those who have worked on this so far, especially Ranran - it is much appreciated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 09, 2020, 02:00:49 AM
Quote from: jamespetts on December 09, 2020, 01:50:53 AMThe next step will be testing the new build. The version that I have compiled this evening can be found here. Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.
It seems that the selectable fonts in my self-build version cannot be changed in this build.
Fonts in the windows folder are not selectable in this build. (under c:\Windows\Fonts\ )

It seems that the commit number is standard's one (#9495). Did I overwrite the settings by merging standard commits?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 11:15:42 AM
Quote from: Ranran on December 09, 2020, 02:00:49 AM
It seems that the selectable fonts in my self-build version cannot be changed in this build.
Fonts in the windows folder are not selectable in this build. (under c:\Windows\Fonts\ )

It seems that the commit number is standard's one (#9495). Did I overwrite the settings by merging standard commits?

I note that I was compiling with FREETYPE = 0 in the makefile configuration. I suspect that this is because I had difficulty setting up libraries for this when I first started cross compiling some time ago. I will look into whether I can enable this, but I am not sure whether I shall be able to do so.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 12:09:24 PM
I have looked into this and am having intractible problems in compiling a cross-compile compatible version of freetype2.

For some reason, when I amend the configuration files to point to the correct cross-compiler, the cross-compiler seems to fail to recognise the forward slashes used to denote directories and reports:


x86_64-w64-mingw32-gcc  -I.\objs -I.\builds\windows -I.\include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs\ftsystem.obj src\base\ftsystem.c
x86_64-w64-mingw32-gcc: error: srcbaseftsystem.c: No such file or directory
x86_64-w64-mingw32-gcc: fatal error: no input files
compilation terminated.
make: *** [builds/freetype.mk:204: objs/ftsystem.obj] Error 1


This really makes no sense at all; any assistance in resolving this would be appreciated.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 12:49:43 PM
src/base/ftsystem.c    'src\base\ftsystem.c'    src\\base\\ftsystem.c
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 02:09:06 PM
Quote from: TurfIt on December 09, 2020, 12:49:43 PM
src/base/ftsystem.c    'src\base\ftsystem.c'    src\\base\\ftsystem.c


Thank you for that. The configuration files for Freetype are very difficult to deal with (and extremely numerous) and, so far as I can tell, very poorly documented. There was a backslash specified in one of them, which, when changed to a forward slash, eliminated the error. However, I now get another error:


x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftsystem.obj src/base/ftsystem.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftdebug.obj src/base/ftdebug.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftinit.obj src/base/ftinit.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbase.obj ./src/base/ftbase.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbbox.obj src/base/ftbbox.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbdf.obj src/base/ftbdf.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbitmap.obj src/base/ftbitmap.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftcid.obj src/base/ftcid.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftfstype.obj src/base/ftfstype.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgasp.obj src/base/ftgasp.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftglyph.obj src/base/ftglyph.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgxval.obj src/base/ftgxval.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftmm.obj src/base/ftmm.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftotval.obj src/base/ftotval.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftpatent.obj src/base/ftpatent.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftpfr.obj src/base/ftpfr.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftstroke.obj src/base/ftstroke.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftsynth.obj src/base/ftsynth.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/fttype1.obj src/base/fttype1.c
x86_64-w64-mingw32-gcc  -I./src/base -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftwinfnt.obj src/base/ftwinfnt.c
x86_64-w64-mingw32-gcc  -I./src/truetype -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/truetype.obj ./src/truetype/truetype.c
x86_64-w64-mingw32-gcc  -I./src/type1 -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type1.obj ./src/type1/type1.c
x86_64-w64-mingw32-gcc  -I./src/cff -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/cff.obj ./src/cff/cff.c
x86_64-w64-mingw32-gcc  -I./src/cid -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type1cid.obj ./src/cid/type1cid.c
x86_64-w64-mingw32-gcc  -I./src/pfr -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pfr.obj ./src/pfr/pfr.c
x86_64-w64-mingw32-gcc  -I./src/type42 -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/type42.obj ./src/type42/type42.c
x86_64-w64-mingw32-gcc  -I./src/winfonts -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/winfnt.obj ./src/winfonts/winfnt.c
x86_64-w64-mingw32-gcc  -I./src/pcf -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pcf.obj ./src/pcf/pcf.c
x86_64-w64-mingw32-gcc  -I./src/bdf -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/bdf.obj ./src/bdf/bdf.c
x86_64-w64-mingw32-gcc  -I./src/sfnt -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/sfnt.obj ./src/sfnt/sfnt.c
x86_64-w64-mingw32-gcc  -I./src/autofit -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/autofit.obj ./src/autofit/autofit.c
x86_64-w64-mingw32-gcc  -I./src/pshinter -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/pshinter.obj ./src/pshinter/pshinter.c
x86_64-w64-mingw32-gcc  -I./src/raster -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/raster.obj ./src/raster/raster.c
x86_64-w64-mingw32-gcc  -I./src/smooth -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/smooth.obj ./src/smooth/smooth.c
x86_64-w64-mingw32-gcc  -I./src/cache -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftcache.obj ./src/cache/ftcache.c
x86_64-w64-mingw32-gcc  -I./src/gzip -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftgzip.obj ./src/gzip/ftgzip.c
x86_64-w64-mingw32-gcc  -I./src/lzw -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftlzw.obj ./src/lzw/ftlzw.c
x86_64-w64-mingw32-gcc  -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/ftbzip2.obj ./src/bzip2/ftbzip2.c
x86_64-w64-mingw32-gcc  -I./src/psaux -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/psaux.obj ./src/psaux/psaux.c
x86_64-w64-mingw32-gcc  -I./src/psnames -I./objs -I./builds/windows -I./include  -c -g2 -O -DFT2_BUILD_LIBRARY -Foobjs/psnames.obj ./src/psnames/psnames.c
lcclib /out:objs/freetype.lib  ./objs/ftsystem.obj ./objs/ftdebug.obj ./objs/ftinit.obj ./objs/ftbase.obj ./objs/ftbbox.obj ./objs/ftbdf.obj ./objs/ftbitmap.obj ./objs/ftcid.obj ./objs/ftfstype.obj ./objs/ftgasp.obj ./objs/ftglyph.obj ./objs/ftgxval.obj ./objs/ftmm.obj ./objs/ftotval.obj ./objs/ftpatent.obj ./objs/ftpfr.obj ./objs/ftstroke.obj ./objs/ftsynth.obj ./objs/fttype1.obj ./objs/ftwinfnt.obj ./objs/truetype.obj ./objs/type1.obj ./objs/cff.obj ./objs/type1cid.obj ./objs/pfr.obj ./objs/type42.obj ./objs/winfnt.obj ./objs/pcf.obj ./objs/bdf.obj ./objs/sfnt.obj ./objs/autofit.obj ./objs/pshinter.obj ./objs/raster.obj ./objs/smooth.obj ./objs/ftcache.obj ./objs/ftgzip.obj ./objs/ftlzw.obj ./objs/ftbzip2.obj ./objs/psaux.obj ./objs/psnames.obj ./objs/truetype.obj ./objs/type1.obj ./objs/cff.obj ./objs/type1cid.obj ./objs/pfr.obj ./objs/type42.obj ./objs/winfnt.obj ./objs/pcf.obj ./objs/bdf.obj ./objs/sfnt.obj ./objs/autofit.obj ./objs/pshinter.obj ./objs/raster.obj ./objs/smooth.obj ./objs/ftcache.obj ./objs/ftgzip.obj ./objs/ftlzw.obj ./objs/ftbzip2.obj ./objs/psaux.obj ./objs/psnames.obj
make: lcclib: Command not found
make: *** [config.mk:55: objs/freetype.lib] Error 127


The reference to a .lib file, combined with the earlier specification of the backslash, makes me wonder whether the configuration that I am using for Freetype is not a configuration for producing libraries for a cross-compile build, but rather a configuration for cross-compiling libraries for use when compiling using those libraries on Windows machines. If that is so, then it is very unclear to me how to configure the various configuration files to build libraries for cross compiling.
Title: Re: Incorporating changes from Standard
Post by: prissi on December 09, 2020, 02:09:46 PM
Since even windows can hande "/" as path seperator, I strongly suggest to forget using "\" at all. Just use "/" is all pathes.

For crosscompiling, I found most useful to have a file in my oath, called mingw64

#!/bin/sh
PREFIX=i686-w64-mingw32
export CC=$PREFIX-gcc
export CXX=$PREFIX-g++
export CPP=$PREFIX-cpp
export WINDRES=$PREFIX-windres
export AR=$PREFIX-ar
export RANLIB=$PREFIX-ranlib
export PATH="/usr/i686-w64-mingw32/bin:$PATH"
exec "$@"


Then the actual crosscompiling script looks like this:
cd /home/simutrans/mingw64/trunk
rm simu*.zip
rm sim
rm sim.exe
rm config.default
cp config.default.gdi config.default
export export PATH="/home/simutrans/bin:$PATH"
svn revert -R .
svn up
mingw64 gcc -xc++ -dM -E - < /dev/null
mingw64 make clean
mingw64 make
mingw64 strip sim
mv sim sim.exe
/home/simutrans/mingw64/trunk/distribute.sh
rm sim.exe
svn revert -R .
mingw64 make clean
rm -rf /home/simutrans/mingw64/trunk/build


If you copy the *.h files and the .a into the respective include and lib fodlers, then the crosscompiler finds libfreetype and compiles it without any extra pathes. Also for compiling freetype, forget about the stupid libharfbuzz. That adds 3 MB for nothing Simutrans can use. Without it (and maybe even without libbrotli) freetypes compiles easily.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 02:12:49 PM
Prissi - thank you for that. The problem that I am having at present is the cross-compiling of the cross-compile Freetype libraries; aside from missing Freetype libraries, I can cross-compile a working build of Simutrans-Extended (albeit only one with Freetype disabled).
Title: Re: Incorporating changes from Standard
Post by: prissi on December 09, 2020, 02:15:24 PM
Sorry, see my edit. Freetype can do with libharfbuzz.

if you have a mingw64 script like my example, then you can use the "mingw64 ./configure  --without-harfbuzz ..." to build the lib. Or just compile the lib under windows and upload it to your server ...
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 03:10:33 PM
Quote from: jamespetts on December 09, 2020, 02:09:06 PM
If that is so, then it is very unclear to me how to configure the various configuration files to build libraries for cross compiling.
Is there something wrong with './configure --build={whatever your build system is} --host=x86_64-w64-mingw32'  as specified in freetype-2.10.4/docs/INSTALL.CROSS?  (and of course with --prefix as needed...)
Title: Re: Incorporating changes from Standard
Post by: Matthew on December 09, 2020, 05:13:24 PM
I just want to point out a decision which seem to be being made by default in this thread.

The existing cross-compilation process is not documented at all. This is for a very good reason. James, you are self-taught coder who just wants something that works, since you are primarily interested in transport and Simutrans, not wading through obscure details of harfbuzz. That is entirely understandable - that's where I'm coming from too. But the short-term fix is not ideal in the long-run because (a) if you are the only person who can cross-compile Extended, it increases the demands on you and (b) it means the Extended build process becomes dependent upon where files are located in one particular system (Bridgewater-Brunel).

The CMake build process was intended to get Extended out of this hole by moving to a single build process that works everywhere and manages dependencies wherever possible. It also integrates with Github Actions, which also reduces the project's dependency on Bridgewater-Brunel.

The way that the very real dependency problems are being tackled in this thread is digging us further into the hole of undocumented, B-B-dependent compilation. I understand that it's easier in the short-term. And I guess it would be possible to use the old system first and move to CMake later, at the cost of doing all the work twice. But the fact that B-B has just been updated and you and Ranran are very kindly integrating a large number of Standard features in one go means this may well be the best opportunity for several years to move dependency management over to the CMake-based process.

I can't offer to help you to move to a CMake process, because I know much less than anyone else here about coding. I can't even promise it will be easier. But I would urge you to step back for a moment to consider whether you really want to stay with the existing process or move to a CMake-based process, since that decision is being made by default.

Quote from: jamespetts on December 09, 2020, 01:50:53 AM
I have made some significant progress with this this evening - I have managed to get a 64-bit Windows build running on the merge-from-standard-zstd branch and working without the crash reported in to-day's nightly builds (I will post more on that in the other thread shortly).

...
The next step will be testing the new build. The version that I have compiled this evening can be found here (http://bridgewater-brunel.me.uk/downloads/Simutrans-Extended-zstd-mingw64.exe). Any intrepid testers are encouraged to report findings on this thread so that Ranran and/or I (as appropriate) can look into and address the issues found.

I can confirm that it runs on my Windows 10 VM with an offline B-B save from today and that the follow-me-underground feature is really cool!  8)

I am aware that it would be helpful to test out the theming features. Anything else?

QuoteAs many people as possible testing the zstd compression speed as against the zlib compression speed would also be very helpful.

Hmm. I need to sit down and work out how to do this.

QuoteThank you to all those who have worked on this so far, especially Ranran - it is much appreciated.

Ranran, I can see from Github that your have poured dozens if not hundreds of hours into this project. Thank you so much!
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 05:20:11 PM
Thank you all for your help. Unfortunately, I have still not succeeded in building a workable freetype library. Using TurfIt's suggestion, the build of the library apparently completes without errors, but attempting to compile Simutrans-Extended results in:


===> LD  build/mingw64/Simutrans-Extended.exe
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf18): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf35): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf4c): undefined reference to `FT_Set_Pixel_Sizes'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1060): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x107d): undefined reference to `FT_Load_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1094): undefined reference to `FT_Render_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1149): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1153): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1184): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1357): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1361): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x20b): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x21e): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x22c): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x2d3): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x635): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x6b1): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x708): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x725): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/mingw64/Simutrans-Extended.exe] Error 1


I execute this command:


./configure --host=x86_64-w64-mingw32 --without-harfbuzz


and get this apparently correct output:


FreeType build system -- automatic system detection

The following settings are used:

  platform                    unix
  compiler                    cc
  configuration directory     ./builds/unix
  configuration rules         ./builds/unix/unix.mk

If this does not correspond to your system or settings please remove the file
`config.mk' from this directory then read the INSTALL file for help.

Otherwise, simply type `make' again to build the library,
or `make refdoc' to build the API reference (this needs Python >= 3.5).

cd builds/unix; \
        ./configure  '--host=x86_64-w64-mingw32' '--without-harfbuzz'
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for x86_64-w64-mingw32-pkg-config... /usr/bin/x86_64-w64-mingw32-pkg-config
checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building
no
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /usr/bin/x86_64-w64-mingw32-ld
checking if the linker (/usr/bin/x86_64-w64-mingw32-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/usr/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/x86_64-w64-mingw32-ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for archiver @FILE support... @
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking for gawk... no
checking for mawk... mawk
checking command to parse /usr/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for x86_64-w64-mingw32-mt... no
checking for mt... mt
configure: WARNING: using cross tools not prefixed with host triplet
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/usr/bin/x86_64-w64-mingw32-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking windows.h usability... yes
checking windows.h presence... yes
checking for windows.h... yes
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking for x86_64-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for suffix of native executables...
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking size of int... 4
checking size of long... 4
checking for unsigned long long int... yes
checking for long long int... yes
checking whether cpp computation of bit length in ftconfig.h.in works... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for memcpy... yes
checking for memmove... yes
checking for -fvisibility=hidden compiler flag... yes
checking for ZLIB... no
checking for gzsetparams in -lz... no
checking for BZIP2... no
checking for BZ2_bzDecompress in -lbz2... no
checking for LIBPNG... no
checking for libpng-config... yes
checking for BROTLI... no
checking for library containing clock_gettime... no
checking for python3... python3
checking for python version... 3.8.5
checking for `docwriter' Python module... no
configure: creating ./config.status
config.status: creating ftoption.h
config.status: creating unix-cc.mk
config.status: creating unix-def.mk
config.status: creating ftconfig.h
config.status: ftconfig.h is unchanged
config.status: executing libtool commands
configure:

Library configuration:
  external zlib: no
  bzip2:         no
  libpng:        yes (libpng-config)
  harfbuzz:      no
  brotli:        no

configure: WARNING:
  `make refdoc' will fail since pip package `docwriter' is not installed.
  To install, run `python3 -m pip install docwriter', or to use a Python
  virtual environment, run `make refdoc-venv' (requires pip package
  `virtualenv'). These operations require Python >= 3.5.


I then issue a "make" command and get an output too long to reproduce here, but which appears to conclude without error, albeit there are some warnings at the end:


*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libm.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: x86_64-w64-mingw32-ar cru /root/freetype-2.10.4/objs/.libs/libfreetype.a  /root/freetype-2.10.4/objs/ftsystem.o /root/freetype-2.10.4/objs/ftdebug.o /root/freetype-2.10.4/objs/ftinit.o /root/freetype-2.10.4/objs/ftver.o /root/freetype-2.10.4/objs/ftbase.o /root/freetype-2.10.4/objs/ftbbox.o /root/freetype-2.10.4/objs/ftbdf.o /root/freetype-2.10.4/objs/ftbitmap.o /root/freetype-2.10.4/objs/ftcid.o /root/freetype-2.10.4/objs/ftfstype.o /root/freetype-2.10.4/objs/ftgasp.o /root/freetype-2.10.4/objs/ftglyph.o /root/freetype-2.10.4/objs/ftgxval.o /root/freetype-2.10.4/objs/ftmm.o /root/freetype-2.10.4/objs/ftotval.o /root/freetype-2.10.4/objs/ftpatent.o /root/freetype-2.10.4/objs/ftpfr.o /root/freetype-2.10.4/objs/ftstroke.o /root/freetype-2.10.4/objs/ftsynth.o /root/freetype-2.10.4/objs/fttype1.o /root/freetype-2.10.4/objs/ftwinfnt.o /root/freetype-2.10.4/objs/truetype.o /root/freetype-2.10.4/objs/type1.o /root/freetype-2.10.4/objs/cff.o /root/freetype-2.10.4/objs/type1cid.o /root/freetype-2.10.4/objs/pfr.o /root/freetype-2.10.4/objs/type42.o /root/freetype-2.10.4/objs/winfnt.o /root/freetype-2.10.4/objs/pcf.o /root/freetype-2.10.4/objs/bdf.o /root/freetype-2.10.4/objs/sfnt.o /root/freetype-2.10.4/objs/autofit.o /root/freetype-2.10.4/objs/pshinter.o /root/freetype-2.10.4/objs/raster.o /root/freetype-2.10.4/objs/smooth.o /root/freetype-2.10.4/objs/ftcache.o /root/freetype-2.10.4/objs/ftgzip.o /root/freetype-2.10.4/objs/ftlzw.o /root/freetype-2.10.4/objs/ftbzip2.o /root/freetype-2.10.4/objs/psaux.o /root/freetype-2.10.4/objs/psnames.o
x86_64-w64-mingw32-ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: x86_64-w64-mingw32-ranlib /root/freetype-2.10.4/objs/.libs/libfreetype.a
libtool: link: ( cd "/root/freetype-2.10.4/objs/.libs" && rm -f "libfreetype.la" && ln -s "../libfreetype.la" "libfreetype.la" )


Having done that, issuing a make command for Simutrans-Extended with the mingw64 compile option gives the errors set out above. For reference, the following is set in config.mingw64:


LDFLAGS = -L/root/freetype-2.10.4


/root/freetype-2.10.4 is the directory in which I have extracted and built the Freetype libraries. I have also tried


LDFLAGS = -L/root/freetype-2.10.4/objs


also without success. I am not sure quite what further thing that I can try, especially as the build appears to complete without errors but I am unable to link from Simutrans-Extended.
For reference, these are the contents of the relevant folders:
root@438242:~/freetype-2.10.4/objs# ls -l
total 5492
-rwxr-xr-x 1 root          root   22112 Dec  9 16:39 apinames
-rw-r--r-- 1 root          root     300 Dec  9 17:11 autofit.lo
-rw-r--r-- 1 root          root  405887 Dec  9 17:11 autofit.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 bdf.lo
-rw-r--r-- 1 root          root  132609 Dec  9 17:10 bdf.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 cff.lo
-rw-r--r-- 1 root          root  294089 Dec  9 17:10 cff.o
-rw-r--r-- 1 root          root     297 Dec  9 17:09 ftbase.lo
-rw-r--r-- 1 root          root  643683 Dec  9 17:09 ftbase.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 ftbbox.lo
-rw-r--r-- 1 root          root   18364 Dec  9 17:10 ftbbox.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftbdf.lo
-rw-r--r-- 1 root          root   22426 Dec  9 17:10 ftbdf.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftbitmap.lo
-rw-r--r-- 1 root          root   60821 Dec  9 17:10 ftbitmap.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 ftbzip2.lo
-rw-r--r-- 1 root          root    8181 Dec  9 17:11 ftbzip2.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 ftcache.lo
-rw-r--r-- 1 root          root  168990 Dec  9 17:11 ftcache.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftcid.lo
-rw-r--r-- 1 root          root   23517 Dec  9 17:10 ftcid.o
-rw-r--r-- 1 root          root     300 Dec  9 17:09 ftdebug.lo
-rw-r--r-- 1 root          root    3561 Dec  9 17:09 ftdebug.o
-rw-r--r-- 1 root          root    3978 Dec  9 16:39 ftexport.sym
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftfstype.lo
-rw-r--r-- 1 root          root   21184 Dec  9 17:10 ftfstype.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 ftgasp.lo
-rw-r--r-- 1 root          root   26252 Dec  9 17:10 ftgasp.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftglyph.lo
-rw-r--r-- 1 root          root   44615 Dec  9 17:10 ftglyph.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftgxval.lo
-rw-r--r-- 1 root          root   24132 Dec  9 17:10 ftgxval.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 ftgzip.lo
-rw-r--r-- 1 root          root  134120 Dec  9 17:11 ftgzip.o
-rw-r--r-- 1 root          root     297 Dec  9 17:09 ftinit.lo
-rw-r--r-- 1 root          root   26131 Dec  9 17:09 ftinit.o
-rw-r--r-- 1 root          root     294 Dec  9 17:11 ftlzw.lo
-rw-r--r-- 1 root          root   35788 Dec  9 17:11 ftlzw.o
-rw-r--r-- 1 root          root     291 Dec  9 17:10 ftmm.lo
-rw-r--r-- 1 root          root   46102 Dec  9 17:10 ftmm.o
-rw-r--r-- 1 root          root     925 Dec  9 11:36 ftmodule.h
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftotval.lo
-rw-r--r-- 1 root          root   22124 Dec  9 17:10 ftotval.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftpatent.lo
-rw-r--r-- 1 root          root   16186 Dec  9 17:10 ftpatent.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 ftpfr.lo
-rw-r--r-- 1 root          root   26339 Dec  9 17:10 ftpfr.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftstroke.lo
-rw-r--r-- 1 root          root  127869 Dec  9 17:10 ftstroke.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 ftsynth.lo
-rw-r--r-- 1 root          root   19739 Dec  9 17:10 ftsynth.o
-rw-r--r-- 1 root          root     303 Dec  9 17:09 ftsystem.lo
-rw-r--r-- 1 root          root   14266 Dec  9 17:09 ftsystem.o
-rw-r--r-- 1 root          root     300 Dec  9 17:10 fttype1.lo
-rw-r--r-- 1 root          root   26792 Dec  9 17:10 fttype1.o
-rw-r--r-- 1 root          root     294 Dec  9 16:44 ftver.lo
-rw-r--r-- 1 root          root    1020 Dec  9 16:44 ftver.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 ftwinfnt.lo
-rw-r--r-- 1 root          root   21501 Dec  9 17:10 ftwinfnt.o
-rw-r--r-- 1 root          root     929 Dec  9 17:11 libfreetype.la
-rw-r--r-- 1 root          root     288 Dec  9 17:10 pcf.lo
-rw-r--r-- 1 root          root   93133 Dec  9 17:10 pcf.o
-rw-r--r-- 1 root          root     288 Dec  9 17:10 pfr.lo
-rw-r--r-- 1 root          root  151406 Dec  9 17:10 pfr.o
-rw-r--r-- 1 root          root     294 Dec  9 17:11 psaux.lo
-rw-r--r-- 1 root          root  447039 Dec  9 17:11 psaux.o
-rw-r--r-- 1 root          root     303 Dec  9 17:11 pshinter.lo
-rw-r--r-- 1 root          root  188038 Dec  9 17:11 pshinter.o
-rw-r--r-- 1 root          root     300 Dec  9 17:11 psnames.lo
-rw-r--r-- 1 root          root  106313 Dec  9 17:11 psnames.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 raster.lo
-rw-r--r-- 1 root          root   97808 Dec  9 17:11 raster.o
-rw-r--r-- 1 administrator users     80 Jan 19  2020 README
-rw-r--r-- 1 root          root     291 Dec  9 17:10 sfnt.lo
-rw-r--r-- 1 root          root  684892 Dec  9 17:10 sfnt.o
-rw-r--r-- 1 root          root     297 Dec  9 17:11 smooth.lo
-rw-r--r-- 1 root          root   75313 Dec  9 17:11 smooth.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 truetype.lo
-rw-r--r-- 1 root          root  493490 Dec  9 17:10 truetype.o
-rw-r--r-- 1 root          root     303 Dec  9 17:10 type1cid.lo
-rw-r--r-- 1 root          root  136873 Dec  9 17:10 type1cid.o
-rw-r--r-- 1 root          root     294 Dec  9 17:10 type1.lo
-rw-r--r-- 1 root          root  265266 Dec  9 17:10 type1.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 type42.lo
-rw-r--r-- 1 root          root  125160 Dec  9 17:10 type42.o
-rw-r--r-- 1 root          root     297 Dec  9 17:10 winfnt.lo
-rw-r--r-- 1 root          root   59958 Dec  9 17:10 winfnt.o
root@438242:~/freetype-2.10.4/objs# cd ..
root@438242:~/freetype-2.10.4# ls -l
total 6424
-rw-r--r--  1 root          root  382541 Dec  9 14:05 autofit.o
-rwxr-xr-x  1 administrator users   3935 Aug 31 08:26 autogen.sh
-rw-r--r--  1 root          root  119014 Dec  9 14:05 bdf.o
drwxr-xr-x 17 administrator users   4096 Dec  9 11:59 builds
-rw-r--r--  1 root          root  278555 Dec  9 14:05 cff.o
-rw-r--r--  1 administrator users 155426 Oct 20 06:13 ChangeLog
-rw-r--r--  1 administrator users  91563 Jan 19  2020 ChangeLog.20
-rw-r--r--  1 administrator users 329142 Aug 27 07:17 ChangeLog.21
-rw-r--r--  1 administrator users  99819 Jan 19  2020 ChangeLog.22
-rw-r--r--  1 administrator users 272330 Jan 19  2020 ChangeLog.23
-rw-r--r--  1 administrator users 207336 Jan 19  2020 ChangeLog.24
-rw-r--r--  1 administrator users 162296 Jan 19  2020 ChangeLog.25
-rw-r--r--  1 administrator users 176364 Jan 19  2020 ChangeLog.26
-rw-r--r--  1 administrator users  63133 Jan 19  2020 ChangeLog.27
-rw-r--r--  1 administrator users  96385 Jan 19  2020 ChangeLog.28
-rw-r--r--  1 administrator users  72091 Jan 19  2020 ChangeLog.29
-rw-r--r--  1 administrator users  18071 Oct 20 06:03 CMakeLists.txt
-rw-r--r--  1 root          root    1621 Dec  9 17:08 config.mk
-rwxr-xr-x  1 administrator users   4000 Mar 22  2020 configure
drwxr-xr-x  2 administrator users   4096 Oct 20 06:14 devel
drwxr-xr-x  3 administrator users   4096 Oct 20 06:15 docs
-rw-r--r--  1 root          root  390154 Dec  9 14:05 ftbase.o
-rw-r--r--  1 root          root   18132 Dec  9 14:05 ftbbox.o
-rw-r--r--  1 root          root   22134 Dec  9 14:05 ftbdf.o
-rw-r--r--  1 root          root   59435 Dec  9 14:05 ftbitmap.o
-rw-r--r--  1 root          root    8101 Dec  9 14:05 ftbzip2.o
-rw-r--r--  1 root          root  148317 Dec  9 14:05 ftcache.o
-rw-r--r--  1 root          root   23929 Dec  9 14:05 ftcid.o
-rw-r--r--  1 root          root    3461 Dec  9 14:04 ftdebug.o
-rw-r--r--  1 root          root   20832 Dec  9 14:05 ftfstype.o
-rw-r--r--  1 root          root   26496 Dec  9 14:05 ftgasp.o
-rw-r--r--  1 root          root   41681 Dec  9 14:05 ftglyph.o
-rw-r--r--  1 root          root   23414 Dec  9 14:05 ftgxval.o
-rw-r--r--  1 root          root   95993 Dec  9 14:05 ftgzip.o
-rw-r--r--  1 root          root   24934 Dec  9 14:05 ftinit.o
-rw-r--r--  1 root          root   34144 Dec  9 14:05 ftlzw.o
-rw-r--r--  1 root          root   40840 Dec  9 14:05 ftmm.o
-rw-r--r--  1 root          root   21284 Dec  9 14:05 ftotval.o
-rw-r--r--  1 root          root   16070 Dec  9 14:05 ftpatent.o
-rw-r--r--  1 root          root   24625 Dec  9 14:05 ftpfr.o
-rw-r--r--  1 root          root  109919 Dec  9 14:05 ftstroke.o
-rw-r--r--  1 root          root   19451 Dec  9 14:05 ftsynth.o
-rw-r--r--  1 root          root   13956 Dec  9 14:04 ftsystem.o
-rw-r--r--  1 root          root   26508 Dec  9 14:05 fttype1.o
-rw-r--r--  1 root          root   21129 Dec  9 14:05 ftwinfnt.o
drwxr-xr-x  3 administrator users   4096 Oct 20 06:14 include
-rw-r--r--  1 administrator users    846 Dec  9 11:40 Makefile
-rw-r--r--  1 administrator users  10876 Sep 22 18:55 meson.build
-rw-r--r--  1 administrator users   1351 Sep 21 06:53 meson_options.txt
-rw-r--r--  1 administrator users   6398 Aug 24 21:21 modules.cfg
drwxr-xr-x  3 administrator users   4096 Dec  9 17:11 objs
-rw-r--r--  1 root          root   86591 Dec  9 14:05 pcf.o
-rw-r--r--  1 root          root  143663 Dec  9 14:05 pfr.o
-rw-r--r--  1 root          root  412090 Dec  9 14:05 psaux.o
-rw-r--r--  1 root          root  167320 Dec  9 14:05 pshinter.o
-rw-r--r--  1 root          root  104294 Dec  9 14:05 psnames.o
-rw-r--r--  1 root          root   91462 Dec  9 14:05 raster.o
-rw-r--r--  1 administrator users   2826 Oct 20 06:03 README
-rw-r--r--  1 administrator users   1613 Aug 31 08:26 README.git
-rw-r--r--  1 root          root  510820 Dec  9 14:05 sfnt.o
-rw-r--r--  1 root          root   74655 Dec  9 14:05 smooth.o
drwxr-xr-x 26 administrator users   4096 Oct 20 06:14 src
-rw-r--r--  1 root          root  464753 Dec  9 14:05 truetype.o
-rw-r--r--  1 root          root  131073 Dec  9 14:05 type1cid.o
-rw-r--r--  1 root          root  220438 Dec  9 14:05 type1.o
-rw-r--r--  1 root          root  122610 Dec  9 14:05 type42.o
-rw-r--r--  1 administrator users    236 Jan 19  2020 version.sed
-rw-r--r--  1 administrator users  36034 Jan 19  2020 vms_make.com
-rw-r--r--  1 root          root   57720 Dec  9 14:05 winfnt.o

Edit: In relation to CMake - this is not something that I am familiar with at all. I do not know how, if at all, this handles cross-compilation and libraries, or on which server(s) that it runs. I am not sure whether I am relying on third party servers which might be shut down at any time in order to run this, or whether I can run my own CMake server on Bridgwater-Brunel, and, if so, how much work that it would take to set this up.
Learning an entirely new build system from scratch would take an unknown amount of time and might indefinitely postpone all work on Simutrans-Extended if the amount of time that it requires becomes extreme, as I can forsee that it might well. Embarking on a project with no idea at all of whether it can be completed within any reasonable time is best avoided.

If there are those who are willing and able to assist in setting up a CMake system, preferably to run alongside the existing compiling system to allow sufficient redundancy, this might be another matter, depending on the level of assistance that they are able to provide.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 05:49:08 PM
Missing '--build=' triple, although it's detecting 'x86_64-pc-linux-gnu' which if correct is ok.
Missing pkgconfig "checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building no" OK if you want to have to specify paths all the time rather than letting it "just work"
Missing way more than just harfbuzz:

Library configuration:
  external zlib: no
  bzip2:         no
  libpng:        yes (libpng-config)
  harfbuzz:      no
  brotli:        no

  image you need atleast zlib, as does Simutrans itself.
Missing 'make install' after 'make' ?  Again ok if you want a path mess. And will put things where you've specified with '--prefix=' which needs to be set for wherever your cross toolchain uses.  (/usr/x86_64-w64-mingw32/ maybe?)
LDFLAGS shouldn't need explicit setting if done "right". paths come from freetype2.pc via pkg-config called in makefile. (although you might still have freetype-config in there which may/may not work, so can just override in your config.mingw.  i.e. FREETYPE_CONFIG = pkg-config freetype2
And do note the libs are in objs/.libs after building freetype (before make/install does its thing...)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 06:16:07 PM
Thank you for your help. I have tried specifying the objs/.libs directory (which I had not seen before because it was hidden) as a library directory, but sadly this does not assist.

I have to say, I did not know that there was any system for automating the directories for cross-compiling; I am aware that this is normal for native compiling, but I had not found any documentation anywhere suggesting that this was a thing for cross-compiling (after struggling for months to get cross-compiling to work when I first started the nightly build server back in 2017), so I had just set up the directories in the /root folder and linked to them manually, which worked.

As to library configurations, do I understand that freetype needs zlib to work? I am not getting any compile errors, so this is somewhat surprising; what is being compiled if there are dependencies missing? The objs/.libs directory is populated as follows:


-rw-r--r-- 1 root root  405887 Dec  9 17:11 autofit.o
-rw-r--r-- 1 root root  132609 Dec  9 17:10 bdf.o
-rw-r--r-- 1 root root  294089 Dec  9 17:10 cff.o
-rw-r--r-- 1 root root  646787 Dec  9 17:09 ftbase.o
-rw-r--r-- 1 root root   18472 Dec  9 17:10 ftbbox.o
-rw-r--r-- 1 root root   22566 Dec  9 17:10 ftbdf.o
-rw-r--r-- 1 root root   61113 Dec  9 17:10 ftbitmap.o
-rw-r--r-- 1 root root    8289 Dec  9 17:11 ftbzip2.o
-rw-r--r-- 1 root root  169530 Dec  9 17:11 ftcache.o
-rw-r--r-- 1 root root   23729 Dec  9 17:10 ftcid.o
-rw-r--r-- 1 root root    3561 Dec  9 17:09 ftdebug.o
-rw-r--r-- 1 root root   21292 Dec  9 17:10 ftfstype.o
-rw-r--r-- 1 root root   26352 Dec  9 17:10 ftgasp.o
-rw-r--r-- 1 root root   44871 Dec  9 17:10 ftglyph.o
-rw-r--r-- 1 root root   24336 Dec  9 17:10 ftgxval.o
-rw-r--r-- 1 root root  134256 Dec  9 17:11 ftgzip.o
-rw-r--r-- 1 root root   26331 Dec  9 17:09 ftinit.o
-rw-r--r-- 1 root root   35892 Dec  9 17:11 ftlzw.o
-rw-r--r-- 1 root root   46662 Dec  9 17:10 ftmm.o
-rw-r--r-- 1 root root   22260 Dec  9 17:10 ftotval.o
-rw-r--r-- 1 root root   16342 Dec  9 17:10 ftpatent.o
-rw-r--r-- 1 root root   26503 Dec  9 17:10 ftpfr.o
-rw-r--r-- 1 root root  128501 Dec  9 17:10 ftstroke.o
-rw-r--r-- 1 root root   19879 Dec  9 17:10 ftsynth.o
-rw-r--r-- 1 root root   14266 Dec  9 17:09 ftsystem.o
-rw-r--r-- 1 root root   26996 Dec  9 17:10 fttype1.o
-rw-r--r-- 1 root root    1020 Dec  9 16:44 ftver.o
-rw-r--r-- 1 root root   21609 Dec  9 17:10 ftwinfnt.o
-rw-r--r-- 1 root root 5359480 Dec  9 17:11 libfreetype.a
lrwxrwxrwx 1 root root      17 Dec  9 17:11 libfreetype.la -> ../libfreetype.la
-rw-r--r-- 1 root root     930 Dec  9 17:11 libfreetype.lai
-rw-r--r-- 1 root root   93133 Dec  9 17:10 pcf.o
-rw-r--r-- 1 root root  151406 Dec  9 17:10 pfr.o
-rw-r--r-- 1 root root  447039 Dec  9 17:11 psaux.o
-rw-r--r-- 1 root root  188038 Dec  9 17:11 pshinter.o
-rw-r--r-- 1 root root  106313 Dec  9 17:11 psnames.o
-rw-r--r-- 1 root root   97808 Dec  9 17:11 raster.o
-rw-r--r-- 1 root root  684892 Dec  9 17:10 sfnt.o
-rw-r--r-- 1 root root   75313 Dec  9 17:11 smooth.o
-rw-r--r-- 1 root root  493614 Dec  9 17:10 truetype.o
-rw-r--r-- 1 root root  136873 Dec  9 17:10 type1cid.o
-rw-r--r-- 1 root root  265266 Dec  9 17:10 type1.o
-rw-r--r-- 1 root root  125160 Dec  9 17:10 type42.o
-rw-r--r-- 1 root root   59958 Dec  9 17:10 winfnt.o
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 07:07:56 PM
I would guess you're not even trying to link it. i.e. missing -lfreetype.    VERBOSE=1 is to help for exactly this type of thing.
Perusing the headache inducing Extended Makefile, the only place that would come from are the "system for automating the directories"...

Do you have freetype-config (for the cross environment)?   freetype2.pc?  (try 'x86_64_w64-mingw32-pkg-config freetype2' [or whatever your cross prefix is])
If so, the paths, libraries, etc. all come from them.
If not, you need to define FREETYPE_CONFIG= as blank in config.default. And same for SDL2_CONFIG, etc., etc.. as per config.template "# Define these as empty strings, if you don't have the respective config program"

zlib is required for freetype, but it includes it's own copy if a 'system' one can't be found. Hence why you still compile.
bzip2 would be needed for certain fonts too, but only the 'system' one.
Since both zlib and bzip2 are needed by Simutrans, I would've expected them to be installed already, but if you've stuck them in some /root/blah path rather than in the 'system', then....

Also note from the warnings when you built freetype, your cross environment is missing libz and libm so the resultant freetype is static linkage only. obj/.lib is missing the libfreetype.dll.a and libfreetype-6.dll files.

---
Can you post output from 'x86_64-w64-mingw32-gcc -v' and 'x86_64-w64-mingw32-ld --verbose'  (just searchdirs section near top of ld output...) Could help to see where your cross system dirs are.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 07:43:25 PM
Thank you for that: that is most helpful.

The config.mingw64 file was not updated when config.template was updated, so there was no blank FREETYPE_CONFIG option. I have now added this. However, adding this, either with FREETYPE_CONFIG = freetype-config or FREETYPE_CONFIG = (blank) makes no difference.

With VERBOSE = 1, I get the following output:


x86_64-w64-mingw32-g++  build/mingw64/sys/simsys_w32_png.o  build/mingw64/sys/clipboard_w32.o  build/mingw64/bauer/brueckenbauer.o  build/mingw64/bauer/fabrikbauer.o  build/mingw64/bauer/hausbauer.o  build/mingw64/bauer/tunnelbauer.o  build/mingw64/bauer/vehikelbauer.o  build/mingw64/bauer/goods_manager.o  build/mingw64/bauer/wegbauer.o  build/mingw64/descriptor/image.o  build/mingw64/descriptor/bridge_desc.o  build/mingw64/descriptor/factory_desc.o  build/mingw64/descriptor/ground_desc.o  build/mingw64/descriptor/building_desc.o  build/mingw64/descriptor/obj_base_desc.o  build/mingw64/descriptor/reader/bridge_reader.o  build/mingw64/descriptor/reader/building_reader.o  build/mingw64/descriptor/reader/citycar_reader.o  build/mingw64/descriptor/reader/crossing_reader.o  build/mingw64/descriptor/reader/factory_reader.o  build/mingw64/descriptor/reader/good_reader.o  build/mingw64/descriptor/reader/ground_reader.o  build/mingw64/descriptor/reader/groundobj_reader.o  build/mingw64/descriptor/reader/image_reader.o  build/mingw64/descriptor/reader/imagelist2d_reader.o  build/mingw64/descriptor/reader/imagelist3d_reader.o  build/mingw64/descriptor/reader/imagelist_reader.o  build/mingw64/descriptor/reader/obj_reader.o  build/mingw64/descriptor/reader/pedestrian_reader.o  build/mingw64/descriptor/reader/roadsign_reader.o  build/mingw64/descriptor/reader/root_reader.o  build/mingw64/descriptor/reader/sim_reader.o  build/mingw64/descriptor/reader/skin_reader.o  build/mingw64/descriptor/reader/sound_reader.o  build/mingw64/descriptor/reader/text_reader.o  build/mingw64/descriptor/reader/tree_reader.o  build/mingw64/descriptor/reader/tunnel_reader.o  build/mingw64/descriptor/reader/vehicle_reader.o  build/mingw64/descriptor/reader/way_obj_reader.o  build/mingw64/descriptor/reader/way_reader.o  build/mingw64/descriptor/reader/xref_reader.o  build/mingw64/descriptor/sound_desc.o  build/mingw64/descriptor/tunnel_desc.o  build/mingw64/descriptor/vehicle_desc.o  build/mingw64/descriptor/goods_desc.o  build/mingw64/descriptor/way_desc.o  build/mingw64/boden/boden.o  build/mingw64/boden/brueckenboden.o  build/mingw64/boden/fundament.o  build/mingw64/boden/grund.o  build/mingw64/boden/monorailboden.o  build/mingw64/boden/tunnelboden.o  build/mingw64/boden/wasser.o  build/mingw64/boden/wege/kanal.o  build/mingw64/boden/wege/maglev.o  build/mingw64/boden/wege/monorail.o  build/mingw64/boden/wege/narrowgauge.o  build/mingw64/boden/wege/runway.o  build/mingw64/boden/wege/schiene.o  build/mingw64/boden/wege/strasse.o  build/mingw64/boden/wege/weg.o  build/mingw64/dataobj/crossing_logic.o  build/mingw64/dataobj/objlist.o  build/mingw64/dataobj/settings.o  build/mingw64/dataobj/schedule.o  build/mingw64/dataobj/freelist.o  build/mingw64/dataobj/gameinfo.o  build/mingw64/dataobj/height_map_loader.o  build/mingw64/dataobj/koord.o  build/mingw64/dataobj/koord3d.o  build/mingw64/dataobj/loadsave.o  build/mingw64/dataobj/marker.o  build/mingw64/dataobj/powernet.o  build/mingw64/dataobj/rect.o  build/mingw64/dataobj/ribi.o  build/mingw64/dataobj/route.o  build/mingw64/dataobj/scenario.o  build/mingw64/dataobj/tabfile.o  build/mingw64/dataobj/translator.o  build/mingw64/dataobj/environment.o  build/mingw64/obj/baum.o  build/mingw64/obj/bruecke.o  build/mingw64/obj/crossing.o  build/mingw64/obj/field.o  build/mingw64/obj/gebaeude.o  build/mingw64/obj/groundobj.o  build/mingw64/obj/label.o  build/mingw64/obj/leitung2.o  build/mingw64/obj/pillar.o  build/mingw64/obj/roadsign.o  build/mingw64/obj/signal.o  build/mingw64/obj/tunnel.o  build/mingw64/obj/wayobj.o  build/mingw64/obj/wolke.o  build/mingw64/obj/zeiger.o  build/mingw64/display/font.o  build/mingw64/display/simgraph16.o  build/mingw64/display/simview.o  build/mingw64/display/viewport.o  build/mingw64/finder/placefinder.o  build/mingw64/freight_list_sorter.o  build/mingw64/gui/ai_option_t.o  build/mingw64/gui/banner.o  build/mingw64/gui/baum_edit.o  build/mingw64/gui/base_info.o  build/mingw64/gui/citybuilding_edit.o  build/mingw64/gui/citylist_frame_t.o  build/mingw64/gui/citylist_stats_t.o  build/mingw64/gui/climates.o  build/mingw64/gui/display_settings.o  build/mingw64/gui/components/gui_aligned_container.o  build/mingw64/gui/components/gui_building.o  build/mingw64/gui/components/gui_button.o  build/mingw64/gui/components/gui_button_to_chart.o  build/mingw64/gui/components/gui_chart.o  build/mingw64/gui/components/gui_colorbox.o  build/mingw64/gui/components/gui_combobox.o  build/mingw64/gui/components/gui_container.o  build/mingw64/gui/components/gui_convoiinfo.o  build/mingw64/gui/components/gui_divider.o  build/mingw64/gui/components/gui_obj_view_t.o  build/mingw64/gui/components/gui_factory_storage_info.o  build/mingw64/gui/components/gui_halthandled_lines.o  build/mingw64/gui/components/gui_fixedwidth_textarea.o  build/mingw64/gui/components/gui_flowtext.o  build/mingw64/gui/components/gui_image.o  build/mingw64/gui/components/gui_image_list.o  build/mingw64/gui/components/gui_component.o  build/mingw64/gui/components/gui_label.o  build/mingw64/gui/components/gui_map_preview.o  build/mingw64/gui/components/gui_numberinput.o  build/mingw64/gui/components/gui_scrollbar.o  build/mingw64/gui/components/gui_scrolled_list.o  build/mingw64/gui/components/gui_scrollpane.o  build/mingw64/gui/components/gui_speedbar.o  build/mingw64/gui/components/gui_tab_panel.o  build/mingw64/gui/components/gui_textarea.o  build/mingw64/gui/components/gui_textinput.o  build/mingw64/gui/components/gui_world_view_t.o  build/mingw64/gui/convoi_detail_t.o  build/mingw64/gui/convoi_filter_frame.o  build/mingw64/gui/convoi_frame.o  build/mingw64/gui/convoi_info_t.o  build/mingw64/gui/convoy_item.o  build/mingw64/gui/curiosity_edit.o  build/mingw64/gui/curiositylist_frame_t.o  build/mingw64/gui/curiositylist_stats_t.o  build/mingw64/gui/depot_frame.o  build/mingw64/gui/depotlist_frame.o  build/mingw64/gui/enlarge_map_frame_t.o  build/mingw64/gui/extend_edit.o  build/mingw64/gui/fabrik_info.o  build/mingw64/gui/factory_chart.o  build/mingw64/gui/factory_edit.o  build/mingw64/gui/factorylist_frame_t.o  build/mingw64/gui/factorylist_stats_t.o  build/mingw64/gui/schedule_gui.o  build/mingw64/gui/goods_frame_t.o  build/mingw64/gui/goods_stats_t.o  build/mingw64/gui/ground_info.o  build/mingw64/gui/gui_frame.o  build/mingw64/gui/gui_theme.o  build/mingw64/gui/halt_detail.o  build/mingw64/gui/halt_info.o  build/mingw64/gui/halt_list_filter_frame.o  build/mingw64/gui/halt_list_frame.o  build/mingw64/gui/halt_list_stats.o  build/mingw64/gui/headquarter_info.o  build/mingw64/gui/help_frame.o  build/mingw64/gui/jump_frame.o  build/mingw64/gui/minimap.o  build/mingw64/gui/kennfarbe.o  build/mingw64/gui/label_info.o  build/mingw64/gui/labellist_frame_t.o  build/mingw64/gui/labellist_stats_t.o  build/mingw64/gui/line_class_manager.o  build/mingw64/gui/line_item.o  build/mingw64/gui/line_management_gui.o  build/mingw64/gui/load_relief_frame.o  build/mingw64/gui/loadfont_frame.o  build/mingw64/gui/loadsave_frame.o  build/mingw64/gui/map_frame.o  build/mingw64/gui/message_frame_t.o  build/mingw64/gui/message_option_t.o  build/mingw64/gui/message_stats_t.o  build/mingw64/gui/messagebox.o  build/mingw64/gui/money_frame.o  build/mingw64/gui/onewaysign_info.o  build/mingw64/gui/optionen.o  build/mingw64/gui/overtaking_mode.o  build/mingw64/gui/pakselector.o  build/mingw64/gui/password_frame.o  build/mingw64/gui/player_frame_t.o  build/mingw64/gui/privatesign_info.o  build/mingw64/gui/savegame_frame.o  build/mingw64/gui/scenario_frame.o  build/mingw64/gui/scenario_info.o  build/mingw64/gui/schedule_list.o  build/mingw64/gui/schiene_info.o  build/mingw64/gui/server_frame.o  build/mingw64/gui/settings_frame.o  build/mingw64/gui/settings_stats.o  build/mingw64/gui/signal_info.o  build/mingw64/gui/signal_spacing.o  build/mingw64/gui/signalboxlist_frame.o  build/mingw64/gui/simwin.o  build/mingw64/gui/sound_frame.o  build/mingw64/gui/sprachen.o  build/mingw64/gui/times_history.o  build/mingw64/gui/times_history_container.o  build/mingw64/gui/times_history_entry.o  build/mingw64/gui/city_info.o  build/mingw64/gui/station_building_select.o  build/mingw64/gui/themeselector.o  build/mingw64/gui/tool_selector.o  build/mingw64/gui/trafficlight_info.o  build/mingw64/gui/vehiclelist_frame.o  build/mingw64/gui/obj_info.o  build/mingw64/gui/vehicle_class_manager.o  build/mingw64/gui/welt.o  build/mingw64/network/checksum.o  build/mingw64/network/memory_rw.o  build/mingw64/network/network.o  build/mingw64/network/network_address.o  build/mingw64/network/network_cmd.o  build/mingw64/network/network_cmd_ingame.o  build/mingw64/network/network_cmd_scenario.o  build/mingw64/network/network_cmp_pakset.o  build/mingw64/network/network_file_transfer.o  build/mingw64/network/network_packet.o  build/mingw64/network/network_socket_list.o  build/mingw64/network/pakset_info.o  build/mingw64/network/pwd_hash.o  build/mingw64/old_blockmanager.o  build/mingw64/player/ai.o  build/mingw64/player/ai_goods.o  build/mingw64/player/ai_passenger.o  build/mingw64/player/finance.o  build/mingw64/player/simplay.o  build/mingw64/script/api_class.o  build/mingw64/script/api_function.o  build/mingw64/script/api_param.o  build/mingw64/script/api/api_city.o  build/mingw64/script/api/api_const.o  build/mingw64/script/api/api_control.o  build/mingw64/script/api/api_convoy.o  build/mingw64/script/api/api_gui.o  build/mingw64/script/api/api_factory.o  build/mingw64/script/api/api_halt.o  build/mingw64/script/api/api_include.o  build/mingw64/script/api/api_line.o  build/mingw64/script/api/api_map_objects.o  build/mingw64/script/api/api_obj_desc.o  build/mingw64/script/api/api_obj_desc_base.o  build/mingw64/script/api/api_player.o  build/mingw64/script/api/api_scenario.o  build/mingw64/script/api/api_schedule.o  build/mingw64/script/api/api_settings.o  build/mingw64/script/api/api_simple.o  build/mingw64/script/api/api_tiles.o  build/mingw64/script/api/api_world.o  build/mingw64/script/api/export_desc.o  build/mingw64/script/api/get_next.o  build/mingw64/script/dynamic_string.o  build/mingw64/script/export_objs.o  build/mingw64/script/script.o  build/mingw64/squirrel/sq_extensions.o  build/mingw64/squirrel/squirrel/sqapi.o  build/mingw64/squirrel/squirrel/sqclass.o  build/mingw64/squirrel/squirrel/sqdebug.o  build/mingw64/squirrel/squirrel/sqlexer.o  build/mingw64/squirrel/squirrel/sqobject.o  build/mingw64/squirrel/squirrel/sqtable.o  build/mingw64/squirrel/squirrel/sqbaselib.o  build/mingw64/squirrel/squirrel/sqcompiler.o  build/mingw64/squirrel/squirrel/sqfuncstate.o  build/mingw64/squirrel/squirrel/sqmem.o  build/mingw64/squirrel/squirrel/sqstate.o  build/mingw64/squirrel/squirrel/sqvm.o  build/mingw64/squirrel/sqstdlib/sqstdaux.o  build/mingw64/squirrel/sqstdlib/sqstdio.o  build/mingw64/squirrel/sqstdlib/sqstdrex.o  build/mingw64/squirrel/sqstdlib/sqstdstring.o  build/mingw64/squirrel/sqstdlib/sqstdblob.o  build/mingw64/squirrel/sqstdlib/sqstdmath.o  build/mingw64/squirrel/sqstdlib/sqstdstream.o  build/mingw64/squirrel/sqstdlib/sqstdsystem.o  build/mingw64/simcity.o  build/mingw64/simconvoi.o  build/mingw64/simdebug.o  build/mingw64/simdepot.o  build/mingw64/simobj.o  build/mingw64/simevent.o  build/mingw64/simfab.o  build/mingw64/simhalt.o  build/mingw64/siminteraction.o  build/mingw64/simintr.o  build/mingw64/simio.o  build/mingw64/simline.o  build/mingw64/simlinemgmt.o  build/mingw64/simloadingscreen.o  build/mingw64/simmain.o  build/mingw64/simmem.o  build/mingw64/simmenu.o  build/mingw64/simmesg.o  build/mingw64/simplan.o  build/mingw64/simsignalbox.o  build/mingw64/simskin.o  build/mingw64/simsound.o  build/mingw64/simticker.o  build/mingw64/simtool.o  build/mingw64/simware.o  build/mingw64/simworld.o  build/mingw64/sys/simsys.o  build/mingw64/unicode.o  build/mingw64/utils/cbuffer_t.o  build/mingw64/utils/csv.o  build/mingw64/utils/log.o  build/mingw64/utils/searchfolder.o  build/mingw64/utils/sha1.o  build/mingw64/utils/simrandom.o  build/mingw64/vehicle/simroadtraffic.o  build/mingw64/utils/simstring.o  build/mingw64/utils/simthread.o  build/mingw64/vehicle/movingobj.o  build/mingw64/vehicle/simpeople.o  build/mingw64/vehicle/simvehicle.o  build/mingw64/simunits.o  build/mingw64/convoy.o  build/mingw64/utils/float32e8_t.o  build/mingw64/path_explorer.o  build/mingw64/gui/components/gui_table.o  build/mingw64/gui/components/gui_convoy_assembler.o  build/mingw64/gui/components/gui_convoy_label.o  build/mingw64/gui/components/gui_convoy_formation.o  build/mingw64/gui/components/gui_convoy_payloadinfo.o  build/mingw64/gui/replace_frame.o  build/mingw64/dataobj/livery_scheme.o  build/mingw64/dataobj/replace_data.o  build/mingw64/sys/simsys_s2.o  build/mingw64/sound/sdl2_sound.o  build/mingw64/music/w32_midi.o  build/mingw64/simres.o -L/root/freetype-2.10.4/objs/.libs -L/root/miniupnpc/miniupnpc-2.1.20201016 -L/root/zstd/zstd/lib -L/root/zlib-source/zlib-1.2.11 -L/root/bzip64/bzip2-1.0.6 -L/usr/x86_64-w64-mingw32/lib/ -L/root/SDL2-2.0.7/build-win64/build/.libs -lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -static-libgcc -static-libstdc++ -static -mwindows -lzstd -lpthread -lmingw32 -lgdi32 -lwinmm -lws2_32 -limm32 -lbz2 -lz -lbz2 -lz -lSDL2 -o build/mingw64/Simutrans-Extended.exe
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf18): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf35): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0xf4c): undefined reference to `FT_Set_Pixel_Sizes'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1060): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x107d): undefined reference to `FT_Load_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1094): undefined reference to `FT_Render_Glyph'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1149): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1153): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1184): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1357): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/display/font.o:font.cc:(.text+0x1361): undefined reference to `FT_Done_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x20b): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x21e): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x22c): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x2d3): undefined reference to `FT_Get_Char_Index'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x635): undefined reference to `FT_Init_FreeType'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x6b1): undefined reference to `FT_New_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x708): undefined reference to `FT_Done_Face'
/usr/bin/x86_64-w64-mingw32-ld: build/mingw64/gui/loadfont_frame.o:loadfont_frame.cc:(.text+0x725): undefined reference to `FT_Done_FreeType'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/mingw64/Simutrans-Extended.exe] Error 1


For reference, my config.mingw64 file is as follows:



#
# to compile:
# copy this file to config.default and adjust the settings
#

#BACKEND = allegro
#BACKEND = gdi
#BACKEND = opengl
#BACKEND = sdl
BACKEND = sdl2
#BACKEND = mixer_sdl
#BACKEND = posix

#COLOUR_DEPTH = 0
COLOUR_DEPTH = 16

#OSTYPE = amiga
#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = haiku
#OSTYPE = linux
#OSTYPE = mingw32
OSTYPE = mingw64
#OSTYPE = mac

#DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
OPTIMISE = 1  # Add umpteen optimisation flags
#PROFILE = 1  # Enable profiling
#PROFILE = 2  # Enable profiling with optimisation flags, can be used with `OPTIMISE = 1'

WITH_REVISION = 1 # adds the revision from svn; required for networkgames
# if you do not use SVN, add -DREVISION="1234" to the FLAGS below

#WIN32_CONSOLE = 1 # adds a console for windows debugging

# Set to 0 because I am currently unable to cross-compile a library for this: it seems as though the cross-compile
# settings are intended to produce a Windows .lib file for compiling the final code on Windows, rather than libraries
# for cross-compiling the final Windows code on Linux, and the documentation as to how to do this is lacking.
USE_FREETYPE = 0

# Currently not working for cross-compiling because I am unable to cross-compile a static library for this for some reason.
# This is probably non-essential.
#USE_UPNP = 1

USE_ZSTD = 1

MULTI_THREAD = 1 # Enable multithreading

# Define these as empty strings, if you don't have the respective config program
#ALLEGRO_CONFIG = allegro-config
#PNG_CONFIG     = pkg-config libpng
#SDL_CONFIG     = sdl-config
SDL2_CONFIG     = sdl2-config
FREETYPE_CONFIG =

VERBOSE = 1

# The following useful conditional compilation flags exist
#
# Needed to compile:
# USE_C: no assembler for copying (required for not using GCC on x86)
# SIM_BIG_ENDIAN: MUST be set for PPC/Motorola byte order! (old mac, amiga)
# NO_INTPTR_T: must be set if intptr_t is not available
#
# Changing appearance:
# USE_SOFTPOINTER: emulate mouse pointer (set automatically in Makefile)
#
# Useful for debugging:
# DEBUG_ROUTES: show routing calculation information in minimap
# SHOW_FORE_GRUND: show which objects are drawn as foreground
# DEBUG_FLUSH_BUFFER: show the dirty areas on the screen
# USE_VALGRIND_MEMCHECK: make valgrind-memcheck aware of the memory allocation stuff in dataobj/freelist
# SYSLOG: send debug output to syslog
#
# Following flags alter game engine (and are off for standard builds)
# OTTD_LIKE: Enables half height tiles and crossconnects all industries
# AUTOMATIC_BRIDGES and AUTOMATIC_TUNNELS: will be built also for player
# AUTOJOIN_PUBLIC: stations next to a public stop will be joined to it
# USE_DIFFERENT_WIND: different airplane approach directions over the map
# DESTINATION_CITYCARS: Citycars can have a destination (enabled automatically - cannot be disabled)
#
# In order to use the flags, add a line like this: (-Dxxx)
# FLAGS = -DUSE_C

# Output directories:
#
# use this put objects file in same directory, where the sources are (not recommended):
# ... otherwise defaults to 'build/default')
#
# BUILDDIR = $(shell pwd)
#
# use this to specifiy the target directory for the executable:
# .. otherwise defaults to BUILDDIR
#
# MAKEOBJ_PROGDIR = $(shell pwd)
# NETTOOL_PROGDIR = $(shell pwd)
# PROGDIR  = $(shell pwd)

# Add -g1 to FLAGS= to enable debugging information, but increase the file size.
FLAGS = -D_REENTRANT -DUSE_C -DALT_SDL_DIR -fno-delete-null-pointer-checks -fno-strict-aliasing -std=c++11 -I/root/freetype-2.10.4/include ->

# The below linkes pthread statically, but this is suspected of causing problems.
#-DPTW32_STATIC_LIB

LDFLAGS = -L/root/freetype-2.10.4/objs/.libs -L/root/miniupnpc/miniupnpc-2.1.20201016 -L/root/zstd/zstd/lib -L/root/zlib-source/zlib-1.2.11 >

CC=x86_64-w64-mingw32-gcc
CXX=x86_64-w64-mingw32-g++
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 08:16:17 PM
--- possibly missed edit above:
Can you post output from 'x86_64-w64-mingw32-gcc -v' and 'x86_64-w64-mingw32-ld --verbose'  (just searchdirs section near top of ld output...) Could help to see where your cross system dirs are.

---
verbose output shows indeed -lfreetype is not there. But that would be expected for config.mingw64 with USE_FREETYPE=0, but then the FT_* functions in font.cc shouldn't even be compiled with #ifdef USE_FREETYPE failing...
Are you trying to compile with freetype or not? And I trust you're running 'make CFG=mingw64' to actually use config.mingw64 instead of config.default.
Also, with FREETYPE_CONFIG= make sure no trailing characters....  "=", not "= ".  That got me with OSX and SDL2. grrr.

Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 08:53:01 PM
Thank you for that. I had not remembered that I had set USE_FREETYPE=0 earlier. I have now added a manual -lfreetype flag and modified the config file as follows (removing the trailing space after FREETYPE_CONFIG=):


  GNU nano 4.8                                                   config.mingw64
#
# to compile:
# copy this file to config.default and adjust the settings
#

#BACKEND = allegro
#BACKEND = gdi
#BACKEND = opengl
#BACKEND = sdl
BACKEND = sdl2
#BACKEND = mixer_sdl
#BACKEND = posix

#COLOUR_DEPTH = 0
COLOUR_DEPTH = 16

#OSTYPE = amiga
#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = haiku
#OSTYPE = linux
#OSTYPE = mingw32
OSTYPE = mingw64
#OSTYPE = mac

#DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
OPTIMISE = 1  # Add umpteen optimisation flags
#PROFILE = 1  # Enable profiling
#PROFILE = 2  # Enable profiling with optimisation flags, can be used with `OPTIMISE = 1'

WITH_REVISION = 1 # adds the revision from svn; required for networkgames
# if you do not use SVN, add -DREVISION="1234" to the FLAGS below

#WIN32_CONSOLE = 1 # adds a console for windows debugging

# Set to 0 because I am currently unable to cross-compile a library for this: it seems as though the cross-compile
# settings are intended to produce a Windows .lib file for compiling the final code on Windows, rather than libraries
# for cross-compiling the final Windows code on Linux, and the documentation as to how to do this is lacking.
USE_FREETYPE = 1

# Currently not working for cross-compiling because I am unable to cross-compile a static library for this for some reason.
# This is probably non-essential.
#USE_UPNP = 1

USE_ZSTD = 1

MULTI_THREAD = 1 # Enable multithreading

# Define these as empty strings, if you don't have the respective config program
#ALLEGRO_CONFIG = allegro-config
#PNG_CONFIG      = pkg-config libpng
#SDL_CONFIG     = sdl-config
SDL2_CONFIG     = sdl2-config
FREETYPE_CONFIG =

VERBOSE = 1

# The following useful conditional compilation flags exist
#
# Needed to compile:
# USE_C: no assembler for copying (required for not using GCC on x86)
# SIM_BIG_ENDIAN: MUST be set for PPC/Motorola byte order! (old mac, amiga)
# NO_INTPTR_T: must be set if intptr_t is not available
#
# Changing appearance:
# USE_SOFTPOINTER: emulate mouse pointer (set automatically in Makefile)
#
# Useful for debugging:
# DEBUG_ROUTES: show routing calculation information in minimap
# SHOW_FORE_GRUND: show which objects are drawn as foreground
# DEBUG_FLUSH_BUFFER: show the dirty areas on the screen
# USE_VALGRIND_MEMCHECK: make valgrind-memcheck aware of the memory allocation stuff in dataobj/freelist
# SYSLOG: send debug output to syslog
#
# Following flags alter game engine (and are off for standard builds)
# OTTD_LIKE: Enables half height tiles and crossconnects all industries
# AUTOMATIC_BRIDGES and AUTOMATIC_TUNNELS: will be built also for player
# AUTOJOIN_PUBLIC: stations next to a public stop will be joined to it
# USE_DIFFERENT_WIND: different airplane approach directions over the map
# DESTINATION_CITYCARS: Citycars can have a destination (enabled automatically - cannot be disabled)
#
# In order to use the flags, add a line like this: (-Dxxx)
# FLAGS = -DUSE_C

# Output directories:
#
# use this put objects file in same directory, where the sources are (not recommended):
# ... otherwise defaults to 'build/default')
#
# BUILDDIR = $(shell pwd)
#
# use this to specifiy the target directory for the executable:
# .. otherwise defaults to BUILDDIR
#
# MAKEOBJ_PROGDIR = $(shell pwd)
# NETTOOL_PROGDIR = $(shell pwd)
# PROGDIR  = $(shell pwd)

# Add -g1 to FLAGS= to enable debugging information, but increase the file size.
FLAGS = -D_REENTRANT -DUSE_C -DALT_SDL_DIR -fno-delete-null-pointer-checks -fno-strict-aliasing -std=c++11 -I/root/freetype-2.10.4/include ->

# The below linkes pthread statically, but this is suspected of causing problems.
#-DPTW32_STATIC_LIB

LDFLAGS = -L/root/freetype-2.10.4/objs/.libs -L/root/miniupnpc/miniupnpc-2.1.20201016 -L/root/zstd/zstd/lib -L/root/zlib-source/zlib-1.2.11 >

CC=x86_64-w64-mingw32-gcc
CXX=x86_64-w64-mingw32-g++


I can confirm that I am issuing the correct env CFG=mingw64 make command.

Having added -lfreetype to LDFLAGS, I get a different set of errors:


root@438242:/usr/share/games/nightly/simutrans-experimental# env CFG=mingw64 make
===> LD  build/mingw64/Simutrans-Extended.exe
x86_64-w64-mingw32-g++  build/mingw64/sys/simsys_w32_png.o  build/mingw64/sys/clipboard_w32.o  build/mingw64/bauer/brueckenbauer.o  build/mingw64/bauer/fabrikbauer.o  build/mingw64/bauer/hausbauer.o  build/mingw64/bauer/tunnelbauer.o  build/mingw64/bauer/vehikelbauer.o  build/mingw64/bauer/goods_manager.o  build/mingw64/bauer/wegbauer.o  build/mingw64/descriptor/image.o  build/mingw64/descriptor/bridge_desc.o  build/mingw64/descriptor/factory_desc.o  build/mingw64/descriptor/ground_desc.o  build/mingw64/descriptor/building_desc.o  build/mingw64/descriptor/obj_base_desc.o  build/mingw64/descriptor/reader/bridge_reader.o  build/mingw64/descriptor/reader/building_reader.o  build/mingw64/descriptor/reader/citycar_reader.o  build/mingw64/descriptor/reader/crossing_reader.o  build/mingw64/descriptor/reader/factory_reader.o  build/mingw64/descriptor/reader/good_reader.o  build/mingw64/descriptor/reader/ground_reader.o  build/mingw64/descriptor/reader/groundobj_reader.o  build/mingw64/descriptor/reader/image_reader.o  build/mingw64/descriptor/reader/imagelist2d_reader.o  build/mingw64/descriptor/reader/imagelist3d_reader.o  build/mingw64/descriptor/reader/imagelist_reader.o  build/mingw64/descriptor/reader/obj_reader.o  build/mingw64/descriptor/reader/pedestrian_reader.o  build/mingw64/descriptor/reader/roadsign_reader.o  build/mingw64/descriptor/reader/root_reader.o  build/mingw64/descriptor/reader/sim_reader.o  build/mingw64/descriptor/reader/skin_reader.o  build/mingw64/descriptor/reader/sound_reader.o  build/mingw64/descriptor/reader/text_reader.o  build/mingw64/descriptor/reader/tree_reader.o  build/mingw64/descriptor/reader/tunnel_reader.o  build/mingw64/descriptor/reader/vehicle_reader.o  build/mingw64/descriptor/reader/way_obj_reader.o  build/mingw64/descriptor/reader/way_reader.o  build/mingw64/descriptor/reader/xref_reader.o  build/mingw64/descriptor/sound_desc.o  build/mingw64/descriptor/tunnel_desc.o  build/mingw64/descriptor/vehicle_desc.o  build/mingw64/descriptor/goods_desc.o  build/mingw64/descriptor/way_desc.o  build/mingw64/boden/boden.o  build/mingw64/boden/brueckenboden.o  build/mingw64/boden/fundament.o  build/mingw64/boden/grund.o  build/mingw64/boden/monorailboden.o  build/mingw64/boden/tunnelboden.o  build/mingw64/boden/wasser.o  build/mingw64/boden/wege/kanal.o  build/mingw64/boden/wege/maglev.o  build/mingw64/boden/wege/monorail.o  build/mingw64/boden/wege/narrowgauge.o  build/mingw64/boden/wege/runway.o  build/mingw64/boden/wege/schiene.o  build/mingw64/boden/wege/strasse.o  build/mingw64/boden/wege/weg.o  build/mingw64/dataobj/crossing_logic.o  build/mingw64/dataobj/objlist.o  build/mingw64/dataobj/settings.o  build/mingw64/dataobj/schedule.o  build/mingw64/dataobj/freelist.o  build/mingw64/dataobj/gameinfo.o  build/mingw64/dataobj/height_map_loader.o  build/mingw64/dataobj/koord.o  build/mingw64/dataobj/koord3d.o  build/mingw64/dataobj/loadsave.o  build/mingw64/dataobj/marker.o  build/mingw64/dataobj/powernet.o  build/mingw64/dataobj/rect.o  build/mingw64/dataobj/ribi.o  build/mingw64/dataobj/route.o  build/mingw64/dataobj/scenario.o  build/mingw64/dataobj/tabfile.o  build/mingw64/dataobj/translator.o  build/mingw64/dataobj/environment.o  build/mingw64/obj/baum.o  build/mingw64/obj/bruecke.o  build/mingw64/obj/crossing.o  build/mingw64/obj/field.o  build/mingw64/obj/gebaeude.o  build/mingw64/obj/groundobj.o  build/mingw64/obj/label.o  build/mingw64/obj/leitung2.o  build/mingw64/obj/pillar.o  build/mingw64/obj/roadsign.o  build/mingw64/obj/signal.o  build/mingw64/obj/tunnel.o  build/mingw64/obj/wayobj.o  build/mingw64/obj/wolke.o  build/mingw64/obj/zeiger.o  build/mingw64/display/font.o  build/mingw64/display/simgraph16.o  build/mingw64/display/simview.o  build/mingw64/display/viewport.o  build/mingw64/finder/placefinder.o  build/mingw64/freight_list_sorter.o  build/mingw64/gui/ai_option_t.o  build/mingw64/gui/banner.o  build/mingw64/gui/baum_edit.o  build/mingw64/gui/base_info.o  build/mingw64/gui/citybuilding_edit.o  build/mingw64/gui/citylist_frame_t.o  build/mingw64/gui/citylist_stats_t.o  build/mingw64/gui/climates.o  build/mingw64/gui/display_settings.o  build/mingw64/gui/components/gui_aligned_container.o  build/mingw64/gui/components/gui_building.o  build/mingw64/gui/components/gui_button.o  build/mingw64/gui/components/gui_button_to_chart.o  build/mingw64/gui/components/gui_chart.o  build/mingw64/gui/components/gui_colorbox.o  build/mingw64/gui/components/gui_combobox.o  build/mingw64/gui/components/gui_container.o  build/mingw64/gui/components/gui_convoiinfo.o  build/mingw64/gui/components/gui_divider.o  build/mingw64/gui/components/gui_obj_view_t.o  build/mingw64/gui/components/gui_factory_storage_info.o  build/mingw64/gui/components/gui_halthandled_lines.o  build/mingw64/gui/components/gui_fixedwidth_textarea.o  build/mingw64/gui/components/gui_flowtext.o  build/mingw64/gui/components/gui_image.o  build/mingw64/gui/components/gui_image_list.o  build/mingw64/gui/components/gui_component.o  build/mingw64/gui/components/gui_label.o  build/mingw64/gui/components/gui_map_preview.o  build/mingw64/gui/components/gui_numberinput.o  build/mingw64/gui/components/gui_scrollbar.o  build/mingw64/gui/components/gui_scrolled_list.o  build/mingw64/gui/components/gui_scrollpane.o  build/mingw64/gui/components/gui_speedbar.o  build/mingw64/gui/components/gui_tab_panel.o  build/mingw64/gui/components/gui_textarea.o  build/mingw64/gui/components/gui_textinput.o  build/mingw64/gui/components/gui_world_view_t.o  build/mingw64/gui/convoi_detail_t.o  build/mingw64/gui/convoi_filter_frame.o  build/mingw64/gui/convoi_frame.o  build/mingw64/gui/convoi_info_t.o  build/mingw64/gui/convoy_item.o  build/mingw64/gui/curiosity_edit.o  build/mingw64/gui/curiositylist_frame_t.o  build/mingw64/gui/curiositylist_stats_t.o  build/mingw64/gui/depot_frame.o  build/mingw64/gui/depotlist_frame.o  build/mingw64/gui/enlarge_map_frame_t.o  build/mingw64/gui/extend_edit.o  build/mingw64/gui/fabrik_info.o  build/mingw64/gui/factory_chart.o  build/mingw64/gui/factory_edit.o  build/mingw64/gui/factorylist_frame_t.o  build/mingw64/gui/factorylist_stats_t.o  build/mingw64/gui/schedule_gui.o  build/mingw64/gui/goods_frame_t.o  build/mingw64/gui/goods_stats_t.o  build/mingw64/gui/ground_info.o  build/mingw64/gui/gui_frame.o  build/mingw64/gui/gui_theme.o  build/mingw64/gui/halt_detail.o  build/mingw64/gui/halt_info.o  build/mingw64/gui/halt_list_filter_frame.o  build/mingw64/gui/halt_list_frame.o  build/mingw64/gui/halt_list_stats.o  build/mingw64/gui/headquarter_info.o  build/mingw64/gui/help_frame.o  build/mingw64/gui/jump_frame.o  build/mingw64/gui/minimap.o  build/mingw64/gui/kennfarbe.o  build/mingw64/gui/label_info.o  build/mingw64/gui/labellist_frame_t.o  build/mingw64/gui/labellist_stats_t.o  build/mingw64/gui/line_class_manager.o  build/mingw64/gui/line_item.o  build/mingw64/gui/line_management_gui.o  build/mingw64/gui/load_relief_frame.o  build/mingw64/gui/loadfont_frame.o  build/mingw64/gui/loadsave_frame.o  build/mingw64/gui/map_frame.o  build/mingw64/gui/message_frame_t.o  build/mingw64/gui/message_option_t.o  build/mingw64/gui/message_stats_t.o  build/mingw64/gui/messagebox.o  build/mingw64/gui/money_frame.o  build/mingw64/gui/onewaysign_info.o  build/mingw64/gui/optionen.o  build/mingw64/gui/overtaking_mode.o  build/mingw64/gui/pakselector.o  build/mingw64/gui/password_frame.o  build/mingw64/gui/player_frame_t.o  build/mingw64/gui/privatesign_info.o  build/mingw64/gui/savegame_frame.o  build/mingw64/gui/scenario_frame.o  build/mingw64/gui/scenario_info.o  build/mingw64/gui/schedule_list.o  build/mingw64/gui/schiene_info.o  build/mingw64/gui/server_frame.o  build/mingw64/gui/settings_frame.o  build/mingw64/gui/settings_stats.o  build/mingw64/gui/signal_info.o  build/mingw64/gui/signal_spacing.o  build/mingw64/gui/signalboxlist_frame.o  build/mingw64/gui/simwin.o  build/mingw64/gui/sound_frame.o  build/mingw64/gui/sprachen.o  build/mingw64/gui/times_history.o  build/mingw64/gui/times_history_container.o  build/mingw64/gui/times_history_entry.o  build/mingw64/gui/city_info.o  build/mingw64/gui/station_building_select.o  build/mingw64/gui/themeselector.o  build/mingw64/gui/tool_selector.o  build/mingw64/gui/trafficlight_info.o  build/mingw64/gui/vehiclelist_frame.o  build/mingw64/gui/obj_info.o  build/mingw64/gui/vehicle_class_manager.o  build/mingw64/gui/welt.o  build/mingw64/network/checksum.o  build/mingw64/network/memory_rw.o  build/mingw64/network/network.o  build/mingw64/network/network_address.o  build/mingw64/network/network_cmd.o  build/mingw64/network/network_cmd_ingame.o  build/mingw64/network/network_cmd_scenario.o  build/mingw64/network/network_cmp_pakset.o  build/mingw64/network/network_file_transfer.o  build/mingw64/network/network_packet.o  build/mingw64/network/network_socket_list.o  build/mingw64/network/pakset_info.o  build/mingw64/network/pwd_hash.o  build/mingw64/old_blockmanager.o  build/mingw64/player/ai.o  build/mingw64/player/ai_goods.o  build/mingw64/player/ai_passenger.o  build/mingw64/player/finance.o  build/mingw64/player/simplay.o  build/mingw64/script/api_class.o  build/mingw64/script/api_function.o  build/mingw64/script/api_param.o  build/mingw64/script/api/api_city.o  build/mingw64/script/api/api_const.o  build/mingw64/script/api/api_control.o  build/mingw64/script/api/api_convoy.o  build/mingw64/script/api/api_gui.o  build/mingw64/script/api/api_factory.o  build/mingw64/script/api/api_halt.o  build/mingw64/script/api/api_include.o  build/mingw64/script/api/api_line.o  build/mingw64/script/api/api_map_objects.o  build/mingw64/script/api/api_obj_desc.o  build/mingw64/script/api/api_obj_desc_base.o  build/mingw64/script/api/api_player.o  build/mingw64/script/api/api_scenario.o  build/mingw64/script/api/api_schedule.o  build/mingw64/script/api/api_settings.o  build/mingw64/script/api/api_simple.o  build/mingw64/script/api/api_tiles.o  build/mingw64/script/api/api_world.o  build/mingw64/script/api/export_desc.o  build/mingw64/script/api/get_next.o  build/mingw64/script/dynamic_string.o  build/mingw64/script/export_objs.o  build/mingw64/script/script.o  build/mingw64/squirrel/sq_extensions.o  build/mingw64/squirrel/squirrel/sqapi.o  build/mingw64/squirrel/squirrel/sqclass.o  build/mingw64/squirrel/squirrel/sqdebug.o  build/mingw64/squirrel/squirrel/sqlexer.o  build/mingw64/squirrel/squirrel/sqobject.o  build/mingw64/squirrel/squirrel/sqtable.o  build/mingw64/squirrel/squirrel/sqbaselib.o  build/mingw64/squirrel/squirrel/sqcompiler.o  build/mingw64/squirrel/squirrel/sqfuncstate.o  build/mingw64/squirrel/squirrel/sqmem.o  build/mingw64/squirrel/squirrel/sqstate.o  build/mingw64/squirrel/squirrel/sqvm.o  build/mingw64/squirrel/sqstdlib/sqstdaux.o  build/mingw64/squirrel/sqstdlib/sqstdio.o  build/mingw64/squirrel/sqstdlib/sqstdrex.o  build/mingw64/squirrel/sqstdlib/sqstdstring.o  build/mingw64/squirrel/sqstdlib/sqstdblob.o  build/mingw64/squirrel/sqstdlib/sqstdmath.o  build/mingw64/squirrel/sqstdlib/sqstdstream.o  build/mingw64/squirrel/sqstdlib/sqstdsystem.o  build/mingw64/simcity.o  build/mingw64/simconvoi.o  build/mingw64/simdebug.o  build/mingw64/simdepot.o  build/mingw64/simobj.o  build/mingw64/simevent.o  build/mingw64/simfab.o  build/mingw64/simhalt.o  build/mingw64/siminteraction.o  build/mingw64/simintr.o  build/mingw64/simio.o  build/mingw64/simline.o  build/mingw64/simlinemgmt.o  build/mingw64/simloadingscreen.o  build/mingw64/simmain.o  build/mingw64/simmem.o  build/mingw64/simmenu.o  build/mingw64/simmesg.o  build/mingw64/simplan.o  build/mingw64/simsignalbox.o  build/mingw64/simskin.o  build/mingw64/simsound.o  build/mingw64/simticker.o  build/mingw64/simtool.o  build/mingw64/simware.o  build/mingw64/simworld.o  build/mingw64/sys/simsys.o  build/mingw64/unicode.o  build/mingw64/utils/cbuffer_t.o  build/mingw64/utils/csv.o  build/mingw64/utils/log.o  build/mingw64/utils/searchfolder.o  build/mingw64/utils/sha1.o  build/mingw64/utils/simrandom.o  build/mingw64/vehicle/simroadtraffic.o  build/mingw64/utils/simstring.o  build/mingw64/utils/simthread.o  build/mingw64/vehicle/movingobj.o  build/mingw64/vehicle/simpeople.o  build/mingw64/vehicle/simvehicle.o  build/mingw64/simunits.o  build/mingw64/convoy.o  build/mingw64/utils/float32e8_t.o  build/mingw64/path_explorer.o  build/mingw64/gui/components/gui_table.o  build/mingw64/gui/components/gui_convoy_assembler.o  build/mingw64/gui/components/gui_convoy_label.o  build/mingw64/gui/components/gui_convoy_formation.o  build/mingw64/gui/components/gui_convoy_payloadinfo.o  build/mingw64/gui/replace_frame.o  build/mingw64/dataobj/livery_scheme.o  build/mingw64/dataobj/replace_data.o  build/mingw64/sys/simsys_s2.o  build/mingw64/sound/sdl2_sound.o  build/mingw64/music/w32_midi.o  build/mingw64/simres.o -L/root/freetype-2.10.4/objs/.libs -L/root/miniupnpc/miniupnpc-2.1.20201016 -L/root/zstd/zstd/lib -L/root/zlib-source/zlib-1.2.11 -L/root/bzip64/bzip2-1.0.6 -L/usr/x86_64-w64-mingw32/lib/ -L/root/SDL2-2.0.7/build-win64/build/.libs -lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -lfreetype -static-libgcc -static-libstdc++ -static -mwindows -lfreetype -lzstd -lpthread -lmingw32 -lgdi32 -lwinmm -lws2_32 -limm32 -lbz2 -lz -lbz2 -lz -lSDL2 -o build/mingw64/Simutrans-Extended.exe
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `Load_SBit_Png':
/root/freetype-2.10.4/src/sfnt/pngshim.c:295: undefined reference to `png_create_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:305: undefined reference to `png_create_info_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:313: undefined reference to `png_set_longjmp_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:446: undefined reference to `png_destroy_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:319: undefined reference to `png_set_read_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:321: undefined reference to `png_read_info'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:322: undefined reference to `png_get_IHDR'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:360: undefined reference to `png_set_expand_gray_1_2_4_to_8'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:367: undefined reference to `png_get_valid'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:382: undefined reference to `png_set_interlace_handling'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:384: undefined reference to `png_set_filler'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:387: undefined reference to `png_read_update_info'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:388: undefined reference to `png_get_IHDR'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:410: undefined reference to `png_set_read_user_transform_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:439: undefined reference to `png_read_image'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:443: undefined reference to `png_read_end'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:379: undefined reference to `png_set_gray_to_rgb'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:374: undefined reference to `png_set_packing'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:368: undefined reference to `png_set_tRNS_to_alpha'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:371: undefined reference to `png_set_strip_16'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:354: undefined reference to `png_set_palette_to_rgb'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:415: undefined reference to `png_set_read_user_transform_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:309: undefined reference to `png_destroy_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `error_callback':
/root/freetype-2.10.4/src/sfnt/pngshim.c:199: undefined reference to `png_get_error_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:206: undefined reference to `png_set_longjmp_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `read_data_from_FT_Stream':
/root/freetype-2.10.4/src/sfnt/pngshim.c:230: undefined reference to `png_get_io_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:236: undefined reference to `png_get_error_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:240: undefined reference to `png_error'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/mingw64/Simutrans-Extended.exe] Error 1


This suggests that freetype is having difficulties with a png library, which is odd, since it appears to compile the libraries.

The output of the command to which you referred is:

root@438242:/usr/share/games/nightly/simutrans-experimental# x86_64-w64-mingw32-gcc -v' and 'x86_64-w64-mingw32-ld --verbose
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/lto-wrapper
x86_64-w64-mingw32-gcc: error: unrecognized command line option '-v and x86_64-w64-mingw32-ld'
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: win32
gcc version 9.3-win32 20200320 (GCC)


To clarify, I am indeed trying to compile with Freetype. I have been able to compile successfully without freetype, but I believe that this loses significant functionality for users of Japanese character sets, so this may be of some importance given the popularity of Simutrans in Japan.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 09, 2020, 09:38:00 PM
Well, if you want to statically link a library, you need to statically link all its dependents too... and dependents of dependents, and.....  and then all in the correct order too. fun. Hence why config scripts or pkg-config exists.
You're missing libpng.

As an example, on MSYS2 MinGW64, dynamic:

$ pkg-config freetype2 --libs
-LC:/msys64/mingw64/lib -lfreetype

Static:

$ pkg-config freetype2 --libs --static
-LC:/msys64/mingw64/lib -lfreetype -LC:/msys64/mingw64/lib -lz -lbz2 -lpng16 -lz -lharfbuzz -lm -lusp10 -lgdi32 -lrpcrt4 -ldwrite -LC:/msys64/mingw64/lib -lgraphite2 -lglib-2.0 -lintl -lws2_32 -lole32 -lwinmm -lshlwapi -pthread -lm -LC:/msys64/mingw64/lib -lpcre -lbrotlidec -LC:/msys64/mingw64/lib -lbrotlicommon


You can look in the freetype-2.10.4\builds\unix\freetype2.pc file after building to see what is required. But you have to follow the dependents manually in their pc files. I would expect to find them in /usr/x86_64-w64-mingw32/lib/pkgconfig/*.pc  if available.


Quote from: jamespetts on December 09, 2020, 08:53:01 PMThis suggests that freetype is having difficulties with a png library, which is odd, since it appears to compile the libraries.
Sort of.

checking for LIBPNG... no
checking for libpng-config... yes

Library configuration:
  libpng:        yes (libpng-config)

Where is freetype2 ./configure finding libpng-config? I have a feeling it's finding the x86_64-linux-gnu version, and not one for x86_64-w64-mingw32. But the headers are likely the same, so you can still build it.
I  presume you don't have a cross version of png installed 'normally' i.e. in /usr/x86_64-w64-mingw32/lib and /usr/x86_64-w64-mingw32/include. else it would say checking for LIBPNG... yes.

Quote from: jamespetts on December 09, 2020, 08:53:01 PMThe output of the command to which you referred is:
That was actually two commands, compiler, and linker...  but it does show your cross environment prefix is /usr/x86_64-w64-mingw32.
Use that as --prefix when running configures and make installs and you should end up with cross libraries in the 'correct' locations.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 10:14:46 PM
I have done some testing of zstd in the new build - I will test and reply to TurfIt's suggestions shortly, but I thought that it would be helpful to record the testing first.

On my system, with the Bridgewater-Brunel saved game from the in-game year 1940, the save took ~36 seconds with zlib and ~23 seconds with zstd with the new build, and ~41 seconds with zlib and the old build (which I suspect has different compression level defaults; I did not change the compression levels).

This suggests that the cross compiled zstd does work effectively to reduce save times - I should be interested to see what effect that this has on the saved games on the server, where saving takes much longer than it does on my system.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 09, 2020, 10:50:55 PM
Further work on attempting to build with Freetype follows.

I executed the following commands:


root@438242:~/freetype-2.10.4# pkg-config freetype2 --libs --static
-L/usr/local/lib -lfreetype -lz -lpng15 -lm -lz -lm
root@438242:~/freetype-2.10.4# ./configure --host=x86_64-w64-mingw32 --without-harfbuzz


and generated the following output:

FreeType build system -- automatic system detection

The following settings are used:

  platform                    unix
  compiler                    cc
  configuration directory     ./builds/unix
  configuration rules         ./builds/unix/unix.mk

If this does not correspond to your system or settings please remove the file
`config.mk' from this directory then read the INSTALL file for help.

Otherwise, simply type `make' again to build the library,
or `make refdoc' to build the API reference (this needs Python >= 3.5).

cd builds/unix; \
        ./configure  '--host=x86_64-w64-mingw32' '--without-harfbuzz'
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for x86_64-w64-mingw32-pkg-config... /usr/bin/x86_64-w64-mingw32-pkg-config
checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building
no
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /usr/bin/x86_64-w64-mingw32-ld
checking if the linker (/usr/bin/x86_64-w64-mingw32-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/usr/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/x86_64-w64-mingw32-ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for archiver @FILE support... @
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking for gawk... no
checking for mawk... mawk
checking command to parse /usr/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for x86_64-w64-mingw32-mt... no
checking for mt... mt
configure: WARNING: using cross tools not prefixed with host triplet
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/usr/bin/x86_64-w64-mingw32-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking windows.h usability... yes
checking windows.h presence... yes
checking for windows.h... yes
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking for x86_64-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for suffix of native executables...
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking size of int... 4
checking size of long... 4
checking for unsigned long long int... yes
checking for long long int... yes
checking whether cpp computation of bit length in ftconfig.h.in works... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for memcpy... yes
checking for memmove... yes
checking for -fvisibility=hidden compiler flag... yes
checking for ZLIB... no
checking for gzsetparams in -lz... no
checking for BZIP2... no
checking for BZ2_bzDecompress in -lbz2... no
checking for LIBPNG... no
checking for libpng-config... yes
checking for BROTLI... no
checking for library containing clock_gettime... no
checking for python3... python3
checking for python version... 3.8.5
checking for `docwriter' Python module... no
configure: creating ./config.status
config.status: creating ftoption.h
config.status: creating unix-cc.mk
config.status: creating unix-def.mk
config.status: creating ftconfig.h
config.status: ftconfig.h is unchanged
config.status: executing libtool commands
configure:

Library configuration:
  external zlib: no
  bzip2:         no
  libpng:        yes (libpng-config)
  harfbuzz:      no
  brotli:        no

configure: WARNING:
  `make refdoc' will fail since pip package `docwriter' is not installed.
  To install, run `python3 -m pip install docwriter', or to use a Python
  virtual environment, run `make refdoc-venv' (requires pip package
  `virtualenv'). These operations require Python >= 3.5.


"make" then generated the following output (truncated to the last section otherwise this would be excessively long):


./builds/unix/libtool --mode=link x86_64-w64-mingw32-gcc -o /root/freetype-2.10.4/objs/libfreetype.la  /root/freetype-2.10.4/objs/ftsystem.lo /root/freetype-2.10.4/objs/ftdebug.lo /root/freetype-2.10.4/objs/ftinit.lo /root/freetype-2.10.4/objs/ftver.lo /root/freetype-2.10.4/objs/ftbase.lo /root/freetype-2.10.4/objs/ftbbox.lo /root/freetype-2.10.4/objs/ftbdf.lo /root/freetype-2.10.4/objs/ftbitmap.lo /root/freetype-2.10.4/objs/ftcid.lo /root/freetype-2.10.4/objs/ftfstype.lo /root/freetype-2.10.4/objs/ftgasp.lo /root/freetype-2.10.4/objs/ftglyph.lo /root/freetype-2.10.4/objs/ftgxval.lo /root/freetype-2.10.4/objs/ftmm.lo /root/freetype-2.10.4/objs/ftotval.lo /root/freetype-2.10.4/objs/ftpatent.lo /root/freetype-2.10.4/objs/ftpfr.lo /root/freetype-2.10.4/objs/ftstroke.lo /root/freetype-2.10.4/objs/ftsynth.lo /root/freetype-2.10.4/objs/fttype1.lo /root/freetype-2.10.4/objs/ftwinfnt.lo /root/freetype-2.10.4/objs/truetype.lo /root/freetype-2.10.4/objs/type1.lo /root/freetype-2.10.4/objs/cff.lo /root/freetype-2.10.4/objs/type1cid.lo /root/freetype-2.10.4/objs/pfr.lo /root/freetype-2.10.4/objs/type42.lo /root/freetype-2.10.4/objs/winfnt.lo /root/freetype-2.10.4/objs/pcf.lo /root/freetype-2.10.4/objs/bdf.lo /root/freetype-2.10.4/objs/sfnt.lo /root/freetype-2.10.4/objs/autofit.lo /root/freetype-2.10.4/objs/pshinter.lo /root/freetype-2.10.4/objs/raster.lo /root/freetype-2.10.4/objs/smooth.lo /root/freetype-2.10.4/objs/ftcache.lo /root/freetype-2.10.4/objs/ftgzip.lo /root/freetype-2.10.4/objs/ftlzw.lo /root/freetype-2.10.4/objs/ftbzip2.lo /root/freetype-2.10.4/objs/psaux.lo /root/freetype-2.10.4/objs/psnames.lo -rpath /usr/local/lib -version-info 23:4:17 -L/usr/local/lib -lpng15 -no-undefined -export-symbols /root/freetype-2.10.4/objs/ftexport.sym
libtool: link: rm -fr  /root/freetype-2.10.4/objs/.libs/libfreetype.a /root/freetype-2.10.4/objs/.libs/libfreetype.la /root/freetype-2.10.4/objs/.libs/libfreetype.lai

*** Warning: linker path does not have real file for library -lz.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libz but no candidates were found. (...for file magic test)

*** Warning: linker path does not have real file for library -lm.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libm and none of the candidates passed a file format test
*** using a file magic. Last file checked: /usr/x86_64-w64-mingw32/lib/libm.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
libtool: link: x86_64-w64-mingw32-ar cru /root/freetype-2.10.4/objs/.libs/libfreetype.a  /root/freetype-2.10.4/objs/ftsystem.o /root/freetype-2.10.4/objs/ftdebug.o /root/freetype-2.10.4/objs/ftinit.o /root/freetype-2.10.4/objs/ftver.o /root/freetype-2.10.4/objs/ftbase.o /root/freetype-2.10.4/objs/ftbbox.o /root/freetype-2.10.4/objs/ftbdf.o /root/freetype-2.10.4/objs/ftbitmap.o /root/freetype-2.10.4/objs/ftcid.o /root/freetype-2.10.4/objs/ftfstype.o /root/freetype-2.10.4/objs/ftgasp.o /root/freetype-2.10.4/objs/ftglyph.o /root/freetype-2.10.4/objs/ftgxval.o /root/freetype-2.10.4/objs/ftmm.o /root/freetype-2.10.4/objs/ftotval.o /root/freetype-2.10.4/objs/ftpatent.o /root/freetype-2.10.4/objs/ftpfr.o /root/freetype-2.10.4/objs/ftstroke.o /root/freetype-2.10.4/objs/ftsynth.o /root/freetype-2.10.4/objs/fttype1.o /root/freetype-2.10.4/objs/ftwinfnt.o /root/freetype-2.10.4/objs/truetype.o /root/freetype-2.10.4/objs/type1.o /root/freetype-2.10.4/objs/cff.o /root/freetype-2.10.4/objs/type1cid.o /root/freetype-2.10.4/objs/pfr.o /root/freetype-2.10.4/objs/type42.o /root/freetype-2.10.4/objs/winfnt.o /root/freetype-2.10.4/objs/pcf.o /root/freetype-2.10.4/objs/bdf.o /root/freetype-2.10.4/objs/sfnt.o /root/freetype-2.10.4/objs/autofit.o /root/freetype-2.10.4/objs/pshinter.o /root/freetype-2.10.4/objs/raster.o /root/freetype-2.10.4/objs/smooth.o /root/freetype-2.10.4/objs/ftcache.o /root/freetype-2.10.4/objs/ftgzip.o /root/freetype-2.10.4/objs/ftlzw.o /root/freetype-2.10.4/objs/ftbzip2.o /root/freetype-2.10.4/objs/psaux.o /root/freetype-2.10.4/objs/psnames.o
x86_64-w64-mingw32-ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: x86_64-w64-mingw32-ranlib /root/freetype-2.10.4/objs/.libs/libfreetype.a
libtool: link: ( cd "/root/freetype-2.10.4/objs/.libs" && rm -f "libfreetype.la" && ln -s "../libfreetype.la" "libfreetype.la" )


I do not know whether the -lm and -lz warnings are significant in this context. Attempting to compile the cross-compiled version, I get the following output with the same errors as before:


===> LD  build/mingw64/Simutrans-Extended.exe
x86_64-w64-mingw32-g++  build/mingw64/sys/simsys_w32_png.o  build/mingw64/sys/clipboard_w32.o  build/mingw64/bauer/brueckenbauer.o  build/mingw64/bauer/fabrikbauer.o  build/mingw64/bauer/hausbauer.o  build/mingw64/bauer/tunnelbauer.o  build/mingw64/bauer/vehikelbauer.o  build/mingw64/bauer/goods_manager.o  build/mingw64/bauer/wegbauer.o  build/mingw64/descriptor/image.o  build/mingw64/descriptor/bridge_desc.o  build/mingw64/descriptor/factory_desc.o  build/mingw64/descriptor/ground_desc.o  build/mingw64/descriptor/building_desc.o  build/mingw64/descriptor/obj_base_desc.o  build/mingw64/descriptor/reader/bridge_reader.o  build/mingw64/descriptor/reader/building_reader.o  build/mingw64/descriptor/reader/citycar_reader.o  build/mingw64/descriptor/reader/crossing_reader.o  build/mingw64/descriptor/reader/factory_reader.o  build/mingw64/descriptor/reader/good_reader.o  build/mingw64/descriptor/reader/ground_reader.o  build/mingw64/descriptor/reader/groundobj_reader.o  build/mingw64/descriptor/reader/image_reader.o  build/mingw64/descriptor/reader/imagelist2d_reader.o  build/mingw64/descriptor/reader/imagelist3d_reader.o  build/mingw64/descriptor/reader/imagelist_reader.o  build/mingw64/descriptor/reader/obj_reader.o  build/mingw64/descriptor/reader/pedestrian_reader.o  build/mingw64/descriptor/reader/roadsign_reader.o  build/mingw64/descriptor/reader/root_reader.o  build/mingw64/descriptor/reader/sim_reader.o  build/mingw64/descriptor/reader/skin_reader.o  build/mingw64/descriptor/reader/sound_reader.o  build/mingw64/descriptor/reader/text_reader.o  build/mingw64/descriptor/reader/tree_reader.o  build/mingw64/descriptor/reader/tunnel_reader.o  build/mingw64/descriptor/reader/vehicle_reader.o  build/mingw64/descriptor/reader/way_obj_reader.o  build/mingw64/descriptor/reader/way_reader.o  build/mingw64/descriptor/reader/xref_reader.o  build/mingw64/descriptor/sound_desc.o  build/mingw64/descriptor/tunnel_desc.o  build/mingw64/descriptor/vehicle_desc.o  build/mingw64/descriptor/goods_desc.o  build/mingw64/descriptor/way_desc.o  build/mingw64/boden/boden.o  build/mingw64/boden/brueckenboden.o  build/mingw64/boden/fundament.o  build/mingw64/boden/grund.o  build/mingw64/boden/monorailboden.o  build/mingw64/boden/tunnelboden.o  build/mingw64/boden/wasser.o  build/mingw64/boden/wege/kanal.o  build/mingw64/boden/wege/maglev.o  build/mingw64/boden/wege/monorail.o  build/mingw64/boden/wege/narrowgauge.o  build/mingw64/boden/wege/runway.o  build/mingw64/boden/wege/schiene.o  build/mingw64/boden/wege/strasse.o  build/mingw64/boden/wege/weg.o  build/mingw64/dataobj/crossing_logic.o  build/mingw64/dataobj/objlist.o  build/mingw64/dataobj/settings.o  build/mingw64/dataobj/schedule.o  build/mingw64/dataobj/freelist.o  build/mingw64/dataobj/gameinfo.o  build/mingw64/dataobj/height_map_loader.o  build/mingw64/dataobj/koord.o  build/mingw64/dataobj/koord3d.o  build/mingw64/dataobj/loadsave.o  build/mingw64/dataobj/marker.o  build/mingw64/dataobj/powernet.o  build/mingw64/dataobj/rect.o  build/mingw64/dataobj/ribi.o  build/mingw64/dataobj/route.o  build/mingw64/dataobj/scenario.o  build/mingw64/dataobj/tabfile.o  build/mingw64/dataobj/translator.o  build/mingw64/dataobj/environment.o  build/mingw64/obj/baum.o  build/mingw64/obj/bruecke.o  build/mingw64/obj/crossing.o  build/mingw64/obj/field.o  build/mingw64/obj/gebaeude.o  build/mingw64/obj/groundobj.o  build/mingw64/obj/label.o  build/mingw64/obj/leitung2.o  build/mingw64/obj/pillar.o  build/mingw64/obj/roadsign.o  build/mingw64/obj/signal.o  build/mingw64/obj/tunnel.o  build/mingw64/obj/wayobj.o  build/mingw64/obj/wolke.o  build/mingw64/obj/zeiger.o  build/mingw64/display/font.o  build/mingw64/display/simgraph16.o  build/mingw64/display/simview.o  build/mingw64/display/viewport.o  build/mingw64/finder/placefinder.o  build/mingw64/freight_list_sorter.o  build/mingw64/gui/ai_option_t.o  build/mingw64/gui/banner.o  build/mingw64/gui/baum_edit.o  build/mingw64/gui/base_info.o  build/mingw64/gui/citybuilding_edit.o  build/mingw64/gui/citylist_frame_t.o  build/mingw64/gui/citylist_stats_t.o  build/mingw64/gui/climates.o  build/mingw64/gui/display_settings.o  build/mingw64/gui/components/gui_aligned_container.o  build/mingw64/gui/components/gui_building.o  build/mingw64/gui/components/gui_button.o  build/mingw64/gui/components/gui_button_to_chart.o  build/mingw64/gui/components/gui_chart.o  build/mingw64/gui/components/gui_colorbox.o  build/mingw64/gui/components/gui_combobox.o  build/mingw64/gui/components/gui_container.o  build/mingw64/gui/components/gui_convoiinfo.o  build/mingw64/gui/components/gui_divider.o  build/mingw64/gui/components/gui_obj_view_t.o  build/mingw64/gui/components/gui_factory_storage_info.o  build/mingw64/gui/components/gui_halthandled_lines.o  build/mingw64/gui/components/gui_fixedwidth_textarea.o  build/mingw64/gui/components/gui_flowtext.o  build/mingw64/gui/components/gui_image.o  build/mingw64/gui/components/gui_image_list.o  build/mingw64/gui/components/gui_component.o  build/mingw64/gui/components/gui_label.o  build/mingw64/gui/components/gui_map_preview.o  build/mingw64/gui/components/gui_numberinput.o  build/mingw64/gui/components/gui_scrollbar.o  build/mingw64/gui/components/gui_scrolled_list.o  build/mingw64/gui/components/gui_scrollpane.o  build/mingw64/gui/components/gui_speedbar.o  build/mingw64/gui/components/gui_tab_panel.o  build/mingw64/gui/components/gui_textarea.o  build/mingw64/gui/components/gui_textinput.o  build/mingw64/gui/components/gui_world_view_t.o  build/mingw64/gui/convoi_detail_t.o  build/mingw64/gui/convoi_filter_frame.o  build/mingw64/gui/convoi_frame.o  build/mingw64/gui/convoi_info_t.o  build/mingw64/gui/convoy_item.o  build/mingw64/gui/curiosity_edit.o  build/mingw64/gui/curiositylist_frame_t.o  build/mingw64/gui/curiositylist_stats_t.o  build/mingw64/gui/depot_frame.o  build/mingw64/gui/depotlist_frame.o  build/mingw64/gui/enlarge_map_frame_t.o  build/mingw64/gui/extend_edit.o  build/mingw64/gui/fabrik_info.o  build/mingw64/gui/factory_chart.o  build/mingw64/gui/factory_edit.o  build/mingw64/gui/factorylist_frame_t.o  build/mingw64/gui/factorylist_stats_t.o  build/mingw64/gui/schedule_gui.o  build/mingw64/gui/goods_frame_t.o  build/mingw64/gui/goods_stats_t.o  build/mingw64/gui/ground_info.o  build/mingw64/gui/gui_frame.o  build/mingw64/gui/gui_theme.o  build/mingw64/gui/halt_detail.o  build/mingw64/gui/halt_info.o  build/mingw64/gui/halt_list_filter_frame.o  build/mingw64/gui/halt_list_frame.o  build/mingw64/gui/halt_list_stats.o  build/mingw64/gui/headquarter_info.o  build/mingw64/gui/help_frame.o  build/mingw64/gui/jump_frame.o  build/mingw64/gui/minimap.o  build/mingw64/gui/kennfarbe.o  build/mingw64/gui/label_info.o  build/mingw64/gui/labellist_frame_t.o  build/mingw64/gui/labellist_stats_t.o  build/mingw64/gui/line_class_manager.o  build/mingw64/gui/line_item.o  build/mingw64/gui/line_management_gui.o  build/mingw64/gui/load_relief_frame.o  build/mingw64/gui/loadfont_frame.o  build/mingw64/gui/loadsave_frame.o  build/mingw64/gui/map_frame.o  build/mingw64/gui/message_frame_t.o  build/mingw64/gui/message_option_t.o  build/mingw64/gui/message_stats_t.o  build/mingw64/gui/messagebox.o  build/mingw64/gui/money_frame.o  build/mingw64/gui/onewaysign_info.o  build/mingw64/gui/optionen.o  build/mingw64/gui/overtaking_mode.o  build/mingw64/gui/pakselector.o  build/mingw64/gui/password_frame.o  build/mingw64/gui/player_frame_t.o  build/mingw64/gui/privatesign_info.o  build/mingw64/gui/savegame_frame.o  build/mingw64/gui/scenario_frame.o  build/mingw64/gui/scenario_info.o  build/mingw64/gui/schedule_list.o  build/mingw64/gui/schiene_info.o  build/mingw64/gui/server_frame.o  build/mingw64/gui/settings_frame.o  build/mingw64/gui/settings_stats.o  build/mingw64/gui/signal_info.o  build/mingw64/gui/signal_spacing.o  build/mingw64/gui/signalboxlist_frame.o  build/mingw64/gui/simwin.o  build/mingw64/gui/sound_frame.o  build/mingw64/gui/sprachen.o  build/mingw64/gui/times_history.o  build/mingw64/gui/times_history_container.o  build/mingw64/gui/times_history_entry.o  build/mingw64/gui/city_info.o  build/mingw64/gui/station_building_select.o  build/mingw64/gui/themeselector.o  build/mingw64/gui/tool_selector.o  build/mingw64/gui/trafficlight_info.o  build/mingw64/gui/vehiclelist_frame.o  build/mingw64/gui/obj_info.o  build/mingw64/gui/vehicle_class_manager.o  build/mingw64/gui/welt.o  build/mingw64/network/checksum.o  build/mingw64/network/memory_rw.o  build/mingw64/network/network.o  build/mingw64/network/network_address.o  build/mingw64/network/network_cmd.o  build/mingw64/network/network_cmd_ingame.o  build/mingw64/network/network_cmd_scenario.o  build/mingw64/network/network_cmp_pakset.o  build/mingw64/network/network_file_transfer.o  build/mingw64/network/network_packet.o  build/mingw64/network/network_socket_list.o  build/mingw64/network/pakset_info.o  build/mingw64/network/pwd_hash.o  build/mingw64/old_blockmanager.o  build/mingw64/player/ai.o  build/mingw64/player/ai_goods.o  build/mingw64/player/ai_passenger.o  build/mingw64/player/finance.o  build/mingw64/player/simplay.o  build/mingw64/script/api_class.o  build/mingw64/script/api_function.o  build/mingw64/script/api_param.o  build/mingw64/script/api/api_city.o  build/mingw64/script/api/api_const.o  build/mingw64/script/api/api_control.o  build/mingw64/script/api/api_convoy.o  build/mingw64/script/api/api_gui.o  build/mingw64/script/api/api_factory.o  build/mingw64/script/api/api_halt.o  build/mingw64/script/api/api_include.o  build/mingw64/script/api/api_line.o  build/mingw64/script/api/api_map_objects.o  build/mingw64/script/api/api_obj_desc.o  build/mingw64/script/api/api_obj_desc_base.o  build/mingw64/script/api/api_player.o  build/mingw64/script/api/api_scenario.o  build/mingw64/script/api/api_schedule.o  build/mingw64/script/api/api_settings.o  build/mingw64/script/api/api_simple.o  build/mingw64/script/api/api_tiles.o  build/mingw64/script/api/api_world.o  build/mingw64/script/api/export_desc.o  build/mingw64/script/api/get_next.o  build/mingw64/script/dynamic_string.o  build/mingw64/script/export_objs.o  build/mingw64/script/script.o  build/mingw64/squirrel/sq_extensions.o  build/mingw64/squirrel/squirrel/sqapi.o  build/mingw64/squirrel/squirrel/sqclass.o  build/mingw64/squirrel/squirrel/sqdebug.o  build/mingw64/squirrel/squirrel/sqlexer.o  build/mingw64/squirrel/squirrel/sqobject.o  build/mingw64/squirrel/squirrel/sqtable.o  build/mingw64/squirrel/squirrel/sqbaselib.o  build/mingw64/squirrel/squirrel/sqcompiler.o  build/mingw64/squirrel/squirrel/sqfuncstate.o  build/mingw64/squirrel/squirrel/sqmem.o  build/mingw64/squirrel/squirrel/sqstate.o  build/mingw64/squirrel/squirrel/sqvm.o  build/mingw64/squirrel/sqstdlib/sqstdaux.o  build/mingw64/squirrel/sqstdlib/sqstdio.o  build/mingw64/squirrel/sqstdlib/sqstdrex.o  build/mingw64/squirrel/sqstdlib/sqstdstring.o  build/mingw64/squirrel/sqstdlib/sqstdblob.o  build/mingw64/squirrel/sqstdlib/sqstdmath.o  build/mingw64/squirrel/sqstdlib/sqstdstream.o  build/mingw64/squirrel/sqstdlib/sqstdsystem.o  build/mingw64/simcity.o  build/mingw64/simconvoi.o  build/mingw64/simdebug.o  build/mingw64/simdepot.o  build/mingw64/simobj.o  build/mingw64/simevent.o  build/mingw64/simfab.o  build/mingw64/simhalt.o  build/mingw64/siminteraction.o  build/mingw64/simintr.o  build/mingw64/simio.o  build/mingw64/simline.o  build/mingw64/simlinemgmt.o  build/mingw64/simloadingscreen.o  build/mingw64/simmain.o  build/mingw64/simmem.o  build/mingw64/simmenu.o  build/mingw64/simmesg.o  build/mingw64/simplan.o  build/mingw64/simsignalbox.o  build/mingw64/simskin.o  build/mingw64/simsound.o  build/mingw64/simticker.o  build/mingw64/simtool.o  build/mingw64/simware.o  build/mingw64/simworld.o  build/mingw64/sys/simsys.o  build/mingw64/unicode.o  build/mingw64/utils/cbuffer_t.o  build/mingw64/utils/csv.o  build/mingw64/utils/log.o  build/mingw64/utils/searchfolder.o  build/mingw64/utils/sha1.o  build/mingw64/utils/simrandom.o  build/mingw64/vehicle/simroadtraffic.o  build/mingw64/utils/simstring.o  build/mingw64/utils/simthread.o  build/mingw64/vehicle/movingobj.o  build/mingw64/vehicle/simpeople.o  build/mingw64/vehicle/simvehicle.o  build/mingw64/simunits.o  build/mingw64/convoy.o  build/mingw64/utils/float32e8_t.o  build/mingw64/path_explorer.o  build/mingw64/gui/components/gui_table.o  build/mingw64/gui/components/gui_convoy_assembler.o  build/mingw64/gui/components/gui_convoy_label.o  build/mingw64/gui/components/gui_convoy_formation.o  build/mingw64/gui/components/gui_convoy_payloadinfo.o  build/mingw64/gui/replace_frame.o  build/mingw64/dataobj/livery_scheme.o  build/mingw64/dataobj/replace_data.o  build/mingw64/sys/simsys_s2.o  build/mingw64/sound/sdl2_sound.o  build/mingw64/music/w32_midi.o  build/mingw64/simres.o -L/root/freetype-2.10.4/objs/.libs -L/root/miniupnpc/miniupnpc-2.1.20201016 -L/root/zstd/zstd/lib -L/root/zlib-source/zlib-1.2.11 -L/root/bzip64/bzip2-1.0.6 -L/usr/x86_64-w64-mingw32/lib/ -L/root/SDL2-2.0.7/build-win64/build/.libs -lmingw32 -lSDL2main -lSDL2 -mwindows -lm -ldinput8 -ldxguid -ldxerr8 -luser32 -lgdi32 -lwinmm -limm32 -lole32 -loleaut32 -lshell32 -lversion -luuid -lfreetype -static-libgcc -static-libstdc++ -static -mwindows -lfreetype -lzstd -lpthread -lmingw32 -lgdi32 -lwinmm -lws2_32 -limm32 -lbz2 -lz -lbz2 -lz -lSDL2 -o build/mingw64/Simutrans-Extended.exe
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `Load_SBit_Png':
/root/freetype-2.10.4/src/sfnt/pngshim.c:295: undefined reference to `png_create_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:305: undefined reference to `png_create_info_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:313: undefined reference to `png_set_longjmp_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:446: undefined reference to `png_destroy_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:319: undefined reference to `png_set_read_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:321: undefined reference to `png_read_info'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:322: undefined reference to `png_get_IHDR'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:360: undefined reference to `png_set_expand_gray_1_2_4_to_8'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:367: undefined reference to `png_get_valid'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:382: undefined reference to `png_set_interlace_handling'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:384: undefined reference to `png_set_filler'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:387: undefined reference to `png_read_update_info'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:388: undefined reference to `png_get_IHDR'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:410: undefined reference to `png_set_read_user_transform_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:439: undefined reference to `png_read_image'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:443: undefined reference to `png_read_end'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:379: undefined reference to `png_set_gray_to_rgb'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:374: undefined reference to `png_set_packing'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:368: undefined reference to `png_set_tRNS_to_alpha'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:371: undefined reference to `png_set_strip_16'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:354: undefined reference to `png_set_palette_to_rgb'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:415: undefined reference to `png_set_read_user_transform_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:309: undefined reference to `png_destroy_read_struct'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `error_callback':
/root/freetype-2.10.4/src/sfnt/pngshim.c:199: undefined reference to `png_get_error_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:206: undefined reference to `png_set_longjmp_fn'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/objs/.libs/libfreetype.a(sfnt.o): in function `read_data_from_FT_Stream':
/root/freetype-2.10.4/src/sfnt/pngshim.c:230: undefined reference to `png_get_io_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:236: undefined reference to `png_get_error_ptr'
/usr/bin/x86_64-w64-mingw32-ld: /root/freetype-2.10.4/src/sfnt/pngshim.c:240: undefined reference to `png_error'
collect2: error: ld returned 1 exit status
make: *** [common.mk:27: build/mingw64/Simutrans-Extended.exe] Error 1


I note the reference to not having libpng properly installed for the cross-compiler; this is indeed the case: when I set this up, I did not realise that standardised directories for cross-compile libraries were a thing, and I still do not know how to go about setting this up. However, what I do notice is that I do not have any manual flags for libraries or includes set up in config.mingw64.

Looking at the /usr/x86_64-w64-mingw32/lib directory, however, there is no libpng.* file there, although I notice that there are pthreads files there, suggesting that I had begun to set up the automatic system somehow in 2017 and not beel able to set this up for the other libraries.

Thus, I am not sure how libpng is being linked. I have a manually created libpng directory containing the following contents:


total 3504
-rw-r--r--  1 meme 5101  44739 Aug 24  2017 aclocal.m4
-rw-r--r--  1 meme 5101   4490 Aug 24  2017 ANNOUNCE
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 arm
-rwxr-xr-x  1 meme 5101   7979 Aug  3  2015 autogen.sh
-rw-r--r--  1 meme 5101 299235 Aug 24  2017 CHANGES
-rw-r--r--  1 meme 5101  34778 Aug 24  2017 CMakeLists.txt
-rwxr-xr-x  1 meme 5101   7333 Feb 21  2015 compile
-rwxr-xr-x  1 meme 5101  42938 Feb 21  2015 config.guess
-rw-r--r--  1 meme 5101   3615 Aug 24  2017 config.h.in
-rw-r--r--  1 root root  37248 Jan 15  2018 config.log
-rwxr-xr-x  1 meme 5101  35987 Feb 21  2015 config.sub
-rwxr-xr-x  1 meme 5101 483297 Aug 24  2017 configure
-rw-r--r--  1 meme 5101  19424 Aug 24  2017 configure.ac
drwxr-xr-x 16 meme 5101   4096 Aug 24  2017 contrib
-rwxr-xr-x  1 meme 5101  23566 Feb 21  2015 depcomp
-rw-r--r--  1 meme 5101  40471 Aug 24  2017 example.c
-rw-r--r--  1 meme 5101  19276 Aug 24  2017 INSTALL
-rwxr-xr-x  1 meme 5101  14675 Feb 21  2015 install-sh
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 intel
-rw-r--r--  1 meme 5101 273361 Aug 24  2017 libpng.3
-rw-r--r--  1 meme 5101   2396 Aug 24  2017 libpng-config.in
-rw-r--r--  1 meme 5101 230300 Aug 24  2017 libpng-manual.txt
-rw-r--r--  1 meme 5101    308 Aug 24  2017 libpng.pc.in
-rw-r--r--  1 meme 5101    796 Aug 24  2017 libpngpf.3
-rw-r--r--  1 meme 5101   4987 Aug 24  2017 LICENSE
-rwxr-xr-x  1 meme 5101 324089 Aug 24  2017 ltmain.sh
-rw-r--r--  1 meme 5101  13910 Aug  4  2017 Makefile.am
-rw-r--r--  1 meme 5101  91604 Aug 24  2017 Makefile.in
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 mips
-rwxr-xr-x  1 meme 5101   6872 Feb 21  2015 missing
-rw-r--r--  1 meme 5101   2431 Aug 24  2017 png.5
-rw-r--r--  1 meme 5101   2498 Jul 12  2000 pngbar.jpg
-rw-r--r--  1 meme 5101   2399 Jul 12  2000 pngbar.png
-rw-r--r--  1 meme 5101 157869 Aug 24  2017 png.c
-rw-r--r--  1 meme 5101  22842 Aug 24  2017 pngconf.h
-rw-r--r--  1 meme 5101   5368 Aug 24  2017 pngdebug.h
-rw-r--r--  1 meme 5101  29230 Aug 24  2017 pngerror.c
-rw-r--r--  1 meme 5101  34087 Aug 24  2017 pngget.c
-rw-r--r--  1 meme 5101 144052 Aug 24  2017 png.h
-rw-r--r--  1 meme 5101  12536 Aug 24  2017 pnginfo.h
-rw-r--r--  1 meme 5101   8372 Aug 24  2017 pngmem.c
-rw-r--r--  1 meme 5101   2069 Aug 26  2004 pngnow.png
-rw-r--r--  1 meme 5101  31835 Aug 24  2017 pngpread.c
-rw-r--r--  1 meme 5101  88792 Aug 24  2017 pngpriv.h
-rw-r--r--  1 meme 5101 141985 Aug 24  2017 pngread.c
-rw-r--r--  1 meme 5101   3956 Aug 24  2017 pngrio.c
-rw-r--r--  1 meme 5101 168916 Aug 24  2017 pngrtran.c
-rw-r--r--  1 meme 5101 147076 Aug 24  2017 pngrutil.c
-rw-r--r--  1 meme 5101  51471 Aug 24  2017 pngset.c
-rw-r--r--  1 meme 5101  20037 Aug 24  2017 pngstruct.h
-rw-r--r--  1 meme 5101  62909 Aug 24  2017 pngtest.c
-rw-r--r--  1 meme 5101   8759 Jul 18  2017 pngtest.png
-rw-r--r--  1 meme 5101  25324 Aug 24  2017 pngtrans.c
-rw-r--r--  1 meme 5101    497 Aug 24  2017 pngusr.dfa
-rw-r--r--  1 meme 5101   5655 Aug 24  2017 pngwio.c
-rw-r--r--  1 meme 5101  76574 Aug 24  2017 pngwrite.c
-rw-r--r--  1 meme 5101  15402 Aug 24  2017 pngwtran.c
-rw-r--r--  1 meme 5101  81047 Aug 24  2017 pngwutil.c
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 powerpc
drwxr-xr-x  5 meme 5101   4096 Aug 24  2017 projects
-rw-r--r--  1 meme 5101  11684 Aug 24  2017 README
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 scripts
-rwxr-xr-x  1 meme 5101   4640 Feb 21  2015 test-driver
drwxr-xr-x  2 meme 5101   4096 Aug 24  2017 tests
-rw-r--r--  1 meme 5101   1247 Jan 20  2017 TODO


but none of those appear to be compiled library files. I cannot remember now how I set up libpng to link for Simutrans-Exnteded myself, and I am confused as to where the relevant library files are for linking to Freetype or how to go about finding them.
Title: Re: Incorporating changes from Standard
Post by: prissi on December 09, 2020, 11:56:02 PM
Cmake does not run on mingw for windows. Does not work. Moreover, Cmake generates a gnu makefile, which we have and which works on most systems. So Cmake seems not the way out (at least until it generates useful Makefiles for Mingw).

But there is the nightly generation on github, using all relevant libraries. Why not download from there? It is just a wget/curl command away ...

The current simutrans nightlies for standard also come from github, since I did not want to bother with zstd cross-compilation on my server. It was way easier to just add curl download command.


cd /home/simutrans/mingw64/trunk
REVISION=`svnversion`

rm /var/www/nightly/*
#sudo -u simutrans /home/simutrans/make-simugdi.sh >/var/www/nightly/simugdi.log 2>&1
#mv /home/simutrans/mingw64/trunk/simuwin-*.zip /var/www/nightly
curl -L https://github.com/aburch/simutrans/releases/download/Nightly/simuwin-gdi32-nightly.zip > /var/www/nightly/simuwin-$REVISION.zip
chown -R www-data:www-data /var/www/nightly
sudo -u simutrans /home/simutrans/make-simulinux.sh >/var/www/nightly/simulinux.log 2>&1
mv /home/simutrans/mingw64/trunk/simulinux-*.zip /var/www/nightly
curl -L https://github.com/aburch/simutrans/releases/download/Nightly/simumac-nightly.zip > /var/www/nightly/simumac-$REVISION.zip
chown -R www-data:www-data /var/www/nightly




Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 10, 2020, 12:25:53 AM
Quote from: prissi on December 09, 2020, 11:56:02 PM
Cmake does not run on mingw for windows. Does not work. Moreover, Cmake generates a gnu makefile, which we have and which works on most systems. So Cmake seems not the way out (at least until it generates useful Makefiles for Mingw).

But there is the nightly generation on github, using all relevant libraries. Why not download from there? It is just a wget/curl command away ...

The current simutrans nightlies for standard also come from github, since I did not want to bother with zstd cross-compilation on my server. It was way easier to just add curl download command.


cd /home/simutrans/mingw64/trunk
REVISION=`svnversion`

rm /var/www/nightly/*
#sudo -u simutrans /home/simutrans/make-simugdi.sh >/var/www/nightly/simugdi.log 2>&1
#mv /home/simutrans/mingw64/trunk/simuwin-*.zip /var/www/nightly
curl -L https://github.com/aburch/simutrans/releases/download/Nightly/simuwin-gdi32-nightly.zip > /var/www/nightly/simuwin-$REVISION.zip
chown -R www-data:www-data /var/www/nightly
sudo -u simutrans /home/simutrans/make-simulinux.sh >/var/www/nightly/simulinux.log 2>&1
mv /home/simutrans/mingw64/trunk/simulinux-*.zip /var/www/nightly
curl -L https://github.com/aburch/simutrans/releases/download/Nightly/simumac-nightly.zip > /var/www/nightly/simumac-$REVISION.zip
chown -R www-data:www-data /var/www/nightly






Thank you for the suggestion. I have tried to download the Windows Mingw32 SDL build from Github, but it seems to be compiled as dynamically linked, and fails at runtime with an error indicating that I need libstdc++-6.dll (and a lot of other .dlls including for pthreads and zlib).

I suspect that setting up CI to work properly will be at least as much work, if not much more, than setting up the Bridgewater-Brunel server to work. At present, the Bridgewater-Brunel compiling works so long as Freetype is not enabled - and this is not in any event enabled on current nightly builds, so, if I cannot find a solution to this, an option would be just to continue building without Freetype for the time being.
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 10, 2020, 12:38:23 AM
Quote from: jamespetts on December 09, 2020, 10:50:55 PM
I executed the following commands:


root@438242:~/freetype-2.10.4# pkg-config freetype2 --libs --static
-L/usr/local/lib -lfreetype -lz -lpng15 -lm -lz -lm

Almost certainly these are the requirement for your linux system library, not the cross library.  Try "x86_64-w64-mingw32-pkg-config freetype2 --libs --static". I expect you to get either "x86_64-w64-mingw32-pkg-config: command not found" or "Package freetype2 was not found in t....". If the later, good, can work with that. If the former, need to muck with some paths. cross that if needed.


Quote from: jamespetts on December 09, 2020, 10:50:55 PM

root@438242:~/freetype-2.10.4# ./configure --host=x86_64-w64-mingw32 --without-harfbuzz

No. "./configure --prefix=/usr/x86_64-w64-mingw32 --host=x86_64-w64-mingw32  --without-zlib --without-bzip2 --without-png --without-harfbuzz --without-brotli"
Nuke all the optional library dependancies to prevent it finding your linux ones (through config scripts like libpng-config).  Can add back later if desired once stripped basic version running.


Quote from: jamespetts on December 09, 2020, 10:50:55 PM
and generated the following output:

FreeType build system -- automatic system detection

checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building
no
Please do as it says and install dpkg-dev.  (before running ./configure....)


Quote from: jamespetts on December 09, 2020, 10:50:55 PM
"make" then generated the following output (truncated to the last section otherwise this would be excessively long):


*** Warning: linker path does not have real file for library -lz.

*** Warning: linker path does not have real file for library -lm.


I do not know whether the -lm and -lz warnings are significant in this context. Attempting to compile the cross-compiled version, I get the following output with the same errors as before:
For libz, why not just install the package for it? "libz-mingw-w64-dev". Then one less library to self compile...
libm. hmmm. ugly. Easiest to just ignore for now since not important for static linking. If you want ability to dynamic link freetype in future, need to solve (something to do with libm.a in mingw being an import library - even static it actually is dynamic against Windows dlls.)


Quote from: jamespetts on December 09, 2020, 10:50:55 PM
I note the reference to not having libpng properly installed for the cross-compiler; this is indeed the case: when I set this up, I did not realise that standardised directories for cross-compile libraries were a thing, and I still do not know how to go about setting this up.
I don't believe Simutrans is using any functions in freetype2 that require libpng, so skip for now.
So.
1. Install dpkg-dev
2. Install libz-mingw-w64-dev
3. Run "root@438242:~/freetype-2.10.4#./configure --prefix=/usr/x86_64-w64-mingw32 --host=x86_64-w64-mingw32  --without-bzip2 --without-png --without-harfbuzz --without-brotli"
4. Confirm in output:

  Library configuration:
    external zlib: yes (pkg-config)
    bzip2:         no
    libpng:        no
    harfbuzz:      no
    brotli:        no

5. Run "make"
6. Confirm it's only complaining about dynamic libm.   libz should now be ok since you installed it.
7. Run "make install"
8. Confirm you now have "/usr/x86_64-w64-mingw32/lib/libfreetype.a", "/usr/x86_64-w64-mingw32/lib/pkgconfig/freetype2.pc", "/usr/x86_64-w64-mingw32/include/freetype2/*", etc.
9. Test "x86_64-w64-mingw32-pkg-config freetype2 --libs --static". Should now work.
10. Set "FREETYPE_CONFIG=x86_64-w64-mingw32-pkg-config freetype2" in config.mingw64
11. Compile Simutrans.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 10, 2020, 01:42:05 AM
Thank you very much for this: this is most kind.

As to the packages to install - I already have dpkg-dev installed: I confirmed by executing the "apt install dpkg-dev" command, and the returned message indicated that it was installed. I installed libz-mingw-w64-dev.

Executing the command gives the following output:


./configure --prefix=/usr/x86_64-w64-mingw32 --host=x86_64-w64-mingw32  --without-bzip2 --without-png --without-harfbuzz --without-brotli

FreeType build system -- automatic system detection

The following settings are used:

  platform                    unix
  compiler                    cc
  configuration directory     ./builds/unix
  configuration rules         ./builds/unix/unix.mk

If this does not correspond to your system or settings please remove the file
`config.mk' from this directory then read the INSTALL file for help.

Otherwise, simply type `make' again to build the library,
or `make refdoc' to build the API reference (this needs Python >= 3.5).

cd builds/unix; \
        ./configure  '--prefix=/usr/x86_64-w64-mingw32' '--host=x86_64-w64-mingw32' '--without-bzip2' '--without-png' '--without-harfbuzz' '--without-brotli'
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-w64-mingw32
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-w64-mingw32-gcc accepts -g... yes
checking for x86_64-w64-mingw32-gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... x86_64-w64-mingw32-gcc -E
checking for x86_64-w64-mingw32-pkg-config... /usr/bin/x86_64-w64-mingw32-pkg-config
checking pkg-config is at least version 0.24... Please install dpkg-dev to use pkg-config when cross-building
no
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-w64-mingw32-gcc... /usr/bin/x86_64-w64-mingw32-ld
checking if the linker (/usr/bin/x86_64-w64-mingw32-ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/x86_64-w64-mingw32-nm -B
checking the name lister (/usr/bin/x86_64-w64-mingw32-nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-w64-mingw32 format... func_convert_file_nix_to_w32
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/x86_64-w64-mingw32-ld option to reload object files... -r
checking for x86_64-w64-mingw32-objdump... x86_64-w64-mingw32-objdump
checking how to recognize dependent libraries... file_magic ^x86 archive import|^x86 DLL
checking for x86_64-w64-mingw32-dlltool... x86_64-w64-mingw32-dlltool
checking how to associate runtime and link libraries... func_cygming_dll_for_implib
checking for x86_64-w64-mingw32-ar... x86_64-w64-mingw32-ar
checking for archiver @FILE support... @
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for x86_64-w64-mingw32-ranlib... x86_64-w64-mingw32-ranlib
checking for gawk... no
checking for mawk... mawk
checking command to parse /usr/bin/x86_64-w64-mingw32-nm -B output from x86_64-w64-mingw32-gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for x86_64-w64-mingw32-mt... no
checking for mt... mt
configure: WARNING: using cross tools not prefixed with host triplet
checking if mt is a manifest tool... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... no
checking for x86_64-w64-mingw32-as... x86_64-w64-mingw32-as
checking for x86_64-w64-mingw32-dlltool... (cached) x86_64-w64-mingw32-dlltool
checking for x86_64-w64-mingw32-objdump... (cached) x86_64-w64-mingw32-objdump
checking for objdir... .libs
checking if x86_64-w64-mingw32-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-w64-mingw32-gcc option to produce PIC... -DDLL_EXPORT -DPIC
checking if x86_64-w64-mingw32-gcc PIC flag -DDLL_EXPORT -DPIC works... yes
checking if x86_64-w64-mingw32-gcc static flag -static works... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... yes
checking if x86_64-w64-mingw32-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-w64-mingw32-gcc linker (/usr/bin/x86_64-w64-mingw32-ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking windows.h usability... yes
checking windows.h presence... yes
checking for windows.h... yes
checking for x86_64-w64-mingw32-windres... x86_64-w64-mingw32-windres
checking for x86_64-pc-linux-gnu-gcc... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for suffix of native executables...
checking for a BSD-compatible install... /usr/bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for ANSI C header files... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking size of int... 4
checking size of long... 4
checking for unsigned long long int... yes
checking for long long int... yes
checking whether cpp computation of bit length in ftconfig.h.in works... yes
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for stdlib.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/param.h... yes
checking for getpagesize... yes
checking for working mmap... no
checking for memcpy... yes
checking for memmove... yes
checking for -fvisibility=hidden compiler flag... yes
checking for ZLIB... no
checking for gzsetparams in -lz... yes
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for library containing clock_gettime... no
checking for python3... python3
checking for python version... 3.8.5
checking for `docwriter' Python module... no
configure: creating ./config.status
config.status: creating ftoption.h
config.status: creating unix-cc.mk
config.status: creating unix-def.mk
config.status: creating ftconfig.h
config.status: ftconfig.h is unchanged
config.status: executing libtool commands
configure:

Library configuration:
  external zlib: yes (autoconf test)
  bzip2:         no
  libpng:        no
  harfbuzz:      no
  brotli:        no

configure: WARNING:
  `make refdoc' will fail since pip package `docwriter' is not installed.
  To install, run `python3 -m pip install docwriter', or to use a Python
  virtual environment, run `make refdoc-venv' (requires pip


This appears to work.

"make" produces the following output (mostly truncated as this is very long as before: end part only shown):


x86_64-w64-mingw32-ar: `u' modifier ignored since `D' is the default (see `U')
libtool: link: x86_64-w64-mingw32-ranlib /root/freetype-2.10.4/objs/.libs/libfreetype.a
libtool: link: ( cd "/root/freetype-2.10.4/objs/.libs" && rm -f "libfreetype.la" && ln -s "../libfreetype.la" "libfreetype.la" )


make install produces the following output:


rm -rf /usr/x86_64-w64-mingw32/include/freetype2
rm -f /usr/x86_64-w64-mingw32/include/ft2build.h
/bin/mkdir -p /usr/x86_64-w64-mingw32/lib                               \
                         /usr/x86_64-w64-mingw32/lib/pkgconfig                     \
                         /usr/x86_64-w64-mingw32/include/freetype2/freetype/config \
                         /usr/x86_64-w64-mingw32/share/aclocal
./builds/unix/libtool --mode=install /usr/bin/install -c                             \
                                  /root/freetype-2.10.4/objs/libfreetype.la /usr/x86_64-w64-mingw32/lib
libtool: install: /usr/bin/install -c /root/freetype-2.10.4/objs/.libs/libfreetype.dll.a /usr/x86_64-w64-mingw32/lib/libfreetype.dll.a
libtool: install: base_file=`basename /root/freetype-2.10.4/objs/libfreetype.la`
libtool: install:  dlpath=`/bin/bash 2>&1 -c '. /root/freetype-2.10.4/objs/.libs/'libfreetype.la'i; echo libfreetype-6.dll'`
libtool: install:  dldir=/usr/x86_64-w64-mingw32/lib/`dirname ../bin/libfreetype-6.dll`
libtool: install:  test -d /usr/x86_64-w64-mingw32/lib/../bin || mkdir -p /usr/x86_64-w64-mingw32/lib/../bin
libtool: install:  /usr/bin/install -c /root/freetype-2.10.4/objs/.libs/libfreetype-6.dll /usr/x86_64-w64-mingw32/lib/../bin/libfreetype-6.dll
libtool: install:  chmod a+x /usr/x86_64-w64-mingw32/lib/../bin/libfreetype-6.dll
libtool: install:  if test -n '' && test -n 'x86_64-w64-mingw32-strip --strip-unneeded'; then eval 'x86_64-w64-mingw32-strip --strip-unneeded /usr/x86_64-w64-mingw32/lib/../bin/libfreetype-6.dll' || exit 0; fi
libtool: install: /usr/bin/install -c /root/freetype-2.10.4/objs/.libs/libfreetype.lai /usr/x86_64-w64-mingw32/lib/libfreetype.la
libtool: install: /usr/bin/install -c /root/freetype-2.10.4/objs/.libs/libfreetype.a /usr/x86_64-w64-mingw32/lib/libfreetype.a
libtool: install: chmod 644 /usr/x86_64-w64-mingw32/lib/libfreetype.a
libtool: install: x86_64-w64-mingw32-ranlib /usr/x86_64-w64-mingw32/lib/libfreetype.a
for P in /root/freetype-2.10.4/include/freetype/tttables.h /root/freetype-2.10.4/include/freetype/ftcid.h /root/freetype-2.10.4/include/freetype/ftstroke.h /root/freetype-2.10.4/include/freetype/t1tables.h /root/freetype-2.10.4/include/freetype/fterrors.h /root/freetype-2.10.4/include/freetype/ftparams.h /root/freetype-2.10.4/include/freetype/ftglyph.h /root/freetype-2.10.4/include/freetype/ftbitmap.h /root/freetype-2.10.4/include/freetype/ftmodapi.h /root/freetype-2.10.4/include/freetype/ftsystem.h /root/freetype-2.10.4/include/freetype/ftoutln.h /root/freetype-2.10.4/include/freetype/ftsynth.h /root/freetype-2.10.4/include/freetype/ftlcdfil.h /root/freetype-2.10.4/include/freetype/ftpfr.h /root/freetype-2.10.4/include/freetype/ftsizes.h /root/freetype-2.10.4/include/freetype/ftrender.h /root/freetype-2.10.4/include/freetype/ftlzw.h /root/freetype-2.10.4/include/freetype/ftfntfmt.h /root/freetype-2.10.4/include/freetype/ftbzip2.h /root/freetype-2.10.4/include/freetype/ftlist.h /root/freetype-2.10.4/include/freetype/ftincrem.h /root/freetype-2.10.4/include/freetype/ftchapters.h /root/freetype-2.10.4/include/freetype/ftbdf.h /root/freetype-2.10.4/include/freetype/ftcache.h /root/freetype-2.10.4/include/freetype/ttnameid.h /root/freetype-2.10.4/include/freetype/ftgzip.h /root/freetype-2.10.4/include/freetype/ftdriver.h /root/freetype-2.10.4/include/freetype/ftmac.h /root/freetype-2.10.4/include/freetype/fttypes.h /root/freetype-2.10.4/include/freetype/ftwinfnt.h /root/freetype-2.10.4/include/freetype/freetype.h /root/freetype-2.10.4/include/freetype/ftcolor.h /root/freetype-2.10.4/include/freetype/ftbbox.h /root/freetype-2.10.4/include/freetype/ftmm.h /root/freetype-2.10.4/include/freetype/ftadvanc.h /root/freetype-2.10.4/include/freetype/ftmoderr.h /root/freetype-2.10.4/include/freetype/ftgasp.h /root/freetype-2.10.4/include/freetype/ftgxval.h /root/freetype-2.10.4/include/freetype/ftsnames.h /root/freetype-2.10.4/include/freetype/tttags.h /root/freetype-2.10.4/include/freetype/ftotval.h /root/freetype-2.10.4/include/freetype/fterrdef.h /root/freetype-2.10.4/include/freetype/fttrigon.h /root/freetype-2.10.4/include/freetype/ftimage.h ; do                           \
          /usr/bin/install -c -m 644                                    \
            $P /usr/x86_64-w64-mingw32/include/freetype2/freetype ; \
        done
for P in /root/freetype-2.10.4/include/freetype/config/ftstdlib.h /root/freetype-2.10.4/include/freetype/config/public-macros.h /root/freetype-2.10.4/include/freetype/config/ftconfig.h /root/freetype-2.10.4/include/freetype/config/mac-support.h /root/freetype-2.10.4/include/freetype/config/ftmodule.h /root/freetype-2.10.4/include/freetype/config/ftoption.h /root/freetype-2.10.4/include/freetype/config/ftheader.h /root/freetype-2.10.4/include/freetype/config/integer-types.h  /root/freetype-2.10.4/objs/ftmodule.h ./builds/unix/ftoption.h ; do                                  \
          /usr/bin/install -c -m 644                                           \
            $P /usr/x86_64-w64-mingw32/include/freetype2/freetype/config ; \
        done
/usr/bin/install -c -m 644 /root/freetype-2.10.4/include/ft2build.h                  \
          /usr/x86_64-w64-mingw32/include/freetype2/ft2build.h
/usr/bin/install -c -m 644 ./builds/unix/ftconfig.h                        \
          /usr/x86_64-w64-mingw32/include/freetype2/freetype/config/ftconfig.h
/usr/bin/install -c -m 644 /root/freetype-2.10.4/objs/ftmodule.h                          \
          /usr/x86_64-w64-mingw32/include/freetype2/freetype/config/ftmodule.h
/usr/bin/install -c -m 644 ./builds/unix/ftoption.h                        \
          /usr/x86_64-w64-mingw32/include/freetype2/freetype/config/ftoption.h
/usr/bin/install -c -m 644 ./builds/unix/freetype2.m4             \
          /usr/x86_64-w64-mingw32/share/aclocal/freetype2.m4
/usr/bin/install -c -m 644 ./builds/unix/freetype2.pc             \
          /usr/x86_64-w64-mingw32/lib/pkgconfig/freetype2.pc


The next step fails as dpkg-dev is not recognised despite the fact that I have it installed:


root@438242:~/freetype-2.10.4# x86_64-w64-mingw32-pkg-config freetype2 --libs --static
Please install dpkg-dev to use pkg-config when cross-building
root@438242:~/freetype-2.10.4# apt install dpkg-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
dpkg-dev is already the newest version (1.19.7ubuntu3).
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.


Despite this, however, making the build works, the server now builds properly with Freetype for cross-compiling.

Thank you very much for all your detailed help - that is very much appreciated indeed. You desrve cake.

For testing purposes, the Freetype enabled build can be downloaded here (http://bridgewater-brunel.me.uk/downloads/Simutrans-Extended-server-build-zstd-freetype.exe).


Edit: Ranran - can I check which UI features, if any, need further testing before this is integrated into the master branch? Do you think that anything further needs to be done before integration?
Title: Re: Incorporating changes from Standard
Post by: TurfIt on December 10, 2020, 02:25:41 AM
Quote from: jamespetts on December 10, 2020, 01:42:05 AMThe next step fails as dpkg-dev is not recognised despite the fact that I have it installed:
Apparently fixed in 'mingw-w64 (7.0.0-3) unstable'. Presumably you're running 7.0.0-2.
Workaround is just using pkg-config (i.e. the non cross one) with PKG_CONFIG_LIBDIR set to the cross libs .pcs.
or go back to manually specifying everything.

Installing bzip2 "correctly" and redoing the freetype compile might be desired in case some users wish to use fonts compressed with it...
Title: Re: Incorporating changes from Standard
Post by: prissi on December 10, 2020, 05:11:20 AM
Mingw cross compile on Debian is somewhat broken, since it claims full C11++ support but chokes on std::thread::... even though there is a header and __Cplusplus is laregr than 2011/3. One either has to use posix threads (and a ton of DLLs) or deliverately detect cross compilation and avoid this. Since this is the most portable way to detect the number of threads for zstd, I stopped cross-compilation and use the mingw builds from github (which are built on windows, where the same code works!)
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 12, 2020, 09:57:19 AM
I have fixed some bugs and brushed up the GUI.
(1) The construction site was not displayed correctly in hide building mode. This bug can be reproduced on the master branch, but I'm guessing it was probably caused by changing the one way ribi display. I fixed it anyway.

(2) Made the convoy detail dialog (many parts) a new GUI engine. Repaired a broken function. The layout has changed.
The display of the convoy overview can now be switched. This was because the transition of the new GUI engine made it easy to switch this display because it is used in other dialogs, so all I had to do was add a button.
Moved buttons such as sell now and retire to the maintenance tab.
I'm planning to put the class manager inside a tab, but that can take some time.

(3) Brushed up the signalbox list
Added radius display. Added has vacans slot filter. This added two translations.
helptxt_filter_sb_has_vacant_slot
Vacant slot



QuoteRanran - can I check which UI features, if any, need further testing before this is integrated into the master branch?
There are three branches you can test:

(1) accel curve chart
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/accel-curve-chart-v2
This adds a physics chart to the convoy detail dialog.
I'm planning to open this dialog from the depot dialog, but it hasn't been implemented yet.

(2) halt detail plus
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/halt-detail-plus-v2
This was a lot of work done before the standard merging work. Many improvements have been added to halt detail.
- The third tab is split and route_tab is added.
  You can see a lot of information in debug builds (line speed and preferred line), but it is hidden in release builds.
- Information around the station is added to the first tab.
- Two display options are added to the station dialog. Sort by which line the cargo is waiting for.
  Please note that this is a plan. In short, the preferred line is displayed. If a convoy heading for the same destination arrives first, they may ride on it. This is the same as in the real world.

Note that these patch also adds some translatable terms.


(3) Incorporating from standard (makeobj update - factory location(r8571-) )
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-makeobj-update

This adds parameters for factory location conditions (forest, river, shore). However, this requires updating the pakset, so I have not confirmed the behavior of the added parameters.


QuoteDo you think that anything further needs to be done before integration?
I can't think of anything.




Another big patch from the standard is the climate patch branch.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/std-r9148-climate-patch
I don't think this can be merged right away.
It seems that there is a conflict in the way the river is created and there is a problem with its operation. Can I ask if the river generation method is different between extended and standard?

I also tried sqapi related merging, which seems to be a huge amount of work. Those who are interested in this may be able to proceed with it.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 12, 2020, 04:18:56 PM
Thank you very much - this is very helpful. I have now incorporated the latest changes from the zstd branch into the master branch: the signal box  list and convoy details improvement were most helpful. I have modified the server's simuconf.tab to switch to zstd level 3 compression when it next restarts, so hopefully to-morrow we will see the effect of zstd on making the server more responsive on loading/saving.

Thank you very much for your excellent work on this to date - it is very much appreciated. The improvement of the GUI between the new version and the old is very great indeed.

As to the other branches, I will test those shortly and revert on this thread when I have done so, but I thought it more important to incorporate the bulk of the changes - especially zstd - into the master branch sooner rather than later now that it is working.

I should note, incidentally, that I have not yet set up 32-bit Windows cross-compile builds. Does anyone use the 32-bit Windows executable any more? It may be worthwhile discontinuing this as a separate build, as many games take more memory than this version is capable of handling in any event.

As to future work, it will be very interesting to see progress on the climates branch. I cannot immediately recall whether there has been an intentional difference in river generation between Extended and Standard; I recall some time ago looking into river generation and testing to ensure that a realistic number of rivers were generated, but I am not sure whether this entailed making some adjustments to the code or simply altering the default river generation parameters. Certainly, if there are any modifications to the Extended river code, I have not made any major changes to it; I cannot immediately recall whether anyone else made changes to this, but I do not recall any major changes of this sort.

As to the scripting API, I can anticipate that this would be a huge amount of work, and, since scripted scenarios are not the paradigm play style for Simutrans-Extended, this is not a priority at present. If anyone is very keen on doing this, it would certainly not hurt to have this integrated, but I suspect that development time is best focussed elsewhere.

After completion of the merging of important features from Standard, the next task, I think, will be the task of reviving and completing the vehicle-management branch, which contains the beginnings of some features that will be very important to game balance. I will need to do the coding for the simulation aspects of this, which will be a substantial task in itself, but the UI will need some consideration. Ves had started to write a UI for this back in 2018 when work was last done on this branch, but this will now be out of date and not compatible with the latest version of the UI code. At least a basic UI will need to be in place for testing purposes (the current state of the code is that I have a lot of memory structures written but no code to do anything with them). Would you be interested in assisting with this? It would be extremely helpful. This will be a project to start early next year, I anticipate, and the first work will be resolving the large numbers of merge conflicts likely to be present, since this branch has not been updated since early 2018. I will need to work on the non-UI aspects of this, but help on the UI aspects (of such UI has has been implemented on this branch so far - I am not sure whether any has been integrated yet) would be appreciated.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 12, 2020, 05:58:42 PM
I am now looking at the first of the new branches, the halt detail branch. First of all, and most importantly, this is an excellent improvement with a great deal of good useful detail and a very clear layout. This is splendid work.

A few very small things: the graphs for "Around passenger demands" seem to overlap with the text in some cases, at least with the "modern" theme. These figures would be easier to read if the thousands were grouped as the numbers can get quite high in some cases.

In at least one instance (Christminster Eastgate on default.sve in Pak128.Britain-Ex), the success rate for commuting trips seems to be >100%, which suggests that there might be a bug in calculating this.

I have corrected a spelling error for the word "preferred". Translation texts will need producing for this branch, and likewise updated help texts.

The default width of this dialogue is often too narrow for all the text that needs to fit into it both horizontally and vertically, especially in the route tab; I am not sure whether this is reasonably easy to change or not. Perhaps the dialogue needs to be resized on opening a new tab to the maximum of the current size or the minimum size necessary to see all the details without scrolling?

Under "Direct routes from here", the names of goods, mail and passengers do not seem to be translated under hl_btn_by_stat... (the rest is truncated).

The text for "transshipment time" seems not to be quite aligned with the "Transfer time" text as though they were all centre aligned: unless there is some good reason for this, either left align or right align would probably be easier to read.

In any event, this is very good work - thank you again for this.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 12, 2020, 07:15:50 PM
Testing further, the accel-curve-chart-2 branch will not compile when merged with the current master.

The branch updating makeobj I have tested and this appears to work satisfactorily, with forestry industries at least: I have configured these in Pak128.Britain-Ex so that they only spawn in forests, and, testing with a large map, they do indeed only spawn in forests. I have therefore merged this into the master branch.
Title: Re: Incorporating changes from Standard
Post by: Matthew on December 12, 2020, 07:51:04 PM
Quote from: jamespetts on December 12, 2020, 04:18:56 PM
Thank you very much - this is very helpful. I have now incorporated the latest changes from the zstd branch into the master branch: the signal box  list and convoy details improvement were most helpful. I have modified the server's simuconf.tab to switch to zstd level 3 compression when it next restarts, so hopefully to-morrow we will see the effect of zstd on making the server more responsive on loading/saving.

Thank you very much for your excellent work on this to date - it is very much appreciated. The improvement of the GUI between the new version and the old is very great indeed.

Thank you very much to Prissi, Dwachs & the Standard team for the original changes, Ranran for integrating them into Extended, and James for the code review!:

(https://upload.wikimedia.org/wikipedia/commons/f/f8/A_bouquet_of_garden_flowers_2020-06-07_9401.jpg)

Quotewhen it next restarts, so hopefully to-morrow

B-B has not restarted at 0600 for several days now, so it seems unlikely that it will do so tomorrow....  ???

QuoteAs to the other branches, I will test those shortly and revert on this thread when I have done so, but I thought it more important to incorporate the bulk of the changes - especially zstd - into the master branch sooner rather than later now that it is working.

It seems sensible to pause after integrating so many changes since it's reasonable to expect some problems to crop up after such a big merge and more new code makes cause analysis harder. But you knew that already!

QuoteI should note, incidentally, that I have not yet set up 32-bit Windows cross-compile builds. Does anyone use the 32-bit Windows executable any more? It may be worthwhile discontinuing this as a separate build, as many games take more memory than this version is capable of handling in any event.

Roboron's statistics (https://forum.simutrans.com/index.php/topic,20405.msg191619.html#msg191619) for (Standard) Steam users are the most useful data for this decision:

(https://i.imgur.com/1c29WcC.png)

We can see that 32-bit Windows was not in the top 10 used OSes for Standard. I am aware from Discord & Reddit of one Brazilian player who uses the 32-bit Extended executable because he can't get the 64-bit to work on his system. However, I don't think he uses the Nightly Updater and he does have a 64-bit system, so I would not regard his situation as a reason to delay.

Going by these statistics and forum comments, a statically-linked Linux build seems more important than a 32-bit Windows build, since there are definitely users who are unable to play with the dynamically-linked Linux version. (Full disclosure: I am one those unable to use the new Linux version  :-[ , though I hope to build a new PC with Ubuntu 20.04 next week).
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 12, 2020, 10:46:51 PM
Thank you! I should also, incidentally, mark appreciation, not just of Ranran for all the excellent work in integrating and extending the Standard changes, but the Standard developers who coded them in the first place; they have very significantly improved the UI.

Those statistics are very interesting and useful and confirm that a 32-bit Windows build is not a priority; I shall probably discontinue provindg 32-bit Windows builds as a result of this.

In relation to the server restarting, I have modified the nightly script to try to deal with this problem: hitherto, it had use the nettool shutdown command, but this was prone to timing out if, for example, a player was connecting at the time that the command was sent, so I have reverted to using the external control script to stop the Simutrans-Extended instance to prevent this difficulty from arising.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 13, 2020, 12:14:40 AM
Quote from: jamespetts on December 12, 2020, 07:15:50 PMTesting further, the accel-curve-chart-2 branch will not compile when merged with the current master.
The cause was that the necessary header file include was removed by the merge.
It would be helpful if you could check it again.
Title: Re: Incorporating changes from Standard
Post by: Andarix on December 13, 2020, 06:01:14 AM
Quote from: Matthew on December 12, 2020, 07:51:04 PM
...
Roboron's statistics (https://forum.simutrans.com/index.php/topic,20405.msg191619.html#msg191619) for (Standard) Steam users are the most useful data for this decision:

(https://i.imgur.com/1c29WcC.png)

We can see that 32-bit Windows was not in the top 10 used OSes for Standard. I am aware from Discord & Reddit of one Brazilian player who uses the 32-bit Extended executable because he can't get the 64-bit to work on his system. However, I don't think he uses the Nightly Updater and he does have a 64-bit system, so I would not regard his situation as a reason to delay.

Going by these statistics and forum comments, a statically-linked Linux build seems more important than a 32-bit Windows build, since there are definitely users who are unable to play with the dynamically-linked Linux version. (Full disclosure: I am one those unable to use the new Linux version  :-[ , though I hope to build a new PC with Ubuntu 20.04 next week).

For something like this there have been player surveys in the wiki since 2008 (https://simutrans-germany.com/wiki/wiki/tiki-survey_stats.php).

2015 - 153 users
QuoteWhich operating system do you use?
32bit   31   20.67%   
64bit   119   79.33%   

2017 - 134 users
QuoteWhich operating system do you use?
32bit   13   9.70%   
64bit   121   90.30%

2019 - 58 users
QuoteWhich operating system do you use?
32bit   3   5.45%   
64bit   52   94.55%
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 13, 2020, 10:01:35 AM
Thank you and well done to Ranran, this is a mostly excellent patch. There are a number of problems which I will report over time, but I will start with the message window. The main problems are:
1. Transparency is not consistent between the top part of the window and the rest of the window.
2. messages are often repeated, including when scrolling the window.
3. coordinate messages cannot be right-clicked to jump
4. message colours are wrong. This includes the 'other players' category, where relevant messages are no longer in player colours.
(https://i.imgur.com/5z8oEsT.png)
(https://i.imgur.com/7GhqWHu.png)
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 13, 2020, 12:09:05 PM
Thank you for your feed back.

Quote1. Transparency is not consistent between the top part of the window and the rest of the window.
This may have been caused by code that differs from standard for more than a decade.

Quote2. messages are often repeated, including when scrolling the window.
This seems to reload the message when switching players. At least this behavior can be reproduced with standard, so it is from standard.

Quote3. coordinate messages cannot be right-clicked to jump
That feature was removed in the standard r9347.

Quote4. message colours are wrong. This includes the 'other players' category, where relevant messages are no longer in player colours.
I'm not sure about this. (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 13, 2020, 12:22:21 PM
Quote from: Ranran on December 13, 2020, 12:09:05 PMThis seems to reload the message when switching players. At least this behavior can be reproduced with standard, so it is from standard.
No, it repeats constantly without switching players at all.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 13, 2020, 12:43:45 PM
Apparently the right-click jump feature was successfully restored. Check the zstd branch.

EDIT:
Duplicate message - It may not be possible to reproduce with the standard that was my misunderstanding.

EDIT2:
I think the duplicate message bug has been fixed by r9500 and r9501. @prissi-Thank you for fixing it.
Title: Re: Incorporating changes from Standard
Post by: prissi on December 13, 2020, 12:50:40 PM
The right click to pos died rather accidently, I would say. That is in in r9500. And r9501 solved the double entries.

Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 13, 2020, 01:12:30 PM
Quote from: Ranran on December 13, 2020, 12:43:45 PM
Apparently the right-click jump feature was successfully restored. Check the zstd branch.

EDIT:
Duplicate message - It may not be possible to reproduce with the standard that was my misunderstanding.

Thank you for this. Unfortunately, I get compile errors when I merge this with the current master - there seem to be some conflicts somewhere with this.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 13, 2020, 01:22:40 PM
Quote from: Ranran on December 13, 2020, 12:14:40 AM
The cause was that the necessary header file include was removed by the merge.
It would be helpful if you could check it again.

Excellent, this now compiles, thank you.

This is interesting and helpful - thank you for this. One thing that I do notice, however, is that the f-v graph has the issue that I reported a while ago in relation to the acceleration curve chart, which is that the last entry is always 0kN both for tractive effort and rolling resistance. This does not make sense, especially for rolling resistance, which increases with speed exponentially. It also means that users have to click on the individual graph nodes to see the right-hand side graph value, which makes the chart harder to use than would be ideal.

Is there any way of truncating the last entry so as for it not to do this?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 13, 2020, 02:48:41 PM
Quote from: jamespetts on December 12, 2020, 05:58:42 PMI am now looking at the first of the new branches, the halt detail branch.
Thank you for your feedback.

QuoteA few very small things: the graphs for "Around passenger demands" seem to overlap with the text in some cases, at least with the "modern" theme. These figures would be easier to read if the thousands were grouped as the numbers can get quite high in some cases.
I didn't consider the font size as it was in the previous specification. It has been fixed.


QuoteIn at least one instance (Christminster Eastgate on default.sve in Pak128.Britain-Ex), the success rate for commuting trips seems to be >100%, which suggests that there might be a bug in calculating this.
Fixed so that the number of successes does not exceed the generate number in each building.


QuoteThe default width of this dialogue is often too narrow for all the text that needs to fit into it both horizontally and vertically, especially in the route tab; I am not sure whether this is reasonably easy to change or not. Perhaps the dialogue needs to be resized on opening a new tab to the maximum of the current size or the minimum size necessary to see all the details without scrolling?
(1) I forgot to mention the added three symbols. If the pakset has those symbols, some text will be replaced with the symbols, saving space.
(2) Two type of average speed is only displayed in debug mode. Therefore, the amount of text is smaller in release builds.

The symbol dat is here
https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/commit/0610efff425a588ca854ffbf49083947398378d6


QuoteUnder "Direct routes from here", the names of goods, mail and passengers do not seem to be translated under hl_btn_by_stat... (the rest is truncated).
The width of the two switching buttons is now 1.5 times larger. I also fixed the goods category name that couldn't translate.


QuoteThe text for "transshipment time" seems not to be quite aligned with the "Transfer time" text as though they were all centre aligned: unless there is some good reason for this, either left align or right align would probably be easier to read.
I think this has been fixed.


The translations added by this patch are:
(1)station detail dialog
Route_tab
lb_served_goods_and_classes
Fare class
%s mins. walking
%s mins. travelling
%s mins. waiting
Around passenger demands
Transportation status around this stop
hd_generated
Success rate
Visiting trip
Commuting trip
hd_mailing
hd_btn_by_station
hd_btn_by_category


(2)station dialog (freight list)
Carrying out
Undecided
Line to

Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 13, 2020, 03:03:00 PM
Quote from: jamespetts on December 13, 2020, 01:22:40 PMIs there any way of truncating the last entry so as for it not to do this?
I think it is difficult in current systems. For example, if the maximum speed is 409km / h, the graph will never take an integer in the middle unless an array of 409 is automatically generated.
That is, we need a system that creates arrays and graphs in a fluid manner.
Or set a sharp point such as 410, then move the axis slightly forward at the end, set the end point of the graph there, draw a line and truncate the rest.
This also requires modification of the code.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 13, 2020, 06:24:18 PM
The text below each of the convoys on the Line Management dialogue seems to be missing?  Makes it quite difficult to see which convoy is profitable or loaded.

(https://wlindley.com/simutrans/missing-text-new-dialog.jpg)Also not sure what I have to do so to that cl_btn_general gets translated...
Title: Re: Incorporating changes from Standard
Post by: Phystam on December 14, 2020, 04:29:29 AM
This is a small report and is not a bug. After incorporating standard features, the Extended revision has not been shown on the top but the Standard revision.
(https://media.discordapp.net/attachments/665986412641779712/787898271514361856/unknown.png)
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 14, 2020, 08:44:03 AM
Feel free to split this into a new thread if necessary. Petrol vehicles are no longer available at any time on any map from any type of depot, including road depots and aircraft hangars.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 14, 2020, 09:28:07 AM
Quote from: freddyhayward on December 14, 2020, 08:44:03 AMPetrol vehicles are no longer available at any time on any map from any type of depot, including road depots and aircraft hangars.
Thank you for your report. I think I've fixed it. Please confirm.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 14, 2020, 11:31:00 AM
Quote from: Ranran on December 14, 2020, 09:28:07 AM
Thank you for your report. I think I've fixed it. Please confirm.

Thank you - now incorporated.

Quote from: Phystam on December 14, 2020, 04:29:29 AM
This is a small report and is not a bug. After incorporating standard features, the Extended revision has not been shown on the top but the Standard revision.
(https://media.discordapp.net/attachments/665986412641779712/787898271514361856/unknown.png)

I am afraid that I cannot reproduce this on my local development version - can anyone else reproduce this?
Edit: I can reproduce this on the builds from the Bridgewater-Brunel server, but not locally.
Edit 2: This issue also appears in the server browser in-game, with something like an SVN revision number being used instead of the truncated Github hash. This occurs both on versions built locally and those built on the server.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 14, 2020, 11:32:21 AM
I cannot yet reproduce this, but I have had numerous segfaults when switching players since the merge, sometimes with the vehicle list open.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 14, 2020, 01:41:36 PM
With a1d2dc --Attempting to display the Change Players dialog gives:

simutrans-extended: gui/player_frame_t.cc:111: ki_kontroll_t::ki_kontroll_t(): Assertion `player_t::MAX_AI==4' failed.
Aborted (core dumped)

Stepping through players works normally.
Also, newly saved games go to the bottom of the Load list, and have a blank instead of "Pak128.Britain" where the pakset should be.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 14, 2020, 02:57:34 PM
The assertion failure seems to be from a spurious assertion which I have commented out, and doing so allows the player dialogue to be opened apparently without trouble.

The issue with the saved games list I can confirm.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 14, 2020, 05:04:09 PM
Confirm that d50bdb corrects assertion failure.  That was quick!

I do note that saving and reloading a game resets the player number.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 14, 2020, 05:20:59 PM
Quote from: wlindley on December 14, 2020, 05:04:09 PMI 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.
Title: Re: Incorporating changes from Standard
Post by: Matthew on December 14, 2020, 08:05:13 PM
Thank you for today's fixes, James.

Quote from: jamespetts on December 14, 2020, 11:31:00 AM
I am afraid that I cannot reproduce this on my local development version - can anyone else reproduce this?
Edit: I can reproduce this on the builds from the Bridgewater-Brunel server, but not locally.
Edit 2: This issue also appears in the server browser in-game, with something like an SVN revision number being used instead of the truncated Github hash. This occurs both on versions built locally and those built on the server.

I can reproduce this (https://forum.simutrans.com/index.php?topic=20592.msg193303;topicseen#msg193303). Notice that it also affects the listing website (http://list.extended.simutrans.org:8080/list?detail=bridgewater-brunel.me.uk:13353#bridgewater-brunel.me.uk:13353), which makes it more difficult to self-compile builds matching the Bridgewater-Brunel server.
Title: Re: Incorporating changes from Standard
Post by: Matthew on December 14, 2020, 08:37:06 PM
Quote from: Ranran on December 14, 2020, 09:28:07 AM
Thank you for your report. I think I've fixed it. Please confirm.

The fix did not work for me. I built from this branch (https://github.com/MatthewForrester/simutrans-extended/tree/community-version) at commit #5b76bff, which at the moment is identical to jamespetts/master, and compiled using MSYS2 on Windows 10. I ran the client (also in Windows) with an offline Bridgewater-Brunel save. I opened an aircraft hangar & an internal combustion bus depot and could not see petrol vehicles in either of them (unless I checked the 'Show all' box).
EDIT: The fix works in today's (2020-1215) nightly.

I was able to open the Players dialogue without a crash, so that bug does appear to be fixed.  :done: :thumbsup:

Double-post for new information and to make use of reply function.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 14, 2020, 11:28:22 PM
This is excellent work!  The sawmills always being in the forest is a little thing perhaps but enhances the realism. 

I did test setting "Location=River" for the early textile mills, ironworks and steel mills; that seems to work properly.  Better and better!
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 15, 2020, 11:25:15 PM
Quote from: wlindley on December 14, 2020, 11:28:22 PM
This is excellent work!  The sawmills always being in the forest is a little thing perhaps but enhances the realism. 

I did test setting "Location=River" for the early textile mills, ironworks and steel mills; that seems to work properly.  Better and better!

Excellent - thank you for testing! Are you able to push these changes to your github branch? This would seem to be a sensible thing to have in the pakset.

It would be lovely if somebody could make a water-mill; like a wind-mill, only with different graphics, needing to be near water, and having a greater capacity/throughput.
Title: Re: Incorporating changes from Standard
Post by: prissi on December 16, 2020, 12:55:09 AM
In pak64 standard, all powerplant have the river set, since they need cooling water ... Makes also shipping oil easier in some cases.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 16, 2020, 11:11:49 PM
Quote from: jamespetts on December 15, 2020, 11:25:15 PMAre you able to push these changes to your github branch?
I have put a possible pull-request (https://github.com/jamespetts/simutrans-pak128.britain/pull/102) with an early spinner's cottage (1750, pre-water-powered Mill) along with a water mill (not having drawn a water wheel, but without a smokestack).  References are provided for the technology and dates indicated.

Also added an intermediate steam-powered mill which requires a small amount of coal.  The existing mill without the coal requirement is retained for compatibility with existing saved games. 
I am not entirely happy with the "number of jobs" and the goods quantities but have not been able to pick .dat values which give lower jobs numbers, so please consider this all a preliminary attempt.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 17, 2020, 10:50:18 PM
Thank you for this - now incorporated. That is lovely.

I notice that you have some other branches from some time ago relating to a leather and steel industry; I cannot recall whether these are awaiting my review or more work from you; can you remind me?

Thank you again.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 17, 2020, 11:22:07 PM
Ranran - thank you very much for your work on the improved halt detail dialogue. I have just reviewed this, added the translation texts and incorporated it.

This is a great improvement on what went before.
Edit: As to the acceleration curve chart, if it is an unreasonable amount of work to truncate the graphs so that they do not always end in 0km/h and 0kN, then it is better to have them like this than not.

Can I ask whether this is ready for a final review? If so, I should be grateful if you could list all the translation texts for this branch.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 18, 2020, 12:56:09 AM
Quote from: jamespetts on December 17, 2020, 11:22:07 PMCan I ask whether this is ready for a final review?
In a nutshell, it still has problems. (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: Matthew on December 18, 2020, 03:53:01 AM
Would it perhaps be sensible to pause integrating branches with new features until we understand the current stability bugs?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 18, 2020, 09:27:06 AM
Quote from: Ranran on December 13, 2020, 02:48:41 PM(1) I forgot to mention the added three symbols. If the pakset has those symbols, some text will be replaced with the symbols, saving space.
(2) Two type of average speed is only displayed in debug mode. Therefore, the amount of text is smaller in release builds.

The symbol dat is here
As mentioned above, pakset needs to include a new symbol to complete the merge of the halt-detail-plus-v2 branch.
It's in the newlists branch (https://github.com/Ranran-the-JuicyPork/simutrans-pak128.britain/tree/newlists).

I found some bugs in the halt detail dialog and fixed them. Check pull request #313.

I'm aware of a scrollbar issue, but I haven't fixed it yet.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 18, 2020, 06:49:02 PM
Thank you - I have now incorporated those fixes.

As to the newlists branch, I believe that I have already merged this, as I do not see any option for merging this when I look at my Git GUI. If you believe that I have not merged this, it would help to issue a pull request so that I can try to merge this using an alternative method. Thank you.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 18, 2020, 10:31:48 PM
Quote from: jamespetts on December 18, 2020, 06:49:02 PMAs to the newlists branch, I believe that I have already merged this, as I do not see any option for merging this when I look at my Git GUI.
(https://i.imgur.com/1jMzTuk.png)
Symbols should look like this on the station detail dialog if merged correctly, but pak128.britain-ex still doesn't have those symbols.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 18, 2020, 11:58:45 PM
Quote from: Ranran on December 18, 2020, 10:31:48 PM
(https://i.imgur.com/1jMzTuk.png)
Symbols should look like this on the station detail dialog if merged correctly, but pak128.britain-ex still doesn't have those symbols.

Can you issue a pull request since I seem to have trouble merging this in the usual way? Thank you.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 19, 2020, 12:10:09 AM
Quote from: jamespetts on December 18, 2020, 11:58:45 PMCan you issue a pull request since I seem to have trouble merging this in the usual way?
Already requested.
https://github.com/jamespetts/simutrans-pak128.britain/pull/104
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 19, 2020, 12:41:46 AM
Thank you - now incorporated.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 19, 2020, 11:46:24 AM
Thank you for the station info improvements, I have some feedback:
1. it should be group by destination/category, not sort.
2. In future, there could be sort by speed, distance (current default), travel time, and frequency.
3. The list cannot be scrolled. I believe you said you were aware of this.
4. The 'line' and 'line to' sort modes should sort its results, either by amount or name.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 19, 2020, 11:48:49 AM
Thank you - I have amended the text to implement the first of these suggestions.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 19, 2020, 02:48:05 PM
Quote from: jamespetts on December 17, 2020, 11:22:07 PMAs to the acceleration curve chart, if it is an unreasonable amount of work to truncate the graphs so that they do not always end in 0km/h and 0kN, then it is better to have them like this than not.
As I explained a few months ago, this has a complex problem.

In the real world, the theoretical value is drawn from the calculation formula. But in the patch the numbers use in-game calculations.

In this example, the maximum speed is 8km / h and the chart is drawn up to 8km / h.
(https://i.imgur.com/hSAvw4K.png)
The problem is the value of max speed, but when ask the function for the acceleration force at max speed, 0 is returned. Because otherwise convoy will accelerate above the top speed.
The same is true for resistance. If the acceleration force is 0, the resistance force is not 0 or the balance cannot be achieved.
We have to change it so that you can get the theoretical value for the chart. But the code was written by Bernd Gabriel and is definitely a black box for me.


The second problem is the drawing of graphs. All the charts that exist in simutrans today have a fixed number of x-axis in advance. In this case it is 24. Draw a graph using up to 24 arrays. Making this a flexible x-axis number instead of a fixed number is a new system that I can't do with my skills. The maximum speed can change each time player change the configuration of the convoy in the depot, and it has to change the number of arrays and redraw each time.
And as explained before, if the maximum velocity is a prime number, the x-axis will not be all integers except the both ends.
Therefore, the x-axis is drawn by the integer span, but since the number of arrays is fixed, there are cases where it does not fit neatly like this.
(https://i.imgur.com/9mEjWf5.png)

The top speed is 56km / h, but the existing x-axis is 54 and 57.

The only way to draw this correctly is to flexibly extend the array as explained or create a system that draws a line in the middle of the axis.
Thus I think it would be difficult to achieve it.

(https://i.imgur.com/pk3Zqhz.gif)
You can easily check the maximum value by turning the graph on and off.


QuoteCan I ask whether this is ready for a final review? If so, I should be grateful if you could list all the translation texts for this branch.
It's ready to be reviewed.

cd_physics_tab
v-t graph
f-v graph
Acceleration(actual)
Acceleration(full load)
Acceleration(empty)
Running resistance
time_to_top_speed:
distance_required_to_top_speed:
helptxt_starting_acceleration
helptxt_actual_acceleration
helptxt_v-t_graph
helptxt_f-v_graph
Acceleration graph when nothing is loaded on the convoy
helptxt_vt_graph_full_load
helptxt_fv_graph_tractive_effort
Total force acting in the opposite direction of the convoy
helptxt_acceleration_time
helptxt_acceleration_distance
Unreachable
%.2f sec
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 19, 2020, 06:27:25 PM
May I suggest that a basic solution would be simply to truncate the graph at 1km/h less than the top speed? One does not look at this graph to find out the vehicle's top speed, and the datum in the graph corresponding with the top speed is incorrect and not of any use to anyone, so truncating it at 1km/h below the top speed, where the data are still useful, would seem to be a better way of dealing with this. Truncating 1km/h below the top speed would then avoid the problem with there being a fixed number of axes.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 20, 2020, 03:20:21 AM
Quote from: jamespetts on December 19, 2020, 06:27:25 PMMay I suggest that a basic solution would be simply to truncate the graph at 1km/h less than the top speed? One does not look at this graph to find out the vehicle's top speed, and the datum in the graph corresponding with the top speed is incorrect and not of any use to anyone, so truncating it at 1km/h below the top speed, where the data are still useful, would seem to be a better way of dealing with this. Truncating 1km/h below the top speed would then avoid the problem with there being a fixed number of axes.
I changed it that way. However, it is not 1km/h but one before the x-axis span.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 20, 2020, 06:31:05 AM
Due to mass merging from standard, the save function of the dialog that was opened when saving by manual save has disappeared.
The dialog that was opened at the time of saving is restored only in the case of automatic save.
However, as far as I can confirm, there seems to be no function to restore the opened dialog when manually saving in standard.
Was this an extended-specific feature?

Or do you know what part of the code to look for?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 20, 2020, 11:41:47 AM
Thank you for that: the graph is now much more readable with the truncation.

However, I have noticed one issue: with the "modern" theme (at least), opening the graph tab for the first time leaves part of the buttons cut off:

(http://bridgewater-brunel.me.uk/screenshots/accel-chart-when-opened.png)

As to saving the dialogue positions, this is a Standard feature; it had not been working fully in Extended as this was implemented in Standard after the divergence with Extended, but there is no Extended specific code here. I cannot now remember where in the code that this is located.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 20, 2020, 12:13:06 PM
Quote from: jamespetts on December 20, 2020, 11:41:47 AMHowever, I have noticed one issue: with the "modern" theme (at least), opening the graph tab for the first time leaves part of the buttons cut off:
This was simply because the initial dialog size wasn't set to anything. In other words, it was opened with the default size common to all dialogs.
I have set the initial size to the size that the chart will display properly.

QuoteAs to saving the dialogue positions, this is a Standard feature; it had not been working fully in Extended as this was implemented in Standard after the divergence with Extended, but there is no Extended specific code here. I cannot now remember where in the code that this is located.
Does anyone know if standard had ever restored a dialog position with a manual save? I downloaded and tried 112 and 120.1.2 but neither of them had that feature. Of course not in 122.0.
However, the function existed in extended before recent mass merging.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 20, 2020, 12:37:28 PM
Excellent - that has fixed the issue, thank you. I have now added English translation texts to this. Can I check whether this is ready for merging or whether you believe that there is further work to be done?

I was not aware that manual and automatic saving differed in Standard for dialogue position restoration. I am not sure whether this is intentional or not, and I do not know this part of the code very well at all.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 20, 2020, 12:58:34 PM
Quote from: jamespetts on December 20, 2020, 12:37:28 PMExcellent - that has fixed the issue, thank you. I have now added English translation texts to this. Can I check whether this is ready for merging or whether you believe that there is further work to be done?
There are currently no plans to add features related to physical charts. Therefore, it is a break.
I think it's ready to be merged. If there is no problem in operation.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 20, 2020, 01:04:05 PM
I recently segfaulted after clicking the 'details' button on a stop. No reproduction yet.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 20, 2020, 01:11:48 PM
Quote from: Ranran on December 20, 2020, 12:58:34 PM
There are currently no plans to add features related to physical charts. Therefore, it is a break.
I think it's ready to be merged. If there is no problem in operation.


Splendid - now incorporated. Thank you.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 20, 2020, 02:34:29 PM
Furhter work on incorporation, aside from critical bug fixes, will now need to await the work on the vehicle-management-new branch of Github, discussed further here (https://forum.simutrans.com/index.php/topic,17852.msg193440.html#msg193440). The priority now is merging the work that I undertook in 2018 towards adding new balance critical features relating to vehicles/convoys (especially recombination, maintenance and degradation), which is a large but important task.

Merging this with the changed state of the master branch and making it work will be a very large task, so it is necessary that all other work on the master branch be paused until this is completed (save for critical bug fixes), or else it will make it extremely difficult to undertake the merging work.

One of the issues with running the code from the vehicle-management-new branch at present is that, on starting a pakset with no demo.sve, the game crashes on line 452 of simmenu.cc because tool is null. This looks to be a UI issue, although it is not immediately clear whether this relates to any of the UI changes discussed in this thread.

It would be helpful if those who have worked on the merging and UI work discussed in this thread could check over the new branch to see that their work has been correctly merged.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 23, 2020, 05:24:56 AM
I recently had a segfault after clicking 'very low' in the direct routes tab. this was a few minutes after adding a new service to that stop.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on December 24, 2020, 12:57:47 PM
I recently had another crash (floating point exception) after clicking the force tab in the performance tab in the convoy detail window for a skiff wherry.
Title: Re: Incorporating changes from Standard
Post by: wlindley on December 24, 2020, 09:06:38 PM
Quote from: jamespetts on December 17, 2020, 10:50:18 PM
some other branches from some time ago

I have a possible apothecary, blacksmith, and cooper (https://github.com/jamespetts/simutrans-pak128.britain/pull/106) pull request.  The other component (a new Good, "hide" with a modification to the slaughter-house and a small resulting chain) I will leave for later.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 24, 2020, 10:04:23 PM
Quote from: wlindley on December 24, 2020, 09:06:38 PM
I have a possible apothecary, blacksmith, and cooper (https://github.com/jamespetts/simutrans-pak128.britain/pull/106) pull request.  The other component (a new Good, "hide" with a modification to the slaughter-house and a small resulting chain) I will leave for later.

Excellent - now incorporated. I wonder, however, whether, for the blacksmith, it would be better to replace the existing city building called a "Smithy"? You can then use the graphics from that building rather than the cooper with different coloured signs. The original "smithy" itself can be deleted and another industrial city building specified in its stead in simuconf.tab.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 25, 2020, 09:14:11 AM
Quote from: freddyhayward on December 24, 2020, 12:57:47 PMI recently had another crash (floating point exception) after clicking the force tab in the performance tab in the convoy detail window for a skiff wherry.
Thank you for your report. I believe I've fixed it.
It was due to the fact that we decided to cut off the display below the top speed, which could cause the graph element to be 0 if the top speed was too low.
In other words, if the maximum speed is 1km/h the display is cut off before 1km/h, it tries to display 0-0km/h and craches.

In order to avoid a crash, it has been changed to display up to the maximum speed when the above conditions are met. At maximum speed the value will be 0.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 25, 2020, 01:54:45 PM
Splendid, thank you; now incorporated.

Merry Christmas!
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on December 28, 2020, 12:52:16 PM
I compared the diffs with the standard code and found that the part that should have been SAVEGAME_VER_NR is now SERVER_SAVEGAME_VER_NR. (save statement for offline game)
This has been wrong for at least a few years now, but it's possible that integration from the standard has brought errors to the surface.

Another thing I noticed with the save error is that _cached_exp.xml is currently not updated correctly.
But unfortunately I'm not familiar with these codes.


By the way, for some reason this board doesn't seem to have a like button.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 28, 2020, 01:19:45 PM
Quote from: Ranran on December 28, 2020, 12:52:16 PM
I compared the diffs with the standard code and found that the part that should have been SAVEGAME_VER_NR is now SERVER_SAVEGAME_VER_NR. (save statement for offline game)
This has been wrong for at least a few years now, but it's possible that integration from the standard has brought errors to the surface.

Another thing I noticed with the save error is that _cached_exp.xml is currently not updated correctly.
But unfortunately I'm not familiar with these codes.

Thank you for looking into that - that is helpful. I will have to look into that when I get back home.

Quote
By the way, for some reason this board doesn't seem to have a like button.


I have now enabled this.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 14, 2021, 10:56:03 AM
I've requested a pull request for some small fix commits from recent standards. #341
I think it's a small fix that doesn't affect the game or system very much.

EDIT:
These commits are included in the building info patch because the building info patch contained an error that required this fix to be included.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 20, 2021, 11:01:00 PM
I've requested a pull request to incorporating changes to the standard's edit ui update. Check pull request #347.
I made changes that optimize for extended. In extended, jobs and visitor demands were not displayed at present, so I added those. And fixed some values being incorrect.

I would like to take this opportunity to thank Leartin for updating the edit UI.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 20, 2021, 11:13:53 PM
Thank you - now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 01, 2021, 12:59:08 PM
I pullrequested some bugfixes in addition to some recent updates from the standard. Check pull request #354.

Extended's bugs fixes:
--The GUI theme settings are not loaded correctly
--The number of tiles displayed in the tooltip when building a bridge is not the distance
--The unit of the "margin" chart in the finance dialog is not the percentage display.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 02, 2021, 07:25:02 PM
Thank you - now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 08, 2021, 11:21:25 AM
standard has changed the function to get the version. I made an extended version of it. This is because it was more convenient to have it when incorporating r9576.

What used to be code like this

if((file->get_extended_version() == 14 && file->get_extended_revision() >= 32) || file->get_extended_version() >= 15) {


can be written as:

if( file->is_version_ex_atleast(14, 32) ) {


Similar functions include is_version_ex_less and is_version_ex_equal.

EDIT:
It was omitted because it seems that it is no longer necessary to pass the welt of the second argument of get_obsolete_year_month, is_obsolete and has_available_upgrade due to the incorporating effect from standard.
Title: Re: Incorporating changes from Standard
Post by: Roboron on February 12, 2021, 06:36:40 PM
I opened a PR with some MacOS specific changes (https://github.com/jamespetts/simutrans-extended/pull/357) from Standard, mainly for distribution (everything in place to make a simutrans-extended.app bundle running ./distribute.sh).

It also includes the fix to prevent MacOS crashing due to music playback (https://forum.simutrans.com/index.php/topic,19439). However, the very same fix that works for Standard doesn't seem to work on Extended: on my tests, it keeps crashing. I don't have the slightest idea why it differs, but I'm also not willing to invest more time on fixing it.

But don't worry, after this is merged I'll work on porting the new music backend to Extended. This will make MacOS and Linux sing again, hopefully without crashes  :)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 13, 2021, 11:28:09 AM
Thank you very much for this: I have now incorporated Roboron's and Ranran's changes. Apologies for the delay: my home internet was down until yesterday, so I was not able to connect with my main computer.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on February 13, 2021, 12:16:12 PM
Quote from: jamespetts on February 13, 2021, 11:28:09 AM
Thank you very much for this: I have now incorporated Roboron's and Ranran's changes. Apologies for the delay: my home internet was down until yesterday, so I was not able to connect with my main computer.
I'm confident that ranran's changes will break private car routes on all saves due to changing all occurrences of NSEW to NESW for directions. This will fix itself after one or two refresh cycles but will cause significant disruption in the meantime.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 13, 2021, 01:44:16 PM
Quote from: freddyhayward on February 13, 2021, 12:16:12 PM
I'm confident that ranran's changes will break private car routes on all saves due to changing all occurrences of NSEW to NESW for directions. This will fix itself after one or two refresh cycles but will cause significant disruption in the meantime.

I thought that I saw a commit somewhere correcting for this, or am I imagining things...?
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on February 13, 2021, 08:07:40 PM
Quote from: jamespetts on February 13, 2021, 01:44:16 PMI thought that I saw a commit somewhere correcting for this, or am I imagining things...?
You might be remembering that I suggested changes at some point - though this may have been a misuse of that feature if it's supposed to contain the actual changes rather than just a description of them.
edit: this has now been fixed.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 14, 2021, 11:33:04 AM
Fix incorporated yesterday - thank you.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on February 18, 2021, 07:22:24 AM
I have made another pull request that fixes erroneous next signal/junction information for signals here: https://github.com/jamespetts/simutrans-extended/pull/360
Title: Re: Incorporating changes from Standard
Post by: Roboron on February 23, 2021, 07:26:04 PM
Quote from: Roboron on February 12, 2021, 06:36:40 PMafter this is merged I'll work on porting the new music backend to Extended

Pull Request opened (https://github.com/jamespetts/simutrans-extended/pull/361).

Some notes about this if you have not been following the thread:
(https://i.imgur.com/krnIvQd.png)

*Note that FluidSynth implementation for Simutrans on Linux needs SDL2 driver, which is available from fluidsynth 2.1.0 (december 2019). If your distribution is an old LTS (pre 2020), it won't work. Mac & Windows use their own drivers.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 02, 2021, 11:19:27 AM
Thank you for this and apologies for the delay. Github indicates that this causes an error when building nettool:


ht (C) Microsoft Corporation. All rights reserved.

Building the projects in this solution one at a time. To enable parallel build, please add the "-m" switch.
Build started 2/23/2021 7:06:10 PM.
Project "D:\a\simutrans-extended\simutrans-extended\build\Simutrans-Extended.sln" on node 1 (nettool-extended target(s)).
ValidateSolutionConfiguration:
  Building solution configuration "Release|x64".
ValidateProjects:
  The project "INSTALL" is not selected for building in solution configuration "Release|x64".
  The project "PACKAGE" is not selected for building in solution configuration "Release|x64".
Project "D:\a\simutrans-extended\simutrans-extended\build\Simutrans-Extended.sln" (1) is building "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (2) on node 1 (default targets).
Project "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (2) is building "D:\a\simutrans-extended\simutrans-extended\build\ZERO_CHECK.vcxproj" (3) on node 1 (default targets).
PrepareForBuild:
  Creating directory "x64\Release\ZERO_CHECK\".
  Creating directory "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\".
InitializeBuildStatus:
  Creating "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
CustomBuild:
  Checking Build System
FinalizeBuildStatus:
  Deleting file "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\unsuccessfulbuild".
  Touching "x64\Release\ZERO_CHECK\ZERO_CHECK.tlog\ZERO_CHECK.lastbuildstate".
Done Building Project "D:\a\simutrans-extended\simutrans-extended\build\ZERO_CHECK.vcxproj" (default targets).
Project "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (2) is building "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj" (4) on node 1 (default targets).
PrepareForBuild:
  Creating directory "nettool-extended.dir\Release\".
  Creating directory "D:\a\simutrans-extended\simutrans-extended\build\simutrans\Release\".
  Creating directory "nettool-extended.dir\Release\nettool-extended.tlog\".
InitializeBuildStatus:
  Creating "nettool-extended.dir\Release\nettool-extended.tlog\unsuccessfulbuild" because "AlwaysCreate" was specified.
CustomBuild:
  Building Custom Rule D:/a/simutrans-extended/simutrans-extended/nettools/CMakeLists.txt
ClCompile:
  C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.28.29333\bin\HostX64\x64\CL.exe /c /nologo /W3 /WX- /diagnostics:column /O2 /Ob2 /D WIN32 /D _WINDOWS /D NDEBUG /D NETTOOL=1 /D COLOUR_DEPTH=0 /D MSG_LEVEL=0 /D _CRT_SECURE_NO_WARNINGS /D _SCL_SECURE_NO_WARNINGS /D NOMINMAX /D WIN32_LEAN_AND_MEAN /D "CMAKE_INTDIR=\"Release\"" /D _MBCS /Gm- /EHsc /MD /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"nettool-extended.dir\Release\\" /Fd"nettool-extended.dir\Release\vc142.pdb" /Gd /TP /wd4244 /wd4267 /wd4068 /errorReport:queue "D:\a\simutrans-extended\simutrans-extended\nettools\nettool.cc" "D:\a\simutrans-extended\simutrans-extended\dataobj\freelist.cc" "D:\a\simutrans-extended\simutrans-extended\network\memory_rw.cc" "D:\a\simutrans-extended\simutrans-extended\network\network_address.cc" "D:\a\simutrans-extended\simutrans-extended\network\network_cmd.cc" "D:\a\simutrans-extended\simutrans-extended\network\network_packet.cc" "D:\a\simutrans-extended\simutrans-extended\network\network_socket_list.cc" "D:\a\simutrans-extended\simutrans-extended\network\pwd_hash.cc" "D:\a\simutrans-extended\simutrans-extended\simdebug.cc" "D:\a\simutrans-extended\simutrans-extended\simmem.cc" "D:\a\simutrans-extended\simutrans-extended\utils\simstring.cc" "D:\a\simutrans-extended\simutrans-extended\utils\fetchopt.cc" "D:\a\simutrans-extended\simutrans-extended\utils\sha1.cc" "D:\a\simutrans-extended\simutrans-extended\utils\log.cc" "D:\a\simutrans-extended\simutrans-extended\network\network.cc" "D:\a\simutrans-extended\simutrans-extended\network\network_file_transfer.cc"
  nettool.cc
  freelist.cc
  memory_rw.cc
  network_address.cc
  network_cmd.cc
D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\basetsd.h(433): message : see previous definition of 'MAXUINT32' [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  network_packet.cc
  network_socket_list.cc
D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\basetsd.h(433): message : see previous definition of 'MAXUINT32' [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  pwd_hash.cc
  simdebug.cc
  simmem.cc
  simstring.cc
  fetchopt.cc
  sha1.cc
  log.cc
D:\a\simutrans-extended\simutrans-extended\utils\../sys/simsys.h(13,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  network.cc
D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\shared\basetsd.h(433): message : see previous definition of 'MAXUINT32' [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  network_file_transfer.cc
D:\a\simutrans-extended\simutrans-extended\network\../sys/simsys.h(13,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  Generating Code...
Done Building Project "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj" (default targets) -- FAILED.
Done Building Project "D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (default targets) -- FAILED.
Done Building Project "D:\a\simutrans-extended\simutrans-extended\build\Simutrans-Extended.sln" (nettool-extended target(s)) -- FAILED.

Build FAILED.

"D:\a\simutrans-extended\simutrans-extended\build\Simutrans-Extended.sln" (nettool-extended target) (1) ->
"D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (default target) (2) ->
"D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj" (default target) (4) ->
(ClCompile target) ->
  D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\simunits.h(153,1): warning C4005: 'MAXUINT32': macro redefinition [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1473,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\network\../simworld.h(1478,1): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]


"D:\a\simutrans-extended\simutrans-extended\build\Simutrans-Extended.sln" (nettool-extended target) (1) ->
"D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj.metaproj" (default target) (2) ->
"D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj" (default target) (4) ->
(ClCompile target) ->
  D:\a\simutrans-extended\simutrans-extended\utils\../sys/simsys.h(13,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]
  D:\a\simutrans-extended\simutrans-extended\network\../sys/simsys.h(13,10): fatal error C1083: Cannot open include file: 'zlib.h': No such file or directory [D:\a\simutrans-extended\simutrans-extended\build\nettools\nettool-extended.vcxproj]

    9 Warning(s)
    2 Error(s)

Time Elapsed 00:00:20.50
Error: Process completed with exit code 1.


Can you confirm whether you can build nettool successfully with this code in place?
Title: Re: Incorporating changes from Standard
Post by: Roboron on April 02, 2021, 09:16:24 PM
Looking at the Github Actions history, the Windows Nettool (MSVC) build has been failing for some months, it doesn't seem related to any recent change.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 03, 2021, 01:16:07 PM
Quote from: Roboron on April 02, 2021, 09:16:24 PM
Looking at the Github Actions history, the Windows Nettool (MSVC) build has been failing for some months, it doesn't seem related to any recent change.

Ahh, yes, you are quite right: this affects only the Visual Studio build. Now incorporated - thank you.
Title: Re: Incorporating changes from Standard
Post by: ceeac on April 03, 2021, 04:08:49 PM
Quote from: Roboron on April 02, 2021, 09:16:24 PMhe Windows Nettool (MSVC) build has been failing for some months
I have opened a Pull Request (#368) which fixes the issue.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 03, 2021, 04:14:24 PM
Quote from: ceeac on April 03, 2021, 04:08:49 PM
I have opened a Pull Request (#368) which fixes the issue.

Excellent, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on May 07, 2021, 12:07:49 PM
Quote from: freddyhayward on December 13, 2020, 10:01:35 AM1. Transparency is not consistent between the top part of the window and the rest of the window.

case windowskin:
//display_img_stretch( gui_theme_t::windowback, rect);
break;

This can be fixed by commenting out this part of the gui_scrolled_list.cc, but it's not the case with standard so I'm not sure what the difference is.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 12, 2021, 04:20:51 PM
Pull request #393 is a change centered on incorporating changes from the standard.
See each commit message for details.
Some commits up to r9860. Unfortunately, major changes that are difficult for me have been skipped.

Toolbar position can be selected with display setting
https://forum.simutrans.com/index.php/topic,11936.0.html

Newly designed sort order button
https://forum.simutrans.com/index.php/topic,20886.0.html

Adjustments that look good even on dark themes
https://forum.simutrans.com/index.php/topic,20813.0.html


gui_titlebar_player_color_background_brightness = 2
gui_color_text_weak = #999999
pressed_button_sinks = 1
gui_color_indicator_border_top_left = #CCCCCC
gui_color_indicator_border_bottom_right = #666666

- The brightness of the title bar can be set individually using gui_titlebar_player_color_background_brightness.
- Since you cannot specify the font thickness in simutrans, you can specify the font color that is used for the purpose of making it less noticeable than normal text.
- It is possible to set whether the pressed button sinks.
- You can specify the frame color of the indicator.


And, fine adjustments and fixes to the Extended-specific GUI
and Japanese translation proofreading.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 12, 2021, 08:42:48 PM
Splendid, thank you for that! The new sort order button is good.

I have put this on the merge-from-standard-r9860 branch for now to allow for some testing. Aside from the new sort button, what in particular do you think needs testing before this can be deployed?

I am minded to put this on the master branch in a few days' time if such testing as people have been able to do in that time has not found any significant problems.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 12, 2021, 10:28:35 PM
Quote from: jamespetts on June 12, 2021, 08:42:48 PMAside from the new sort button, what in particular do you think needs testing before this can be deployed?
It seems that a general playtest is needed due to the many minor changes. I've done some simple test play so far, but there may be issues that I haven't found.
The changes that are easy to notice:
The revision number is incremented due to changes in the environment variables and the save of the opened dialog.
The open state of the list dialogs are now saved and reloaded.
A text input filter has been added to some list dialogs.
You can change the display position of the menu bar from the display setting dialog.
These changes from standard are described in the simutrans/history.txt.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 13, 2021, 01:18:14 PM
Thank you for this.

Unfortunately, the new revision number clashes with the new revision number for the amber traffic lights phase feature recently added by Phystam and just incorporated into the master branch. Would you be able to re-increment the version in this branch to address this clash so that we can test with this?

I should be most grateful.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 13, 2021, 03:19:14 PM
Quote from: jamespetts on June 13, 2021, 01:18:14 PMUnfortunately, the new revision number clashes with the new revision number for the amber traffic lights phase feature recently added by Phystam and just incorporated into the master branch. Would you be able to re-increment the version in this branch to address this clash so that we can test with this?
I think I have fixed it.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 20, 2021, 12:23:11 PM
Quote from: Ranran on June 13, 2021, 03:19:14 PM
I think I have fixed it.

Excellent, thank you for that. I have incorporated your latest set of changes in the merge-from-standard-june-2021 branch in my Github repository.

I have done a little testing of this, but it would be helpful if others could compile this and test it over the next week or so. If I have had no reported issues, and have found none myself, by next week, I plan to merge this into the master branch.

Thank you for your work on this.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 26, 2021, 12:47:27 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 29, 2021, 10:38:36 AM
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  :done:
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  :done:
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  :done:
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  :done:
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commits/std-r9757
Standard code changes and GUI minor modifications.

Pull request #411  :done:
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  :done:
std-r9808-
The list dialog is saved. A text search is added to some list dialogs.

Pull request #414   :done:
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.
Title: Re: Incorporating changes from Standard
Post by: freddyhayward on July 01, 2021, 06:23:36 AM
Quote from: jamespetts on June 26, 2021, 12:47:27 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on July 12, 2021, 09:48:16 AM
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on July 18, 2021, 10:56:49 AM
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 (https://forum.simutrans.com/index.php/topic,20994.0.html).
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 03, 2021, 10:51:48 PM
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... (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 03, 2021, 11:15:35 PM
Quote from: Ranran on August 03, 2021, 10:51:48 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 03, 2021, 11:36:49 PM
Quote from: jamespetts on August 03, 2021, 11:15:35 PMCan 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 (https://forum.simutrans.com/index.php/topic,17852.140.html),
from there earlier this year there is my branch (https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/graphical-schedule-UI) 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 04, 2021, 10:10:06 AM
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?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 04, 2021, 10:48:22 PM
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 06, 2021, 11:16:49 AM
Quote from: Ranran on August 04, 2021, 10:48:22 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 06, 2021, 07:44:18 PM
Quote from: jamespetts on August 06, 2021, 11:16:49 AMI 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 08, 2021, 09:57:56 AM
Quote from: Ranran on August 06, 2021, 07:44:18 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 08, 2021, 05:30:03 PM
Quote from: jamespetts on August 08, 2021, 09:57:56 AMMay 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 08, 2021, 08:50:27 PM
Quote from: Ranran on August 08, 2021, 05:30:03 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 09, 2021, 11:11:01 PM
Quote from: jamespetts on August 08, 2021, 08:50:27 PMWould 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
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 11, 2021, 06:57:25 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on August 18, 2021, 11:35:16 AM
I couldn't playtest because I was busy watching Evangelion last weekend, but I think this bug (https://forum.simutrans.com/index.php/topic,21047.0.html) and this bug (https://forum.simutrans.com/index.php/topic,21053.0.html) have been fixed. (´・ω・`)
Check pull request #428.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on August 21, 2021, 10:05:14 AM
Quote from: Ranran on August 18, 2021, 11:35:16 AM
I couldn't playtest because I was busy watching Evangelion last weekend, but I think this bug (https://forum.simutrans.com/index.php/topic,21047.0.html) and this bug (https://forum.simutrans.com/index.php/topic,21053.0.html) have been fixed. (´・ω・`)
Check pull request #428.



Now incorporated - thank you.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 06, 2021, 02:54:43 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 07, 2021, 03:40:46 PM
Pull request #458 is a set of small fixes up to r10164.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 16, 2021, 11:35:50 PM
Excellent, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 24, 2021, 04:21:42 AM
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on December 23, 2021, 03:01:08 PM
Excellent, thank you: now incorporated.

My apologies for having taken so long to get around to this: I have been very busy/preoccupied lately.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 15, 2022, 09:57:03 PM
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. (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 16, 2022, 01:40:40 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 16, 2022, 02:53:31 PM
Quote from: jamespetts on January 16, 2022, 01:40:40 PMUnfortunately, 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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 16, 2022, 03:39:11 PM
Quote from: Ranran on January 16, 2022, 02:53:31 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 26, 2022, 12:28:39 PM
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.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 29, 2022, 03:55:58 PM
Splendid, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 01, 2022, 12:27:13 PM
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.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 03, 2022, 08:28:33 AM
Quote from: wlindley on December 14, 2020, 05:04:09 PMI do note that saving and reloading a game resets the player number.
Quote from: Ranran on December 14, 2020, 05:20:59 PMThis 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. (´・ω・`)
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 16, 2022, 07:18:11 PM
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
Quote
could not find any instance of Visual Studio.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 16, 2022, 10:07:48 PM
Quote from: ceeac on February 16, 2022, 07:18:11 PMWindows 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.
Title: Re: Incorporating changes from Standard
Post by: prissi on February 17, 2022, 02:28:41 AM
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.
Title: Re: Incorporating changes from Standard
Post by: Roboron on February 17, 2022, 11:13:16 AM
Changing windows-latest to windows-2019 in the CI fix it. For some reason it is not able to find MSVC in windows-2022.
Title: Re: Incorporating changes from Standard
Post by: Andarix on February 17, 2022, 11:24:23 AM
Quote from: Roboron on February 17, 2022, 11:13:16 AM
Changing windows-latest to windows-2019 in the CI fix it. For some reason it is not able to find MSVC in windows-2022.

Windows Server 2022 (I think VS 2022 because it was also announced) has a newer version of MSVC than Windows Server 2019 (VS 2015). And so the paths should differ.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 18, 2022, 12:19:55 AM
Quote from: ceeac on February 16, 2022, 07:18:11 PM
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

Thank you for your work on this (and to the others, too).

Before I incorporate this, can I check what Heavy Mode is in this context?
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 18, 2022, 02:44:55 PM
This makes debugging easier and optionally produces two save files at the exact sync_step the desync occurred, at the cost of severely reduced performance.
To enable Heavy Mode, both client and server must be started with the -heavy 1 command line flag.
For details, see the original thread here:
https://forum.simutrans.com/index.php/topic,21211
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 18, 2022, 11:17:12 PM
I have tried to merge this, but I get a "missing endif" error on compiling referring to line 777 of the makefile. Does this assume that I have merged prior pull requests from Ranran in this project?
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 19, 2022, 07:30:21 AM
No, the error was unrelated - Should be fixed now.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 11:37:36 AM
I am afraid that I am still getting the same error:

$ make -j3
Makefile:777: *** missing 'endif'. Stop.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 11:51:04 AM
Quote from: Ranran on February 01, 2022, 12:27:13 PM
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.

I am afraid that I get a compile error when trying to build this:


gui/trafficlight_info.cc: In constructor 'trafficlight_info_t::trafficlight_info_t(roadsign_t*)':
gui/trafficlight_info.cc:42:27: error: 'class roadsign_t' has no member named 'get_ticks_yellow_ns'; did you mean 'get_ticks_amber_ns'?
   42 |    amber_ns.set_value( s->get_ticks_yellow_ns() );
      |                           ^~~~~~~~~~~~~~~~~~~
      |                           get_ticks_amber_ns
gui/trafficlight_info.cc:48:27: error: 'class roadsign_t' has no member named 'get_ticks_yellow_ow'; did you mean 'get_ticks_amber_ow'?
   48 |    amber_ow.set_value( s->get_ticks_yellow_ow() );
      |                           ^~~~~~~~~~~~~~~~~~~
      |                           get_ticks_amber_ow
gui/trafficlight_info.cc: In member function 'void trafficlight_info_t::update_data()':
gui/trafficlight_info.cc:110:32: error: 'class roadsign_t' has no member named 'get_ticks_yellow_ns'; did you mean 'get_ticks_amber_ns'?
  110 |  amber_ns.set_value( roadsign->get_ticks_yellow_ns() );
      |                                ^~~~~~~~~~~~~~~~~~~
      |                                get_ticks_amber_ns
gui/trafficlight_info.cc:111:32: error: 'class roadsign_t' has no member named 'get_ticks_yellow_ow'; did you mean 'get_ticks_amber_ow'?
  111 |  amber_ow.set_value( roadsign->get_ticks_yellow_ow() );
      |                                ^~~~~~~~~~~~~~~~~~~
      |                                get_ticks_amber_ow
make: *** [common.mk:55: simutrans/gui/trafficlight_info.o] Error 1
make: *** Waiting for unfinished jobs....
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 19, 2022, 12:27:10 PM
Oh, I'm so sorry.
Quote from: jamespetts on February 19, 2022, 11:51:04 AMalso translation from amber to yellow.
In standard, this was implemented as yellow, but in extended, I think there may have been a history of it being intentionally made into amber, which is why I revert it a few days ago. The cause is that the revert is clearly incomplete. I apologize for the lack of confirmation.
Can I ask what the color notation should be?
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 12:51:05 PM
Quote from: Ranran on February 19, 2022, 12:27:10 PM
Oh, I'm so sorry.In standard, this was implemented as yellow, but in extended, I think there may have been a history of it being intentionally made into amber, which is why I revert it a few days ago. The cause is that the revert is clearly incomplete. I apologize for the lack of confirmation.
Can I ask what the color notation should be?

For traffic lights, the colour should be "amber". For railway signals, the colour should be "yellow". In the UK at least, the actual colours of traffic lights on roads are distinctly different to railway signals: roads have always had red/amber/green, whereas railways have red/yellow/green. (For reference, amber is a yellowish orange).
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 19, 2022, 01:28:10 PM
Quote from: jamespetts on February 19, 2022, 12:51:05 PMFor traffic lights, the colour should be "amber"
Thank you for the clarification. I think I have restored it and now it is testable.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 01:46:04 PM
Quote from: Ranran on February 19, 2022, 01:28:10 PM
Thank you for the clarification. I think I have restored it and now it is testable.

Excellent, thank you: now incorporated.
Edit: Unfortunately, I now get a merge conflict with Ceeac's heavy mode branch.
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 19, 2022, 02:00:14 PM
Quote from: jamespetts on February 19, 2022, 11:37:36 AMI am afraid that I am still getting the same error:
Could not reproduce. I have now rebased the branch onto the current master branch to resolve the merge conflict and the issue does not occur there for me either (commit 6c60afa91).
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 03:32:30 PM
Quote from: ceeac on February 19, 2022, 02:00:14 PM
Could not reproduce. I have now rebased the branch onto the current master branch to resolve the merge conflict and the issue does not occur there for me either (commit 6c60afa91).

Thank you. I have now rebased, but I am afraid that we are now getting a save format incompatibility issue with the latest master: games saved in the latest master can't be opened in the heavy mode branch, and vice versa.
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 19, 2022, 04:48:41 PM
Quote from: jamespetts on February 19, 2022, 03:32:30 PMgames saved in the latest master can't be opened in the heavy mode branch
That was a bug and should be fixed now.

Quote from: jamespetts on February 19, 2022, 03:32:30 PMand vice versa.
That is not a bug because the save game version is incremented in the heavy mode branch.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 06:40:03 PM
Quote from: ceeac on February 19, 2022, 04:48:41 PM
That was a bug and should be fixed now.
That is not a bug because the save game version is incremented in the heavy mode branch.

Excellent - now incorporated. Thank you.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 19, 2022, 11:39:07 PM
There seems to be a problem in compiling with MSVC, because the current changes for heavy mode have not been applied to MSVC. I was able to add the file specification and compile on my own (I just added a link to the file for debug mode), but I don't know if that's correct because I don't understand the conditions correctly.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 19, 2022, 11:54:33 PM
Quote from: Ranran on February 19, 2022, 11:39:07 PM
There seems to be a problem in compiling with MSVC, because the current changes for heavy mode have not been applied to MSVC. I was able to add the file specification and compile on my own (I just added a link to the file for debug mode), but I don't know if that's correct because I don't understand the conditions correctly.

Did you have to add a .cc file to the project? If you did and that solved the problem, then this should be a relatively straightforward fix. Can I ask what file it was that you added?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 20, 2022, 12:12:54 AM
Quote from: jamespetts on February 19, 2022, 11:54:33 PMDid you have to add a .cc file to the project? If you did and that solved the problem, then this should be a relatively straightforward fix. Can I ask what file it was that you added?
I had to make at least the following changes to get the build to work on MSVC.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/36c9cd51899d71719fa440e14df0b2b521f722ee
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 20, 2022, 12:20:15 AM
Quote from: Ranran on February 20, 2022, 12:12:54 AM
I had to make at least the following changes to get the build to work on MSVC.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/commit/36c9cd51899d71719fa440e14df0b2b521f722ee


Thank you - that is very helpful.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 20, 2022, 12:10:43 PM
We are getting a consistent loss of synchronisation error occurring on all online server games, as reported here (https://forum.simutrans.com/index.php/topic,20355.msg199224.html#msg199224) which cannot be reproduced on a local client/server pair. As the "heavy mode" patch is the only thing that affects either the simulation itself or client/server synchronisation, I strongly suspect that this is the cause, but have not looked into it in sufficient detail to know how this causation might occur. Ceeac - is there anything that you can think of that might be responsible for this?
Title: Re: Incorporating changes from Standard
Post by: ceeac on February 20, 2022, 03:00:55 PM
Probably different settings (simuconf.tab/settings.xml). Try starting two instances in singleuser mode, I managed to reproduce the desync this way. I have not investigated the root cause of the desyncs yet, though.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 20, 2022, 03:08:47 PM
Quote from: ceeac on February 20, 2022, 03:00:55 PM
Probably different settings (simuconf.tab/settings.xml). Try starting two instances in singleuser mode, I managed to reproduce the desync this way. I have not investigated the root cause of the desyncs yet, though.

Hmm - different simuconf.tab settings ought not to cause losses of synchronisation, since the settings that make a difference to the synchronised game state ought to be transmitted with the saved game. I will have to test running two different computers on the same local network to see whether this produces loss of synchronisation.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 20, 2022, 06:13:12 PM
As reported here (https://forum.simutrans.com/index.php/topic,20355.msg199245.html#msg199245), I have found the immediate cause of the problem: different versions of (the base) en.tab between server and client cause a loss of synchronisation.

This is very similar to a problem which I identified and solved in 2017: the town name fragments are randomised. At the time, they used simrand, not sim_async_rand, with the result that any divergence between the list of town name fragments on client and server would cause the random number state to diverge between them. I think that I fixed this by switching the town name randomisation to use sim_async_rand.

I am not sure whether that is the exact problem that has now recurred or whether something different but similar is behind this, but it is instructive to know what caused the previous very similar problem in order to understand how best to go about narrowing down the problem.

Ceeac and Ranran - have either of you altered anything in the commits that went in yesterday that related in any way to an interaction between translation texts and the random number generator?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 20, 2022, 10:42:58 PM
Quote from: jamespetts on February 20, 2022, 06:13:12 PMCeeac and Ranran - have either of you altered anything in the commits that went in yesterday that related in any way to an interaction between translation texts and the random number generator?
https://github.com/jamespetts/simutrans-extended/commit/b9175ecc95e26bdad924eb3e74d1d696f19bb7a2
There are some changes related to translation texts. I'm not sure if that will affect it. Indirect effects, if any.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 20, 2022, 10:53:48 PM
Quote from: Ranran on February 20, 2022, 10:42:58 PM
https://github.com/jamespetts/simutrans-extended/commit/b9175ecc95e26bdad924eb3e74d1d696f19bb7a2
There are some changes related to translation texts. I'm not sure if that will affect it. Indirect effects, if any.

There is nothing obvious in that affecting RNG states - it is mainly multi-language support and translations that appear to be affected; code with which I am not particularly familiar.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on February 21, 2022, 10:52:49 AM
One of the mistakes I noticed in the heavy mode patch is that the version specification in function rdwr() is obviously wrong.
https://github.com/jamespetts/simutrans-extended/blob/36c9cd51899d71719fa440e14df0b2b521f722ee/dataobj/objlist.cc#L1043

I believe that (14,46) and (14,47) are used as revisions to fix max_speed_drive_by_sight_tram_kmh and are irrelevant to it. Probably the revision when the patch started to be created.
After they were added in this commit (https://github.com/jamespetts/simutrans-extended/commit/fa4f798ee709c915ee8d4b696dd822be59c6f748), the numbers in boden.cc seem to have been fixed, but the ones in objlist.cc seem to remain unchanged (https://github.com/jamespetts/simutrans-extended/commit/99ad442f3bfea4c66432c18625d23079020cc99a).
Title: Re: Incorporating changes from Standard
Post by: jamespetts on February 21, 2022, 11:16:57 AM
Quote from: Ranran on February 21, 2022, 10:52:49 AMhttps://github.com/jamespetts/simutrans-extended/blob/36c9cd51899d71719fa440e14df0b2b521f722ee/dataobj/objlist.cc#L1043

Thank you for that. I have now fixed this. However, I doubt that this is the cause of the problem, since, if the problem were faulty load/save code, desynchronisation would happen whether or not en.tab were the same.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on March 15, 2022, 09:46:18 PM
Pull Request #523 is incorporating from the standard and focuses on symsys.
It seems that the last update was incomplete, and the complement is done. As a result, I hope that the problem of map scrolling will be solved. I would appreciate it if you could confirm it.
Title: Re: Incorporating changes from Standard
Post by: prissi on March 16, 2022, 01:22:21 AM
I would strongly suggest to also update simevent.cc, siminteraction.cc and simsys_s2.cc to the latest revision, since the actual scrolling and event processing still had some errors.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on March 16, 2022, 12:30:17 PM
QuoteI would strongly suggest to also update simevent.cc, siminteraction.cc and simsys_s2.cc
They are also in focus. I lost track of the original thread, so the description was omitted. The patch includes commits up to the 123.0 release. I expected it to be stable as there are blanks from there until those files are updated (For example, there is a gap up to r10344,345,368, which seems to be related to screen scale.), but is it still broken?
Title: Re: Incorporating changes from Standard
Post by: prissi on March 16, 2022, 01:35:33 PM
There were still some errors, especially for tablets and draggign dialogues. Maybe nothing so obvious for mouse. (apart from infinite scrolling back for mouse).
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 15, 2022, 09:43:56 AM
Excellent, thank you for this. Apologies for the delay in considering this. I have now tested this, and it does appear to fix the scrolling issue, which makes the game much better to interact with. Now merged.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 16, 2022, 11:04:28 AM
Having deployed this in the master branch, a problem has revealed itself: the server announce feature no longer appears to be working. I am able to connect using the net:bridgewater-brunel.me.uk in the load dialogue, and remain connected, but nothing reaches the announce server.

I have tested merging the 2202-some-fix branch and manually redeployed this on the server, but this does not appear to have assisted matters.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on April 16, 2022, 12:04:24 PM
Pull request #529 as posted here (https://forum.simutrans.com/index.php/topic,20944.msg199836/topicseen.html#msg199836) may solve that issue.



Currently identified issue:
https://forum.simutrans.com/index.php/topic,21536.msg199838/topicseen.html#msg199838
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on April 16, 2022, 04:18:05 PM
Quote from: Ranran on April 16, 2022, 12:04:24 PMCurrently identified issue:
https://forum.simutrans.com/index.php/topic,21536.msg199838/topicseen.html#msg199838
Pull request #530 is the incorporation and correction of commits related to this. Please confirm.
Since Extended is not Android-compatible and I don't think many people play with touch screens, the default is to offer the same mouse control options as before.
The revision number will increase as more options are added.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on April 16, 2022, 05:47:09 PM
Thank you for this. I have tested this, but found that this reintroduces the scroll problem, so have not incorporated this for the present.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on April 17, 2022, 04:26:50 AM
Quote from: jamespetts on April 16, 2022, 05:47:09 PMfound that this reintroduces the scroll problem,
It's odd that this happens because it's not a revert-like change to something, and there are few changes. I think the cause is quite limited.
I also don't think I understand correctly what the "scroll problem" is. Can you elaborate?
(I searched this thread for "scroll" and found no explanation.)

Note that extended has now halfway merged in standard commits, as reported in another thread, which reduces mouse playability. I apologize for the inconvenience.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on April 22, 2022, 01:33:04 PM
Pull request #525 adds a remove signal tool and translates some German variable names.

As already explained, I will basically not be doing this work anymore in the future, so anyone can take over this project.
The recently merged commits are listed in documentation / cherry-picked-commits.txt with reference to what OPRP is doing to make it easier to take over. please refer.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on May 01, 2022, 12:50:20 PM
Apologies for the delay in response - the scroll problem was the problem described in another thread (I cannot immediately recall where) in which, in at least some cases (I could reproduce this on my Linux computer), scrolling a large game with slower performance resulted in very large sudden jumps in position, making it extremely difficult to move around the map or control one's position. This had been a problem for some time, but was fixed about a month ago, with one of your patches, I think. Pull request no. 530 reintroduced this problem.

Can I check whether pull request 530 is cumulative with 525, or whether the intention is that 525 be merged first?

In any event, thank you very much for the work that you have done to date on merging; it is a very large and difficult piece of work, and your dedication to this has greatly improved Simutrans-Extended.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on May 14, 2022, 04:28:08 PM
Having tested again, the latest version of this appears not to have the scroll problem any longer, so I have incorporated this. I should note, however, that I cannot find any remove signal tool - is this because the tool icon/definition has not yet been added to the configuration files?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on May 17, 2022, 10:43:26 AM
Quote from: jamespetts on May 01, 2022, 12:50:20 PMCan I check whether pull request 530 is cumulative with 525, or whether the intention is that 525 be merged first?
Those pull requests are independent.


QuoteHaving tested again, the latest version of this appears not to have the scroll problem any longer, so I have incorporated this.
PR#525 has nothing to do with the scroll problem.


QuoteI should note, however, that I cannot find any remove signal tool - is this because the tool icon/definition has not yet been added to the configuration files?
It is the same as the removal tool dedicated to rails and electrifications. So pakset should be prepared with an icon like for example signal with a bulldozer.


Quotescrolling a large game with slower performance resulted in very large sudden jumps in position, making it extremely difficult to move around the map or control one's position. This had been a problem for some time, but was fixed about a month ago, with one of your patches, I think. Pull request no. 530 reintroduced this problem.
I added a commit from standard to pull request #530. It looks like r10618 has improved performance. please confirm.
Title: Incorporating changes from Standard (PR#570)
Post by: Ranran(retired) on September 17, 2022, 04:48:19 AM
Pull request #570 incorporates minor changes from r10659 to 10719.

- Minor improvements to font setting UI by roboron
- Destruction tools ignore pedestrians. This could save Freddy from suffering.  ;)
- Fixed some UI bugs
- Fixed bug in tunnel graphics when changing terrain
- Fixed an issue where factories would sometimes not register as power plants as intended
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 23, 2022, 02:59:55 PM
Quote from: Ranran on September 17, 2022, 04:48:19 AMPull request #570 incorporates minor changes from r10659 to 10719.

- Minor improvements to font setting UI by roboron
- Destruction tools ignore pedestrians. This could save Freddy from suffering.  ;)
- Fixed some UI bugs
- Fixed bug in tunnel graphics when changing terrain
- Fixed an issue where factories would sometimes not register as power plants as intended
Thank you very much for this. Can I check whether this has been tested with the ex-15 branch for merge conflicts? I need to ensure that it merges properly with that branch before I can safely incorporate it into the master branch.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 23, 2022, 05:11:01 PM
The ex15 branch has had issues a few months ago, so I'd prefer to resolve those first before merging.
I can't test it because I've had problems with boot in the past.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 31, 2022, 12:15:55 AM
Quote from: Ranran on October 23, 2022, 05:11:01 PMThe ex15 branch has had issues a few months ago, so I'd prefer to resolve those first before merging.
I can't test it because I've had problems with boot in the past.
Thank you for letting me know. I believe that I have now fixed this - I should be grateful if you could test the compatibility of integration with the ex-15 branch before I incorporate this into the master branch. Thank you.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on October 31, 2022, 12:19:15 PM
Quote from: jamespetts on October 31, 2022, 12:15:55 AMI should be grateful if you could test the compatibility of integration with the ex-15 branch before I incorporate this into the master branch.
I've confirmed that pull request #570 and #580 work fine with the ex15 branch.
PR#582 is a minor bug fix unrelated to ex15, so I think it's fine.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on November 05, 2022, 01:16:59 PM
Quote from: Ranran on October 31, 2022, 12:19:15 PMI've confirmed that pull request #570 and #580 work fine with the ex15 branch.
PR#582 is a minor bug fix unrelated to ex15, so I think it's fine.
Excellent, thank you for that. I have now incorporated these. No. 580 did need some adjustment to the load/save versioning, however.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on November 18, 2022, 01:16:57 PM
PR#592 is a slight integration from standard. I'm taking a break from simutrans for a while, so I'll submit the commits I've completed so far.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 03, 2023, 10:40:12 PM
Quote from: (N)Ranran (Hibernating) on November 18, 2022, 01:16:57 PMPR#592 is a slight integration from standard. I'm taking a break from simutrans for a while, so I'll submit the commits I've completed so far.
Thank you very much for this, and apologies for the delay in responding. Can I ask whether this has been tested for Ex-15 branch compatibility?
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on January 03, 2023, 11:17:50 PM
Quote from: jamespetts on January 03, 2023, 10:40:12 PMThank you very much for this, and apologies for the delay in responding. Can I ask whether this has been tested for Ex-15 branch compatibility?

This change has already been merged into the new branch for ex15 and has been tested.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on January 03, 2023, 11:47:56 PM
Quote from: (N)Ranran (Hibernating) on January 03, 2023, 11:17:50 PMThis change has already been merged into the new branch for ex15 and has been tested.
Excellent, thank you: now incorporated.
Title: Re: Incorporating changes from Standard
Post by: neroden on April 28, 2023, 04:35:26 PM
Does someone have a summary of the current state of incorporation of changes from standard?
Is the documentation/cherry-picked-commits.txt file relevant to this question?
Title: Re: Incorporating changes from Standard
Post by: ceeac on April 28, 2023, 05:55:41 PM
The cherry-picked-commits.txt file lists most (all?) commits that Ranran cherry-picked from Standard, however he is taking a break from Simutrans at the moment. I have also submitted a few pull requests incorporating changes from Standard, mostly around improving code quality (automated tests) and tools for desync debugging ("heavy mode"). Many of the automated tests are still disabled though because the functionality is different between Standard and Extended.

I am currently working on a larger patch which incorporates the terraformer refactoring made in r10443 (this is mostly finished, should be ready by this or next weekend), and a port of the source reorganization script added in r10444. This should make incorporating further changes much easier again.
Title: Re: Incorporating changes from Standard
Post by: ceeac on April 29, 2023, 10:50:25 AM
The terraformer changes are now finished: #609 (https://github.com/jamespetts/simutrans-extended/pull/609) for the master branch and #610 (https://github.com/jamespetts/simutrans-extended/pull/610) for the ex-15 branch.
Title: Re: Incorporating changes from Standard
Post by: neroden on May 02, 2023, 02:35:41 AM
That's great news.  I see that the cherry-picked-commits.txt file runs from 9700 to 10802, plus three stray cherry-picks from earlier.

A. Carlotti definitely got everything up to #7429, with Phystam working up to 7753 or 8125, and it looks like Ranran started around there.  I see that James merged Ranran's merge-from-8434 branch.  Are we sure we have everything from 8435 to 9700? 

That's where the discussion in this thread got confusing and lost in questions of compilation so I'm a bit confused.

Regarding the source reorganization script.... well.... I kind of want to make sure we have all the patches we want from standard which went in *before* the source reorganization *before* we apply the source reorganization script, which is why I'm asking about this.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on May 05, 2023, 11:23:56 PM
Ceeac - thank you for this. Now incorporated.
Title: Re: Incorporating changes from Standard
Post by: Ranran(retired) on June 14, 2023, 11:30:36 AM
Quote from: neroden on April 28, 2023, 04:35:26 PMDoes someone have a summary of the current state of incorporation of changes from standard?
Is the documentation/cherry-picked-commits.txt file relevant to this question?
The reason I wrote out the cherry picked commits is to make it clear that I'm only picking up specific commits because I skipped commits that were not UI related. Because I just followed ACarlotti's recommendation and proceeded with the merge from the standard to expedite the work of implementing the GUI.

There is a concern that changing the folder structure while missing important commits will make it difficult to obtain those commits in the future.


A bunch of big unfetched commits that I can recall are:

(1) moisture patch

(2) Support for the new dat description method of makeobj
dat file for standard may not be reused as it is for extended. Specifically, simplification of image specification description.

(3) multi-tile citybuilding

Of particular importance is the repair of the broken multi-tile citybuilding code.
Extended's multi-tile citybuilding code was written by THLeaderH. But standard is not. This only makes it difficult to move between standard and extended and reduces maintainability.
And prissi points out that the Extended multi-tile citybuilding code is broken. But unfortunately extended doesn't have a normal pakset with multi-tile citybuilding so it's not easy to test it.
It should also be noted that he introduced a number of bugs in the overtaking feature that he has neglected to fix most of the time. The irresponsible Japanese who wrote the code won't help us anyway. And so years have passed.


Please refer to the following.
https://forum.simutrans.com/index.php/topic,17857.0.html
https://forum.simutrans.com/index.php/topic,17814.0.html




Some relevant thread are below:
https://forum.simutrans.com/index.php/topic,21166.msg201034.html#msg201034

https://forum.simutrans.com/index.php/topic,21029.msg196285.html#msg196285

https://forum.simutrans.com/index.php?msg=184192

https://forum.simutrans.com/index.php?msg=196974


QuoteA. Carlotti definitely got everything up to #7429
I've completed some missing trivial commits, but I think his work is mostly accurate.

Quote from: neroden on May 02, 2023, 02:35:41 AMwith Phystam working up to 7753 or 8125
I find Phystam's work is not much, but there were a lot of errors. It's similar to what A.Carlotti pointed out about his work before he left. Note that A.Carlotti mentioned commits before r7753, but I'm talking about after r7753.

Quote from: ACarlotti on January 09, 2019, 11:04:07 PMThere'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.
There were some examples of missing changes (sets of rows).

A
B
A'
B'
Sometimes he missed A'B' with a change like that. (I mean he removed A'B' from the change. Looking for it by looking at the history is a very troublesome task.)

Many errors were missing "_rgb" in ABC_rgb. And many typos (upper and lower case mistakes). A number of similar variable names were mixed up. He missed a lot of it being changed to xxx_rgb.

I got the impression he was manually typing and transcribing changes because there were many weird typos. (Such typos don't happen with automerge or copy and paste.)

I've fixed the ones I noticed, but for example the crash bug when switching players was caused by incorrect merging and was overlooked until recently. Note that I am not saying this to condemn him, but to clarify the possibility that such errors may already be lurking if someone takes over the work, to clarify the cause of the error, and to prevent its recurrence.

Quote from: ACarlotti on January 10, 2019, 07:36:14 AMI'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 also missed a lot of basic changes since r7753.


Unfortunately, I also have doubts about the accuracy of my work.


Extended currently still has some old style GUIs.
(1) Player list
(2) Schedule list

Since these are extended with many functions, they need to be dealt with individually.
As we merged from standard, the old dialogs became more and more anomalous.
Also, some GUI parts may have bugs in extended due to placement not implemented in standard. For example combobox. But I think it's a bug in standard.
Title: Re: Incorporating changes from Standard
Post by: jamespetts on June 18, 2023, 03:17:38 PM
Ranran - thank you for that summary: that is most helpful. I agree that the priority is fixing the multi-tile city building code (i.e. incorporating the fixes from Standard).
Title: Re: Incorporating changes from Standard
Post by: neroden on October 15, 2023, 04:56:18 AM
So, I may have a chance this winter to work on cleaning this up and properly incorporating the commits from 7429 to 10444, which should be done before the source reorganization.

The problem I have is this.  I want to do this work properly using Git (specifically, actually using "git merge" and "git cherry-pick"). 

But how do I tell what SVN commit number matches to what Git commit?  Is there an easy way to do this?
Title: Re: Incorporating changes from Standard
Post by: ceeac on October 15, 2023, 05:03:59 AM
Quote from: neroden on October 15, 2023, 04:56:18 AMBut how do I tell what SVN commit number matches to what Git commit?  Is there an easy way to do this?

$ git log -n1 master | grep git-svn-id | grep -Poe "(?<=@)[0-9]+"
10984
Title: Re: Incorporating changes from Standard
Post by: jamespetts on October 21, 2023, 09:36:44 AM
Quote from: neroden on October 15, 2023, 04:56:18 AMSo, I may have a chance this winter to work on cleaning this up and properly incorporating the commits from 7429 to 10444, which should be done before the source reorganization.

The problem I have is this.  I want to do this work properly using Git (specifically, actually using "git merge" and "git cherry-pick"). 

But how do I tell what SVN commit number matches to what Git commit?  Is there an easy way to do this?
That would be splendid - I shall look forward to your work on this.