You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As you know, there are some airports in the world, which are close to each other and causing false detections during landing or flight start. And also there are some addon related "fake airports" which are identified as proper airports by acars.
If we can have a comma separated list at admin side and if vmsAcars reads them during initial load and uses it (as an array) when the airport checks are done to avoid/exclude, then we may have a simple way to avoid detection errors.
You are flying to WSSS / Singapore Changi Airport
Landing on runways 02R or 02C will result a false airport detection of WSAC / Singapore Changi Airbase (East)
Because both ends of those runways are closer to the military base.
( Also there are smaller strips in some European airports, like Flying club bases with different ICAO codes, pretty close to main airports, even some are in the zone of main airport but identified differently. Which we had problems before but I am not able to find that example. It was in Poland probably, a small strip close the the one end of a runway causing false identification same like the one above )
Another scenario about addon problems;
You land to Amsterdam (any runway)
But you are close to a fake airport called (ZHAM, which is a fake/invisible airport covering real EHAM)
This will be recorded as a diversion
In FsX/Prepar series, some developers use different afcad techniques to have better results, as an example FlyTampa's EHAM (Amsterdam) scenery has some fake active airports with ZHAM icao code. Also FsDG's LOWG (Graz) has some called LOG1 and LOG2 as separate airports. Both will be identified during landing and departure checks depending on your location.
My suggestion is something like below;
Admins enter the airport codes (fake or real) at admin side, vmsAcars module settings
Field Name; excluded_airports
Field Type; mediumtext (or varchar)
Field Value; ZHAM, WSAC, LOG1, LOG2 // Entered manually by the admin
During acars airport checks (flight start or landing)
Get these list, either by code or by location
Exclude them from checks
$excluded_airports = explode(',', $settings->$excluded_airports);
if ($closest_airport->whereIn('icao', $excluded_airports)) {
continue;
}
Alternate solution (performance related)
If live check/skip hurts scanning performance, then we may have a boolean field for airports at vmsAcars database called active.
Default will be true (1) during record creation (re-sync button press).
Query loading airports within acars should have WHERE active = 1
If the admin adds some airports to the exclude list, then during acars start and re-scan process, these airport codes should be updated/created as active = false (0)
If they get removed, they should be updated back as active
(or a scenery re-scan should be done to have them re-recorded with default value)
This will simply avoid them even being read by the queries checking for closest airports.
Either of the solutions above will give admins to have the ability to define their "excluded" airports to avoid problems as they face them (or new ones arise when new problem causing airports come up)
The text was updated successfully, but these errors were encountered:
As you know, there are some airports in the world, which are close to each other and causing false detections during landing or flight start. And also there are some addon related "fake airports" which are identified as proper airports by acars.
If we can have a comma separated list at admin side and if vmsAcars reads them during initial load and uses it (as an array) when the airport checks are done to avoid/exclude, then we may have a simple way to avoid detection errors.
https://geojson.io/#map=14/1.3471/103.9982
https://www.openstreetmap.org/search?query=Changi%20Airport#map=14/1.3388/104.0235
You are flying to WSSS / Singapore Changi Airport
Landing on runways 02R or 02C will result a false airport detection of WSAC / Singapore Changi Airbase (East)
Because both ends of those runways are closer to the military base.
( Also there are smaller strips in some European airports, like Flying club bases with different ICAO codes, pretty close to main airports, even some are in the zone of main airport but identified differently. Which we had problems before but I am not able to find that example. It was in Poland probably, a small strip close the the one end of a runway causing false identification same like the one above )
You land to Amsterdam (any runway)
But you are close to a fake airport called (ZHAM, which is a fake/invisible airport covering real EHAM)
This will be recorded as a diversion
In FsX/Prepar series, some developers use different afcad techniques to have better results, as an example FlyTampa's EHAM (Amsterdam) scenery has some fake active airports with ZHAM icao code. Also FsDG's LOWG (Graz) has some called LOG1 and LOG2 as separate airports. Both will be identified during landing and departure checks depending on your location.
Admins enter the airport codes (fake or real) at admin side, vmsAcars module settings
Field Name; excluded_airports
Field Type; mediumtext (or varchar)
Field Value; ZHAM, WSAC, LOG1, LOG2 // Entered manually by the admin
During acars airport checks (flight start or landing)
Get these list, either by code or by location
Exclude them from checks
If live check/skip hurts scanning performance, then we may have a boolean field for airports at vmsAcars database called active.
Default will be true (1) during record creation (re-sync button press).
Query loading airports within acars should have
WHERE active = 1
If the admin adds some airports to the exclude list, then during acars start and re-scan process, these airport codes should be updated/created as active = false (0)
If they get removed, they should be updated back as active
(or a scenery re-scan should be done to have them re-recorded with default value)
This will simply avoid them even being read by the queries checking for closest airports.
Either of the solutions above will give admins to have the ability to define their "excluded" airports to avoid problems as they face them (or new ones arise when new problem causing airports come up)
The text was updated successfully, but these errors were encountered: