OHM BaseSyncMFD 3.3 for Orbiter 2010

[Fabri91]

I'm having a bit of an issue with this MFD: I installed it in the new O2016 RC, so it's probably due to that, but it just doesn't show up in the MFD selection screen, despite the module being enabled.

Just a heads-up for a potential official release for the new Orbiter version.

EDIT: here's the first part of Orbiter's log, for reference:

**** Orbiter.log
000000.000: Build Jul 12 2016 [v.160712]
000000.000: Timer precision: 2.56e-007 sec
000000.000: Found 0 joystick(s)
000000.000: Module AtlantisConfig.dll .... [Build 160712, API 160712]
000000.000: Module AtmConfig.dll ......... [Build 160712, API 160712]
000000.000: Module DGConfigurator.dll .... [Build 160712, API 160712]
000000.000: Module D3D9Client.dll ........ [Build 160714, API 160703]
000000.000: Module transx.dll ............ [Build 160216, API 160214]
000000.000: Module ScnEditor.dll ......... [Build 160712, API 160712]
000000.000: Module OrbiterSound.dll ...... [Build 121120, API 100830]
000000.000: Module AeroBrakeMFD.dll ...... [Build ******, API 100830]
000000.000: ---------------------------------------------------------------
000000.000: >>> WARNING: Obsolete API function used: oapiRegisterMFDMode
000000.000: At least one active module is accessing an obsolete interface function.
000000.000: Addons which rely on obsolete functions may not be compatible with
000000.000: future versions of Orbiter.
000000.000: ---------------------------------------------------------------
============================ ERROR: ===========================
Failed loading module Modules\Plugin\BaseSyncMFD.dll (code 126)
[Orbiter::LoadModule | .\Orbiter.cpp | 600]
===============================================================

 

[ADSWNJ]

I'm having a bit of an issue with this MFD: I installed it in the new O2016 RC, so it's probably due to that, but it just doesn't show up in the MFD selection screen, despite the module being enabled.

It's not compiled for the O2016 app yet.

I am still hoping we can get multi-version support in OrbitHangar, so a single addon page can hold two packages, so you can download for the right version of Orbiter.

Or ... I'm hoping there will be some advice in the O2016 docs on how to compile once and be compatible with both O2010 and O2016. Once O2016 is released, I'll refresh all my addons with O2016 versions.

 

[Enjo]

Or ... I'm hoping there will be some advice in the O2016 docs on how to compile once and be compatible with both O2010 and O2016. Once O2016 is released, I'll refresh all my addons with O2016 versions.

I'm not sure if it's entirely possible due to seemingly incompatible ABIs. What does work across some versions are CameraShake and AbsoluteKillrot, but they use a small subset of Orbiter's API.

 

[ADSWNJ]

I'm not sure if it's entirely possible due to seemingly incompatible ABIs. What does work across some versions are CameraShake and AbsoluteKillrot, but they use a small subset of Orbiter's API.

Yup - that's what I feared. Easy to compile new versions (I'm looking at BaseSync today and hoping/expecting it to be a simple recompile only), but we need a solution for OrbitHangar:

Do we want:

A: 2016 parallel versions of everything. (E.g. BaseSyncMFD v3.0 and BaseSyncMFD 2016 v3.0).

B: A new sub-location under orbithangar.com with a duplicate of the original (e.g. orbithangar.com/O2016 ... with a BaseSyncMFD v3.0 ).

C: Same OrbitHangar and same BaseSyncMFD v3.0, but with the ability to have multiple download files per version, so you can select what you want.

D: Go somewhere else for all this - e.g. GitHub?

 

[Enjo]

What we want is limited to what we may have, because OH is maintained, but not developed anymore. Only option A) comes into question. I'd choose option D) only as the last resort.

Here's my way of dealing with it:
I have multiple targets in my projects, each pointing to a different version of Orbiters' SDK dirs, and I build them.
Then, once the .dll files are in the Modules/Plugin dir, I search for them and copy them to release folders, however it's expected that these folders already exist, and are populated with all other files, other than the .dlls (docs, configs, etc.). Therefore it's a task of simply copying the previous release to a folder with an incremented version, adapting the below script, and running it.
https://sourceforge.net/p/enjomitchsorbit/codeHG/ci/default/tree/scripts/prep-release.py

 

[Face]

What we want is limited to what we may have, because OH is maintained, but not developed anymore. Only option A) comes into question. I'd choose option D) only as the last resort.

Why is D only a last resort? IMHO it is way better suited for open source projects than something as rigid - and as you said: undeveloped - as OH.

 

[ADSWNJ]

IMHO - this community has grown up with OrbitHangar as the go to place for addons. I would like to continue to support it for Orbiter 2016. GitHub is also great, as a source repo, but you don't get the Orbiter experience there.

@Mods - can you fork this into a separate thread please?

 

[Face]

IMHO - this community has grown up with OrbitHangar as the go to place for addons. I would like to continue to support it for Orbiter 2016. GitHub is also great, as a source repo, but you don't get the Orbiter experience there.

@Mods - can you fork this into a separate thread please?

Unfortunately, OH has not grown up like the community and Orbiter itself did. I think Enjo is right in saying that it may be maintained, but it is not developed any further.

Sure it would be nice to continue supporting OH, but you don't need to continue to host the various versions there. You could e.g. make one OH entry and simply put links into the description to point to the various versions. AFAIK, OH supports redirect entries, i.e. not actually offering a download link, but a redirection link.

This later one could be a link to the officially release version, while the description body contains links to other interesting versions as well (e.g. the latest beta compatible, the master version, some experimental branch, etc.).

Whether you host the versions on GitHub, SourceForge or on WhatsYourCloud doesn't matter here. You brought up the first name, not me. My point was more on "somewhere else" than on "GitHub".

 

[Fabri91]

Have no webdev experience but I hope this idea might be useful: Kerbal Space Program faces a similar problem with mods, which have to be available for many different versions. One of the most used repositories is Spacedock.info, which also has sections for other games, such as Stellaris.

http://www.spacedock.info

More importantly, the entire website is open source.

Since OHM isn't in active development anymore, I could see two options:

• Use the code to revamp OHM or create an alternative
• Contact Spacedock itself and ask for an Orbiter section

 

[Face]

I'm having a bit of an issue with this MFD: I installed it in the new O2016 RC, so it's probably due to that, but it just doesn't show up in the MFD selection screen, despite the module being enabled.

Just a heads-up for a potential official release for the new Orbiter version.

FYI: I've compiled an "Enjo-free" version of BaseSyncMFD 3.0 - i.e. without ModuleMessagingExt support - for O2010P1, and it still works fine in O2016RC1. So here's hope it will just need a recompile of all involved components.

 

[Lucy]

Just to weigh in a little on the OHM front; the current site is maintained, a new version is being (slowly) developedto accommodate new features and bring the site up to more modern standards. However, it's a spare time project, and I have precious little of that, so it ain't fast, but I might be able to get something up and running by the time O2016 is actually released (I hope).

 

[Face]

Just to weigh in a little on the OHM front; the current site is maintained, a new version is being (slowly) developedto accommodate new features and bring the site up to more modern standards. However, it's a spare time project, and I have precious little of that, so it ain't fast, but I might be able to get something up and running by the time O2016 is actually released (I hope).

Will multi-version support be a part of what you are preparing?

 

[ADSWNJ]

I have put up a supported version of BaseSync v3.0 as BaseSync for Orbiter 2016 v3.0 in OH. Note the orbiter version number says 100830 because there's no 16xxxx yet (so ignore that).

I also re-based it onto Visual Studio 2015 Community Edition (new Win 10 build, new Orbiter 2016 clean install, new private repo, new props files, and new VS Community Edition) ... so note that you need the redist file for VS 2015 from https://www.microsoft.com/en-us/download/details.aspx?id=48145

Let me know if this works for everyone.

Oh ... and by the way - you need the ModuleMessagingExt for Orbiter 2016 download as well.

 

[Enjo]

FYI: I've compiled an "Enjo-free" version of BaseSyncMFD 3.0 - i.e. without ModuleMessagingExt support - for O2010P1, and it still works fine in O2016RC1. So here's hope it will just need a recompile of all involved components.

Oh ... and by the way - you need the ModuleMessagingExt for Orbiter 2016 download as well.

It might be worth double checking if "Enjo-pollution" is actually the cause of the incompatibility, since MM / MMExt only link the very basic symbols from Orbiter ABI, which should stay compatible, just like AbsoluteKillrot and CamShake.
Andrew - in other words, if I'm right, you shouldn't need to prepare any extra version of MMExt for O2016. I've already experimented with it, and designated the MMExt as a mandatory requirement for my Beta versions of addons, and got no complaints so far. (Worked on my machine™, if that's of any indication...)

---------- Post added at 08:27 PM ---------- Previous post was at 08:20 PM ----------

Why is D only a last resort? IMHO it is way better suited for open source projects than something as rigid - and as you said: undeveloped - as OH.

Because, as Andrew said, it's some sort of a hub of addons and has some history. As long as O-F / O-H continue operating, I see no need for an immediate reaction. Notice that you may search for categorized addons on OH, which wouldn't be possible if we were dispersed. No newbie has a chance to know that there's a super-duper addon somewhere on github.

Just to weigh in a little on the OHM front; the current site is maintained, a new version is being (slowly) developedto accommodate new features and bring the site up to more modern standards. However, it's a spare time project, and I have precious little of that, so it ain't fast, but I might be able to get something up and running by the time O2016 is actually released (I hope).

I'm not complaining here at all. I'm fine with it as it is. But it would help if you could quickly add Orbiter2016 version and maybe an "ethereal" Beta version.

 

[Face]

It might be worth double checking if "Enjo-pollution" is actually the cause of the incompatibility, since MM / MMExt only link the very basic symbols from Orbiter ABI, which should stay compatible, just like AbsoluteKillrot and CamShake.

:shrug: I have no idea if indeed the MMExt thingy is the culprit. I've got that version of BaseSyncMFD 3.0 in stock, and it still works with the beta, to my own surprise. Just wanted to let you know that it couldn't be that big of a problem regarding Orbiter ABI.

Because, as Andrew said, it's some sort of a hub of addons and has some history. As long as O-F / O-H continue operating, I see no need for an immediate reaction. Notice that you may search for categorized addons on OH, which wouldn't be possible if we were dispersed. No newbie has a chance to know that there's a super-duper addon somewhere on github.

Yeah, I've already addressed that. I don't see why you can't keep the OHM entry for those newbies while at the same time use a better suited place to host your various artifacts. Again: I was not the one to bring up GitHub. "Somewhere else" was the point there. OHM already supports that AFAIK.

 

[ADSWNJ]

IMO, having a clean split of addons linked against Orbiter 2010 from those against Orbiter 2016 is a good way to go. I'm impressed with the backwards compatibility so far, but I also expect we will all be moving to use the new API calls sooner or later, where it becomes a real pain to stub them for the old Orbiter versions.

Good for you, Xyon. Let us know your plans for Orbiter 2016 support, and how we should prep the addons to assist you. E.g. searching "for Orbiter 2016" may be a simple way for you to start the clone repo for Orbiter 2016.

 

[Enjo]

On the other hand, I'd add to the wish concert a "Is forward compatible until version X" option.
Andrew: it's your choice, but I find it nice that I dont have to recompile some of my addons.

---------- Post added at 08:39 AM ---------- Previous post was at 07:42 AM ----------

I'd add to the wish concert a "Is forward compatible until version X" option.

Scratch that. "Latest known compatible version = X" fits better, because of many orphaned addons. The community usually prepares a list of major orphaned addons on every release, and a mod could reflect this on OH.

---------- Post added at 01:56 PM ---------- Previous post was at 08:39 AM ----------

:shrug: I have no idea if indeed the MMExt thingy is the culprit. I've got that version of BaseSyncMFD 3.0 in stock, and it still works with the beta, to my own surprise. Just wanted to let you know that it couldn't be that big of a problem regarding Orbiter ABI.

Then taking it all into account, I suspect a missing VC redistributable on the user's side.

Yeah, I've already addressed that. I don't see why you can't keep the OHM entry for those newbies while at the same time use a better suited place to host your various artifacts. Again: I was not the one to bring up GitHub. "Somewhere else" was the point there. OHM already supports that AFAIK.

You may, sure, but it's an extra effort, and I doubt that a typical person will want to do it. But ultimately it's their choice.

 

[Face]

You may, sure, but it's an extra effort, and I doubt that a typical person will want to do it. But ultimately it's their choice.

Indeed. I just think that someone doing an Orbiter addon open-source style is not the typical person here. So if you are the untypical person, you can well do the "social coding" hosting of your various versions without any change on OHM's side. Today. Having to deploy some "special" artifact to the hangar is then the extra effort IMHO.

But to each his own, of course.

BTW @Xyon: I think my question about the upcoming OHM update got unnoticed, so let me repeat it: is multi-version support in the making? If so, the discussion would be academic, anyway.

 

[Lucy]

BTW @Xyon: I think my question about the upcoming OHM update got unnoticed, so let me repeat it: is multi-version support in the making? If so, the discussion would be academic, anyway.

Well no, I was going to reply saying we'd fork that discussion, but I needed to add a project space first. We can discuss OHM features there now; that one is in brief here.

There are two others I've listed, but this is not an exhaustive feature list; more will follow as I have time to write them up from internal notes.

 

[Ripley]

BaseSync MFD 3.0 ITA manual uploaded!!