yagni01
Addon Developer
Just a reminder, If you guys need more commands accessible via Orb:Connect, just let me know.
Open-source versions of built-in MFDs?
- Thread starter Hielor
- Start date
cjp
Addon Developer
Is my Free Orbit MFD useful?
I was thinking of finding a way that would allow you to port Free Orbit MFD to other platforms while still having the same code base. There are two issues to be solved for this:
About GDI: I'm thinking of porting my MFD to the sketchpad API of the next Orbiter version (which was discussed here). I would include the GDI implementation in my own sources, to make it work with the current version of Orbiter. If you would make a stetchpad implementation on Allegro, you would automatically have an Allegro-based Orbit MFD. A potential issue here is that the next version of Orbiter is still in development, so all its related APIs are probably moving targets.
About the Orbiter API: I could separate the core functionality from the MFD class, and put them in different source files. An alternative would be to implement a sufficient subset of the Orbiter API on top of Orb:Connect. I never worked with Orb:Connect, so what is your(*) opinion on this?
(*): Hielor, yagni01, and whoever has an opinion on this.
I was thinking of finding a way that would allow you to port Free Orbit MFD to other platforms while still having the same code base. There are two issues to be solved for this:
- The Orbiter API
- The GDI API
About GDI: I'm thinking of porting my MFD to the sketchpad API of the next Orbiter version (which was discussed here). I would include the GDI implementation in my own sources, to make it work with the current version of Orbiter. If you would make a stetchpad implementation on Allegro, you would automatically have an Allegro-based Orbit MFD. A potential issue here is that the next version of Orbiter is still in development, so all its related APIs are probably moving targets.
About the Orbiter API: I could separate the core functionality from the MFD class, and put them in different source files. An alternative would be to implement a sufficient subset of the Orbiter API on top of Orb:Connect. I never worked with Orb:Connect, so what is your(*) opinion on this?
(*): Hielor, yagni01, and whoever has an opinion on this.
Artlav
Aperiodic traveller
- Joined
- Jan 7, 2008
- Messages
- 5,814
- Reaction score
- 869
- Points
- 203
- Location
- Earth
- Website
- orbides.org
- Preferred Pronouns
- she/her
It surely is.
And to give a reason for digging up this thread, i think that is exactly a thing to do to make it even more useful.
Basically, split the thing into an OrbitGraph class that does all the counting and drawing and MFD class that provides Orbiter connection.
Graphics are handled by using simple wrappers.
For the oapi calls, all it takes is position/velocity of the target and vessel, as well as masses and sizes of them and reference. This can be stored in the OrbitGraph class, updated with MFD updates.
For G indicator - some kind of wrapper of getgbodyparams kind.
Purpose - to develop a set of Orbiter-independent Space Flight Tools.
Same goes for other default MFD's of which open-source remakes are to be made - functional class, Orbiter wrapper.
How about that?
yagni01
Addon Developer
Hielor is poking into it right now for the next RemoteMFD. I agree that the drawing and Orbiter connections be done through separate classes. My suggestion is to create a interfaces where the data is pushed into the MFD core, and a draw request comes out. This would allow for either opcPostStep or Orb:Connect subscriptions to drive the MFD along with processing of keystrokes separately.
