James wrote :
> Making the current fgcom code work as a thread inside fgfs isn't especially hard, I am happy to offer advice on it, and keeping this an #ifdef / CMake flag so it can be a standalone process is also pretty easy.

My current topics/fgcom branch already include a CMake flag (-D ENABLE_FGCOM) at OFF by default.
I think a simple --enable-fgcom will be efficient . I don't know how to make a cross platform process for now. Can you confirm me that you are ready to accept a similar solution as QProcess in Qt ? In this way FGCom will lives in a separate PID, the problem being : what happens to this separate PID if FG has a crash ? He will become a ghost and make the network port busy, right ?

What about implementing an SGProcess ?

Eric wrote :
> So if you are changing stuff to FGCOM /FG, maybe you can consider
> supporting 8.33kHz spacing?

FG/FGCom are ready for 8.33KHz spacing. It require a little change on Asterisk side (118.305 = 118.300, 118.330 = 118.325, 118.355 = 118.350 118.380 = 118.375) but the main problem is that X-Plane data are not yet ready for 8.33KHz spacing. Here is some examples :

ICAO :: apt.dat => possible frequency

EDFA :: 12103 => 121.030 ? 121.035 ?
EDCQ :: 12338 => 123.380 ? 123.385 ?
EBAV :: 12343 => 123.430 ? 123.435 ?
KSPI :: 13141 => 131.410 ? 131.415 ?

That's why we need to wait the next APT format who support 8.33KHz spacing (i.e: add a new digit in the frequency field)