flightgear-devel Mailing List for FlightGear - Flight Simulator

On Fri, 17 Apr 2026 07:54:32 +0000
Josh Davidson <jos...@ou...> wrote:

> Speaking of which, why after roughly 30 seconds of the flight recorder, does it get "less detailed"? Really sucks when you want to replay your landings and see some beautiful gear animations 🙂
> 
> Surely that time should be extended so I can at the very least, taxi off the runway?

Are you aware of "Continuous" disc-based recording/replay?

This has been available on next since 2021, and is in 2024.1.

See https://wiki.flightgear.org/Instant_Replay.

- Jules

> 
> --
> Josh Davidson
> ________________________________
> From: James Turner <ja...@fl...>
> Sent: Friday, April 17, 2026 02:51
> To: FlightGear developers discussions <fli...@li...>
> Subject: Re: [Flightgear-devel] External UDP flight recorder
> 
> 
> 
> On 17 Apr 2026, at 00:26, Israel Emmanuel <sri...@gm...> wrote:
> 
> Hello again! I've been looking at some FlightGear docs for some work I've been doing, and I've recently discovered FlightGear's capability to output sim data over UDP at rather high frequencies. The flight recorder we have in sim currently does the job, but it can look blocky during replays, the number of custom properties that can be recorded is limited, and (I think?) it's running on the sim's resources. Is it viable/a good idea to have an external tool record flight properties at a certain rate, and allow FlightGear to play those back? Please let me know what you think.
> 
> I think you’d be better understanding/ fixing the blockyness you mention with the built-in recorder, since the Network I/O also runs synchronously with the main loop: you can’t escape the problem by using the network, on the playback side. The replay system does do some down-sampling, but this is tuneable if you’re seeing issues with it.
> 
> You can already save replays to file, that’s called a ’tape’ - Jules added support for that a while ago.
> 
> The replay system uses a trivial amount of resources and (as far as I can remember) allows an arbitrary number of custom properties, so I think unless you have a highly specific use case (which, ok, maybe you do), you aren’t going to magically solve anything by switching to a UDP solution.
> 
> Kind regards,
> James
> 



-- 
http://op59.net

> On 17 Apr 2026, at 11:40, bo23--- via Flightgear-devel <fli...@li...> wrote:
> 
> 
> The following is a different issue, maybe it was there before, but just
> noticed it in conjunction with this change in C-ARES. Some examples
> along the lines:
>    .../next/simgear/simgear/io/DNSClient_cares.cxx:95:19: warning: ‘void ares_query(ares_channel_t*, const char*, int, int, ares_callback, void*)’ is deprecated: Use ares_query_dnsrec instead [-Wdeprecated-declarations]
>    .../next/simgear/simgear/io/DNSClient_cares.cxx:134:44: warning: ‘int ares_parse_naptr_reply(const unsigned char*, int, ares_naptr_reply**)’ is deprecated: Use ares_dns_parse instead [-Wdeprecated-declarations]

https://gitlab.com/flightgear/simgear/-/work_items/19
Conditionally, use the C-Ares 1.28 APi (#19) · Issues · FlightGear Flight Simulator / simgear · GitLab
gitlab.com


Kind regards,
James

On 2026-04-17 10:30 +0100, James Turner wrote:
> 
> > On 17 Apr 2026, at 09:50, Florent Rougon via Flightgear-devel <fli...@li...> wrote:
> > 
> > This should now be fixed in 'next' and in 'release/2024.1’.
> 
> Thanks Florent for figuring this out - since I don’t use D&C I was pretty confused how we were getting non-released versions of dependencies in Mariuz’s build.

Tested and approved here with DnC on Debian 13 stable, both 'next' and
'release/2024.1' compile fine. Thanks to Florent, Mariusz and PlayeRom.


The following is a different issue, maybe it was there before, but just
noticed it in conjunction with this change in C-ARES. Some examples
along the lines:
    .../next/simgear/simgear/io/DNSClient_cares.cxx:95:19: warning: ‘void ares_query(ares_channel_t*, const char*, int, int, ares_callback, void*)’ is deprecated: Use ares_query_dnsrec instead [-Wdeprecated-declarations]
    .../next/simgear/simgear/io/DNSClient_cares.cxx:134:44: warning: ‘int ares_parse_naptr_reply(const unsigned char*, int, ares_naptr_reply**)’ is deprecated: Use ares_dns_parse instead [-Wdeprecated-declarations]

> On 17 Apr 2026, at 09:50, Florent Rougon via Flightgear-devel <fli...@li...> wrote:
> 
> This should now be fixed in 'next' and in 'release/2024.1’.

Thanks Florent for figuring this out - since I don’t use D&C I was pretty confused how we were getting non-released versions of dependencies in Mariuz’s build.

Kind regards,
James

> On 17 Apr 2026, at 09:48, Josh Davidson <jos...@ou...> wrote:
> 
> ok, hopefully I remember to run some tests. If I forget, feel free to nag me... or maybe other replies on this thread will remind me 🙂
> 
> I leave on weekends to be elsewhere so my FG is pre-compiled.

It’s a property :) No re-compilation needed….

Kind regards,
James

Hi,

Le 16/04/2026, bo23--- via Flightgear-devel <fli...@li...> a écrit:

> Since I'm unable to join GitLab, I want to add to the work item #45 [1]
> that there was an update of C-ARES on 2026-04-12 [2] which indeed does
> break compilation for both release/2024.1 and next using the
> download_and_compile.sh script.

> [1] https://gitlab.com/flightgear/simgear/-/work_items/45
> [2]
> https://github.com/c-ares/c-ares/commit/6475221a427394b6d2a3d3cb0b0abe189681ddd4#diff-2d7ae311fda1b7648d4ed70203bc820699d76845a5a72165baf6dd1d6deea8f9

This should now be fixed in 'next' and in 'release/2024.1'.

Regards

-- 
Florent

ok, hopefully I remember to run some tests. If I forget, feel free to nag me... or maybe other replies on this thread will remind me 🙂

I leave on weekends to be elsewhere so my FG is pre-compiled.

--
Josh Davidson
________________________________
From: James Turner <ja...@fl...>
Sent: Friday, April 17, 2026 03:46
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] External UDP flight recorder



On 17 Apr 2026, at 09:42, Josh Davidson <jos...@ou...> wrote:

Nevermind, it's already 60. Then lets double to 120. How does that affect?

Depends how many properties are recorded, but you should be able to test empirically.

(SCIENCE again)

But wild guess, we’re talking some MBs, not GBs, so ‘probably fine’, even to go to say 240/300.

Kind regards,
James

> On 17 Apr 2026, at 09:42, Josh Davidson <jos...@ou...> wrote:
> 
> Nevermind, it's already 60. Then lets double to 120. How does that affect?

Depends how many properties are recorded, but you should be able to test empirically. 

(SCIENCE again)

But wild guess, we’re talking some MBs, not GBs, so ‘probably fine’, even to go to say 240/300.

Kind regards,
James

Nevermind, it's already 60. Then lets double to 120. How does that affect?

--
Josh Davidson
________________________________
From: Josh Davidson <jos...@ou...>
Sent: Friday, April 17, 2026 03:41
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] External UDP flight recorder

How bad would it be to bump it to 60s, to match the FSX/P3D sims?

--
Josh Davidson
________________________________
From: James Turner <ja...@fl...>
Sent: Friday, April 17, 2026 03:38
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] External UDP flight recorder



On 17 Apr 2026, at 08:54, Josh Davidson <jos...@ou...> wrote:

Speaking of which, why after roughly 30 seconds of the flight recorder, does it get "less detailed"? Really sucks when you want to replay your landings and see some beautiful gear animations 🙂

Surely that time should be extended so I can at the very least, taxi off the runway?


<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>
[FlightGear_logo.png]
src/Aircraft/replay-internal.cxx · next · FlightGear Flight Simulator / flightgear · GitLab<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>
gitlab.com<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>

We can probably raise these a bit, but it does eat some memory, which is typically one of our ‘more constrained’ resources.

Kind regards,
James

How bad would it be to bump it to 60s, to match the FSX/P3D sims?

--
Josh Davidson
________________________________
From: James Turner <ja...@fl...>
Sent: Friday, April 17, 2026 03:38
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] External UDP flight recorder



On 17 Apr 2026, at 08:54, Josh Davidson <jos...@ou...> wrote:

Speaking of which, why after roughly 30 seconds of the flight recorder, does it get "less detailed"? Really sucks when you want to replay your landings and see some beautiful gear animations 🙂

Surely that time should be extended so I can at the very least, taxi off the runway?


<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>
[FlightGear_logo.png]
src/Aircraft/replay-internal.cxx · next · FlightGear Flight Simulator / flightgear · GitLab<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>
gitlab.com<https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305>

We can probably raise these a bit, but it does eat some memory, which is typically one of our ‘more constrained’ resources.

Kind regards,
James

> On 17 Apr 2026, at 08:54, Josh Davidson <jos...@ou...> wrote:
> 
> Speaking of which, why after roughly 30 seconds of the flight recorder, does it get "less detailed"? Really sucks when you want to replay your landings and see some beautiful gear animations 🙂
> 
> Surely that time should be extended so I can at the very least, taxi off the runway?


https://gitlab.com/flightgear/flightgear/-/blob/next/src/Aircraft/replay-internal.cxx?ref_type=heads#L305
src/Aircraft/replay-internal.cxx · next · FlightGear Flight Simulator / flightgear · GitLab
gitlab.com

We can probably raise these a bit, but it does eat some memory, which is typically one of our ‘more constrained’ resources.

Kind regards,
James

Speaking of which, why after roughly 30 seconds of the flight recorder, does it get "less detailed"? Really sucks when you want to replay your landings and see some beautiful gear animations 🙂

Surely that time should be extended so I can at the very least, taxi off the runway?

--
Josh Davidson
________________________________
From: James Turner <ja...@fl...>
Sent: Friday, April 17, 2026 02:51
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] External UDP flight recorder



On 17 Apr 2026, at 00:26, Israel Emmanuel <sri...@gm...> wrote:

Hello again! I've been looking at some FlightGear docs for some work I've been doing, and I've recently discovered FlightGear's capability to output sim data over UDP at rather high frequencies. The flight recorder we have in sim currently does the job, but it can look blocky during replays, the number of custom properties that can be recorded is limited, and (I think?) it's running on the sim's resources. Is it viable/a good idea to have an external tool record flight properties at a certain rate, and allow FlightGear to play those back? Please let me know what you think.

I think you’d be better understanding/ fixing the blockyness you mention with the built-in recorder, since the Network I/O also runs synchronously with the main loop: you can’t escape the problem by using the network, on the playback side. The replay system does do some down-sampling, but this is tuneable if you’re seeing issues with it.

You can already save replays to file, that’s called a ’tape’ - Jules added support for that a while ago.

The replay system uses a trivial amount of resources and (as far as I can remember) allows an arbitrary number of custom properties, so I think unless you have a highly specific use case (which, ok, maybe you do), you aren’t going to magically solve anything by switching to a UDP solution.

Kind regards,
James

> On 17 Apr 2026, at 00:26, Israel Emmanuel <sri...@gm...> wrote:
> 
> Hello again! I've been looking at some FlightGear docs for some work I've been doing, and I've recently discovered FlightGear's capability to output sim data over UDP at rather high frequencies. The flight recorder we have in sim currently does the job, but it can look blocky during replays, the number of custom properties that can be recorded is limited, and (I think?) it's running on the sim's resources. Is it viable/a good idea to have an external tool record flight properties at a certain rate, and allow FlightGear to play those back? Please let me know what you think.

I think you’d be better understanding/ fixing the blockyness you mention with the built-in recorder, since the Network I/O also runs synchronously with the main loop: you can’t escape the problem by using the network, on the playback side. The replay system does do some down-sampling, but this is tuneable if you’re seeing issues with it.

You can already save replays to file, that’s called a ’tape’ - Jules added support for that a while ago.

The replay system uses a trivial amount of resources and (as far as I can remember) allows an arbitrary number of custom properties, so I think unless you have a highly specific use case (which, ok, maybe you do), you aren’t going to magically solve anything by switching to a UDP solution. 

Kind regards,
James

> On 17 Apr 2026, at 02:58, Josh Davidson <jos...@ou...> wrote:
> 
> So all in all, this was just one of my "didn't really pan out" ideas. I will not pursue it further.

All good info, thanks for trying, and writing up the results.

SCIENCE!

(Sorry, couldn’t resist….)

Kind regards,
James

Hi List,

I am no longer pursuing this as originally "imagined".

It works for a game like GTA because they don't simulate flight dynamics. It slews the rate up to a fixed amount based on key input, but if you release before it reaches that rate, it will reverse back to 0. And then if you let it get that rate, releasing slews it back to zero.

I put together a prototype which works as I describe, and immediately two things are obvious:

  1.
for dynamic flightpath like flare, it's not awful, maybe a very slight improvement
  2.
for fixed flightpath, it's ok in roll, but AWFUL in pitch, because pitch doesn't naturally damp to 0 like roll does (assuming coordinated flight, no wx, etc). It is at least NO BETTER than the existing method, except that it's harder to control your rates.
  3.
Pitch trimming is problematic, as on my keyboard, pushing a elevator up/dn key, will interrupt the trim key's "held" event, making it stop trimming. It's almost easier to just "fly" with pitch trim even though that is very slow to respond...
  4.
Sean's initial reaction "So how do I hold a specific aileron deflection for a specific period, e.g. for 10s?" ended up being a pretty big issue, you cannot really do that, and the system cannot react quick enough for tapping to be useful - both due to the required slow deflection (otherwise you'd get PIO constantly if slewed faster), and the delay of hydraulic surfaces (which in GTA, is obviously not a problem).

So all in all, this was just one of my "didn't really pan out" ideas. I will not pursue it further.

Instead, I may switch my efforts over to some sort of "CWS" addon, which allows you to use CWS-inspired control to fly the plane, and narrowing the scope to airliners (and maybe GA) only (as parameters change to drastically for other types, expected rates, etc).

Kind Regards,

--
Josh Davidson
________________________________
From: Josh Davidson <jos...@ou...>
Sent: Monday, April 6, 2026 16:07
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal

Sean - yep, you're right. I wasn't thinking clearly - the roll damps out if the Clp is non zero and the Clda is zero. Duh.

--
Josh Davidson
________________________________
From: Sean McLeod <se...@se...>
Sent: Monday, April 6, 2026 15:48
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal


Hi Josh



No, when the roll damping moment equals the roll moment due to the aileron deflection it means there is no net roll acceleration. Which means that the aircraft will maintain the current roll rate it has.



So in the beginning as you deflect the aileron, there is no roll rate yet, so the roll damping moment is 0, and the roll moment due to the aileron deflection generates a roll acceleration which starts generating an increasing roll rate. As the roll rate continues to increase then the roll damping moment starts to increase until at some point it equals the roll moment due to aileron deflection.



At which point, the roll acceleration which would have been decreasing over time then becomes 0. But by this point the aircraft has built up some roll rate which then becomes the steady-state roll rate. So until the aileron deflection is reduced it will continue rolling at this roll rate.



You can see in the A4 example I shared that it takes roughly 2s for the roll damping moment to equal the roll moment due to aileron deflection, but at which time the roll rate, which now becomes the steady state roll rate has built up to roughly 350deg/s!



Cheers



From: Josh Davidson <jos...@ou...>
Sent: Monday, April 6, 2026 10:08 PM
To: FlightGear developers discussions <fli...@li...>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal



Hi Sean,

If Clp = -Clda, won't the roll rate be ~0 (assuming no wind, coordinated flight, etc)



Or did I misunderstand somewhere?



--

Josh Davidson

________________________________

From: Sean McLeod <se...@se...<mailto:se...@se...>>
Sent: Sunday, April 5, 2026 16:45
To: FlightGear developers discussions <fli...@li...<mailto:fli...@li...>>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal



Hi Josh



“There could also be an option like holding shift will halt it at any deflection maximum until you release the key.”



Yep, that would be an option for someone who wants to hold a specific deflection. Typically a specific deflection of aileron will result in a some steady-state roll rate (pss) once the roll damping moment equals the aileron roll moment.



So if I wanted to say for example achieve a roll attitude of 30 deg I could put in some fixed amount of aileron deflection, which say after a short while gets me to a steady state roll rate (pss) of say 10deg/s. Given the steady state roll rate, as opposed to an ever increasing roll rate I can then more easily judge when to center/slightly over center and back to stop at 30 deg.



See https://seanmcleod70.github.io/FlightDynamicsCalcs/A4SkyhawkRollPerformance.html for an example of the roll rate buildup to a steady state roll rate (pss) etc. for a given aileron deflection for a given airspeed, altitude etc. Once the you get close to pss then the roll angle vs time is linear.



Cheers



From: Josh Davidson <jos...@ou...<mailto:jos...@ou...>>
Sent: Sunday, April 5, 2026 10:59 PM
To: FlightGear developers discussions <fli...@li...<mailto:fli...@li...>>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal



Hi,



Usually this is not done unless you're testing specific things. You normally want to get to the attitude at a small, but not too small roll rate. The way it would work is that it would move initially out and then start moving very slowly so you would have to hold it long to get more deflection and at that point the higher roll rate is probably desired. Typically the higher you want to change the attitude the higher you want the roll rate to go until a certain limit.



I could absolutely have a configurable option to change the coefficient of speed. It would not be a linear curve though.



With some tuning I think it could result in some nice results. Because you don't want it to snap to the end of the input unless the person really wants it to. There could also be an option like holding shift will halt it at any deflection maximum until you release the key.



These are all options I'd have to play with to see what finds the best combination and what can be exposed to the user for tweaking.



Of course in any situation where you want to move the yoke a pre-specified amount, You would use the old system, But when flying a real plane we don't really look at that we don't really know or care how much we're moving the yoke we care more how the airplane responds.



There could also be something exposed to aircraft to modify what the maximum deflection amount when it approximately switches from high to low speed is.



That way if anyone has a super touchy flight model or a super laggy flight model the response could be tuned by the aircraft developer. Or by the user via configuration options in input.



I guess let me get the tech demo together first and then we can explore what possible configure options might be needed.



Perhaps through the process of making the demo I will understand more what may or may not be required and perhaps it will also demonstrate the way that I believe would be good to work.



Kind Regards,

Josh



--

Josh Davidson

________________________________

From: James Turner <ja...@fl...<mailto:ja...@fl...>>
Sent: Sunday, April 5, 2026 3:42:21 PM
To: FlightGear developers discussions <fli...@li...<mailto:fli...@li...>>
Subject: Re: [Flightgear-devel] Alternate Keyboard Flight Control proposal







On 5 Apr 2026, at 20:20, Josh Davidson <jos...@ou...<mailto:jos...@ou...>> wrote:



OK, I'll mock it up. Won't have any UI. Just a "tech demo" if you will.



Isn't that just Wayland? I heard of that issue with KiCad which I use for EE work. Windows and MacOS have no such issue, nor does X11 on Linux. I think there's a way to force it to move on Wayland, I'll see if I can find more info, and I'll make a separate thread with my suggestions for mouse yoke.





macOS also complains (you have to request ‘accessibility access’ or something, from memory). But it does work.



And yes a tech demo would be ideal.



Kind regards,

James

Hello again! I've been looking at some FlightGear docs for some work I've been doing, and I've recently discovered FlightGear's capability to output sim data over UDP at rather high frequencies. The flight recorder we have in sim currently does the job, but it can look blocky during replays, the number of custom properties that can be recorded is limited, and (I think?) it's running on the sim's resources. Is it viable/a good idea to have an external tool record flight properties at a certain rate, and allow FlightGear to play those back? Please let me know what you think.

On 4/14/26 10:33 AM, wki...@gm... wrote:
> i note an old_ws3 directory now... looks like its time stamp is a few minutes 
> after my digging got fully started LOL ok, i'll take another run and see what 
> shakes out...

alright... the new run looks better... the .dirindex files /appear/ to be fine 
and not referencing stuff that should not exist... more detailed "analysis" to 
be done on them to be sure...

however, there's still some "sludge" floating about in the ws3 tree... i've 
attached (~20.5K) my list of urls of directories that exist that should not... 
also note that the last directory in the list, 
vpb/w050s20/ws_w041s19_root_L0_X0_Y0, contains about 375M of *.osgb and *.png 
files that appear to have been extracted or created and left behind for some 
reason...

Hi Pat,

Thanks for looking into this.  Some answers inline.

On Thu, Apr 16, 2026 at 6:28 AM Patrick Callahan wrote:

> After doing a bit of reading about how ws3.0 works and looking at the
> airports.dat.gz data, I'm surprised that the BIKF airport still shows at
> zero elevation.   Any apt.dat.ws3 I've looked at shows the data at 164 or
> 170 ft, yet the airport surface is still being rendered at elevation zero.
>

I haven't looked at the genapts code, but I think that it may use SRTM data
to generate a surface elevation for the airport so that sloping runways are
supported.  So even if the apt.dat file has some elevation data, it may not
be used.  You should confirm that though by looking at genapts.


> The observable berm-like structures appear at three locations at the airport
> 2 going north to south and one going east to west. Great for flood
> protection, but not so good for landing and taking off.  What are those
> things?  Are they the skirts on tiles?
>

Yes, they are the skirts on tiles.  There is runtime code to ensure the
WS3.0 elevation mesh is adjusted to be underneath any airports.  However,
this isn't affecting the skirts of the tiles.  That's a bug I need to fix.


> If you follow the south going berms further than the airport, you can see
> the top line continued due south between scenery on one side or the
> other.
>

That's a texture discontinuity across the tile boundary caused by the UV
coordinates.


> Question:  Are airports "draped over scenery elevations during runtime?
>
>
>
>

No.  Quite the opposite:  The scenery elevations are forced underneath the
airports.

-Stuart

> On 16 Apr 2026, at 19:30, bo23--- via Flightgear-devel <fli...@li...> wrote:
> 
> On 2026-04-16 18:20 +0200, Florent Rougon via Flightgear-devel wrote:
>> I think James meant that with the patch from [1], SG wouldn't build for
>> people whose c-ares is older than commit 6475221a42739[2]. You can try
>> the patch from [3], which is attached. It should work on “all” versions.
> 
> I see, thank you for the clarification, Florent.

Correct, this is what I was trying to explain!

Kind regards,
James

On 2026-04-16 18:20 +0200, Florent Rougon via Flightgear-devel wrote:
> I think James meant that with the patch from [1], SG wouldn't build for
> people whose c-ares is older than commit 6475221a42739[2]. You can try
> the patch from [3], which is attached. It should work on “all” versions.

I see, thank you for the clarification, Florent.

Hi,

Le 16/04/2026, bo23--- via Flightgear-devel <fli...@li...> a écrit:

> Or use the patch by Mariusz / PlayeRom, but you said it isn't backwards
> compatible. I wonder why, but don't waste time on explaining it when you
> have more important things to do.

I think James meant that with the patch from [1], SG wouldn't build for
people whose c-ares is older than commit 6475221a42739[2]. You can try
the patch from [3], which is attached. It should work on “all” versions.

Regards

[1] https://gitlab.com/flightgear/simgear/-/work_items/45
[2] https://github.com/c-ares/c-ares/commit/6475221a427394b6d2a3d3cb0b0abe189681ddd4
[3] https://gitlab.com/flightgear/simgear/-/merge_requests/284

-- 
Florent

On 2026-04-16 16:10 +0100, James Turner wrote:
> Some figuring out here, how to make D&C play nicely. You can follow along on the ticket, but otherwise if you use D&C, you can temporarily  roll back C-Ares to tag 1.34.6  (which is SHA 3ac47ee46edd8ea40370222f91613fc16c434853 )

Or use the patch by Mariusz / PlayeRom, but you said it isn't backwards
compatible. I wonder why, but don't waste time on explaining it when you
have more important things to do.

As always, I'm very thankful for all your work, all of you.

On 2026-04-16 16:30 +0100, Stuart Buchanan wrote:
> See https://docs.gitlab.com/security/identity_verification/.

So I am a high-risk untrusted user... I kind of like that ;-)

On 2026-04-16 15:03 +0000, Israel Emmanuel wrote:
> What region are you in?

European Union

Hi Folks,

On Thu, Apr 16, 2026 at 4:28 PM bo23--- via Flightgear-devel <
fli...@li...> wrote:

> On 2026-04-16 16:08 +0100, James Turner wrote:
> > I did select ‘join an existing organisation’, maybe that’s significant?
>
> This step didn't show up on my side. I guess, I will wait three days
> until the registration is cancelled, and then try again, in about three
> months or so... I might record my screen on the next attempt.


See https://docs.gitlab.com/security/identity_verification/.

-Stuart