Please try out the second release candidate.
It's available as ZIP and MSI package:
This supersedes the RC.1 package. For package details see the RC.1 description which still applies.
This RC addresses various points raised with RC.1:
It's available as ZIP and MSI package:
- ZIP: http://mirror.orbiter-radio.co.uk/orbiter/assets/packages/Orbiter_RC/Orbiter2016.zip
- MSI: http://mirror.orbiter-radio.co.uk/orbiter/assets/packages/Orbiter_RC/Orbiter2016.exe
This supersedes the RC.1 package. For package details see the RC.1 description which still applies.
This RC addresses various points raised with RC.1:
This issue should be fixed. Selecting a base target in the Map MFD should now activate the target heading marker in the Surface HUD compass ribbon.The Surface mode HUD always used to have a little marker pointing to the direction of the spaceport you were headed to. I see the .doc still says it's there, in Section 14.3. But I can't bring it up. It neither triggers off a spaceport selected in an MFD, nor using CTRL-R. How do I get the blasted surface marker to work?
This issue should be fixed. The zlib.dll library Orbiter uses has now been compiled with the MSVC90 toolchain, the same as the Orbiter core. Please let me know if you find any other MSVC120 dependencies.I am getting an error: MSVCR120.dll missing
I think we need a list of requirements for Orbiter 2016.
Like: microsoft redistributable 2013 ???
This issue should be fixed. The DG attitude indicator now displays altitude above ground at lower altitudes.2) The alt readout on the DG attitude indicator does not display negative alt (ie <planetRad) correctly e.g. /Delta-Glider/Brighton Beach.scn shows 2.564k alt. at the start. Maybe it should show Radio Alt like the HUD?
This issue should be fixed now.Minor point: Orbiter 2016 MSI installs to folder Orbiter2014.
This issue has been addressed. I would like to hear from anybody who observed related problem if has been fixed / has changed in behaviour / is unchanged in this RC.There is a CTD giving some trouble. I was investigating a cloud layer related anomaly when I noticed it. D3D9Client is required to produce it, haven't noticed it with the inline engine. Vertical sync seems to have major effect in ability to reproduce it. With the sync enabled it becomes very hard to reproduce.
1. Load "DG Mk4 in Orbit" scenario
2. Choose Camera -> Target -> Sun -> Earth -> Apply -> Close the window -> Zoom a bit closer to the Earth
3. Frequently change between the two highest time accelerations while rotating the Earth with mouse.
Here it takes something like 10s-40s to produce the CTD without vertical sync. With the sync enable it's something like 5-10 minutes.
There are no references to any other software in the call stack than the Orbiter.