Hi Gergely,
Looks absolutely fantastic! One point though: Line 75 of EuroScopePlugInIFlightPlanControllerAssignedData.h, virtual std :: string GetValueAsSting should be virtual std :: string GetValueAsString
Thanks for sharing! I start with feedback for the EuroScopePlugInIFlightPlanControllerAssignedData.
I see that approach types are introduced. In our sector file provider GNG, the following list of types is provided, replicating the ARINC capabilities:
A = Approach Transition
B = Loc Back Course
D = VOR/DME
G = IGS
H = RNP
I = ILS
J = GLS
L = Localizer
N = NDB
P = GPS
Q = NDB/DME
R = RNAV
S = VORTAC
T = TACAN
U = SDF
V = VOR
X = LDA
I suggest to use (parts of) this list for the types.
Is it possible to have LandingClearanceReceived flag added? Our vACC plugin currently does this via the cleared altitude and uses values 3 & 4 (cleared APCH, cleared visual APCH). But since this will not be supported, a separate flag similar to the ClearenceReceived one would be nice.
For the ground states I suggest the following additions: OnFreq, Clearance, Crossing (RWY, outbound), De-icing, Crossing (RWY, inbound). Can you think about a possibility to have all corresponding requests recorded (from any ground state), too? So that “pilots requesting clearances” or “pilots requesting taxi” can be recorded in the system? This could be helpful especially for the departure states like clearance, pushback or taxi, which need to be delayed sometimes due to traffic, the number of requests or priorities.
EuroScopePlugInIEuroScope.h
virtual std :: string GetEuroScopeVersion () const noexcept = 0 ;
- Is this planned to return the version in the format “3.2.7.0”, “3.2g” or something else? The first one would make comparisons easiest in cases where a plugin needs to enable/disable some features based on the EuroScope version.
EuroScopePlugInIFlightPlan.h
enum class ERadarStates
- RedundantFirst30Sec appears to be a new (or at least a previously undocumented) state. Could it be a settings-defined time instead of a fixed value?
virtual IFlightPlanRouteSptr GetProbingRoute ( IFlightPlanRouteSptr priorRoute, std :: string_view pointName, int clearedAltitude ) const noexcept = 0 ;
- Could the function be extended (or another one added) to probe a complete flightplan using an IFlightPlanData parameter? The use case would be probing the effects of changes to any combination of flightplan items (type, equipment, route, requested level, …).
EuroScopePlugInIFlightPlanControllerAssignedData.h
enum class EControllerAssignedValues
- Consider standardizing SpeedIas, SpeedMach and ClimbDescendRate entries to contain also min/max values, for example “280” would be 280kts exactly, “280+” 280kts or greater and “280-” 280kts or less.
- Is the numerical data such as Heading stored and communicated to other clients as a string or a number? If a plugin sets an assigned heading “113P”, will the ‘P’ cause SetValue to fail, and if not, will GetValueAsSting return “113” or “113P”?
- Plugins may contain very specific items, and it may not be necessary to have them all listed here. A generic “Custom” data type could be used for plugins to broadcast data that is not of interest to other plugins. The data would then not be permanent as the next broadcast of the same type would overwrite it so the plugins should monitor for changes and save the information locally. This would avoid the list of value types growing excessively long, and misuse of already existing types (due to not understanding the original purpose of the data type)
enum class EGroundStates
- Suggest to add “line-up” state. The use case would be this being an indication that the aircraft is cleared to enter the departure runway but not take off, inhibiting runway incursion alerts but not unauthorized takeoff alerts.
EuroScopePlugInIFlightPlanCoordination.h
enum class ECoordinationTypes
- Consider adding ClimbDescendRate (self explanatory) and TacticalPoint (for point coordinations other than the normal Point coordination)
- Consider same formats for min/max as suggested in EControllerAssignedValues rather than separate coordination types
EuroScopePlugInIFlightPlanData.h
virtual std :: string GetSidName () const noexcept = 0 ;
virtual std :: string GetStarName () const noexcept = 0 ;
virtual std :: string GetDepartureRwy () const noexcept = 0 ;
virtual std :: string GetArrivalRwy () const noexcept = 0 ;
- Consider adding “Set” functions for these
EuroScopePlugInIPopup.h
- Consider adding a possibility for a multiline edit control and adjust the text and background colors
EuroScopePlugInIRadarTarget.h
- Consider adding a function to get “on ground” flag from FSD data (with the current altitude and groundspeed checks as backup)
EuroScopePlugInIScreenList.h
- Consider adding a function to clear the list
- How/where do you set the list title?
EuroScopePlugInISectorFile.h
- Consider adding a class IMultiLineElement, similar to IMultiPointElement. It would contain the line data in a vector of <startposition,endposition,colorref>. The data in many sector file sections can not be expected to represent a continuous line, or even if it is, it may not be in a continuous order. Hence, if you try to draw the element from an IMultiPointElement, the result will not be correct. The IMultiLineElement class should only be used where the data is certain to contain a single continuous sequence of points (sector file regions, ese file sidsstars, sector lines and sectors).
EuroScopePlugInPlugIns.h
virtual void SendPlugInToPlugInMessage ( CPlugInBaseSptr sender, CPlugInBaseSptr target, std :: string_view message ) = 0 ;
- If the 80 character limit is necessary, can a longer message be split into multiple parts (will the parts be received in the correct order)?
- Could it be possible to send these messages to other controllers as well?
3 Likes
I am sorry missing the whole September. Also thank you for the sugesstions. I will answer them in the next days.
I had some progress with the x64 version (it is running), and I made some suggestion on how to change FSD to support all the API functions.
No. The coordination dos not use the FP. It is a direct controller to controller message. Only the two parties will see it. On the other hand controller assigned data will be published to all controllers. It will be available for everyone.
I am also thinking about a new “planning controller” position. This position will receive coordination data too.
2 Likes
“Part of” the list matches the enum at EApproachTypes. Is there any that I should add?
I would be happy not to use A, B, C or D in the enum, but the more readable name.
I added LandingClearenceReceived.
1 Like
Of course, I just added the letters for the full reference. IGS is definitely one that I’m missing and that we are using (LSGS, LSZA). I don’t know why there is a separate entry for LNAV, as this is part of the RNP APCH. SRA could be added too (the 2D kind equivalent of PAR for civil). Is ASR something similar? I’ve never hear of an approach type ASR. RNP AR also doesn’t necessarily require a separate entry in my opinion. If there were different RNP approaches, they would be differentiated with a letter. BTW: a curved segment (RF) requires an RNP AR, but an APCH can also qualify as RNP AR without such a segment.
Hello Gergely,
Could you please consider:
- Give a capability for us to retrieve all, or some, arrival/departure runways configured
- When the event is raised which tells us that runway data has updated, tell us what runway data updated/?
Is it possible to modify FSD to retrieve given user TAS/IAS/Mach or at least his/her sim’s wind/OAT?
3 Likes
If there was such an upgrade, also elements for mode S ELS & EHS (Mode S | SKYbrary Aviation Safety) should be considered to introduce the simulation of mode S downlink capabilities.
4 Likes
This is exactly why am I asking for 
1 Like
Unfortunately, this is something VATSIM FSD devs needs to implement first, which I assume Gregely does not work on. We have been asking this for years now… So I wouldnt count on it 
I don’t think Tech guys get on the forums that often. From what I remember, some of the Tech team is working on a rewrite of FSD, so I imagine they are investing their time in the new, not trying to improve the old, especially with the risk of unintentional breakage due to its age and “spaghetti” code.
Also, I was just informed that different aircraft use different variables for each of those fields, so it’s very complicated to pull that information correctly in a consistent way.
1 Like
If FSD would fetch this data, there would be an incentive to standardise these variables fields among developers. Even if it would only work on new aircraft, that would already be awesome. Backwards compatability would be difficult, but thats fine.
So i hope vatsim gives devs this incentive soon, or at least discuss a standard with plane devs so they can start building their planes accordingly. I assume a lot of new planes are in the makes for msfs2024 so…
1 Like
What’s worth mentioning that it’s not necessary to be a mandatory data pull. Just like in real life not all aircrafts are ewuipepd with EHS, this can be a optional field to download IF aircraft/pilot client is enabled/allowed/supported. Also, i.e. wind data shall be accessible via xuipc/fsuipc, as well as some other data, that can help in calculating estimate of the fields asked.
A long time ago i made a proof of concept which someone turned into a plugin that gives you calculated mach/ias.
Topsky already integrates this natively now
Yes but that’s based on fed weather data. Pulling data from the sim of the user would give you accurate for the given Traffic.
2 Likes
Any ETA of the new ES and API @904331 ?