News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

How to compile Simutrans Extended with Visual Studio 2015 [2019]

Started by Spenk009, December 29, 2014, 08:03:25 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Spenk009

Moderator note: This post is now somewhat out of date. See here for a description of the steps necessary to compile Simutrans-Extended in Windows using Visual Studio as of January 2021. Thanks to Ves for the very helpful information.

This is a guide from my recent experience with compiling Simutrans Extended. This is a snapshot of Dec 2017 on Windows 7 and your configuration may differ.

1. Install Microsoft Visual Studio 2015 (officially: here or any other place you like). Install and let it update. In the mean time you can proceed with the next steps.
2. Get the sources from GitHub: here. You can download the whole folder as a zip file on the right side of the page or sign up and fork your own branch. Extract the folder somewhere memorable (like "D:\Programming").
3. Get bzip2 from here. If you are only building the .exe, choose the appropriate dev version (x86=32bit, x64=64bit). Open this zip and extract the files into your extracted Extended folder under: "...\simutrans-experimental\utils\openttd\lib"
4. If you are also building the game folder you'll need the libbz2.dll, which is in the dll download, keep this extracted dll handy. You'll also need "pthreadVCE2.dll" from here. Select the latest/highest "prebuilt-dll-..-..-..-release", in the folder "dll", in the appropriate x86/x64 folder, you will find "pthreadVCE2.dll". Download this dll too and keep it with "libbz2.dll".
5. Start Visual Studio and open Simutrans-Extended.sln. Now click on Project -> Simutrans-Extended Properties... -> Configuration Properties -> VC++ Directories. Click on "Include Directories" once and then on the right of the field you'll see some paths listed. Next to that is a down arrow. Click that and click on <Edit...> in the resulting dropdown. On the top left of the window appearing you can add folders to the list. Add  "...\simutrans-experimental\utils\openttd" to this list. Things should be looking like this.
6. Below "Include Directories" you will find "Library Directories". Proceed as in the previous step and add "...\simutrans-experimental\utils\openttd\lib" to the list.
7. Try building the executable. The build should compile.

8. Move the Created Simutrans.exe into a fresh folder.
9. Add the .dll files from step 4 to the folder.
10. Add a pakset into the folder such as a nightly build.
11. Run your own compiled Simutrans!

Note: If you get an error with loadsave_t::start_tag(), delete or rename your Simutrans folder in "My Documents".

Moderator note: References to "Simutrans-Experimental" changed to "Simutrans-Extended" 13 February 2017.


jamespetts

Splendid - thank you for posting that. That will surely help people new to the code. I will sticky this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Junna

I have been able to compile in the past, but now I get an error:

C2065: "remaining_wear_capacity", undeclared identifier, in weg.h

Is there a new dependency?

DrSuperGood

The name of that indicates an internal declaration inside the solution (not many standard libraries would use "remaining_wear_capacity" as a name). Either you have forgotten to update one of the files or there is currently a compile error in the GIT.

jamespetts

Ahh - did some of my way wear mechanics accidentally make it into way-improvements? My apologies. If you are on the way-improvements branch, you can delete references to remaining_wear_capacity for now: this feature will be added in when you merge from the new way-wear branch.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Junna

Well, I don't know how to do that, I only use it to download the sources, I don't know how to actually use the git.

jamespetts

It may be easier in that case to use your existing binary until I am able to fix it.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Rollmaterial

Thanks for this very helpful post! Does it apply to compiling in 64-bit too?

jamespetts

There are, I understand, some significant problems associated with the 64-bit version of Simutrans for Windows, which are part of the basic Simutrans code and not specific to Experimental. It is better to compile a 32-bit binary, which will run perfectly well on 64-bit Windows.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteThere are, I understand, some significant problems associated with the 64-bit version of Simutrans for Windows, which are part of the basic Simutrans code and not specific to Experimental. It is better to compile a 32-bit binary, which will run perfectly well on 64-bit Windows.
64bit standard simutrans builds with MSVC and runs perfectly as far as I can tell. The only problem is that outside of allowing larger maps and paks it actually lowers performance due to worse memory density and less optimum cache usage. This is mostly due to some small but very common objects being made larger (less dense) and object references being larger.

jamespetts

If I remember correctly, because of the internal memory pool systems using 32-bit integers, running in 64-bit mode does not allow the game to use more memory than it would running as a 32-bit application on a 64-bit operating system.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Rollmaterial


DrSuperGood

32bit mostly. Only use 64bit if you encounter out of memory errors.

Rollmaterial

Quote from: DrSuperGood on October 31, 2015, 05:43:03 PM
32bit mostly. Only use 64bit if you encounter out of memory errors.
I mean between debug and release, but thanks for that as I could have memory problems too! By the way, how well should a 1026*1710 map work in 32 bit?

DrSuperGood

Debug if you are a developer or plan to leave developer feedback or develop yourself, Release if you just want to play. Debug performs a lot slower but has full strack trace information for errors. Release it heavily optimized so performs better but on errors you get a lot of as good as garbage optimized code traces.

jamespetts

Dr. Supergood is correct about debug/release. As to 32/64-bit, compile as 32 bit in Windows, and 64-bit for 64-bit Linux. Simutrans cannot work with a 64-bit address space and is not optimised for 64-bit use (the low level code was written long ago). A 64-bit build will work, but there is no advantage to it, except on Linux, where 32-bit builds do not work reliably on 64-bit versions of the operating system for some unknown reason.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

laos

The bzlib files are sadly 404ing. Any chance someone who has a copy can reupload them to this thread for those who wish to compile in Windows?

jamespetts

Sadly, I am not near my Windows computer that has a copy of these at present, as I am staying with my parents for Christmas; you might try searching online for it? I suspect that there must be a binary of this for Windows around somewhere.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

You can self build the library, which is what I did.

bzip2 I believe is the official site.

laos

I found this github to be useful: https://github.com/philr/bzip2-windows/releases

the "developer files" include the related .h and .lib - I also happened to need the .dll when launching :)

So far was able to get win32 to compile. x64 is not working (getting a lot of different header and library file requests including SDL and allegro) - not sure if I'm doing something wrong as I'm not very adept with Visual Studio.

jamespetts

You do not need to compile the 64-bit version; there is no advantage to doing so, since Simutrans in any event uses an internal memory management system that cannot take advantage of more than 4Gb of RAM. There are no significant systems in Simutrans that take advantage of actual 64-bit computation. Although I have compiled Windows 64-bit versions in the past, I have not done so recently, and the code would probably need updating to allow for this.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Spenk009

I have updated the build instructions on the executable. If anyone notices a mistake or inaccuracy, send me a pm so I can fix it.

Merry Christmas everyone!

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

DrSuperGood

QuoteThere are no significant systems in Simutrans that take advantage of actual 64-bit computation.
Actually a lot of Simutrans benefits from it. Everything from the graphics routines to factory production benefits with speedups. This is because x86-64 allows single instruction operations on 64bit types as well as having RISC style several general purpose registers allowing for fast function call protocols.

The only slowdown with x86-64 over x86 builds is the 64bit (8 byte) pointer types. Since Simutrans is mostly memory IO bottlenecked, the decrease in memory density as a result of increased pointer size type causes a significant performance decrease. This undoes most of the performance gains from x86-64, except perhaps on the most modern of computer systems where performance is not really a design factor anyway.

jamespetts

I have noticed that, on the very largest maps, Simutrans-Extended is coming close to consuming 4Gb of RAM, so it may well be worthwhile switching to compiling for Windows in 64-bit sometime next year. This will take some time, however.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

I have attempted to follow the OP's instructions but the build fails. I have not done any programming for almost three decades, and never before with C++, so this is surely due to mistakes on my part. I notice that I have different Include files from the screenshot that spenk009 kindly provided. Here is my main Include config from the MSVC Properties dialogue:



And here is the included libraries list:



I don't have the "..\OpenTTD\shared\include" or "..\bzip\include" items. The former two are not in the Simutrans-Extended directory tree. Should I download them from elsewhere?

I added the MSVS item ("Microsoft Visual Studio 14.0\VC\include"), but the build still failed and I got 1,150 warnings, and the following error (13 times):



I can't find a revision.h file anywhere in the Simutrans-Ex or -Standard trees on Github, although I could find multiple references to it in the code.

Any advice on how to compile would be much appreciated. Assume I am an idiot!

I am using MSVS Express for Desktop 2015 on Windows 7.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

Sorry that you are having trouble with this. This thread contains a discussion of the issue that you are experiencing. In short: revision.h is an automatically generated file. Somebody else wrote the code for the automatic generation, and I do not know how it works, so cannot debug this when it goes wrong. However, a workaround is simply to have a blank revision.h file, albeit the revision versioning system will not work (but this is not critical for anything other than release/nightly builds).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

James, thank you for taking the time to track down that thread. I should have searched the forum myself: it's the obvious self-help step in hindsight. Happily, I tried Ves' workaround (just create a blank file) and it seems to have worked: the revision.h errors have disappeared. However, I now have errors because I don't have the files allegro.h, pthreads.h, and sdl.h. That seems to be the same issue discussed in this thread.

Based on the discussion there, could you (or spenk009) please clarify:
- Should I be setting the build options as 'Release' and 'x64' or something else? I am building on, and for, Windows 7 64-bit.
- I have been opening the Simutrans-Extended.sln file in MSVS. Is that correct?

I'm also going to double-check that my MSVS has all the updates it needs, in case that is the problem.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

You can build either as "release" or "debug", although you might be better building as (the perhaps inappositely named) "Debug (open GL)". Again, you can build in either Win32 or x64, but x64 is preferred as the 32 bit builds are prone to running out of memory on large maps.

Visual Studio 2015 is indeed the correct application for opening these files and building Simutrans-Extended for development purposes.

If you are self-building, you might find debug builds more useful than release builds because Visual Studio builds will not stay in sync with a server running a GCC build, whereas cross-compiled GCC builds will stay in sync. (In principle, this is a bug, but it would be so fantastically difficult to track down that it is not worthwhile to do so given that there is such an easy workaround, viz. using the cross-compiled builds which are produced nightly).

What it looks like you need to do from your descriptions of the errors is to point your project file to the correct directories that contain the include files for pthreads and SDL. You should not need allegro.h, so you might want to check your build properties to see whether you are incorrectly trying to build a code file that refers to this header file.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

James, thank you for the advice. I am now working with the "Debug (OpenGL)" config and I have gradually eliminated a series of errors over the course of a couple of dozen build attempts, all caused by my own mistakes, but I've now got two new ones that are foxing me. I get the following errors when I try to compile:



As these are problems with intermediate objects that MSVS creates during the compilation process, I tried deleting the intermediate files (in /x64/Debug (OpenGL)/) in case they were left over from from an earlier botched build but then I get what are ostensibly internal compiler errors (C1001 and D8040), i.e. bugs in MSVS, but I don't doubt for a moment that they're actually my errors, not Microsoft's. I noticed that the Output View also gave these hints:



That suggests that I've somehow downloaded 32-bit versions of the libraries, so I'll try re-downloading and reinstalling those in the morning.

Searching through the game's filetree for compilation hints, I noticed that there is a config.default file. Although the OP's instructions don't mention the need to change this, the config.default that I have pulled from jamespetts/simutrans-extended/simutrans/master/ (copied below) is set to mingw2, and seems to be very different from the config.default that is used by Simutrans-Standard and the settings in jamespetts/simutrans-extended/config.template. The MS help pages for C1001 and D8040 say that they can sometimes be caused by incorrect compilation flags. Is the config.default only used when compiling with mingw2, or do I need to set it to different options for MSVS?

BTW I also get thousands of Warnings when I try to compile; I take it that is normal for a complex, legacy programme like Simutrans?

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

#BACKEND = allegro
BACKEND = gdi
#BACKEND = sdl
#BACKEND = mixer_sdl
#BACKEND = x11

#COLOUR_DEPTH = 8
#COLOUR_DEPTH = 16

#OSTYPE = beos
#OSTYPE = cygwin
#OSTYPE = freebsd
#OSTYPE = linux
OSTYPE = mingw
#OSTYPE = mac

#DEBUG = 3    # Level 1-3, higher number means more debug-friendly, see Makefile
#OPTIMISE = 1 # Add umpteen optimisation flags
PROFILE = 1

# Define these as empty strings, if you don't have allegro/sdl-config
#ALLEGRO_CONFIG = allegro-config
#SDL_CONFIG = sdl-config

#VERBOSE = 1

# Do not determine dependencies
# Header dependencies get NOT tracked this way, so if a header changes you're
# on your own (i.e. manually run a make clean)
# Uncomment this if this stage takes exceptionally long, which happens on some
# broken filesystems
# NO_DEPS = 1

# Following flags exists
# DOUBLE_GROUNDS: Enables two height tiles
# HALF_HEIGHT: Enables half height tiles (8 pixel instead 16)
# OTTD_LIKE: Enables half height tiles and crossconnected industries; defaul folder pak.ttd/
# DESTINATION_CITYCARS: Citycars can have a destination (not recommended)
# USE_C: no assembler for copying
# BIG_ENDIAN: MUST by set for PPC/Motorola byte order! (old mac, amiga)
# STEPS16: 16 steps per tile - nicer on pak64
# NEW_PATHING: New pathing system. Not recommended to omit this.
FLAGS =  -NEW_PATHING
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

The config.default file is not used when compiling with Visual Studio: this is only used when compiling with GCC or a derivative such as MinGW.

The errors that you describe look like a failure to have the correct library files for pthreads, which is the multi-threading interface. It is possible that you have the 32-bit rather than 64-bit version, but also check that you are pointing to the directory with the libraries in Visual Studio's libraries folder.

As to the warnings, Simutrans has always been quite heavy on warnings: most of them are inherited from Standard.

Very best wishes in getting this to compile!
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

James, thank you for explaining that config.default is irrelevant; that's one line of enquiry ruled out.

I've spent another few hours on this today. As you suggested, my previous problem seems to be caused by a 32-bit (x86) library. It seems that most of the libraries provided in the OpenTTD download and linked to in the compilation guides are 32-bit, so I am having to trawl the Web looking for x64 builds (I suspect that it's the same journey that you took in the cross-compilation thread, albeit in a different vehicle). I think I've now got working versions of pthreads and bzip. I installed a 64-bit version of zlib using NuGet, which is MSVS' built-in library manager.  I found an x64 libpng file with NuGet, but unfortunately it seems to be a different version of libpng from the one that your source code uses, with different filenames.

Could you please let me know exactly which versions of freetype2 and libpng you are using for the 64-bit Windows builds? The latest stable version of libpng is 1.6.3.4, and I think that's what NuGet is providing. If I've got to build these libraries myself, then I'd like to make sure that I stay consistent with you.

DrSuperGood, I think you're also compiling with x64 in MSVS - where did you find freetype2 and libpng libraries, please? NuGet or elsewhere?
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

jamespetts

The libraries that I use are from a recent version of OpenTTD, which do include 64-bit versions. My versions.txt file states the following:


The used versions for the libaries in this archive:
freetype 2.6
icu4c 55.1
liblzma 5.2.1
libpng 1.6.18
lzo 2.09
zlib 1.2.8

For the actual sources we redirect you to the sources archive that is located next to this archive.


Does this assist?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Matthew

James, now that the double-post rule has been relaxed, I can write: thank you for this information. I seem to have damaged my Git repository, so I'll get help from that in a more appropriate forum and then review all these libraries to make sure that I've got the right versions.
(Signature being tested) If you enjoy playing Simutrans, then you might also enjoy watching Japan Railway Journal
Available in English and simplified Chinese
如果您喜欢玩Simutrans的话,那么说不定就想看《日本铁路之旅》(英语也有简体中文字幕)。

Spenk009

I'm having trouble compiling a checked out copy of the nightlies. I managed to successfully build an executable, but any subsequent attempts have failed. This same failure occurs on both Ranran and James' branches.

The command issued:
make BACKEND=sdl2 COLOUR_DEPTH=16 OSTYPE=linux -j7

The part of code that fails to build
simworld.cc:4301:2: error: 'await_all_threads' was not declared in this scope
  await_all_threads();
  ^~~~~~~~~~~~~~~~~
simworld.cc:4369:23: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
  for (uint32 i = 0; i < get_parallel_operations(); i++)
                     ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
vehicle/simvehicle.cc: In member function 'virtual void vehicle_t::display_after(int, int, bool) const':
vehicle/simvehicle.cc:3067:12: warning: this statement may fall through [-Wimplicit-fallthrough=]
      color = COL_RED;
vehicle/simvehicle.cc:3069:4: note: here
    case convoi_t::LOADING:
    ^~~~
simworld.cc: In member function 'void karte_t::step()':
simworld.cc:5581:2: error: 'await_passengers_and_mail_threads' was not declared in this scope
  await_passengers_and_mail_threads();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
simworld.cc:5581:2: note: suggested alternative: 'step_passengers_and_mail'
  await_passengers_and_mail_threads();
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  step_passengers_and_mail
In file included from descriptor/vehicle_desc.h:10:0,
                 from convoy.h:70,
                 from convoy.cc:12:


I don't wish to alter the code, since it managed to build successfully before.

ACarlotti

That's an error in the code that wasn't previously spotted because most of us use multithreaded builds.

I was intending to make the thread await functions available in single threaded builds to allow a reduction the number of ifdefs needed elsewhere in the code, but failed to put the declarations outside the #ifdef MULTI_THREAD, and further failed to notice that the function definitions are inside a 600 line #ifdef MULTI_THREAD. There are two possible fixes to this - either put lines 4301 and 5581 inside #ifdefs, or put the function declarations and definitions outside ifdefs.

James: I've uploaded the latter solution to Github, but if you think the former fix would be better then we could probably do that instead.

Spenk009: You can wait for a fix upstream, but if you want to compile the code before then you can either switch to using a multithreaded build, or comment out the two lines that are causing errors.

EDIT: A thought on the merits of being able to call the await functions without #ifdefs - at the moments there is some inconstency about what condition is being tested - e.g. MULTI_THREAD_PATH_EXPLORER v.s. just MULTI_THREAD. If we can just call awaits whenever, then we don't need to worry about choosing between several valid conditions.

Spenk009

Please excuse my ignorance, but what parameter do I add to make a multithreaded build?

ACarlotti

The intended way to configure a build is to copy config.template to config.default, and then uncomment/edit the relevant lines. The template config file has MULTI_THREAD=1 set, so you wouldn't need to change that further unless you wanted to comment it out or set it to 0 (for a build without multithreading). You can also set BACKEND, COLOUR_DEPTH and OSTYPE here , so that you don't need to specify them each time on the command line (and doing so will probably make it less likely that you accidentally specify the wrong parameters on the command line, which could get your build into an inconsistent state).

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Returning to trying to compiling, I dont get this to work at all. It appears to not work "out of the box" anymore as described in the OP.

It seems that a new bunch of dependencies is required, which I have now found online and even compiled myself, and also I would like to know what debug and release compile modes should be used now ("Debug x64", "Debug (Open GL) x64"?).

Anyone with insight could perhaps shed some light on what exactly is required?

jamespetts

The only two compile modes that are still used are Debug and Optimised Debug, both in x64. Have you managed to get the dependencies working?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Ok, thanks for the debug modes, that is a start.

No I havent got the dependencies to work properly, let me explain in detail what I have done:

Making a clean install of the entire Simutrans-extended Github repository, so as to reset all dependency path's etc.
Opening the Simutrans-extended.sln with MSVS2019, I immedietly check that it is set to "Debug" and "x64".
Opening the Include Directories I find that these are targeted:
..\zstd-1.4.4\lib
..\freetype-2.10.1\include\freetype
..\miniupnpc
..\OpenTTD\shared\include
..\bzip\include


and the Library Directories:
..\zstd-1.4.4\build\VS2010\bin\x64_Debug
..\freetype-2.10.1
..\miniupnpc
..\OpenTTD\win64\library
..\bzip\lib\x64

... which I assume are the correct paths to the corresponding files on your computer, James?
AND I assume this is a good representation on what dependencies I need.

zstd-1.4.4
I found the Zipfile named "zstd-1.4.4.zip" here: https://github.com/facebook/zstd/archive/v1.4.4.zip (direct download link)
Then, in order to get hold of the libzstd_static.lib (which the compiler will complain about), I followed the instructions on this webbsite https://rocksdb.org.cn/doc/Building-on-Windows.html ca 1/3rd down the page under the "Build Zstd" section (although I compiled the zstd.sln using msvs2019, right clicking on each project clicking "build" inside msvs2019)
Doing this creates a new folder structure bin\x64_Debug, which incidentally coincides with one of the Library Directories listed above.

Because I put all my dependency directories one level up from the Simutrans-extended.vcxproj file, the above paths should be equal to the ones already specifyed in the directories.

freetype-2.10.1
I found this directory online listing a bunch of freetype downloads: https://download.savannah.gnu.org/releases/freetype/
I picked the one called freetype-2.10.1.tar.gz (what is the difference between the ones ending with .gz and .xz??), downloaded and extracted it.
When comparing the folder structure with the directories listed above, one is pointing to freetype-2.10.1\include\freetype which appears ok, but the other is just pointing to the freetype-2.10.1 folder itself. The compiler will complain about not finding freetype.lib, so I went ahead and compiled that using the "freetype.sln" found in "freetype-2.10.1\builds\windows\vc2010". I set it to Release x64.
This ends up in "freetype.lib" being found in freetype-2.10.1\objs\x64\Release. I move it to the freetype-2.10.1 base folder, since that is the one pointed to by the Simutrans project.

miniupnpc
I found on this site a bunch of files relating to miniupnpc: http://miniupnp.free.fr/files/
Downloading the one called: miniupnpc-2.2.1.tar.gz, I get a folder with a bunch of header files and some folders. Looking at the project directories, they both points to the basefolder, without any version numbering as well. So I extract the folder, remove the "-2.2.1" from the folder name. The compiler (it should really be called a complainer....) will complain about not finding miniupnpc.lib, so I went ahead and compiled the miniupnpc.sln found in miniupnpc\msvc. To compile succesfully I had to rename "miniupnpcstrings.h.in" to just "miniupnpcstrings.h" (removing the .in) found in the base miniupnpc folder.
The resulting "miniupnpc.lib" ends up in "miniupnpc\msvc\Debug", which is not refered to by the project directories, so I just move it to the base miniupnpc folder.

OpenTTD
I remember this being a tricky one and I have several copies on my harddrive which might come in handy. Anyway, I downloaded a fresh one from this site: https://www.openttd.org/downloads/openttd-useful-releases/latest.html
Extracting this gives me a folder called "OpenTTD essentials", but I rename it to just "OpenTTD" in order to match the directories from the project. Other than that, the folder structure and files within seems to match the directories called to by the project.

bzip
I assume that this refers to bzip2, as all references points to that. Following the OP, it links to this site: https://github.com/philr/bzip2-windows/releases.
That download generates a folder with just a few files, not following the folder structure that the project include and library directories suggest.
Instead of following the OP suggestion (putting it within the Simutrans-Extended\utils\openttd\lib) I add the relevant intermedian folders and rename the parent folder to just bzip.


Compiling time:
It complains about pthread.h is missing. I have located a pthread.h in the utils\openttd folder within the simutrans-Extended folder, so I went ahead and added this directory to to the include- and library directories (include: utils\openttd - Library: utils\openttd\lib)

Now it just throws a big bunch of linker errors at me, lnk2001 and lnk2019 specifically:
Build started...
1>------ Build started: Project: Simutrans-Extended, Configuration: Debug 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>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library
1>LINK : warning LNK4217: symbol 'calloc' defined in 'libucrtd.lib(calloc.obj)' is imported by 'libzstd_static.lib(zstd_common.obj)' in function 'ZSTD_calloc'
1>LINK : warning LNK4286: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(zstd_v06.obj)'
1>LINK : warning LNK4286: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(zstd_v07.obj)'
1>LINK : warning LNK4286: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(fse_decompress.obj)'
1>LINK : warning LNK4217: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(zstd_common.obj)' in function 'ZSTD_free'
1>LINK : warning LNK4286: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(fse_compress.obj)'
1>LINK : warning LNK4286: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(xxhash.obj)'
1>LINK : warning LNK4217: symbol 'free' defined in 'libucrtd.lib(free.obj)' is imported by 'libzstd_static.lib(zstd_v05.obj)' in function 'MEM_swap64'
1>LINK : warning LNK4286: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(zstd_v06.obj)'
1>LINK : warning LNK4286: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(zstd_v07.obj)'
1>LINK : warning LNK4286: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(fse_decompress.obj)'
1>LINK : warning LNK4217: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(zstd_common.obj)' in function 'ZSTD_malloc'
1>LINK : warning LNK4217: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(fse_compress.obj)' in function 'FSE_compress_wksp'
1>LINK : warning LNK4286: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(xxhash.obj)'
1>LINK : warning LNK4217: symbol 'malloc' defined in 'libucrtd.lib(malloc.obj)' is imported by 'libzstd_static.lib(zstd_v05.obj)' in function 'MEM_readLEST'
1>LINK : warning LNK4217: symbol '_errno' defined in 'libucrtd.lib(errno.obj)' is imported by 'libzstd_static.lib(threading.obj)' in function 'ZSTD_pthread_create'
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_attr_init referenced in function "public: void __cdecl main_view_t::display(bool)" (?display@main_view_t@@QEAAX_N@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_init
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_init
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_attr_destroy referenced in function "public: void __cdecl main_view_t::display(bool)" (?display@main_view_t@@QEAAX_N@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_destroy
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_destroy
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_attr_setdetachstate referenced in function "public: void __cdecl main_view_t::display(bool)" (?display@main_view_t@@QEAAX_N@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_setdetachstate
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_attr_setdetachstate
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_create referenced in function "public: void __cdecl main_view_t::display(bool)" (?display@main_view_t@@QEAAX_N@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_create
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_create
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_mutex_lock referenced in function "public: bool __cdecl karte_t::load(char const *)" (?load@karte_t@@QEAA_NPEBD@Z)
1>weg.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simgraph16.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simcity.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simconvoi.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simhalt.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simplay.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>freelist.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>powernet.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>route.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>label.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>leitung2.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>tunnel.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>wayobj.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simview.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>bruecke.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>crossing.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>gebaeude.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_lock
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_mutex_unlock referenced in function "public: bool __cdecl karte_t::load(char const *)" (?load@karte_t@@QEAA_NPEBD@Z)
1>weg.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simgraph16.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simcity.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simconvoi.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simhalt.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simplay.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>freelist.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>powernet.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>route.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>label.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>leitung2.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>tunnel.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>wayobj.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simview.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>bruecke.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>crossing.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>gebaeude.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_unlock
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_barrier_init referenced in function "public: void __cdecl main_view_t::display(bool)" (?display@main_view_t@@QEAAX_N@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_init
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_init
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_barrier_wait referenced in function "public: bool __cdecl karte_t::load(char const *)" (?load@karte_t@@QEAA_NPEBD@Z)
1>simview.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_wait
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_wait
1>route.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_wait
1>simconvoi.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_wait
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_cond_wait referenced in function "public: void __cdecl main_view_t::display_region(class koord,class koord,short,short,bool,bool,signed char)" (?display_region@main_view_t@@QEAAXVkoord@@0FF_N1C@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_cond_wait
1>simview.obj : error LNK2019: unresolved external symbol __imp_pthread_cond_broadcast referenced in function "public: void __cdecl main_view_t::display_region(class koord,class koord,short,short,bool,bool,signed char)" (?display_region@main_view_t@@QEAAXVkoord@@0FF_N1C@Z)
1>loadsave.obj : error LNK2001: unresolved external symbol __imp_pthread_cond_broadcast
1>network.obj : error LNK2019: unresolved external symbol freeUPNPDevlist referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol upnpDiscover referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol UPNP_GetValidIGD referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol FreeUPNPUrls referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol UPNP_GetExternalIPAddress referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol UPNP_AddPortMapping referenced in function "bool __cdecl prepare_for_server(char *,char *,int)" (?prepare_for_server@@YA_NPEAD0H@Z)
1>network.obj : error LNK2019: unresolved external symbol UPNP_DeletePortMapping referenced in function "void __cdecl remove_port_forwarding(int)" (?remove_port_forwarding@@YAXH@Z)
1>loadsave.obj : error LNK2019: unresolved external symbol __imp_pthread_join referenced in function "public: void __cdecl loadsave_t::set_buffered(bool)" (?set_buffered@loadsave_t@@QEAAX_N@Z)
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_join
1>loadsave.obj : error LNK2019: unresolved external symbol __imp_pthread_mutex_init referenced in function "public: void __cdecl loadsave_t::set_buffered(bool)" (?set_buffered@loadsave_t@@QEAAX_N@Z)
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_init
1>simgraph16.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_init
1>loadsave.obj : error LNK2019: unresolved external symbol __imp_pthread_mutex_destroy referenced in function "public: void __cdecl loadsave_t::set_buffered(bool)" (?set_buffered@loadsave_t@@QEAAX_N@Z)
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_destroy
1>simgraph16.obj : error LNK2001: unresolved external symbol __imp_pthread_mutex_destroy
1>loadsave.obj : error LNK2019: unresolved external symbol __imp_pthread_barrier_destroy referenced in function "public: void __cdecl loadsave_t::set_buffered(bool)" (?set_buffered@loadsave_t@@QEAAX_N@Z)
1>simworld.obj : error LNK2001: unresolved external symbol __imp_pthread_barrier_destroy
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_exit referenced in function "void * __cdecl unreserve_route_threaded(void *)" (?unreserve_route_threaded@@YAPEAXPEAX@Z)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_mutexattr_init referenced in function "public: void __cdecl karte_t::init_threads(void)" (?init_threads@karte_t@@QEAAXXZ)
1>weg.obj : error LNK2001: unresolved external symbol __imp_pthread_mutexattr_init
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_mutexattr_destroy referenced in function "public: void __cdecl karte_t::destroy_threads(void)" (?destroy_threads@karte_t@@QEAAXXZ)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_pthread_mutexattr_settype referenced in function "public: void __cdecl karte_t::init_threads(void)" (?init_threads@karte_t@@QEAAXXZ)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_sem_init referenced in function "private: void __cdecl karte_t::world_xy_loop(void (__cdecl karte_t::*)(short,short,short,short),unsigned char)" (?world_xy_loop@karte_t@@AEAAXP81@EAAXFFFF@ZE@Z)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_sem_destroy referenced in function "private: void __cdecl karte_t::world_xy_loop(void (__cdecl karte_t::*)(short,short,short,short),unsigned char)" (?world_xy_loop@karte_t@@AEAAXP81@EAAXFFFF@ZE@Z)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_sem_wait referenced in function "private: static void * __cdecl karte_t::world_xy_loop_thread(void *)" (?world_xy_loop_thread@karte_t@@CAPEAXPEAX@Z)
1>simworld.obj : error LNK2019: unresolved external symbol __imp_sem_post referenced in function "private: static void * __cdecl karte_t::world_xy_loop_thread(void *)" (?world_xy_loop_thread@karte_t@@CAPEAXPEAX@Z)
1>weg.obj : error LNK2019: unresolved external symbol __imp_pthread_rwlock_destroy referenced in function "public: virtual __cdecl weg_t::~weg_t(void)" (??1weg_t@@UEAA@XZ)
1>weg.obj : error LNK2019: unresolved external symbol __imp_pthread_rwlock_rdlock referenced in function "public: void __cdecl weg_t::delete_all_routes_from_here(bool)" (?delete_all_routes_from_here@weg_t@@QEAAX_N@Z)
1>weg.obj : error LNK2019: unresolved external symbol __imp_pthread_rwlock_wrlock referenced in function "public: void __cdecl weg_t::add_private_car_route(class koord,class koord3d)" (?add_private_car_route@weg_t@@QEAAXVkoord@@Vkoord3d@@@Z)
1>weg.obj : error LNK2019: unresolved external symbol __imp_pthread_rwlock_unlock referenced in function "public: void __cdecl weg_t::add_private_car_route(class koord,class koord3d)" (?add_private_car_route@weg_t@@QEAAXVkoord@@Vkoord3d@@@Z)
1>libzstd_static.lib(threading.obj) : error LNK2019: unresolved external symbol __imp__beginthreadex referenced in function ZSTD_pthread_create
1>utils\openttd\lib\pthreadVC2.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
1>..\miniupnpc\miniupnpc.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 34 unresolved externals
1>Done building project "Simutrans-Extended.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


I higly suspect that there are some aspects which I have missed, either in which files I have downloaded, or the ones I have compiled myself.
I would be very happy for assistance with this.

jamespetts

I had similar problems - I think that the __imp prefix means that you are trying to use static linking on a library compiled for dynamic linking. Many of the libraries you will have to compile yourself as 64-bit versions are not available. This is generally not too hard as they all have Visual Studio projects, but some care is needed in making sure that you have the properties set for a static build. There was one case where one of the libraries (I now forget which one) had lots of different sets of properties and I had changed the wrong one, which caused great difficulties for some time.

The libraries that you seem to be missing appear to be:

pthreads
miniupnpc

The others do not seem to be an issue. Have a look at how you have set up those libraries in particular. Note that you can compile Simutrans-Extended without miniupnpc if you do not define support for this (this is just for easier self-hosting of servers using the graphical client), but pthreads is essential.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

prissi

The library needed is pthreadVC2.lib (or some other number, must match the pthread.h).

Ves

Thank you, both.

I made it through the pthreadVC2.lib, and I found the one on this site with the matching version number: ftp://sourceware.org/pub/pthreads-win32/prebuilt-dll-2-9-1-release/lib/x64/

I have not been able to make miniupnpc work at all, it gave me 7 error of similar nature as before, but slightly different:
Build started...
1>------ Build started: Project: Simutrans-Extended, Configuration: Debug 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>libzstd_static.lib(zstd_common.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>network.obj : error LNK2001: unresolved external symbol freeUPNPDevlist
1>network.obj : error LNK2001: unresolved external symbol upnpDiscover
1>network.obj : error LNK2001: unresolved external symbol UPNP_GetValidIGD
1>network.obj : error LNK2001: unresolved external symbol FreeUPNPUrls
1>network.obj : error LNK2001: unresolved external symbol UPNP_GetExternalIPAddress
1>network.obj : error LNK2001: unresolved external symbol UPNP_AddPortMapping
1>network.obj : error LNK2001: unresolved external symbol UPNP_DeletePortMapping
1>.\simutrans\Simutrans-Extended-debug.exe : fatal error LNK1120: 7 unresolved externals
1>Done building project "Simutrans-Extended.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

However, I managed to shutoff the miniupnpc, by editing the properties of the solution and remove the USE_UPNP from the Preprocessor Definitions. But strangely, it still required me to have the miniupnpc.lib located for it to continue compiling, which doesnt make sense to me...

The problem with the libzstd_static.lib resolved itself after I went over and made a release build, instead of a debug build. I got confused, because the directories from the Simutrans project file is looking at ..\zstd-1.4.4\build\VS2010\bin\x64_Debug, suggesting that it is supposed to be a debug build. Copying over from the x64_Release solved that.

Now it appears to compile,

Then I found the .dll files needed for it to run (on my windows 10) here:
freetype.dll: Found in the downloaded dependency (after compiling) in the path: freetype-2.10.1\objs
pthreadVC2.dll: Version 15.1.0.0 (the x64 version), found on this webbsite: https://www.dll-files.com/pthreadvc2.dll.html
libbz2.dll: Version 1.0.6 (the x64 version), found on this webbsite: https://github.com/philr/bzip2-windows/releases

Thank you for your help with this, it was quite exhaustive to navigate.....
Perhaps the OP can be updated as well? I would be happy to more organized describe step by step what I have done for this to compile.

jamespetts

Excellent, glad that you have got it working. If you were to suggest some edits to the OP, I should happily incorporate them.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Ok, I will gladly do that. In the mean time, I cannot compile a release build.

I have set the exact same dependencies as with the debug build, and removed the USE_UPNP from the Preprocessor Definitions, and I get these errors:

Build started...
1>------ Build started: Project: Simutrans-Extended, Configuration: Release 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>Generating code
1>0 of 21410 functions ( 0.0%) were compiled, the rest were copied from previous compilation.
1>  0 functions were new in current compilation
1>  0 functions had inline decision re-evaluated but remain unchanged
1>Finished generating code
1>CVTRES : fatal error CVT1100: duplicate resource.  type:MANIFEST, name:1, language:0x0409
1>LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
1>Done building project "Simutrans-Extended.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========


I realize there is a dublet somewhere of something, but what?

jamespetts

I no longer produce release builds in Visual Studio, only debug and optimised debug builds. Release builds are built on the Bridgewater-Brunel server. For this reason, the release build configuration is not set up to work. I suggest using the optimised debug build instead.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

Trying to compile with UPNP support is failing to find the library. Seems that Extended import it using  "#include <miniupnpc.h>" while Standard import it with "#include <miniupnpc/miniupnpc.h>". Is this because the miniupnpc changes are not yet fully incorporated or for other reason?

Ves

Oh, that explains alot!

So, what is the difference between them? What situations calls for the different build types?

jamespetts

Quote from: Ves on January 23, 2021, 03:57:47 PM
Oh, that explains alot!

So, what is the difference between them? What situations calls for the different build types?

Optimised debug has most of the optimisations enabled. This means that it will run a great deal faster than a standard debug build. However, the optimisations make the debugger less effective: it is often not possible to view the value of variables in the debugger because they have been optimised away.

Use this build when you want to test performance (including using the performance profiler) or want to run a map that is so big that it is unusably unresponsive with a standard debug build.

The ordinary debug build is slower, but it does not enable optimisations, which means that debugging is more effective. Use this build when testing using the debugger except in the situations outlined above.

For actually playing, I suggest using the binary downloaded from the Bridgewater-Brunel server.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Ves

Ok thanks, good to know.

One last thing:
Do I have to just stash in git the alterations I made to Simutrans-Extended.vcxproj in order to be able to do actual work?


---
Edit:

This is what I had to download and do to make Simutrans Extended compile with Microsoft Visual Studio 2019 on my 64 bit Windows 10 computer.

When Simutrans-Extended is downloaded fresh, the dependency directories will point to whatever directories the author of the Simutrans-Extended project made them point to. As the below list should be a complete set of dependencies, you can erase all existing entries from the include- and library directories.
I usually put my dependencies one folder up from where the Simutrans-Extended.sln is located. If you put your the same location, you can just copy/paste the entries from this post.
Please note that this guide is aimed towards a 64 bit compilation. I am unsure wether 32 bit is possible, but you would need to download and compile the 32 bit correspondence to all the below downloads instead.

Make sure that you are editing the project properties for both Debug x64 and Optimized debug x64, as those are the two compile modes currently available.



zstd-1.4.4
- Download v1.4.4.zip from here (direct download link): https://github.com/facebook/zstd/archive/v1.4.4.zip
- Unzip and put the folder zstd-1.4.4 in your dependency directory.
- Navigate to the file zstd.sln, located in zstd-1.4.4\build\VS2010 and open with MSVS 2019. Let it do any upgrades if it asks to.
- Set the configuration and platform to Release x64
- In the Solution Explorer rightclick on the project called libzstd and press build.
- This will create a file called libzstd_static.lib, which is what we need. Just leave it in place.

Simutrans-Extended project properties directories:
Include directory: ..\zstd-1.4.4\lib
Library directory: ..\zstd-1.4.4\build\VS2010\bin\x64_Release


freetype-2.10.1
- Download freetype-2.10.1.tar.gz from here: https://download.savannah.gnu.org/releases/freetype/
- Unzip and put the folder freetype-2.10.1 in your dependency directory.
- Navigate to the file freetype.sln, located in freetype-2.10.1\builds\windows\vc2010 and open it with MSVS 2019. Let it do any upgrades if it asks to.
- Set the configuration and platform to Release x64
- Build the solution.
- This will create a file called freetype.lib, which is what we need. Just leave it in place.
- Also it creates freetype.dll, but we will get back to this.

Simutrans-Extended project properties directories:
Include directory: ..\freetype-2.10.1\include\freetype
Library directory: ..\freetype-2.10.1\objs\x64\Release


OpenTTD essentials
- Download openttd-useful-6.0-win.zip from here (choose in the drop down box): https://www.openttd.org/downloads/openttd-useful-releases/latest.html
- Unzip and put the folder OpenTTD essentials in your dependency directory. Rename it to OpenTTD (otherwise it will not work).
- No more actions is needed with this dependency.

Simutrans-Extended project properties directories:
Include directory: ..\OpenTTD\shared\include
Library directory: ..\OpenTTD\win64\library


bzip2
- Download bzip2-dev-1.0.8.0-win-x64.zip from here: https://github.com/philr/bzip2-windows/releases
- Unzip and put the folder bzip2-dev-1.0.8.0-win-x64 in your dependency directory.
- No more actions is needed with this dependency.

Simutrans-Extended project properties directories:
Include directory: ..\bzip2-dev-1.0.8.0-win-x64
Library directory: ..\bzip2-dev-1.0.8.0-win-x64


miniupnpc
Disclaimer: I never made this dependency work on my computer, therefore this is a guide as to how to shut the feature requiring this dependency off. Unfortunately, the game still needs the files from this dependency to work, which is why we must download and install anyway.
- Download miniupnpc-2.2.1.tar.gz from here: http://miniupnp.free.fr/files/
- Unzip and put in the folder miniupnpc-2.2.1 in your dependency directory.
- Navigate to the file genminiupnpcstrings.vbs, located in miniupnpc-2.2.1\msvc and run it. Press "Open" on the security warning. This is a necessary first step!
- Then find the file miniupnpc.sln, also located in miniupnpc-2.2.1\msvc and open it with MSVS 2019. Let it do any upgrades if it asks to.
- Set the configuration and platform to Release Win32 (there is no x64 option)
- Build the solution (using the green "play" button).
- This will create a file called miniupnpc.lib, which is what we need. Just leave it in place.

Simutrans-Extended project properties directories:
Include directory: ..\miniupnpc-2.2.1
Library directory: ..\miniupnpc-2.2.1\msvc\Release

How to shut off miniupnpc:
- In the Simutrans-Extended project properties, navigate the menu to C/C++ -> Preprocessor.
- Click edit on the Preprocessor Definitions.
- Locate the phrase USE_UPNP in the list, and remove it entirely.


Pthreads
- Download pthreadVC2.lib from here: sourceware.org/pub/pthreads-win32/prebuilt-dll-2-9-1-release/lib/x64/
- Put the pthreadVC2.lib into this directory: Simutrans-extended\utils\openttd\lib
Note: If you have problems with pthread when compiling, make sure that the version you download matches the version in pthread.h (#define PTW32_VERSION) location: Simutrans-extended\utils\openttd

Simutrans-Extended project properties directories: (note that these directories is inside the Simutrans-extended project folder)
Include directory: utils\openttd
Library directory: utils\openttd\lib


Now, just to sum up:
Complete list of Include Directories:

..\zstd-1.4.4\lib
..\freetype-2.10.1\include\freetype
..\OpenTTD\shared\include
..\bzip2-dev-1.0.8.0-win-x64
..\miniupnpc-2.2.1
utils\openttd


Complete list of Library Directories:

..\zstd-1.4.4\build\VS2010\bin\x64_Release
..\freetype-2.10.1\objs\x64\Release
..\OpenTTD\win64\library
..\bzip2-dev-1.0.8.0-win-x64
..\miniupnpc-2.2.1\msvc\Release
utils\openttd\lib



Now compile the game using the Debug x64 or Optimized debug x64 configuration.
Only a few things left to do:

Download/locate these three .dll files:
- freetype.dll: Found in the downloaded dependency (after compiling) in the path: freetype-2.10.1\objs
- pthreadVC2.dll: Version 15.1.0.0 (the x64 version), found on this webbsite: https://www.dll-files.com/pthreadvc2.dll.html
- libbz2.dll: Version 1.0.6 (the x64 version), found on this webbsite: https://github.com/philr/bzip2-windows/releases
After you have downloaded/located all three, put them in this folder: Simutrans-extended\simutrans
Note that this folder might not exist until you run the compiler at least once.

jamespetts

Quote from: Roboron on January 22, 2021, 11:17:20 PM
Trying to compile with UPNP support is failing to find the library. Seems that Extended import it using  "#include <miniupnpc.h>" while Standard import it with "#include <miniupnpc/miniupnpc.h>". Is this because the miniupnpc changes are not yet fully incorporated or for other reason?

I have moved this post into a more appropriate topic, as this was not specifically about incorporating changes from Standard. Robron - I suggest that you read the above discussion and follow the steps that Ves used to get this working.

Edit:  Incidentally, Ves, that is very helpful - I have put a link to your post in the first post of this page and directed people to it. Thank you.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Roboron

Quote from: jamespetts on January 24, 2021, 11:38:57 AMI have moved this post into a more appropriate topic, as this was not specifically about incorporating changes from Standard. Robron - I suggest that you read the above discussion and follow the steps that Ves used to get this working.

I'm not using VSCode to compile Extended. But anyway, I don't really need help compiling Extended with miniupnpc support, I just can change the imports to match Standard's and that will work. I just wanted to know why it is not imported the same way as Standard does, since now I have to write a patch to compile Extended the same way I compile Standard. Sorry if I didn't post in the correct thread.

P.D.: But be cautious when moving messages, since I was not susbcribed to this thread and I got no notification email. I just discovered this because I look at the RSS from time to time.

Ranran(retired)

#54
Before I retire, I plan to leave some documentation for newcomers to coding, but I'm stuck on the first step.
It is a guide for beginners to build simutrans extended with MSVC. Most of Japanese use Bill Gates. So MSVC would be a good place to start.

What I expect is that once a newbie installs Visual studio and downloads the simutrans extended source code from the github repository, they can just click on Simutrans-Extended.sln and start coding.
It will make it easier for new people to join the contribution.
But sadly this has never happened before.
I think a lot of newbies will stumble on not being able to compile it correctly. And their challenge ends there.

Current problem is:
- Since the target directory for include files and library files is the parent directory, noobs has to provide the libraries himself.
- Many required files in utils/openttd/ but not linked.
- Some necessary files are missing.
- Incorrect version of libpng.
- Somehow the USE_FREETYPE; option causes the build to fail. I found a solution by turning this off. This doesn't happen in the environment I usually use, but if I use the master branch as it is, it fails. I don't know what caused it.

I've added the missing files and fixed them so that newbies can quickly try coding.
https://github.com/Ranran-the-JuicyPork/simutrans-exp/tree/ready-to-build-msvc

What do you think about this change? Are there any problems? I would appreciate hearing you guys opinion.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)