OHM ModuleMessagingExt v2.1d for Orbiter 2016

[Face]

Well, a good example how to solve this would be looking at the CAN aerospace serial bus standard:

Interesting document, thanks for the link!

On the topic of Orbiter microservices, I must admit that I am very skeptical. From experience, most microservice architectures I've encountered - both private and at work - turned out to be an unmaintainable, over-complicated and over-engineered mess that actually solves problems nobody would have without them. YMMV, of course.

In that light, I'd suggest to first identify the problems you want to solve with such a system. Is there a combination of addons today (or in the foreseeable future) that will work better and/or faster with it? Will it be easier to deploy (versioning comes to mind) and use this combination with the microservice architecture in place?

The example of autopilots is very interesting, but I think it should be sketched out first in order to have a use-case for the architecture.

 

[ADSWNJ]

My preference would be a consistent set of information sharing as a first goal. Enjo and I have done this for years with our set of MFDs, but I would like to do it for more modules.

(By the way - see the developer documentation that comes down with this release ... it's comprehensive!)

With the new Find() call in the Advanced Interface, it's now possible to look for sources of data without pre-knowledge of what will send it. For this to be more solid, I would prefer to have some reserved names and guidance for developers when to use those names, so we know what we are finding. E.g. a simple one: Target OBJHANDLE (where we already do a ton of checks to ensure that OBJHANDLE is always valid on any Put, Find, or Get) ... this should be something that we can agree on quite easily.

What chains of MFD's, or actions in vessels linking to MFD's would people like? To give you some ideas, think about this example:

1. XR-5 at the Cape, going to Luna space station. Initial planning with LaunchMFD, then TransX.

2. Some kind of Flight Management Computer MFD to plan the initial atmo phase up to parking orbit, then the TLI burn and glide to the moon (with pre-planned MCCs), then Lunar insertion and sync to Luna, then docking approach.

3. For the atmo phase ... we would have LaunchMFD, ScramAttitude, Align Planes, and TransX interacting with various controls on the XR-5 (e.g. opening scram doors, controlling APU, watching nose and wing temps), all with entry and exit criteria for using each tool.

4. Potentially the FMC MFD would work a control API interface with each utility, to activate each function at the right point ... e.g. adjusting the XR-5 bank AP to roll out onto 140 degrees, then hand off to LaunchMFD's AP, then leave LaunchMFD doing azimuth, and ScramAttitude to do AoA.

So rather than microservices (which I agree can get us into a ton of work for no benefit), this would be back to the original idea of chaining independent MFDs to achieve the look and feel of an integrated flight deck with all components aware of a bigger situation than just their controls.

Well ... I can dream, I guess...

 

[ADSWNJ]

V2.1 released. Minor tidy-up version to fix some issues as I was coding BaseSync and Glideslope natively to this new interface.

 

[ADSWNJ]

v2.1c release ... more minor bugfixes and improvements (working through a couple things with Enjo). I also updated the MMExtMFD to have a data dump mode mode (as well as a variables and an activity mode), so you can see data changing in real time ... in nice colors too!

 

[Enjo]

It's worth noting, that downloading this release by users and not developers, is absolutely optional, because the communication dll hasn't changed at all.

[EDIT] Except for that MFD update of course, if anyone wishes to use it.

 

[ADSWNJ]

[EDIT] Except for that MFD update of course, if anyone wishes to use it.

Worth it as an end user just for the pretty new colors on the MMExt MFD!!

 

[Enjo]

but you still underestimate the compatibility that you deliver by not changing the core dll and not forcing the users to update, only making it optional. That's a feature too!