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

indy91

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

Marg

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

crisbeta

Member
Hi-res textures

I made a fresh installation of Orbiter2016 and OrbiterBeta.

When I installed hi-res textures I found the following issues:
- 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

New member

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

kuddel

Donator
Donator
Orbitersdk.lib r74 DEBUG build

Hi Martins,

today my build of D3D9Client failed with a strange linker error:
Code:
[COLOR="Red"]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][/COLOR]
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! :facepalm:

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

Last edited:

martins

Orbiter Founder
Orbiter Founder
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

Passed the Turing Test
Donator
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

Donator
Donator
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" :lol:

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
No code has to be inserted here.
Note: the missing cell(s) will be filled once I get back home

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

Last edited:

martins

Orbiter Founder
Orbiter Founder
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

HUMONGOUS IMS shipbuilder
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

Orbiter Founder
Orbiter Founder
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.

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

Beta Tester
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

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... :lol:
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 :lol 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. :shrug:

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

martins

Orbiter Founder
Orbiter Founder
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.

GLS

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.
Yep, that was it! Both solutions work.
Large issue: when I went to Titan, I happened to end up on the night side and landed at a place below 0m (as displayed on SurfaceMFD), which exposed an problem: the vessels are always illuminated when below 0m altitude. I've confirmed this on the Moon. Should I create a ticket for this?

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?
For SSU that seems to be the case, but I don't about everybody else. And AFAIK, only the libraries would need to match.

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.
This link has some info about the .pdb files. At least for the release version, I'd add a 3rd option: no debug info. IMO even for the debug version the debug info is not needed for us devs, as we are not debugging the code in the lib. :shrug: But this might be a PITA for you having to turn that off and on before making the lib public.

martins

Orbiter Founder
Orbiter Founder
I've pushed a new commit r.76 which
• Reverts Titan.cfg to reference the default textures
• Should fix the lighting problem for vessels below planet reference radius
• Compiler option change: all release binaries are set to debug info "none", except for orbitersdk.lib, which is compiled with "old style" debug info (/Z7).
The reason orbitersdk.lib is compiled with a different debug setting is because it is compiled with the VS2008 toolset, which doesn't seem to support "none".

I haven't set up the deployment of the debug libraries, but let me know if you get any changes regarding warning when you link against this version.

There is also a new OVP r.64 commit which also addresses the "vessel below planet radius" lighting problem. Also of interest for graphics client developers may be r.63 which fixes a cloud layer render problem when the camera is below the cloud layer.

kuddel

Donator
Donator
After I've read many pages about this "/MD, /MT, /LD" issue it seems that Microsoft is recommending to publish the lib in all the needed formats...
Like
• orbiterlibrtd.lib (Debug Multithreaded using DLL)
That and you (as the addon developer) have to link against the according lib.

This is neither nice nor convenient ...and why the ONE lib worked with VS2008 remains still a mystery to me.

Still puzzled/disappointed,
Kuddel

---------- Post added at 23:39 ---------- Previous post was at 23:33 ----------

...of course only the really recommended ones (Multithreaded DLL or Multithreaded) should be provided in debug and release versions.
I'm, not sure if you would recommend the Single-threaded linkage at all.