Sorry for the information overflow
If you want to get started ASAP while making some good headway, my suggestion would be to discard the fgms-based approach for the moment, and just concentrate on wrapping your head around the "mpdummy" example I mentioned previously.
This is, because it is much leaner a code base and much easier to grok completely. Your background in Java programming and your professional background should make that quite a feasible approach. In fact, C++ should be much more familiar to a Java programmer than C, especially "modern C++" which also makes use of reference count-based memory allocation by using SmartPointers, so while there is no Garbage Collection in C++, the code will look VERY MUCH like Java syntactically and semantically.
Again, I would suggest to simply have a look at the mpdummy source code and see if you can build it and run it, so that you can start playing around with the source code to see how it is working.
Like I said previously, the "mpdummy" is just to be considered an "example", as such it really isn't very comprehensive or even complete in the first place.
Ultimately, I guess it's also a matter of which code base seems to be more tangible to you in the first place?
Given the compact size of the module, you could check for yourself if you have problems understanding what it is doing:
http://gitorious.org/fgms/fgms-1-x/blob ... pdummy.cxxSo, obviously the plethora of other references and pointers I have given you, would certainly still become useful eventually in order to help fill in any "gaps" that you may encounter due to the restricted scope of the mpdummy module, so I wouldn't worry too much about the amount of information you've been given. I guess it's just a matter of being able to "filter" all the info and see what is applicable and useful right away, and what isn't
Personally, I would suggest to stick with the mpdummy source code for the time being because then you could reuse what's already there, i.e. you could start implementing the "interesting stuff" right away, without having to reverse engineer and document the whole protocol or the fgms server - after all, you are not really interested in creating a new server, but rather a configurable client that can feed in traffic to fgms, right?
My high level solution is to run several fgfs clients on a network that are interconnected via fgms
That sounds like a solid approach, and this is overlapping with the previously mentioned plans to eventually re-implement the existing AI traffic system on top of the Multiplayer protocol, so that AI traffic could eventually be instantiated and controlled by external processes, outside the fgfs core process:
http://wiki.flightgear.org/Decoupling_t ... fic_System2) extend the property tree to allow some 'custom' information to flow between the clients
Depending on the nature of the "custom information" you want to propagate, you may find that it isn't really required to literally extend the property tree itself, in FG it is usually sufficient to just expose new properties and exchange them using the MP protocol. Obviously, that would be different though if you want to expose new primitive types - but personally, I would suggest to refrain from doing so and just try to "marshal" your information into the "property tree encoded" form that is so widely supported by fgfs and its "ecosystem" already.
For instance, "custom information" can already be propagated by fgfs clients by the use of so called "generic properties", which can be used by aircraft to export and share aircraft-specific information with other clients. This doesn't require any modifications to the C++ side of things.
In addition, there's in a fact a fairly flexible and powerful implementation of "data channels" available implemented on top of these "generic properties" in the form of Nasal routines that handle encoding and decoding Nasal data into generic properties that can be sent over the existing MP protocol:
http://www.mail-archive.com/flightgear- ... 14123.htmlhttp://www.mail-archive.com/flightgear- ... 19618.html(To my knowledge, none of this is currently covered in the wiki)
The relevant Nasal routines are contained in $FG_ROOT/Nasal/wildfire.nas:
http://gitorious.org/fg/fgdata/blobs/ma ... ldfire.nasLook out for routines containing "channel" in their names.
In FlightGear this code is currently used for exchanging pretty much arbitrary information between clients, such as for example for the wildfire system (synchronizing events/state) or the bombable/dogfighting addon (propagating hits/impact).
(and handle this information within the clients possibly with NASAL). This is one solution, although the other would be to build my own seperate communication server to be controlled by NASAL if the property tree cannot be easily extended.
It can actually be fairly easily extended, but the real question is if there really is a need to do so - normally, that shouldn't be required. Also, keep in mind that the property tree is considered one of the most essential core components of FG, so anybody tampering with it, should be really sure that it is required ...
After having read what you want to do, my own estimation is that you don't need to modify the property tree at all.
3) build a 'client' that will Tx/Rx information and does some processing in between. The output of this client will be the creation of airborne models that are controlled directly by this client and visible to all the other clients on the network.
In a server-based approach, this could internally be implemented easily by dividing the network "input" and network "output" and keeping it in distinct places in a property tree, such as having a structure like this:
- Code: Select all
/input/client[0]/latitude-deg
/input/client[0]/latitude-deg
/input/client[0]/callsign
/output/client[0]/latitude-deg
/output/client[0]/latitude-deg
/output/client[0]/callsign
For instance, your networking code could implicitly write all received updates to the "internal" location and take all data that is to be sent from the "output" location. The advantage of this approach would be that you could trivially use a piece of Nasal code in order to modify the input and create a new output - this could or example be used to do interpolation or extrapolation.
Obviously, in a client-based approach (which I suggest to favor), you would only have one property tree per client and could directly use Nasal scripting for modifying properties (such as lat/lon, alt) and have them sent to the fgms instance automatically, basically your Nasal code would never be aware of the fact that it is doing network communications - it would just be "setting and getting variables" in/from the property tree.
Eventually, this would enable you to create fairly advanced traffic scenarios without touching any C++ at all.
what would be the 'least invasive' approach to take with these elements? I wish to try and only extend what is already available so that I do not fork away from the main fgfs project and am able to continue development against future releases!
Without trying to cause another information overflow, here's how I'd proceed:
- look at the mpdummy source code
- try to understand what it is doing by reading it
- check if you can build and run fgms locally, for development
- see if you can build and run mpdummy (will be built automatically, as part of fgms)
- see if it is working for you, i.e. by connecting it to a local fgms instance and then running fgfs (you should see your dummy traffic)
- check if you are able to make simple modifications in the mpdummy file (such as changing the position of the traffic) and rebuild/re-run mpdummy
- use a local property tree (SGPropertyNode), so that you can update and sent properties to fgms just by modifyig the property tree
- try to create a more complex scenario in C++ (e.g. permanently flying a holding pattern or circle)
- come to appreciate the fact that C++ is a poor language for programming such high level things
- copy the f_setprop/f_getprop helpers from FG so that these commands become available in your code
- look into embedding the Nasal scripting interpreter into the client, so that you can use scripts for controlling the traffic (plenty of code to borrow from FG)
- consider documenting what you are doing using the wiki
- consider using gitorious to do your development there, so that others can track it and help you more easily
- if you are getting stuck somewhere, refer back to this thread, the wiki and the mailing lists to get help