You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Special output devices like the WinWing CDUs have a very special complex interface for setting display data. Furthermore aquiring the necessary data from planes is complex and very plane specific. For example in case of FBW or Fenix, custom websocket interfaces are provided by external processes and PMDG has their own SDK.
It is not possible any more to realize solutions with standardized configuration. Some "programming" and plane specific logic is needed.
Going forward, how to make it easier for people to participate and provide plane specific solutions to MobiFlight? We cannot program all those specific solutions by ourselves.
Proposal:
For some very popular devices like the WinWing CDUs we program MobiFlight support and provide an external interface which allows to set the data from external processes.
The community can write python scripts as bridges between the special plane interfaces and the external MobiFlight interface.
Furthermore MobiFlight gets a new configuration file which defines for which detected supported special hardware and plane, which external script is executed. After a review, the scripts are included and shipped with mobiflight.
The script is execute on "Play" on stopped on "Stop".
Diagram:
Open questions
Which technology for the MobiFlight external interface?
Just the script file. -> Before script execution detect whether Python is installed and show installation instruction if necessary.
Ship as self contained generated .exe files. Generated from the scripts. -> No dependencies, but that will quickly add up and increase MobiFlight deployment size.
The text was updated successfully, but these errors were encountered:
It might be worth considering following the approach taken by FSUIPC and PilotsDeck and including a scripting engine within the MobiFlight app itself. They both chose LUA, but it could be e.g. IronPython instead.
That would solve the issue of how to ship the scripts and the "external interface" just becomes a series of methods implemented in C# and exposed to the scripting engine.
Current situation
Special output devices like the WinWing CDUs have a very special complex interface for setting display data. Furthermore aquiring the necessary data from planes is complex and very plane specific. For example in case of FBW or Fenix, custom websocket interfaces are provided by external processes and PMDG has their own SDK.
It is not possible any more to realize solutions with standardized configuration. Some "programming" and plane specific logic is needed.
Going forward, how to make it easier for people to participate and provide plane specific solutions to MobiFlight? We cannot program all those specific solutions by ourselves.
Proposal:
Diagram:
Open questions
Which technology for the MobiFlight external interface?
Which scripting language?
How to ship the scripts?
The text was updated successfully, but these errors were encountered: