Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development.

Reply
 
Thread Tools
Old 05-03-2018, 01:32 PM   #481
indy91
Addon Developer
Default

Quote:
Originally Posted by GLS View Post
 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.
indy91 is online now   Reply With Quote
Old 06-16-2018, 08:53 AM   #482
Marg
Orbinaut
Default

So what about cloud microtextures? They do not seem to be working.
Marg is offline   Reply With Quote
Old 07-12-2018, 06:54 PM   #483
crisbeta
Orbinaut
Default Hi-res textures

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!
crisbeta is offline   Reply With Quote
Old 07-29-2018, 01:54 PM   #484
kash01
Orbinaut
Default how can i download

hey how can idownload new beta version and textures i have been looking on forum butit confused me a lot help pls
kash01 is offline   Reply With Quote
Old 07-29-2018, 05:53 PM   #485
crisbeta
Orbinaut
Default

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
crisbeta is offline   Reply With Quote
Old 08-08-2018, 10:27 PM   #486
kuddel
Donator
Bug Orbitersdk.lib r74 DEBUG build

Hi Martins,

today my build of D3D9Client failed with a strange linker error:
Code:
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

Last edited by kuddel; 08-08-2018 at 10:46 PM.
kuddel is online now   Reply With Quote
Thanked by:
Old 08-09-2018, 01:35 AM   #487
martins
Orbiter Founder
Default

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?
martins is offline   Reply With Quote
Thanked by:
Old 08-09-2018, 06:21 AM   #488
Quick_Nick
Passed the Turing Test
 
Quick_Nick's Avatar
Default

Quote:
Originally Posted by martins View Post
 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
Quick_Nick is offline   Reply With Quote
Thanked by:
Old 08-09-2018, 08:35 AM   #489
kuddel
Donator
Default

Quote:
Originally Posted by martins View Post
 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
ToolchainOrbiterlib revisionResult
VS 201573PASS
VS 201574FAIL
VS 201575PASS
VS 201773PASS
VS 201774FAIL
VS 201775PASS
Note: the missing cell(s) will be filled once I get back home

Quote:
Originally Posted by martins View Post
 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 by kuddel; 08-09-2018 at 06:35 PM.
kuddel is online now   Reply With Quote
Thanked by:
Old 08-09-2018, 09:34 AM   #490
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Old 08-09-2018, 11:14 AM   #491
Dantassii
HUMONGOUS IMS shipbuilder
Default

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
Dantassii is offline   Reply With Quote
Old 08-10-2018, 03:13 AM   #492
martins
Orbiter Founder
Default

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 View Post
 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.
martins is offline   Reply With Quote
Old 08-10-2018, 07:07 AM   #493
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by martins View Post
 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.
Face is offline   Reply With Quote
Thanked by:
Old 08-11-2018, 11:48 AM   #494
GLS
Addon Developer
 
GLS's Avatar
Default

Quote:
Originally Posted by martins View Post
 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.
GLS is online now   Reply With Quote
Thanked by:
Old 08-11-2018, 01:30 PM   #495
martins
Orbiter Founder
Default

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.
martins is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Space Flight Simulator > Orbiter Beta


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 09:00 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.