Hey, very long-time Orbiter player finally getting around to cracking the SDK open, here. I'm posting hoping for some general wisdom on how best to build Virtual Cockpits in a way that doesn't create a ton of technical debt. I come from a Unity/C# background primarily, so you may have to bear with me a little on Orbiter SDK and C++, but I think I'm starting to get it.
About a week ago I got it in my head I wanted to build an Orbiter vessel, which I justified to myself as an excuse to learn C++. I'm a huge virtual cockpit fan and also very bad about not biting off more than I can chew, so I've been going all-out with intent to build an animated VC, custom engine behavior, and whatever system depth I find I have the patience to build. By virtue of the quite-thorough documentation, I've been able to get pretty far:
I built it off the PB, paying reference to the SDK manual and a few third party guides. It's got the basic necessities: retractable landing gear, animated control surfaces, the beginning of a virtual cockpit, and, as a foray into interactive VCs, a light with a dimmer switch. Digging into switches though, the way forward has started to look less certain. I've been trying to reverse engineer my way through it, but the default vessels seem to handle switches a bit differently between them, and I haven't been able to make total sense of what's going on. The Shuttle-A I mostly follow; I don't totally understand how redraws work just yet, but the Shuttle-A seems to define all its clickable VC elements in the main vessel DLL, and does so more or less the way the documentation describes doing it.
That said, I as I understand the great strength of DLLs is portability and scalability, and it would make sense to organize switches into prototypes that I could re-use to perform similar functions on other vessels. This seems to be what the DeltaGlider is doing, with each switch defined separately and inheriting from a common DGSwitch, which in turn inherits from the common Instrument file. Trouble is, owing probably to my newness to C++, I'm having a hard time determining exactly how the DG switch family actually works. It also seems a little overkill for my applications, since I have no intent of defining a 2D cockpit with matching switches, and the intent to support both seems to be a major function of the DG architecture.
The specific questions I've come up with so far are:
Edit:
huh, apparently I took a stab at this way back in 2017 but totally forgot about it. Must not have made much progress. This start has been considerably more auspicious.
About a week ago I got it in my head I wanted to build an Orbiter vessel, which I justified to myself as an excuse to learn C++. I'm a huge virtual cockpit fan and also very bad about not biting off more than I can chew, so I've been going all-out with intent to build an animated VC, custom engine behavior, and whatever system depth I find I have the patience to build. By virtue of the quite-thorough documentation, I've been able to get pretty far:
I built it off the PB, paying reference to the SDK manual and a few third party guides. It's got the basic necessities: retractable landing gear, animated control surfaces, the beginning of a virtual cockpit, and, as a foray into interactive VCs, a light with a dimmer switch. Digging into switches though, the way forward has started to look less certain. I've been trying to reverse engineer my way through it, but the default vessels seem to handle switches a bit differently between them, and I haven't been able to make total sense of what's going on. The Shuttle-A I mostly follow; I don't totally understand how redraws work just yet, but the Shuttle-A seems to define all its clickable VC elements in the main vessel DLL, and does so more or less the way the documentation describes doing it.
That said, I as I understand the great strength of DLLs is portability and scalability, and it would make sense to organize switches into prototypes that I could re-use to perform similar functions on other vessels. This seems to be what the DeltaGlider is doing, with each switch defined separately and inheriting from a common DGSwitch, which in turn inherits from the common Instrument file. Trouble is, owing probably to my newness to C++, I'm having a hard time determining exactly how the DG switch family actually works. It also seems a little overkill for my applications, since I have no intent of defining a 2D cockpit with matching switches, and the intent to support both seems to be a major function of the DG architecture.
The specific questions I've come up with so far are:
- Is there some widely agreed on best practice that I'm just not aware of? Does everyone, say, base their interior switches on DGSwitch? Or, at a lower level, on Instrument? Would I be massively reinventing the wheel to handle it any other way?
- Are there any resources that explain in detail how the DeltaGlider switch family actually works?
- Are there any resources that explain how to build around subsystems the way the DeltaGlider is, and when one would likely want to?
- If I go ahead and define my VC in-line the way the Shuttle-A does, am I going to live to regret it? Or does an approach like that make sense sometimes, perhaps on simpler interiors, or on interiors with a lot of bespoke functions not likely to be shared with other vessels.
- What is the best way to deal with scalability? I don't know what all will be in my virtual cockpit just yet, and intend to add to it as features occur to me or I decide to change how I'm implementing the ones that are there. I can always add new mesh to my heart's content, but every time I introduce a new mesh body (as I probably would for most switches and gauges) I'll be shuffling around the mesh group indices that get used to drive animations. I'd prefer to not have to trawl through the mesh file for which indices I need for every animation I've made every time I make a change. Is there a trick to that? I remember reading some hint that there was a way to access mesh groups by label rather than index, but I haven't found a way to actually do that.
- What are the difference between the VESSEL base classes? I've been working from 3 and just noticed the Shuttle A works from VESSEL4. Meanwhile, The DeltaGlider works instead from ComponentVessel, which I gather is important to working with subsystems and inheritance, but I'm not clear on the particulars.
Edit:
huh, apparently I took a stab at this way back in 2017 but totally forgot about it. Must not have made much progress. This start has been considerably more auspicious.
Last edited: