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

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
I have a question about Orbiter 2016 and I hope this is the appropriate place to ask it.

Does Orbiter 2016 accurately model the Earth as an oblate spheroid and if yes, is the atmosphere modeled to fit the spheroid? I am asking about the shape here, not the gravitational model.

While working on the Virtual AGC for NASSP we have noticed that multiple programs have trouble with the spherical Earth in Orbiter 2010. For example, the program 22 of the AGC is used to track a landmark on Earth. As an input the program wants geocentric latitude, longitude and altitude above the Fischer ellipsoid. The AGC then calculates the position vector of the landmark from these inputs. For a landmark on the Earth, we kind of have to trick the AGC to make it work. The longitude is fine, but latitude and altitude have to be adjusted so the AGC finds the correct position of the landmark on the spherical Earth. In NASSP we have set the radius of the spherical Earth to the radius at Cape Canaveral.

Similarly the entry interface is defined as 400k ft altitude above the Earth. Again, the spherical vs. ellipsoid Earth is relevant in some calculations the AGC does. The AGC actually has a program to calculate midcourse corrections itself. For low latitudes at entry interface, where the radius difference is more pronounced, the maneuvers the AGC is calculating become increasingly inaccurate.

I have set a Delta Glider at different points on the Earth on oceans and the radius always seemed to be identical. So if despite the awesome terrain models in Orbiter 2016 the average shape of the Earth is still not an oblate spheroid, consider this a feature request. :thumbup:

I've been thinking about this, as part part of figuring out how the shuttle launched to a 28.45º orbit from a pad at 28.6º, and found that the pad is at 28.6º geodetic latitude, and at 28.45º geocentric latitude. :hailprobe:
Thus, launching east produces a 28.45º orbit... but I get a 28.6º :uhh: (just tested it with DG). So I also think the Earth is "too spherical".
 

dbeachy1

O-F Administrator
Administrator
Orbiter Contributor
Addon Developer
Donator
Beta Tester
Joined
Jan 14, 2008
Messages
9,214
Reaction score
1,560
Points
203
Location
VA
Website
alteaaerospace.com
Preferred Pronouns
he/him
Do you have "Nonspherical gravity sources" enabled in the Orbiter launchpad settings?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Do you have "Nonspherical gravity sources" enabled in the Orbiter launchpad settings?

This only influences the gravitational field of the orbital bodies, not the actual shape of the e.g. Earth in Orbiter. So the Earth will behave gravitationally as if it was non-spherical, but it doesn't change its shape.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
Also about the "missing oblateness" of the planets: Jupiter and Saturn should be visibly flat at the poles, but are shown as spheres. It's probably not a case of functionality, like mentioned above for the case of Earth, but more a "visual issue".
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Also about the "missing oblateness" of the planets: Jupiter and Saturn should be visibly flat at the poles, but are shown as spheres. It's probably not a case of functionality, like mentioned above for the case of Earth, but more a "visual issue".

For NASSP it is a functionality issue. The Apollo Guidance Computer assumes the Earth to be an ellipsoid (hardcoded, not configurable). And that geometry is used for the star/horizon measurements that can be done with the sextant for onboard navigation. All that basically works in NASSP, just the shape of the Earth doesn't properly cooperate and so we haven't been able to do onboard navigation that is accurate enough to be autonomous without the need to update the state vector in the AGC with external tools (MFDs). This is more of a "nice to have" feature, because onboard navigation was always just a backup during Apollo. I hope the right shape of the planets and moons etc. gets implemented in Orbiter at some point though.
 

GLS

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
For NASSP it is a functionality issue. The Apollo Guidance Computer assumes the Earth to be an ellipsoid (hardcoded, not configurable). And that geometry is used for the star/horizon measurements that can be done with the sextant for onboard navigation. All that basically works in NASSP, just the shape of the Earth doesn't properly cooperate and so we haven't been able to do onboard navigation that is accurate enough to be autonomous without the need to update the state vector in the AGC with external tools (MFDs). This is more of a "nice to have" feature, because onboard navigation was always just a backup during Apollo. I hope the right shape of the planets and moons etc. gets implemented in Orbiter at some point though.

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

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
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

Active member
Joined
Mar 20, 2008
Messages
482
Reaction score
66
Points
28
So what about cloud microtextures? They do not seem to be working.
 

crisbeta

Member
Joined
May 27, 2013
Messages
140
Reaction score
4
Points
18
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!
 

kash01

New member
Joined
Aug 31, 2016
Messages
18
Reaction score
0
Points
1
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
 

kuddel

Donator
Donator
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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
Joined
Oct 20, 2007
Messages
4,088
Reaction score
204
Points
103
Location
Tucson, AZ
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
Joined
Apr 1, 2008
Messages
2,064
Reaction score
507
Points
113
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
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

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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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
Joined
Jul 14, 2012
Messages
508
Reaction score
20
Points
33
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
Joined
Mar 31, 2008
Messages
2,448
Reaction score
462
Points
83
Website
orbit.medphys.ucl.ac.uk
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

Well-known member
Orbiter Contributor
Addon Developer
Beta Tester
Joined
Mar 18, 2008
Messages
4,390
Reaction score
577
Points
153
Location
Vienna
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

Well-known member
Orbiter Contributor
Addon Developer
Joined
Mar 22, 2008
Messages
5,873
Reaction score
2,868
Points
188
Website
github.com
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:
 
Top