Posts by calou95

Hi Juan,

Thanks a lot for sharing the Kilo Code 101: Introduction to AI-Assisted Coding playlist—and for the shout-out! I’ve started watching it and it already helps me connect the dots between how I’ve been using AI intuitively and the more structured “modes” (architect, code, debug). Super useful for my ATC/TTS project.

If you’ve got any favorite episodes or practical tips you’ve tried, I’d love to hear them. In the meantime, enjoy the well-deserved break from hobby-coding—hope it’s a good recharge!

Best regards,

Pascal

Hi Juan,

Thank you very much for your quick and helpful reply. I really appreciate your support and the ideas you shared — it’s very useful for me to move forward.

Best regards,
Pascal

Hi Juan,

First of all, thanks again for your work on the Aerofly FS bridge – it’s been very helpful. I wanted to share where we are with the AP tablet project, because we are currently blocked on one point and I would really value your opinion.

• The sliders (SelectedHeading, SelectedAltitude, SelectedVerticalSpeed, SelectedAirspeed) via WebSocket are working well.
• The AP mode buttons (AP, HDG, ALT, VS, SPD, NAV, APP):
  • When using WebSocket variables (Autopilot.HeadingHold, Autopilot.AltitudeHold, etc.), there is no effect in the aircraft.
  • We tried an alternative solution via a keyboard bridge (the tablet sends keys to the simulator). The bridge works — we can see the key presses in Notepad — but Aerofly does not react to these key events in the aircraft.

So at this point we are unsure:

• Are the AP mode functions simply not exposed to WebSocket, and only available via cockpit interaction or keyboard bindings?
• Do you have any recommendation for reliably triggering those AP modes externally (through WS or another method)?

We are still experimenting, but right now we’re a bit stuck. Any guidance or confirmation from you would help us know whether we are on the right track or if we should change our approach.

Best regards,

Pascal

Hi Juan,

Thank you.

Many thanks for sharing the complete variable list . That’s exactly what I needed, and it will really help me with the work I’m doing right now.

I truly appreciate your support and generosity.

Best,
Pascal

Hi Juan,

First of all, thank you for your amazing work on Aerofly FS4 Bridge – the hash map optimization is really impressive.

I am currently developing a simple autopilot control panel (HTML/JS) using the WebSocket interface.
So far, basic variables like Autopilot.SelectedHeading, Autopilot.SelectedAltitude and Autopilot.SelectedAirspeed work well with sliders.

However, I am having trouble with some other functions:

• Flight Director (FD) → writing to Autopilot.FlightDirector, Autopilot.FD, or Autopilot.FD1/FD2 has no effect.
• Autothrottle → writing to Autopilot.Autothrottle, Autopilot.Autothrust, or Autopilot.AthrMaster also has no effect.
• Mode buttons (HDG, VS, ALT, NAV, APP) → variables like Autopilot.Mode.VS or Autopilot.Mode.APP seem to be read-only.

From the logs, I see the values being sent, but the aircraft does not react in the simulator.

👉 Could you please clarify which variables are actually writable to activate these functions?
Should we instead use specific Autopilot.Input.… variables to trigger these modes, rather than writing directly to the Autopilot.… or Autopilot.Mode.… variables?

Any guidance or a small mapping table (writable vs read-only) would really help us connect our panel correctly.

Thanks again for your great work and support!

Best regards,
Pascal

Hi Juan,

So for the moment the aircraft only detects airports within a 50 mn provided that they are in the manually entered navaids and airports.

it's simply a question for the future, for the tests it's enough for sure

Hi Juan,

Thanks a lot for your example, I do some tests.

Just a quick question: since adding each waypoint and airport one by one is quite tedious, I was wondering if you have any plans for a more automated solution. For example, in Flight Simulator, there's a tool (I think it’s called "MakeRunway") that scans the nav data files and generates a global navigation database. Are you considering something similar for Aerofly to avoid manual entry?

Regards,
Pascal

Hi Juan,

I wanted to sincerely thank you for your incredible work on the Aerofly FS4 Bridge DLL. I’ve downloaded the file and I’m really impressed by the quality and clarity of your documentation — it’s rare to see something so well-structured and well-explained.

I also took note of your important precision: this release doesn’t cover the controls.tmd variables from individual aircraft. As you mentioned, there are over 5,500 variables defined in these files across all aircrafts, and you’ve extracted some from the Cessna 172 controls.tmd file as a reference for adding others we might need.

It’s clear that at this stage, custom DLLs are necessary for specific applications, and we still don’t have a “one-size-fits-all” DLL for all possible needs. I think it’s great that you’re open to including cool custom examples in the examples section — this could encourage the community to contribute and expand the library.

I’ll be running some tests on my side soon, and I’ll be happy to share my results or any useful examples I can come up with.

Thanks again for your help and expertise.

Best regards,
Pascal

Thank you.

Thank you I will check that.

I see I’m not the only one struggling with the Thrustmaster TCA Throttle Quadrant in Aerofly FS4. In my case, the sidestick works fine, but I can’t get the quadrant to behave properly, especially for reverse thrust and detents.

If anyone here has managed to get the TCA Throttle Quadrant working correctly in Aerofly FS4 (with all detents recognised and reverse thrust functional), could you please share your exact settings or a step-by-step guide? It would be extremely helpful for those of us still trying to figure it out.

Thanks in advance!

Hello,

Hi, I actually have the same problem but the other way around. In Microsoft Flight Simulator the reverse thrust works perfectly for me, but in Aerofly I can’t get the reverse detent to work at all. If anyone has a step-by-step guide or instructions on how to set up the reversers in Aerofly with the TCA Airbus throttle, I’d be very interested.

Thanks in advance!

Best Regards,

Pascal

Hi Juan,

Thanks a lot for the update — that makes sense now!

We tested the HTML interface locally and everything works as expected, including the WebSocket communication and command sending.

We understand now that the real interaction with Aerofly will only be possible starting with next week’s release, once the internal WebSocket is integrated.

Looking forward to testing it as soon as it’s available. Great work — and thanks again for sharing this early!

Best regards,
Pascal

Hi Juan,

Thanks for sharing the test HTML file for the internal DLL WebSocket.

We ran the test and everything works fine locally — the WebSocket server responds correctly, and we can see the values being updated in the HTML interface. We’ve attached a screenshot with the log output as proof of concept.

That said, it looks like this is just a local simulation for now, and there is no actual interactivity with the Aerofly simulator yet (e.g., changing the throttle has no visible effect in the aircraft).

We assume this is normal and that it’s just an early test of the WebSocket interface. We’re looking forward to the next step, especially the version connected to Aerofly via the DLL.

Let us know when it’s ready!

Best regards,
Pascal

Hi Juan,

Thank you for the update – this is excellent and very promising news.
I’m really looking forward to testing the upcoming DLL version this weekend.
The WebSocket integration sounds like a great enhancement and opens exciting possibilities for future developments.

I’ll stay tuned for the next updates!

Best regards,
Pascal

Hi Juan,
That’s fantastic news! First time reading strings — it’s a big step forward! 🎉
And yes, what great timing with the release of GPT-5. It’s amazing that you can take advantage of it right away with Cursor. I'm really glad you're making such fast progress — the community is lucky to have you!

Keep going, it’s becoming more and more impressive!

All the best,
Pascal

Thanks Juan,
Yes, I’ve already seen improvements — more buttons and functions are now responsive, and it’s great to see the progress. I’ll continue testing as you update the DLL and scripts. I really appreciate your work on this project. Looking forward to the next version!

Best regards,
Pascal

Juan,

Thank you for your reply and for confirming that the DLL I'm testing is your current development version — that's great news!

I've done several tests using both your Aerofly Master Panel and a custom Python script that communicates directly with the DLL via UDP. Everything is working well on the communication side, and it's very promising for real-time control.

I did notice a few points I wanted to share with you:

• The Master Panel currently allows only fixed heading/altitude values (e.g., 90°, 180°, 500m), without rotary knob simulation or fine adjustments.
• Using a Python script, I was able to send specific values (e.g., heading 320°, selected altitude 1000m, selected airspeed 100 kt) — this offers much more flexibility for ATC-style guidance or radar vectoring.
• Some of the values displayed in the Master Panel (e.g., heading, speed) do not seem to fully match the actual aircraft state yet, but I imagine that will be refined as more variables are added.

Just a quick note to let you know that I reactivated the UDP option in Aerofly FS4. I initially had it turned off to make sure the data was coming directly from the DLL, which it was.

Now that I'm testing both the AeroflyBridge DLL and other tools like ATC Kim or Aircraft Tracker, it makes sense to keep UDP enabled. This way I can run both systems in parallel: your DLL through TCP and other tools through UDP. Everything seems to be working smoothly in that configuration.

Looking forward to your next DLL update — great progress so far.
Thanks again for your continued work. Very exciting to see this project taking shape!

Best regards,
Pascal

Hi Juan,

Thanks again for your work on the DLL. I’m very happy to see the project progressing so well — it’s really promising.

Thanks again for your work on the DLL. I just wanted to clarify something:

Is the version of the DLL you recently shared with me the most up-to-date one you're currently working on, or is it an earlier build?

Also, do you have a list (even partial) of the variables currently implemented in this version? That would help us better understand which systems are already functional and which are still in progress.

Thanks again, and talk soon!

Best regards,
Pascal