OHM BaseSyncMFD 3.3 for Orbiter 2016

[OrbitHangar]

Author: adswnj

Minor update in v3.3: fix MM data transfer bug to BurnTimeCalculator. 

New in v3.2: Updated to use MMExt2 natively (so no more Error 126). No pre-requisites - however for best experience, please install ModuleMessagingExt v2.1 or later. 

Base Sync is a utility to determine the best orbit for reentry to arrive at a target base, and then to determine the deorbit burn information. It predicts your closest approach on up to 99 orbits, and calculates the optimal plane change for direct over-flight of the base, and the retro-burn for re-entry on the desired angle, anticipation and entry interface altitude. 



DOWNLOAD

 

[ADSWNJ]

This is a clean recompile on Visual Studio 2015 Community Edition, for Orbiter 2016 rc.1. Don't run on the old Orbiter 2010 please!

Watch out for those mandatory pre-requisites.

 

[Fabri91]

Nice, thanks!

 

[Kyle]

Downloading now!!!

 

[ADSWNJ]

Interested in any feedback from experts using BaseSync MFD. I had a strange thing happen when compiling it today: there were functions acosh() and asinh() defined in a sub-module (BStools.cpp) that were trying to overwrite the standard math library. The VC++ settings were suppressing the error on my previous compiles, so I only saw it today doing a clean compile on VS2015CE. I could not find any references to them, so they are now commented out (to get a clean compile).

99% certain everything will be OK, but if anyone sees weirdness and has a .scn file, I will take a look.

 

[Mojave]

Thanks for the update, mate. Truly an invaluable tool!

 

[ADSWNJ]

Thanks for the update, mate. Truly an invaluable tool!

You are very welcome. I come to new comments on these threads expecting to find things breaking, so comments like this make me real happy!

 

[Fabri91]

I did a test flight (standard XR-2 to LEO and back taking off and landing at KSC) and everything seems fine so far!

 

[turtle91]

Interested in any feedback from experts using BaseSync MFD. I had a strange thing happen when compiling it today: there were functions acosh() and asinh() defined in a sub-module (BStools.cpp) that were trying to overwrite the standard math library.

Being not an expert...as you know...
I got problems to load several MFDs today, so I decided to re-build the affected MFDs on my own. Basesync was one of them.

I have not the latest C++-runtimes installed...which might explain the problems I had...however:
I am still using MS Visual Studio 2010 and I was not able to compile BaseSyncMFD caused by the "acosh()" function.

Yes, it has been commented out, but was called later on within the code, so I got an undef symbol error. (So a different "math library" in MSVS2010 ?)

After removing the comments, the compile went fine, but I need to do some further testing.

And...just for your information GS2 was crashing RC2, so I compiled it against latest OrbiterSDK, and it works fine now in RC2. (no changes needed...just re-compile).

 

[ADSWNJ]

Never thought to do that. I wonder is there is a more subtle dependency in VS2010 that is now fixed in VS2015. Mmm...

Anyway ... get the latest runtimes and try the official code .

 

[slaver0110]

Quick Question...
I'm having trouble getting my system to install the VC2015 runtimes (it's been a headache for a couple of days now).
Does the BaseSyncMFD for 2010 work with 2016RC2?

 

[turtle91]

You could try the attached build.
I have rebuild the MFD against Orbiter2016 RC2, but used older C++ runtimes.
Maybe it works for you. But should be not a permanent solution...
In my case, the download-speed was about 5kbs a couple of days ago...so I decided to build it for my system...instead waiting for the runtime-download for ages....:huh:

 

[slaver0110]

Perfect! Thanks for that. Will test out tonight.

 

[ADSWNJ]

Quick Question...
I'm having trouble getting my system to install the VC2015 runtimes (it's been a headache for a couple of days now).
Does the BaseSyncMFD for 2010 work with 2016RC2?

What problem are you having with the runtimes?

 

[slaver0110]

What problem are you having with the runtimes?

After I got home this afternoon, I forced myself to sit down and mull over the problem. I'm happy to report that it's been resolved, however just in case anyone else here has the same issue it might be useful to post the solution.

I downloaded the VS2015x64 runtime installer from MS, and ran it under Admin rights. It completed as far as about 98%, then told me that the "Setup had Failed". The Dependency Checker I use said that none of the DLL's that were required for BaseSync were even present on my system (and therefore didn't deploy from the installer). I forced a payload extraction with a DOSScript that I found and managed to get some of VS2015 to install, but then there would be another one missing after that.
Per my habit, I googled for a while and fould that this particular installer was giving the same pains to a lot of people running Win-8 and 8.1 (I'm running 8.1.1, but apples and oranges...)
Finally found a solution from someone on a Python website (???), and here it is...

If you're running Win 8, 8.1, or 8.1.1, the VS2015 Runtime installer will not work properly if you do not have every single essential Windows Update installed. Somewhere along the line, five of the updates are absolutely needed for VS2015. I'm not sure which ones.

To turtle91, thanks for the help, and the download. The effort was appreciated.

ADSWNJ, BaseSync V3 seems to be working just fine now, and I appreciate the help.

Cheers everyone!

 

[ADSWNJ]

I'm always suspicious of x64 runtimes. Maybe irrational, but I always install both the x32 and the x64 runtimes to cover all bases. Maybe Klonky is right ... all write assembler directly with no runtimes, and then the problem goes away (next Orbiter ... Orbiter 2043).

 

[DaveS]

The runtimes are not against the OS version but the application version. So since Orbiter is an 32 bit application you only need to install the x86 version.

 

[Face]

Maybe Klonky is right ... all write assembler directly with no runtimes, and then the problem goes away (next Orbiter ... Orbiter 2043).

I know that was tongue in cheek, but... every generation has its smarty-pants people that think the wheel was done wrong and should be re-invented. Don't listen to them before they deliver extraordinary evidence to their extraordinary claims. Some do, but most never will. :tiphat:

 

[Enjo]

Maybe Klonky is right ... all write assembler directly with no runtimes, and then the problem goes away.

No, we should all use Debian and let the automatic dependency checks do the job.

 

[dbeachy1]

When I installed BaseSync 3.0 for Orbiter 2016 today in the released Orbiter 2016 build, the MFD failed to load with this error in Orbiter.log:

============================ ERROR: ===========================
Failed loading module Modules\Plugin\BaseSyncMFD.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================

Does it work with Orbiter 2016 for anyone else?

EDIT:
Disregard my question -- I missed seeing this text on its OHM page:

Mandatory Pre-Requisites: ModuleMessagingExt for Orbiter 2016 v1.1

Once I installed [ame="http://orbithangar.com/searchid.php?ID=6966"]ModuleMessagingExt for Orbiter 2016[/ame], it loaded up fine. :thumbup: