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.
That's awesome - I would like to implement it but on Mac that seems a big no no.
Hopefully one day...
Sorry to hear that.
@Jet-Pack is there a way to compile on a Mac? Or at least to compile for a Mac? As I understood DLLs are not a Mac-thing?
The possibilities are endless:
...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
And then you need to translate this to the simulator's sliders:
If you are on a PC, you might also use the Wettergerät, which downloads METAR information to Aerofly FS:
We've updated the Aerofly FS 4 external DLL interface project:
I am seeing splendid symbols:
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:
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.
Done - that was easier than expected!
Indeed. Onwards to happy collaboration. 
Believe me or not but I never had a pull request up until now 😂 as you prefer
Here you go:
Believe me or not but I never had a pull request up until now 😂 as you prefer
I try my best. 
Totally forgot about this. I should implement it together with the XAIRCRAFT UDP package…
Do you want to add this to https://github.com/AeroSageMage/r…UDP_Protocol.md?
Or do you want me to make a pull request for this?
Note:
UDP packet XAIRCRAFT is an experimental message generated via GUI_send_udp_data.py that contains additional aircraft data (e.g. callsign, airplane type,...) and can be used for future implementations.In the future it can contain things like radio status, TCAS, ...
Is there any documentation on this?
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.
You are perfectly right. Thanks for testing, I fixed it.
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
, 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 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.)
