Will this work with multiple outputs on one comp? Say I had 1 of with
Mint graphics for the main display and then another of for up to say 4 displays?
Yes. Yagni has all of his displays running from one comp--the same comp that's running Orbiter, actually. You could just as easily have one comp running Orbiter and another doing all your displays.
I'm also guessing that u can make it display almost anything you want? So if you wanted to make a copy of the 2d
Panel and put it on a big touchscreen( funds allowing) that would work?
Two issues:
-First and most important, the 2d panel is fully inside Orbiter, and many of its functions will be vessel-specific, which means that you wouldn't be able to do that through the network.
-It doesn't currently support mouse (and therefore touchscreen) input. It will at some point.
Also will there be an ask released with this that makes it easy for programming n00bs like me to
Make my own panels?
If you want to make a panel from existing components, you can make a config file detailing how to arrange those components. As an example, the screen on the left is of the Engines MFD, which is entirely done in a plaintext config file which defines where the displays go and what data they receive. These config files are loaded at runtime, so you don't have to re-compile RemoteMFD in order to make changes (and, in fact, you can make changes while the program is still running and reload the MFD to see the changes.
For more complex MFDs, there's a fairly simple API (very similar but not exactly the same as Orbiter's) for MFDs. Unfortunately, at this point adding a custom coded MFD requires rebuilding the project (since .dll files can't be loaded by the Linux version), but I'm looking into ways of getting around that, so hopefully at some point it would be just like Orbiter--you drop in a .dll (or a .so or wtf-ever the Linux version) and it can load and use it without needing to recompile the whole project.
Hope that answered your questions!
