Posts by SageMage

  • Aerofly FS4 SDK - External DLL

    Quote from Jugac64

    Well, FFB project is discarded, thanks for your feedback.

    By the way, a simulator doesn’t interact with the AB9 directly, the Moza Cockpit software is in the middle of the communication with the sims, and I suspect it would manage all these controls.

    If this what not the case, I doubt the other sims would have implemented the integration:

    MOZA Cockpit Control Software

    Our proprietary MOZA Cockpit Control Software sets the industry standard with its intuitive UI design and superior interaction experience. It offers plug-and-play convenience along with shareable presets for tailored force feedback settings. Users can effortlessly adjust control parameters, fine-tune the intensity of force feedback, and modify response characteristics to perfectly align with their personal preferences.

    To clarify - when I read about a FFB platform I imagined one of those tilting rigs used in motorsport simulation.
    I wasn’t aware you guys meant the force feedback on the stick.

    Uhm… depends a lot on what kind of inputs the MOZA system accepts.
    If you can calculate out of the sim data provided by the DLL the force on the control surfaces (so more or less a model as Jet-Pack suggested), then you would be able to tell how much force to provide.

    But still - depends how fast is the DLL, your calculations and then the response time of the ffb. You could have some delay or you could have none.

  • Airbus A320 A/P takes shortcuts

    Dear IPACS,

    I am writing to ask a clarification on a certain A320 behaviour during A/P usage following a flightplan. I have seen when there is some sort of "loop back" of the flightplan or a large bend used to change direction, the A/P decides that the flight plan further up is closer and cuts away the large radius curve to shorten the flight and jump to the next section.
    This can be reproduced on standard listed flight (Graz to Zurich).

    After ZUE, on descent, the A/P takes "shortcuts", but I have seen it happening on other flights (manually entered) with similar characteristics.

    This happens independently if is the "copilot" flying the aircraft or the user.



    In flight it looks like this:


    As you can see, the A/P decides that the left hand passage over the airport of Zurich is "too long" or any other reason, and cuts already to the loopback for the approach.

    Aerofly version: 4.07.01.00 (20250521) from App Store (not Test Flight)

    Mac Version:
    Mac Studio 32GB M2 Max Chip, Mac OS Sequoia 15.5
    Let me know what logs do you need or additional screenshots.
    Best regards,

  • Aerofly FS4 SDK - External DLL

    Quote from Jet-Pack (IPACS)

    Just for the record, a lot of what AIs tell you about how this interface with Aerofly FS works is completely false. There is no correct training data for AI so it cannot know the correct answer and just hallucinates. There is also no online documentation for it so there is no correct answer it can give you. This will require human intelligence and creativity to try out and experiment with.

    With enough dedication you can develop a force feedback system as well. You just need to do all the high speed stuff manually but you can use slower values like airspeed to modify the responses over time of course. So basically develop your own physics model for the control forces and then use the data from the sim to tune that model over time.

    Similarly you could theoretically develop a motion platform that has its own physics simulation of the aircraft and then slowly correct your own physical model with the response of the sim, e.g. using a Kalman filter or similar. Nothing is impossible it just takes a lot of work since the DLL is not designed for this high speed response.

    But like I said, for other applications like maps and tracking it should be more than enough.

    Yeah as a data point (without using AI and trying to stay out of IP issues) - in my line of work this kind of applications are done via etherCAT as the simulation data needs to:
    - arrive at 5 to 10kHz to be usable
    - need to be run with it's own realtime node.
    You absolutely do not want the simulation starting to drop frames because windows started the antivirus.
    In addition, once you start to use FFB or anything with humans, a lot of safeties needs to be backed it, like watchdog signals and limit monitoring (also on the motors!).
    You want to be pretty sure you're not sending NaNs to the motors or a high step demand because a delayed torque packet arrives later than expected.

    From what I have seen, 20 to 50ms delays causes big escalations from our users as it shuts down the HiL / SiL / Driver in the Loop - normally this is the range for a watchdog signal to be considered "triggered" and simulation stops.

    If you're doing low-risk, low-speed applications it's all ok.

    If you need to respond in realtime, you need to start implementing Matlab models (imagine a delay in the FFB system that gets out-of-sync with the video - the user would barf after a minute)

  • SayIntentions.AI

    Quote from Armitage

    COM/XPDR Data 1.0.1 (PROPOSAL)

    Send COM/Transponder packets at 1Hz (once per second), structured as:

    XCOM<simulator_name>,<com1_frequency>,<com1_transmitter>,<com2_frequency>,<com2_transmitter>,<transponder_code>,<transponder_ident>,<transponder_mode>

    Fields

    Totally forgot about this. I should implement it together with the XAIRCRAFT UDP package… :/

  • Aerofly FS4 UDP Flight Data recorder and Replay - Rewinger

    Dear all,
    small changes with Rewinger:
    Key Improvements:

    • Simulator-Agnostic UDP Parsing:

    Rewinger now supports UDP packets from multiple flight simulators (Aerofly FS 4, X-Plane 12, MSFS, and others) using the ForeFlight protocol. The simulator name is automatically detected and displayed in the UI.

    • Traffic & Aircraft Data Handling:

    The app now cleanly separates traffic data from simulator data, ensuring correct labeling and display for both your own aircraft and AI/online traffic.

    • Custom Aircraft Info Toggle:

    In the GPS Data Sender tool, you can now choose whether or not to send the custom XAIRCRAFT UDP packet. This is useful for compatibility with different simulators and network setups.

    • UI Improvements:

    The “Send XAIRCRAFT Info” option is now a user-friendly checkbox in the sender’s Aircraft Metadata section, making it easy to enable or disable as needed.

    • General Bug Fixes & Robustness:

    Improved handling of simulator name extraction, better traffic marker labeling, and overall more robust UDP message parsing.How to Update:

    • Pull the latest version from the GitHub repository:
    GitHub - AeroSageMage/rewinger: Modified Airtracker to be used with Aerofly FS4 UDP capabilities.
    Modified Airtracker to be used with Aerofly FS4 UDP capabilities. - AeroSageMage/rewinger
    github.com
    • For the GPS Data Sender, make sure to check the new checkbox if you want to send the custom aircraft info packet.

    Feedback Welcome!
    If you encounter any issues or have suggestions for further improvements, please let me know here or on Flight-Sim.org or on GitHub.

  • New Project: micro-synthetic-atc – Open Source Virtual ATC & Ground Handling for Aerofly!

    Quote from jtp

    Hello and thank-you for your aspiration and contribution, do you anticipate this project to be able to interact with the current ai; as of now they just land and disappear. Ideally it would be nice to be able to control them with instructions to park and then even put them on a schedule for departing again.

    Thank-you.

    Yeah I’m not the dev of the Sim, so until we can have traffic injection we won’t be able to do anything of that. Sorry…

  • SayIntentions.AI

    Quote from Armitage

    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.)

    I will then send you a PM to organize a first call - should we add also Jugac64 ?
    Best regards,

  • SayIntentions.AI

    Quote from Armitage

    What do you have in mind? A GitHub repository where we can collaboratively edit the documentation as well as having AIs understand the specification?

    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?