I understand what you are saying with respect to the seaplane base being inside CYVR, but if your product fails to recognize the position of an aircraft parked at CYVR south terminal (which is a very busy terminal, not to mention all the FBO's located there), and interpolates it as being in range of CAM9, then your ability to properly code is lacking.
Airports in the Navdata don't have something like a "perimeter". They only have a center point, which usually is the real world ARP, and that's it. How you do expect a "properly coded" program could possibly decide which airport you are in, having only two coordinates ( the ARP and the Airplane ) to compare ?
When you are located on CYVR South terminal, your position is CLOSER to CAM9 ARP than it is to CYVR ARP so, what would be your suggestion on what to do in this case ?
GSX has a default "visibility" range for airports, that is 3.0NM, which is usually fine, since most nearby airports are not closer than that. However, this won't work when there are airports inside this range, like Helipads/Airbases/Seaplane docks, etc.
Of course, GSX already some ways to filter out airports that are unlikely to be useful with GSX, so you won't have to edit their visibility manually, and it works in a way that, in order to be considered usable, an airport should have at least 2 parking spots, one taxiway and one runway, which is the bare minimum GSX can work with. Any airports that don't fulfill this criteria will be automatically excluded, and that will remove most of those Helipads or Seaplane bases, so there's no manual editing required in most cases.
However, Flightsim studios CAM9 is a bit unusual, since it has 3 Parking spots, several "taxiways" and one water runway, so it satisfied all the criteria we set in place to automatically accept an airport. Which means, in THIS case, it REQUIRES to use the fully documented procedure in the manual, that is setting its visibility to 0 to exclude it.
OBVIOUSLY, following YOUR report, since never before somebody reported an Seaplane base that looks like a "complete" airport before ( or maybe most users just accepted the normal visibility procedure in the manual and just edited them out without making such a big fuss ), we added a new criteria in the filtering method, which will ignore an airport that has only Water runways, and this will of course included in the next update, due out in the next days.
Yet, it's the sim's fault. The exe.xml file is perfectly fine, as I compared it to the one you posted in the pertinent thread. So, that can't be the reason. This brings us to your second diagnosis that it's the sim's fault. I guess those programmers at Asobo are nowhere near as good as you huh? LMAO
Here's a post on Asobo Developers forum, opened by another developer:
https://devsupport.flightsimulator.com/questions/8061/exexml-fails-to-launch-my-simconnect-external-appl.htmlAnd here's the reply from an actual Asobo developer:
That's an issue we're already tracking. It's related to MS Store checking the app (MSFS) has a correct licence but also checking for child apps and failing in this case. We will come back to you when we know more about this.
So much for me "blaming the sim" for no reason...when this was a very well known and confirmed bug which, even with a perfectly fine EXE.XML, still resulted in the sim not starting the .EXE in some cases. We are not sure if it has been completely fixed in SU11, surely it's not in the release notes, so perhaps Asobo hasn't confirmed it has been fixed, because they still know there might be some cases in which it hasn't.
