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 :