OHM BaseSyncMFD 3.3 for Orbiter 2016

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
What does the orbiter dev comumity think to static linking. I know dbeachy is a fan. I can do it of course, but I always felt it was wrong to give a user a runtime they cannot update. But if it's in a specific use-case (i.e. Orbiter) versus a general use-case (e.g. supporting web e-commerce), then maybe the risk is lower?

I can chime in with my two cents in the pro-static linking camp. :) The Visual Studio runtime libraries implement all the standard C++ library calls like new, delete, sprintf, fopen, etc. Normally, users never have to deal with installing these manually, because a program's installer is supposed to also automatically install any runtime libraries the program needs (this is of course only necessary if the program does not link statically with those libraries).

In my experience I have never had to manually upgrade a Visual Studio runtime library because of a bug, and speaking personally, if the community did discover a bug in my add-on(s) that I traced to the Visual Studio runtime libraries (which, again, seems extremely unlikely), I would much rather relink and release an updated version of my add-ons with the updated runtime libraries linked in statically rather than relying on all my add-ons' new and existing users to go out and manually install the updated Visual Studio 2013 redistributable package themselves. My reasons are:

  1. For new users that download an add-on, many users already have some version of the Visual Studio 2013 redistributable package previously installed by some earlier software's installer, and so installing an Orbiter add-on that requires those same redistributables would load just fine even with the already-installed (possibly buggy) Visual Studio redistributable package. They could even have a redistributable version older than the static version of the package I linked and tested with.
  2. By running with a different version of the redistributables than I linked and beta-tested with, it is also possible that the different (even if newer) version of the redistributable package has a bug that the version I tested with does not.
  3. It is neither easy nor obvious for the average user to figure out what exact version of the Visual Studio redistributables they have installed, and so this would make it harder to troubleshoot issues if indeed it was traced to a problem in the redistributable libraries.
  4. It is confusing for users to figure out which redistributable package they need to install: x86 vs. x64, for example. As I said, normally a software's installer automatically installs the redistributable package the software needs, but Orbiter add-ons do not typically have an installer: they are just a zip package, and so it is left to the user to read the fine print, locate the correct redistributable package, and install it separately.
  5. By far, the main reason I prefer to statically link with the redistributable files is to make it easier for users to install and run the add-on: with static linking, it "just works", but with dynamic linking, if the user doesn't happen to already have the correct Visual Studio redistributable files installed, it is a poor user experience when pilots try to load up a new add-on and it dies with a cryptic error in Orbiter.log. For every user who posts a question about it on the forum, there are probably 10 more who just give up and never get the add-on working. Or worse, they google for the exact error text that pops up and wind up installing one of those phony download packages that actually installs some malware.

And of course we have the Wine issue cited here. :)

But anyway, I am not militant about this, it's just my opinion, and I would not judge other authors for perferring dynamically linking to the redistributable files rather than statically. :tiphat:

P.S. as a side note, there is only one technical reason I am aware of to ever use dynamic linking instead of static linking, and it does not apply to Orbiter: if you are linking with another DLL or EXE that needs to free a memory back to the heap that your software allocated (or vice-versa), then you have to use dynamic redistributable linking so that both DLLs/EXEs use the same memory heap. (This would normally be considred bad programming form, however, since you should normally allocate memory in the constructor and free it in the same object's destructor.) In any case, this situation does not occur when linking with Orbiter because the Orbiter core does not free memory blocks that an add-on allocated, nor does an add-on free memory blocks that the Orbiter core allocated. In other words, the Orbiter core allocates and frees its own memory blocks, and each add-on allocates and frees its own memory blocks. You can safely pass memory blocks from different runtime heaps between DLLs and EXEs that use them, and this is what happens when a statically linked add-on runs with Orbiter.exe. (The other now-obsolete reason to use dynamic runtime linking is because it does use marginally less RAM than having each DLL/EXE include a copy of the actual code for the runtime library calls it makes in its program memory -- back in the early days of Windows, that extra several K of RAM usage did matter.)
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
EDIT: for the Wine users - give this static linked version a go and let me know if this fixes things. (unload it into Modules/Plugin as usual).
Works perfectly! Keep it that way ;)

5. By far, the main reason I prefer to statically link with the redistributable files is to make it easier for users to install and run the add-on: with static linking, it "just works", but with dynamic linking, if the user doesn't happen to already have the correct Visual Studio redistributable files installed, it is a poor user experience when pilots try to load up a new add-on and it dies with a cryptic error in Orbiter.log. For every user who posts a question about it on the forum, there are probably 10 more who just give up and never get the add-on working. Or worse, they google for the exact error text that pops up and wind up installing one of those phony download packages that actually installs some malware.

Fully agree. No offense to Andrew, nor to new users, but quite honestly, I'm a bit fed up with directing users to the redistributables, n-times per a single forum page, especially that these are not my addons that I'm providing basic support for.
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
Good arguments, guys. OK I'll switch to static
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,665
Reaction score
13
Points
38
Location
Germany
Website
www.enderspace.de
Preferred Pronouns
Can't you smell my T levels?
Great, 'cuz here's another example, in case you don't read other threads:
Ok now with the VC2015Redist it works! Thank you very mutch. I had only installed the VC2013Redist, like written in your manual. But you should update/insert the link of the VC2015Redist to your addon's descriptions AND manuals. Only the BaseSync and ModuleMessagingExt are speaking in their addon's description at OrbitHangar about the newer VC2015, not in the manuals. When people later reinstall their windows and orbiter only from archives like me, they can just overlook this.
 

wthess

New member
Joined
Oct 12, 2016
Messages
3
Reaction score
0
Points
0
Visual Studio link issues

I just wanted to make a correction here to the link to the Visual Studio 2015 link referenced in the main post.

1) The link is broken. There is an extra space before " id=" that should be removed in order for the link to work.

2) The description for the link is also incorrect. The Visual Studio 2015 redist referenced in the main post is an entirely different redistributable available from the Visual Studio website rather than from microsoft.com website. The link takes you to the "Visual C++ Redistributable for Visual Studio 2015" download page, which is a completely different package.
 

bisbeejim

New member
Joined
Sep 29, 2016
Messages
21
Reaction score
0
Points
0
Location
Mesa
BAseSyncMFD doesn't appear

I've installed it, plus the ModuleMessagingExt for Orbiter 2016 v1.1 and
Visual Studio 2015 redist. The box is checked in the Modules window. I've checked the folders and its in there, but there's nothing showing up on the MFD panels or tick buttons. Help please.
 

fullarmor2

Member
Joined
Jan 24, 2009
Messages
101
Reaction score
0
Points
16
I noticed that this is a 2 gig download and install - Visual Studio 2015 ? Then I have to download Visual C++ Redistributable ? I have to do all that in order to use Base Sync for 2016 Orbiter? That sucks. What do I do after I download all that crap? How does it connect to Orbiter 2016 to make Base Sync work?
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
I noticed that this is a 2 gig download and install - Visual Studio 2015 ? Then I have to download Visual C++ Redistributable ? I have to do all that in order to use Base Sync for 2016 Orbiter? That sucks. What do I do after I download all that crap? How does it connect to Orbiter 2016 to make Base Sync work?

What are you trying to do? You only need to install Visual Studio 2015 if you are developing code, in which case it will automatically install but the release and debug versions of the appropriate runtime.
 

fullarmor2

Member
Joined
Jan 24, 2009
Messages
101
Reaction score
0
Points
16
What are you trying to do? You only need to install Visual Studio 2015 if you are developing code, in which case it will automatically install but the release and debug versions of the appropriate runtime.

I'm trying to use Basesync for Orbiter 2016. I installed it and checked it, but when I launch Orbiter it doesn't appear as one of my MFD options? I also installed ModuleMessagingExt .
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
I'm trying to use Basesync for Orbiter 2016. I installed it and checked it, but when I launch Orbiter it doesn't appear as one of my MFD options? I also installed ModuleMessagingExt .

Can you check your orbiter.log for any errors (most likely an error 126). Also note the following from the OrbitHangar notice on this addon:

Code:
Mandatory Pre-Requisites: ModuleMessagingExt for Orbiter 2016 v1.1 and
Visual Studio 2015 redist (https://www.microsoft.com/en-us/download/confirmation.aspx? id=48145).

Check to see you have done the Visual Studio redist (32-bit version).

(I don't remember if I linked this one statically or not, but if you put on this redist, you are good either way!).
 

paddy

Addon Developer
Addon Developer
Joined
Jul 14, 2012
Messages
80
Reaction score
0
Points
0
Does any one have a cfg file for a DG IV. I just can not get the DG version to work.
I leave IIS, adjust orbit to 200km by 200km, use basesync to get the best orbit.
At the right time my orbit changes and I start to re enter...... all so good
If I control it by hand I burn up or bounce off, if I use the ALT7 auto re entry It saves an empty user config file??
Help!!!!
 

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
3,133
Reaction score
407
Points
123
Location
Rome
Website
www.tuttovola.org
Does any one have a cfg file for a DG IV...
BaseSync has one general config file, not per-vessel based.

Anyway, my deorbit figures for DGIV are:
ANG = 0.7
ANT = 38 ~ 40
ALT = 80 (from LEO)
 

paddy

Addon Developer
Addon Developer
Joined
Jul 14, 2012
Messages
80
Reaction score
0
Points
0
Ripley, many thanks will try that, cheers
 

wthess

New member
Joined
Oct 12, 2016
Messages
3
Reaction score
0
Points
0
I noticed that this is a 2 gig download and install - Visual Studio 2015 ? Then I have to download Visual C++ Redistributable ? I have to do all that in order to use Base Sync for 2016 Orbiter? That sucks. What do I do after I download all that crap? How does it connect to Orbiter 2016 to make Base Sync work?

No, Visual Studio is not necessary. It is a programming IDE. The original poster stated that Visual Studio redist was necessary, but that's erroneous information. What you need is the Visual C++ Redist.
 

rcraig42

New member
Joined
Jan 23, 2012
Messages
70
Reaction score
0
Points
0
I posted a thread with a serious problem I'm having over in the addon problems forum. Guess I should have posted here:

In the following I brought up base sync about 100 degrees longitude after passing canaveral, the first screen shot shows my green line about 100 degrees counter clockwise from the base's yellow line.

attachment.php


a few minutes later sim time, basesync suddenly shifts the base location about 90 degrees clockwise, showing my ship over 180 degrees counter clockwise from the base, while I'm actually only 129 degrees east of cape canaveral.

attachment.php


This of course renders it useless to me. even if I wait till after it shifts to bring it up, it shows the shifted position rather than the true position of the base.

I tried using 3.0 instead, and had the same issue. Tried different scenario, same issue. tried disabling all other addon mfd's, same issue.

Running Orbiter 2016, Windows 10 Professional x64 latest update.

---------- Post added 11-23-16 at 01:38 AM ---------- Previous post was 11-22-16 at 11:02 PM ----------

okay I tried some default scenarios and it did not have that issue, then I tried the default XR2 ready for launch, without changing anything, and it worked fine, then I changed the date from the 2001 date it had, to now, and it shifterd the base location on the second or third orbit.

Apparently there is some issue caused by the date, sometime between 2001 and late 2016
 

ADSWNJ

Scientist
Addon Developer
Joined
Aug 5, 2011
Messages
1,667
Reaction score
3
Points
38
can you post a scenario file prior to the problem, and then the steps to get to the problem. (I.e. Ctrl-S and find the .cfg file in Quicksave and post it). I'll load it up and let you know what I see.
 

rcraig42

New member
Joined
Jan 23, 2012
Messages
70
Reaction score
0
Points
0
the scenario is in an XR2 just returned on the moon, already lined up for deorbit to canaveral after one more orbit.

To reproduce the problem just bring up base sync with or without linking to glideslope, set up cape canaveral as the target, and watch it's position shift 90 degrees to the west about 5-10 minutes sim time after the ship's starting location (just east of africa over the indian ocean) in orbit. You can do it right away and it will shift, or you can go around to roughly the same location and set up the deorbit. Either way it will start off with canaveral in the right place, then shift.

the first time I encountered the problem I had it linked to glideslope, and auto burn already setup, ttb jumped from around 900 to right now and it did the burn over the middle of the indian ocean instead of Western Austrialia as expected.
 

Attachments

  • XR2 for Moon 2016 0002 0001.scn
    6.1 KB · Views: 3

boogabooga

Bug Crusher
Joined
Apr 16, 2011
Messages
2,999
Reaction score
1
Points
0
The yellow line shows where the base will be at closest approach in a non-rotating frame, not where it is right now. I think what is happening is that BaseSync is finding a better closest approach and showing where the base will be then. If you want the first solution, reduce the number of orbits to show.

Check this thread, I've answered this before:
http://www.orbiter-forum.com/showthread.php?t=34739&highlight=BaseSync
 

rcraig42

New member
Joined
Jan 23, 2012
Messages
70
Reaction score
0
Points
0
The yellow line shows where the base will be at closest approach in a non-rotating frame, not where it is right now. I think what is happening is that BaseSync is finding a better closest approach and showing where the base will be then. If you want the first solution, reduce the number of orbits to show.

Check this thread, I've answered this before:
http://www.orbiter-forum.com/showthread.php?t=34739&highlight=BaseSync

Nope, that is not the problem, the mfd actually thinks the base suddenly shifts 90 degrees to the West, I am not misinterpreting the screen, that orbit I was in passes within 15 km of cape canaveral, there is no "better orbit" 18 hours later that the MFD would suddenly decide to switch to 900 seconds before my deorbit burn, while in the deorbit screen. Also, it happens in the main screen as well, without even going to the deorbit screen.

As I said, the problem only happens to me when I run a scenario dated in the past month, not with the default scenario dates 15 years ago. I haven't had time to do more extensive testing than that to find out if just changing the date with scenario editor at all will do this (no, not in the middle of the flight, but before I take off or ever bring up base sync), or what the cutoff date might be if it really is caused by the date being too recent or in the future, as I want to actually learn how glideslope works and fly some descents with it, So I am flying scenarios dated 15 years ago where the base sync mfd actually works right.

Try the scenario I posted, if it doesn't happen to you, let me know.
 
Last edited:
Top