Failures will have to wait, but I want them too.
Yesterday, or this night, when I was working on Panel A6 I noticed (again) that to get the position of a switch one has to use the DiscreteBundle, even on the panel that created it, which seems a bit inefficient.... Looking at the BasicVCComponent class, it has a GetState() member that seems to be doing nothing ATM except returning 0.0. Was that member supposed to return the switch position (on switch classes), and if so can I make it do that, or it's for something else? We could save some bundles this way, which I'm sure are slower that a function call to get a number.
I suspect I left it in because the VC framework isn't quite done yet. I wanted initially to also have a separation between logical model of the cockpit and the visual model of it with the animations. But merging both into one was then better for the schedule than more abstraction.
Also, it is possible that I need something similar eventually for handling AI crew, which is another feature I want to implement personally. The AI crew would then have a "user model" of the VC available, which allows triggering events and then let the underlying system propagate the changes by the discretes.
What the bundles lack right now is a capability of describing quickly changing events. Like pulses to a RCS thruster. Maybe a problem.
I would not save bundles - especially because the bundles could also be used easily for debugging. I have a simple idea here to make a plain "SSU TEST" MFD, which allows selecting a discrete in a bundle and plot its state.
The bundles are maybe annoying first, but they allow replacing components on run-time without tight dependencies, which is a functionality we need. Also they are not much slower in general - at least not slower than their hardware equivalent in the space shuttle.
The safest way to keep things working here, is to keep components loosely coupled. They must not know that other components exist. They only need bundles that react that way. Yes, it is a lot of work more. Yes, it means that we very often miss dedicated user models there.
But the more I thought about the results, the more sense the bundles made. What I just lack right now are ideas for ways to reduce the effort for connecting components. Some kind of injection framework would be helpful, but then, I have no idea how it could look like.
), but other than that I think they're good enough to go out the door. That said, yes there's still work to be done in the panel logic, nozzle gimballing during burns, DPS interface, Centaur dumps, etc.
