New Orbiter SVN commit (r.71, Oct 14 2017)

[indy91]

Quote:

Originally Posted by GLS

 In the Earth case it is a functionality, but I was saying that for Jupiter and Saturn it's a visual issue.

Ah yeah, great reading comprehension on my part. But at least I got my request for fixing that in a future Orbiter release in there again.

[Marg]

So what about cloud microtextures? They do not seem to be working.

[crisbeta]

I made a fresh installation of Orbiter2016 and OrbiterBeta.

When I installed hi-res textures I found the following issues:
- only download mirror 1 (Europe) have label files
- label files are not included in torrents
- there is no torrent for Mars HRSC files

The biggest issue for me is the third. Mars HRSC files are big. A torrent file will make download faster and after you have finished you can seed for others.

Thank you for this wonderful simulator!

[kash01]

hey how can idownload new beta version and textures i have been looking on forum butit confused me a lot help pls

[crisbeta]

Orbiter Beta:
http://orbit.medphys.ucl.ac.uk/betainstall.html

Orbiter download (select your best mirror for highres):
http://orbit.medphys.ucl.ac.uk/download.html

[kuddel]

Hi Martins,

today my build of D3D9Client failed with a strange linker error:

orbitersdk.lib(Orbitersdk.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MT_StaticRelease' in AABBUtil.obj [c:\Program Files (x86)\Orbiter\D3D9Client\Orbitersdk\D3D9C
lient\D3D9Client.vs2015.vcxproj]
  ..\..\Modules\Plugin\D3D9Client.dll : fatal error LNK1319: 1 mismatches detected [c:\Program Files (x86)\Orbiter\D3D9Client\Orbitersdk\D3D9Client\D3D9Client.vs2015.vcxproj]

At first I was really puzzled 'cause I could not find anything that I did that would explain this,
but after hours of head scratching I realized that my build-scripts automatically pull the HEAD revision of the Orbiter BETA repository!
You have committed a new revision! Aha!

Now to the "error":
It seems that revision 74 of Orbitersdk\lib\Orbitersdk.lib is a "debug version" or "different linked version" that does not fit to the rest...
As soon as I revert Orbitersdk\lib\Orbitersdk.lib to r73 (keeping all the rest of r74) everything is OK.

So could you please check if that's the case[1]?

Regards,
Kuddel

[1] ...and commit a correct one

[martins]

Oh, no. I am in the process of switching my compiler toolchain to VS2015. I guess it was naive to think that this could work seamlessly.

Is it possible that newer versions of VS don't allow linking together modules that have been compiled with a mix of /MT and /MD compiler options? That would be pretty catastrophic for Orbiter, because it would require all addons to be compiled with the same options (and maybe even with the same VS version?) This page seems to suggest so.

I tried to switch the option for the orbitersdk.lib from /MD to /MT, but then I get the same error as you do in reverse for all plugins compiled with the /MD option.

As a last resort I have now compiled orbitersdk.lib with the VS2008 runtimes. This appears to fix the /MT /MD incompatibility for me, but it seems like a hack at best.

I have pushed a new commit with the recompiled orbitersdk.lib. Can you check if this works for you?

Can you think of a better way to resolve this problem?

[Quick_Nick]

Quote:

Originally Posted by martins

 Oh, no. I am in the process of switching my compiler toolchain to VS2015. I guess it was naive to think that this could work seamlessly.

Is it possible that newer versions of VS don't allow linking together modules that have been compiled with a mix of /MT and /MD compiler options? That would be pretty catastrophic for Orbiter, because it would require all addons to be compiled with the same options (and maybe even with the same VS version?) This page seems to suggest so.

I tried to switch the option for the orbitersdk.lib from /MD to /MT, but then I get the same error as you do in reverse for all plugins compiled with the /MD option.

As a last resort I have now compiled orbitersdk.lib with the VS2008 runtimes. This appears to fix the /MT /MD incompatibility for me, but it seems like a hack at best.

I have pushed a new commit with the recompiled orbitersdk.lib. Can you check if this works for you?

Can you think of a better way to resolve this problem?

This post here has one answer from 2010 agreeing that MT and MD are mutually exclusive, but there are two more recent answers with zero votes that suggest workarounds.
I'm not sure how the "/MT /Zl" approach is supposed to work, but I suppose it could be worth a try.

Sent from my SM-G930U using Tapatalk

[kuddel]

Quote:

Originally Posted by martins

 Oh, no. I am in the process of switching my compiler toolchain to VS2015. I guess it was naive to think that this could work seamlessly.

Never underestimate the possible impact of "small changes"

But back to the issue:
I forgot to mention in my post that I was using VS2015 as well. I have access to VS2015 (@home) and VS2017 (@work) so I can give you this table of results so far

Toolchain	Orbiterlib revision	Result
VS 2015	73	PASS
VS 2015	74	FAIL
VS 2015	75	PASS
VS 2017	73	PASS
VS 2017	74	FAIL
VS 2017	75	PASS

Note: the missing cell(s) will be filled once I get back home

Quote:

Originally Posted by martins

 Can you think of a better way to resolve this problem?

Sorry, no. I was also very puzzled as this came up. Even as I used the same toolchain!

I would be happy to change the D3D9Client project to work with the "original r74", but this might not be the case for any other addon.
I'll have to take a deeper look once I'm back home.
So stay tuned...

Kuddel

[martins]

What I don't understand is this: why should there be a conflict in the first place? When orbitersdk.lib is compiled with /MT, aren't all references to the runtime libraries already resolved in the object? Why would anything linking to orbitersdk.lib care about what version of the runtimes have been used? Why does a statically linked static library still have a runtime dependency?

I realise that this doesn't contribute in any way to solving the problem at hand - just curious.

[Dantassii]

A few years ago I started helping out with the IMS 2.0 with VS 2015 instead of 2013. I found that although the code would compile, so many changes were made to the project files that the resulting project could no longer be worked on using VS 2013. I ended up removing VS 2015 and installing VS 2013 to fix this issue.

I also have experience at my 'day job' with converting a system (of about 20 solutions with 1-2 projects per solution) from VS 2010 to VS 2013. In that case, every single module had to be opened up in VS 2013, recompiled, and then checked back into SVN before we could deploy any of our projects to our web servers. We are not looking forward to upgrading to VS 2017 in a year or so....

IMO, if you need/want to upgrade to a newer version of VS, it's probably for the best that everyone upgrade to the new version and not attempt to compile parts of Orbiter with 1 version and parts with another version.

You can send your thanks to Microsoft for this....

Dantassii
HUMONGOUS IMS shipbuilder

[martins]

Ok, looks like the 2008 runtime hack for orbitersdk.lib is working at least for the D3D9 client, so I'll stick to that until something better comes along.

It might be a good idea for other developers to try the latest SVN commit, so I can get an idea if things are majorly broken as a result of the compiler switch.

Quote:

Originally Posted by Quick_Nick

 I'm not sure how the "/MT /Zl" approach is supposed to work, but I suppose it could be worth a try.

For the record, I tried this and it didn't make a difference for me.

[Face]

Quote:

Originally Posted by martins

 It might be a good idea for other developers to try the latest SVN commit, so I can get an idea if things are majorly broken as a result of the compiler switch.

I've done a quick test against OMP (which still is a 2008 solution). It had no problems to link against the new lib.

[GLS]

Quote:

Originally Posted by martins

 It might be a good idea for other developers to try the latest SVN commit, so I can get an idea if things are majorly broken as a result of the compiler switch.

I was just in the shower thinking that...
When I get home tonight I'll try compiling SSU with r74 and r75 (it works with r73), and post the results here.

---------- Post added 08-11-18 at 12:20 AM ---------- Previous post was 08-10-18 at 08:31 AM ----------

So, here is the promised data!
There is an issue running any scenario as a CTD occurs after loading Titan.dll (not sure what). Anyway, I edited the Solar System (yes, it is funny to say that ) and just left the Earth and the Moon and it loaded fine. So I picked one of our projects to show here, the ones that use DlgCtrl.lib have the same result for that lib.


VS2017 v15.7.3
SSU r2891 (+ some changes that shouldn't affect the subject at hand)
Windows SDK Version: 10.0.15063.0
Platform Toolset: Visual Studio 2017 (v141)


>>> OSFS r74 <<<
>> SSU debug <<
Error LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in SSU_Centaur.obj SSU_Centaur trunk\Orbitersdk\Space Shuttle Ultra\Centaur\Orbitersdk.lib(Orbitersdk.obj)
Error LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in SSU_Centaur.obj SSU_Centaur trunk\Orbitersdk\Space Shuttle Ultra\Centaur\Orbitersdk.lib(Orbitersdk.obj)


>>> OSFS r74 <<<
>> SSU release <<
Warning LNK4099 PDB 'Orbitersdk.pdb' was not found with 'Orbitersdk.lib(Orbitersdk.obj)' or at 'trunk\Modules\Orbitersdk.pdb'; linking object as if no debug info SSU_Centaur trunk\Orbitersdk\Space Shuttle Ultra\Centaur\Orbitersdk.lib(Orbitersdk.obj)
CTD after Titan.dll is loaded, fine otherwise


>>> OSFS r75 <<<
>> SSU debug <<
Warning LNK4099 PDB 'vc90.pdb' was not found with 'Orbitersdk.lib(Orbitersdk.obj)' or at 'trunk\Modules\vc90.pdb'; linking object as if no debug info SSU_Centaur trunk\Orbitersdk\Space Shuttle Ultra\Centaur\Orbitersdk.lib(Orbitersdk.obj)
CTD after Titan.dll is loaded, fine otherwise


>>> OSFS r75 <<<
>> SSU release <<
Warning LNK4099 PDB 'vc90.pdb' was not found with 'Orbitersdk.lib(Orbitersdk.obj)' or at 'trunk\Modules\vc90.pdb'; linking object as if no debug info SSU_Centaur trunk\Orbitersdk\Space Shuttle Ultra\Centaur\Orbitersdk.lib(Orbitersdk.obj)
CTD after Titan.dll is loaded, fine otherwise



Last 2 lines on log on the "Titan CTDs":
000000.000: Module Titan.dll ............. [Build 180807, API 180809]
SATSAT Titan: Terms 100


Back to the main issue: I'm not going to pretend I know exactly what is going with this, but it seems to me that this issue comes from the more recent versions of VS "enforcing" objects to use the same CRT library. Now, debug builds use one version, and release builds use another. So in my humble opinion, I think that both a release and a debug version of Orbiter's libraries have to be provided, so that projects can link to the adequate one according to their build, as it is done with the CRT stuff. Now, I don't know if this affects orbiter.exe, or "already compiled addons" like OrbiterSound or some other older addon.

One thing I noticed is that the framerate "widget" at the top of the window is now a bit fuzzy, and the rest also looks +/- the same. Also, the window appears to have a thicker frame (this one is not an issue, I just noticed it).

---------- Post added at 12:48 PM ---------- Previous post was at 12:20 AM ----------

I played a bit more with the "Titan.dll CTD", and indeed it seems to be the cause of the CTD, as removing Titan from the Solar System fixes this issue.

Also, I decided to take a flight to Earth's South Pole, but never got there... memory usage goes thru the roof and framerate goes thru the floor.

[martins]

Thanks for the detailed analysis!

Regarding the Titan issue: I recently created new textures for Titan in Orbiter2016 format (can be downloaded here) and I realised that I may have inadvertently put the config file for this new texture set into the commit.

Can you try one of the following:

• replace Config/Titan.cfg with SVN.r73 or earlier (or just remove the lines "TileFormat = 2; CloudFormat = 2; LabelFormat = 2), or
• Download the .tree files for the new textures and put them into Textures/Titan

If the first of these works, I'll revert the Titan.cfg to the old version for the next commit.

Regarding the Debug/Release conflict: Do I understand correctly that you can no longer do a debug build of your own module if the host Orbiter application is a release build? This seems bizarre. Anyway, I don't see a reason not to provide the debug builds, although I still don't really understand why the new VS version is now so picky about matching build options. Would this only require the debug binaries, or any additional files? The warnings talk about pdb files. Is this where the debug info lives these days? Is the debug information no longer part of the binary? If these additional files are required, it might changing my build system a bit, because at the moment pdb files aren't part of the deployment set.