Posts by Armitage

    Instead of using TCP sockets and JSON parsing, this implementation uses Windows shared memory to create a direct data bridge between Aerofly FS 4 and external applications.

    This is the way to go, if we are to stay on Windows and only need to consider local applications. Actually way more efficient than having a network overhead or even writing a local file over and over again.

    Thank you for your work and research, Jugac64 and a nice trip.

    The possibilities are endless:

    • Send aircraft position data to some external programm, like an external ATC client or moving map - and this could be a local or internet service. There are plans to connect to Sayintensions, but this could also include VATSIM or a virtual airline client.
    • Interact with hardware like motion rigs, or other custom hardware not being able to register as a regular game controller. Think of external cockpit instruments like dedicated radio panels, e.g. Logitech cockpit panels
    • You could also improve mechanics like an external source for system failures on your aircraft, or have a talking co-pilot, screaming passengers or even a more dynamic custom mission generator.

    ...but for everything that needs the weather to change dynamically or inject traffic from the outside.

    This might be slightly off the original topic, but... if I wanted to set the real-world weather for a specific location in AeroFly, how would I do that using the in-sim weather parameters? I mean, if I check the weather from a real-world source, is there a way to match it using the available settings in the sim? I'm asking because right now, I just adjust the weather sliders randomly to change the conditions.


    Regards

    You might want to get structured flight weather, like in

    METAR, TAF and NOTAM decoder for all 68,423 airports
    Meteorological Aerodrome Reports (METAR), Terminal Area Forecasts (TAF), SIGMET and Notices to Airmen (NOTAM) of all airports in the world. Decoded and visual.
    metar-taf.com

    And then you need to translate this to the simulator's sliders:

    aerofly-wettergeraet/docs/aerofly-config.md at main · fboes/aerofly-wettergeraet
    ✈️ Copy METAR weather information into Aerofly FS2 and Aerofly FS 4 - fboes/aerofly-wettergeraet
    github.com

    If you are on a PC, you might also use the Wettergerät, which downloads METAR information to Aerofly FS:

    GitHub - fboes/aerofly-wettergeraet: ✈️ Copy METAR weather information into Aerofly FS2 and Aerofly FS 4
    ✈️ Copy METAR weather information into Aerofly FS2 and Aerofly FS 4 - fboes/aerofly-wettergeraet
    github.com

    We've updated the Aerofly FS 4 external DLL interface project:

    https://www.aerofly.com/developers/

    I am seeing splendid symbols:

    • AircraftName
    • AircraftNearestAirportIdentifier, AircraftBestAirportIdentifier and additional information for this airport
    • AircraftOnGround, AircraftOnRunway
    • NavigationNAV1Frequency and so on
    • NavigationCOM1Frequency, NavigationCOM1FrequencySwap and so on
    • TransponderCode
    • AutopilotHeading etc.
    • SimulationTimeChange, SimulationVisibility

    There is even an example which changes the stand by COM frequency.

    Oh, and it compiles:

    Happy times, this should be a good foundation for multiple ideas - be it the Sayintensions-JSON or a more generalized UDP API.

    Actually fetching METAR data via API needs some basic considerations, like:

    • What is the source of the METAR data?
    • Are there any API service costs for calling the API?
    • How reliable is the source? Is the API reachable at all times? Is it well reachable for all global users?
    • Does the API cover all airports in Aerofly FS?
    • How does Aerofly react if the API is not reachable, slow to respond, yields a broken answer or no aldata for the current airport?
    • How do you authenticate with the API? (You do not want other applications to leech your data by finding out your API key, adding to your costs.)

    In my experiments the APIs tend to have running costs (because offering such a service needs servers accessible via the internet), or offer limited service (a free API I found is centered on CONUS, and the data quality is sometimes lacking like mixing data types or missing data for certain airports at certain times).

    If you were really serious about offering a reliable METAR service, you would need a professional API with a CDN for robust world-wide access. Additionally you might need to build your own service on top of other APIs to offer reliable, ready-to-use and non-leechable data.

    I for one applaud you for flying DME arcs at all. 🫡

    Out of curiosity: is this departure included in Aerofly FS flight planning, or did you do the planning manually?

    (Hm, and I have to brush up on my procedure skills. My last ILS approaches, VOR Holding patterns or NDB / VOR approaches are long time ago. Maybe it is time for some custom missions?)

    My experience is that if airfields do not have an ICAO code, they almost always occur in METAR & TAF and have an individual country-specific code there, which also almost always matches the code in OurAirports.

    Currently around 1-2% of the airport codes of Aerofly FS cannot be resolved using the Ourairports DB. Using a solid pattern to identify airfields would improve the accuracy of external services like weather import or flight planning in outside tools.

    The map of the Aerofly airports in the Missionsgerät cannot display airports which cannot be found in the Ourairports DB (because there is no other source for geo coordinates), so airports with made-up identifiers are invisible there. (If there is any interest in these airports I can supply the list of identifiers.)

    Maybe it is not that useful, but the data needed for the Missionsgerät and its map has found a new purpose:

    Aerofly FS Airport Code Validator

    This small tools allows for checking if an airport exists in Aerofly FS4. You need to supply an ICAO Code, and it will answer if this code is present in the current version of the sim.

    The database (and datasets) behind this are kept up to date by a simple automatisation.

    Hi Frank, would it be possible please to add a checkbox or similar to select to use the name "custom_missions_user.tmc" fo the downloaded file? thanks!

    Jugac64 Well, this was quite a simple operation: The Missionsgerät has now a quick download button für custom_missions_user.tmc as the new primary button, and another button for named downloads.

    Hi Frank, if I want to add many tasks to a single file, I just need to make the missions individually and concatenate them in a single custom_missions_user.tmc file? thanks!

    Indeed, this is a rather manual process. The Missionsgerät will assist you by placing comments before and after every single mission to not mess up files with multiple missions, but the rest is not yet automated.

    At first to create a working group to understand the requirements. At minimum a teams / zoom call to discuss what do we need (IPACS in copy)
    Then, a document with the specifications and a first proof of concept.

    Something more structured than just a repo.

    What do you think?

    Sorry for taking so long with my answer, life has intervened. 😁

    I like the idea of having a big picture before rushing headlong into detail development. I think reaching out to IPACS where / how the community developers can help and/or get support by IPACS should be out first step. Because actually none of our ideas will work without the DLL.

    (I still dream of a general (UDP) API which would work exactly the same on all platforms, allowing for external applications to extend Aerofly without getting into the internal programming of AFS. Our mobile friends deserve ATC like any of us.)

    Or importing a simple CSV or Excel template! even better. Having this option, we would only need to take a snapshot of the task and ask chatgpt to parse it in the required CSV format 8), this would not alter Missionsgerät program flow.

    Well, CSV import is not so big a problem. Actually CUP files are CSV files:

    http://download.naviter.com/docs/CUP-file-format-description.pdf

    The Missionsgerät will happily parse CSV as long as you have at least 5 columns with these values:

    • name, code, country, lat, lon, elev

    Name and country can be ignored, elev is optional. And the file ending needs to be cup.

    But if you use AI, you can also ask it to build Garmin FPL files. Or CUP files. ^^

    (I tried to have AI build Aerofly TMC custom mission files, but as there is no official documentation, AI cannot build these files (yet). I also noticed that even after some teaching AI still believes TMC files to be like XML - which it is not.)