![]() |
|
Orbiter Beta Topics related to Beta releases of Orbiter and Orbiter development. |
![]() |
|
Thread Tools |
![]() |
#481 |
Addon Developer
![]() |
![]() Quote:
![]() |
![]() |
![]() |
![]() |
#482 |
Orbinaut
|
![]()
So what about cloud microtextures? They do not seem to be working.
|
![]() |
![]() |
![]() |
#483 |
Orbinaut
|
![]()
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! |
![]() |
![]() |
![]() |
#484 |
Orbinaut
|
![]()
hey how can idownload new beta version and textures i have been looking on forum butit confused me a lot help pls
|
![]() |
![]() |
![]() |
#485 |
Orbinaut
|
![]()
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 |
![]() |
![]() |
![]() |
#486 |
Donator
![]() |
![]()
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] 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. |
![]() |
![]() |
Thanked by: |
![]() |
#487 |
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? |
![]() |
![]() |
![]() |
#488 |
Passed the Turing Test
![]() |
![]() Quote:
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 |
![]() |
![]() |
![]() |
#489 | |||||||||||||||||||||
Donator
![]() |
![]() Quote:
![]() 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
Quote:
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. |
|||||||||||||||||||||
![]() |
![]() |
![]() |
#490 |
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. |
![]() |
![]() |
![]() |
#491 |
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 |
![]() |
![]() |
![]() |
#492 |
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. Quote:
|
![]() |
![]() |
![]() |
#494 |
Addon Developer
![]() |
![]() Quote:
![]() 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 ![]() 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. |
![]() |
![]() |
Thanked by: |
![]() |
#495 |
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:
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. |
![]() |
![]() |
![]() |
|
Thread Tools | |
|
|
Quick Links | Need Help? |