At the moment, there are about 3 different approaches to implement a "copilot" module for FlightGear - all of them being developed separately, as standalone programs talking to FG using socket connections.
While that is good from a design point of view, I think it is somewhat unfortunate because the people who work separately creating 3 different copilot solutions, could certainly work together and create a single one.
The real issue is that FG being cross platform software, it is generally understood to be a good idea that contributions to FG can also be used by all FG users, regardless of their platform/OS.
I haven't taken a look at FGCopilot yet, but that is also because I am on Linux and I assume that I cannot easily run your code?
redneck's project is more promising in this aspect because it is built using Java, which is multi-platform in general.
Also, redneck's project is reusing code that has been developed by FG core developers - so it is more efficient from a certain angle.
So, personally I would suggest to look into working together with redneck to improve his project - there are obviously many things that could be implemented here. And redneck got a head start already. If you already know Delphi, understanding and writing Java should be straightforward actually. So if you have any ideas or feature requests, I am sure that redneck's project would be a solid foundation actually.
Honestly, I don't think we even need to keep this separate from FG - anybody doing projects like these will inevitably need to deal with the FG property tree, which is usually done using a socket connection. This is more complicated than it needs to be. If you already know a programming language, learning Nasal is actually EASY - and Nasal has native support for dealing with the FG property tree and its API.
Bottom line being, 99% of the work you are doing could be done more easily by switching to Nasal instead. This would also have the added advantage of Nasal code being automatically cross-platform, too. Once people switch to using Nasal, they also ensure that ALL FG users can easily make use of their contributions.
Obviously, there are some things that are easy in a separate language/toolkit, which are more complicated or next to impossible from Nasal space, but usually that would only require modifying or adding 2-3 new Nasal extension functions, which would also be useful for all other Nasal scripts.
Seriously, even redneck mentioned a while ago that Nasal should be seriously considered here, especially because the telnet/props route has been shown to become too slow pretty soon:
viewtopic.php?f=6&t=13435&p=136211&hilit=#p136205redneck wrote:It might be a little... slow
Nasal seems to have all the same functions from my brief glance over some code, so, I suppose I could learn. I've also wanted to have some way to automate holding patterns as well.
Bottom line being, I am absolutely convinced that these autopilot/copilot tools are a great idea for FG, but I also believe anybody not coding this directly IN FlightGear by using Nasal, is making it more complicated than necessary. So, I will try to support anybody who is actually looking into porting this over to "native FlightGear space" by reimplemting such efforts in Nasal space instead - adding a bunch of extension functions to enrich the API is easy and well documented actually. Anybody knowing C++ (or Java for that matter), should be able to understand what's involved:
http://wiki.flightgear.org/Howto:Extending_NasalFinally, it is usually a good idea to add announcements to the FlightGear newsletter (created and maintained using the wiki)- you can even create a new wiki article introducing your project, and linking to it from the newsletter. Let us know if you need any help contributing to the newsletter:
http://wiki.flightgear.org/Next_newsletter