Open quassbutreally opened 3 years ago
Regarding Thought 4, maybe consider using the SimConnect SDK instead of FSUIPC as it can work straight out of the box instead of the faff with FSUIPC and all that?
Regarding Thought 4, maybe consider using the SimConnect SDK instead of FSUIPC as it can work straight out of the box instead of the faff with FSUIPC and all that?
This is something I was considering and is definitely an option, the primary difficulty is that both the P3D Simconnectand X-Plane SDKs are written in C++. Subsequently, I'd need to write a C# wrapper for both to be able to interface with them. This is something I can do but the great benefit of FSUIPC and XUIPC is that Pete has already done that, and both can be interfaced with through C# directly. For the end user there should be no difference besides the requirement of having FSUIPC/XUIPC installed. The MSFS SDK is written for .NET so FSUIPC would not be required in that case.
Hi All,
The final stages of implementing reporting functionality have introduced some difficult decisions regarding functionality and I'd be interested to hear your input. Namely: How reporting should know a) where you are and b) where you're going.
I've had some initial thoughts around this, and would like to know what your thoughts are.
1) EasyCPDLC has no concept of airways or fixes. For every position report you must tell it which fixes you are referencing. EasyCPDLC could store information from the previous report, so the first report you would need to type everything in, but the second report would be mostly prefilled and only require updating. This has the benefit of keeping the program small but obviously is not as efficient as it could be.
2) I can have the conversation with Navigraph regarding use of their data to store fix and waypoint information, and generate the list of fixes that way. That would require a Navigraph subscription in order to use EasyCPDLC, and I don't want to put it behind a second-hand paywall, but if enough people have pre-existing Navigraph subscriptions then that is an option.
3) I can include functionality to load a flight plan file into CPDLC, in P3D, MSFS or X-Plane format. This would simply load the fixes in as they are read from the flight plan. This has the benefit of being efficient and easy but would mean that ATC route changes would not be loaded, and a new flight plan would need to be created, not optimal for NAT operations and such.
4) The last option I am considering at the moment is writing FSUIPC/XPUIPC integration into EasyCPDLC so that it can read data directly from the simulator. This does mean that EasyCPDLC would become considerably larger and more complex, and would take some time to develop, but it would enable the reading of fixes, altitudes and speeds directly from the simulator.
As always, these are only my ideas, feel free to suggest new ones, or perhaps a mix and match or multitude of what's listed above. It's your feedback that I really want to capture here in terms of what the best way to progress might be.
Thanks all.