Reworking the output system

Something has been bothering me ever since I started this project: how to handle output of various functions. If you take a look at the Swashplate code you can see the problem: depending on the configuration you get two to four integers as output. Back then I solved this by having the user pass references to variables in which to store the result of swashplate mixing. The problem with this is that the user will have to pass references for all four result integers and was stuck with defining and passing dummy variables for results he doesn't need; ugly.

This becomes a lot more problematic when dealing with a fixed wing model. There's a ton of possible configurations with loads of servos, especially when you use an 18 channel transmitter's manual for inspiration... There's no way you can have a user pass a dozen or more references to result variables. The first solution was to have an array of integers in the PlaneModel class to store the results and use an enum to create indexes for that array. This way there only needs to be a single getResult function and the user can simply fetch the results it wants.

This works pretty well, but why stop there? Instead of putting the results in the PlaneModel class, they can also be stored in some central place accessible to other code. Other classes like Swashplate, Gyro and Retracts can also store their results there; easy. This also makes it a lot easier to implement programmable mixes later on. Another advantage is that I can now have the Channel class fetch its input from the central location instead of having to pass it as a parameter. Mapping certain functions to channels suddenly becomes a whole lot easier and it's even possible to have multiple channels share the same input and still have their own subtrim, endpoints and reverse settings; pretty neat.

Are there downsides to this approach? Absolutely. I have yet to figure out how to get certain functions store their output in the storage, mainly because there isn't really any encapsulating code for those functions (like throttle and rudder on a helicopter), as a programmer you're still stuck with storing those values in the storage manually. Furthermore you're now stuck with a large array for all possible functions, wasting valuable RAM. The advantages outweigh the disadvantages by far though, and I do believe this is the right approach, or at least a step in the right direction...