Identify Key DataRefs for Pilot Performance #2

[hrmeiners]

fixes issue https://github.com/oss-slu/PilotDataSynchronization/issues/2

What was changed: Documented and researched the key DataRefs of Altitude, Airspeed, Vertical Airspeed, and Heading.

Why was it changed: We need to figure out what values we want to pull from the flight simulator, as there are hundreds to thousands of DataRefs to choose from. Also, these DataRefs and their respective getter/setter functions do not support automatic typing, so we need to have a concrete and clear understanding of the data types being used.

How it was changed: I added a markdown file with my research to the code, along with some questions about the research that I made and the expected outcomes.

I have some concerns that I will address during our in-class code review, including the validity of the data I found and what the issue meant by find the usage of these DataRefs.

1. The values listed may not be the ones we actually want for our plugin, as these all correspond to the true flightmodel readings. There is an argument that DataRefs from gauges and instruments (which may be faulty in the simulator purposefully/accidentally) should be read instead to provide the data the pilot using to fly. I plan to discuss this with my group on Monday during our code reviews and confirm.

2. I am unsure what the github issue meant by finding the usage of these DataRefs. Am I to figure out what they are used for within XPlane itself? Or do I need to figure out what we will be using them for in our plugin? I plan on also raising this issue with my group during our Monday capstone meeting.

[harshitha-thota]

Great job on documenting the key DataRefs for Altitude, Airspeed, Vertical Airspeed, and Heading! The markdown file provides a solid foundation, but there are a few areas that need clarification before final approval. Specifically, the "Usage" section for each DataRef is still marked as tbd, which is crucial for understanding how these values will be applied in the plugin. Additionally, it would be helpful to remove redundant information and provide more context on the choice of data types and why certain DataRefs were selected over others. I also recommend moving the open questions about the DataRefs' usage in XPlane versus the plugin into the issue or PR comments to keep the documentation clean. Once these areas are addressed, the PR will be ready for merge. Looking forward to further discussion!

[hrmeiners]

@kate-holdener Thank you both for the input! Professor Holdener, you are completely right about not including questions in documentation and it completely slipped my mind when making the pull request! I have deleted these questions (but not the initial notes) from my markdown file!

@harshitha-thota , you are right in that the "Usage" sections of the DataRefs still need work, and I will be completing that tonight or tomorrow at some point! I do have a few questions from your comments, however:

1. What redundant information do you mean? Are you referring to the alternate DataRefs that I found that I included in the document? I feel that while including more DataRefs in the documentation may be a little redundant, they are all used for slightly different readings/usages and contain slightly different pieces of data.
2. Going along with my last point, would you rather I describe the DataRefs that have the objective position of the aircraft in my documentation? Or would you rather I focus on what the pilot is flying off of in the simulator (i.e. from instruments that may/may not be faulty). I am confused on what we are using these DataRefs for specifically, and the small differences in data being held in different DataRefs may change the outcome of our code depending on their use.

[harshitha-thota]

Thanks for your response! Regarding the redundant information, I was referring to the inclusion of multiple DataRefs that serve similar purposes, such as for airspeed and vertical airspeed. While it's important to cover all relevant readings, it might help to clarify why each of these DataRefs is necessary or how they differ, to avoid confusion. If you feel they capture slightly different aspects, just make that explicit in the documentation so we can see the distinction. As for focusing on objective position or what the pilot sees, I think it would be more valuable to focus on what the pilot is flying off of (i.e., the instrument readings), since this aligns more closely with evaluating their performance in the simulator environment. This is something we can refine further as we move forward, but for now, documenting the instrument-based readings seems more practical for our synchronization with iMotions.