Board index FlightGear Development

Development Help

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

Development Help

Postby robbo » Thu Sep 15, 2011 9:47 pm

Hi,

I am looking at using Flightgear for a project of mine and was wondering if there is any information as to the format of the network messages used by multiplay to impose aircraft on an instance of flightgear.

Essentially I would like to build a 'fake' server that 'generates' fake aircraft on a single instance of Flightgear, and then controls these aircrafts on predetermined tracks (as controlled by my server). In order to do this, I need to find information on the network messages required by multiplay to accomplish this.

I have read much of the documentation and have established how to control the single aircraft that is held within the instance of Flightgear (by using the /Protocols-input/output), but I am unsure how to actually create multiple instances of aircrafts and then control them without creating many physical instances of Flightgear that are all interconnected.

I guess eventually i will have to sniff the traffic and try and work it out, but i thought that i would give this forum a try to see if anyone can point me in the right direction.

Many thanks for any assistance

Robbo
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Fri Sep 16, 2011 1:10 am

Hi & welcome !

Note that this is a development related question, and as such it is usually better handled using the FG developers mailing list: http://www.flightgear.org/mail.html

The FlightGear multiplayer server is hosted at: http://fgms.sourceforge.net
The latest source code can be inspected and downloaded here: http://gitorious.org/fgms

Also have a look at: http://gitorious.org/fgms/fgms-0-x/blob ... rver/FILES

(You may want to consider forking/branching the fgms repository for your project)

The setup procedures are documented here: http://wiki.flightgear.org/Howto:_Set_u ... yer_server

More comprehensive build instructions can be found here: http://geoffair.net/fg/fgms.htm

The server operation modes are covered here: http://fgms.sourceforge.net/serverops.php

The FlightGear MP system and its protocol are fairly simple at the moment: FlightGear uses XDR encoded messages that are sent via UDP:

http://en.wikipedia.org/wiki/External_D ... esentation
http://en.wikipedia.org/wiki/User_Datagram_Protocol

The underlying protocol itself is documented here: http://wiki.flightgear.org/Multiplayer_protocol

The FlightGear-specific source code for the multiplayer system is largely contained in $FG_SRC/Multiplayer: http://gitorious.org/fg/flightgear/tree ... ultiPlayer

The routines for handling XDR are contained in $FG_SRC/Multiplayer/tiny_xdr.[h|c]xx: http://gitorious.org/fg/flightgear/blob ... ny_xdr.cxx

The protocol itself just keeps pushing out properties and their new values in XDR-encoded form.
The properties are not sent as ASCII strings but rather using hard-coded property identifiers.

You can view the mapping for all properties/identifiers in $FG_SRC/MultiPlayer/multiplaymgr.cxx (check line 68): http://gitorious.org/fg/flightgear/blob ... laymgr.cxx

This file also contains a fair number of source code comments.

The different message types supported by the MP protocol are specified in $FG_SRC/MultiPlayer/mpmessages.hxx: http://gitorious.org/fg/flightgear/blob ... ssages.hxx

The structure/format of the messages is also "documented" there (i.e. plain structures are put on the wire).

The multiplayer subsystem (FGMultiplayMgr) in FG is derived from the SimGear class "SGSubsystem": http://simgear.sourceforge.net/doxygen/ ... ystem.html

You can see its full interface in multiplaymgr.hxx: http://gitorious.org/fg/flightgear/blob ... laymgr.hxx

Internally, the multiplayer subsystem makes use of the socket wrappers provided by SimGear:

http://simgear.sourceforge.net/doxygen/ ... ocket.html
http://simgear.sourceforge.net/doxygen/ ... etUDP.html

It's worth noting that the doxygen docs have not been updated in quite a while obviously - so this is just for reference, you are well advised to check out the latest source code from git and possibly even create your own source code docs using doxygen: http://www.stack.nl/~dimitri/doxygen/

Also note, that there are actually MANY suggestions and ideas related to improving the current system and architecture:
http://fgms.sourceforge.net/protocol.php
http://wiki.flightgear.org/Distributed_ ... Simulation

There's also some ongoing related work to improve the existing MP system: http://gitorious.org/~zakalawe/fg/james ... cs/mpdelta

You may also find some inspiring ideas by searching our "Interfacing" sub forum: viewforum.php?f=36

I have posted a number of suggestions related to project like your's.

In addition, it is probably worth pointing out that the ongoing DIS/HLA-related efforts are likely to eventually
deprecate the existing system: http://virtualair.sourceforge.net/flightgear.html

You may want to search the FG devel mailing list for details: http://sourceforge.net/search/index.php ... la&ml_name[]=flightgear-devel&posted_date_start=&posted_date_end=&form_submit=Search

Finally, when you actually do take a look at the wiki, the fgms tracker or the devel mailing list archives, you'll see that what you want to do is not really new - there have been many other people doing fairly similar things.

In fact, there are now plans to generalize the built-in AI traffic system so that it instantiates traffic via the MP protocol, that way you could create arbitrary traffic: viewtopic.php?f=23&t=6807&p=60580#p60580

You can find another page in the wiki summarizing postings from the FG core developers list here: http://wiki.flightgear.org/Decoupling_t ... fic_System

As you'll see - both, the primary developer of the FG MP server, and the primary developer of the AI traffic system agreed that this would be the way to go.

So if you are interested in this, it might be a good idea to talk to them on how to proceed - that would probably be the safest way to ensure that your project will also be able to work together with upcoming versions of FG.

If you think that our documentation is lacking, we would obviously appreciate it if you could get involved - for example by starting a new wiki page.

I would not mind answering any additional questions you may have, if you don't mind turning your findings into better documentation for our wiki (you could start by copying my pointers to the wiki) ;-)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Fri Sep 16, 2011 7:36 pm

Many thanks for your reply Hooray, your post was much more than I expected!

I think it may take me some time to read and digest the information that you have given me. There appear to be some good links to relevant information within your post which I am sure other readers would benefit from and I am more than happy to repost within your Wiki. I would, however, prefer to absorb the information and perhaps produce some test code that I can use to reference within your Wiki.

Do I take it from your encouragement in having me participate, that you are struggling for assistance within this project in various areas?

Robbo
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Fri Sep 16, 2011 8:11 pm

Do I take it from your encouragement in having me participate, that you are struggling for assistance within this project in various areas?


Well, yes and no: I am myself not really involved in the fgms project, It's just that the multiplayer part of FlightGear (including fgms) simply hasn't been under very active development for quite a while now, this can be seen in many places (forum, mailing lists, bug tracker, wiki).
For example, just check http://fgms.sourceforge.net/contribute.php

Contribute?
The fgms project is quite open to all contributions, large and small. Whether you're a coder, docs writer, tester or <insert role here>, I am sure you will help out in a useful way.

This page documents a bit of how I work internally on the project, so that you can better fit in and help out if you want.
One man show
The development of fgms is in large parts a one man show. Since there is a whole lot of work to do, I appriciate all help I can get. Here I try to document some of the work on my todo list which you might be interrested in (in no particular order).


This was written by the main developer behind fgms, "Oliver Schroder": http://www.o-schroeder.de/

So obviously any help is appreciated. Also, he is probably the best person to get in touch with regarding contributing.

Getting started by contributing to the wiki would surely be a good idea.

Besides, your project could probably be implemented as a part of fgms, or at least by interfacing to fgms using a conventional socket connection:

fgms provides support for so called "relays", these are basically fgms instances that a server can connect to in order to relay/mirror traffic onto other servers. This doesn't require ANY modifications to the existing code.

In addition, fgms has already built-in support for an "admin interface", so that you can connect to the server on a "maintenance port" (for server admins). This feature could basically become the foundation for any related features, such as for example also a "traffic injection API".
Last edited by Hooray on Sat Sep 17, 2011 3:10 am, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby Hooray » Sat Sep 17, 2011 12:21 am

robbo wrote in Thu Sep 15, 2011 9:47 pm:Essentially I would like to build a 'fake' server that 'generates' fake aircraft on a single instance of Flightgear, and then controls these aircrafts on predetermined tracks (as controlled by my server). In order to do this, I need to find information on the network messages required by multiplay to accomplish this.


You didn't yet mention fgms, so I don't know if you are aware of it, but the fgms source tree also contains a "contrib" folder, this contains a handful of contributions and sample source code: http://gitorious.org/fgms/fgms-1-x/trees/master/contrib

Among others, you can also find a folder named "mpdummy": http://gitorious.org/fgms/fgms-1-x/blob ... ib/mpdummy

This contains source code for a "dummy client" process that connects to the fgms server, so if you connect FG instances to the same MP server, you would get to see this "dummy traffic".

That would seem to be pretty relevant to your effort, I guess ...

The thing is however that it really is just that, a "dummy" - in its current form it isn't very full featured at all. However, it does handle all the "dirty" connection and communications issues. On the other hand, the C++ source code isn't necessarily very straightforward, certainly not if you are not already familiar with C++ socket programming.

( Internally, the socket support provided by SimGear and used by fgms is implemented on top of plib's cross-platform "net" library: http://plib.sourceforge.net/net/index.html )

You may want to have a look for yourself: http://gitorious.org/fgms/fgms-1-x/blob ... pdummy.cxx

So you could certainly play around with this code and see if you can make it do more interesting stuff, it's certainly possible.
However, keep in mind that you'd then be creating a *client* that connects to a conventional fgms instance.

So if you'd like to create more than just a single traffic node, you'd then also run several clients. Overall, that seems to be a good solution, certainly easier than creating a completely new server. And it would have the added advantage of being trivially parallelizable (i.e. just by running more processes).

Obviously, instantiating and controlling several aircraft from C++ can be somewhat tedious and inflexible in the long run. It certainly is if you don't provide and use lots of configuration options, like it is done in FG by using the property tree and registering "listeners".

However, you should be able to borrow plenty of C++ source code from FlightGear, the AI traffic system which is entirely implemented in C++ and fairly flexible due to the aforementioned listeners.

These "listeners" are based on the C++ class SGPropertyChangeListener and can be registered to be automatically invoked once a property is accessed/changed - in FG this is also used to implement a fairly flexible signal/events system.

Systems like the AI traffic system use this method to allow dynamic instantiation of traffic just by writing to a bunch of properties, which can be done manually (i.e. by using the built in property tree browser), by using XML "scenario files" or by using scripted flights, implemented in Nasal.

Besides, if you are looking for a less tedious way of creating and controlling traffic, my personal suggestion would be to look into adding a scripting interpreter to the "traffic injector":
No matter if you fancy hacking fgms or if you'd like to extend the mpdummy example, having an embedded scripting interpreter for controlling traffic would be much easier than creating all scenarios in C++ source code.

The SimGear library, which FG and fgms already link to, contains all the code necessary to embed the Nasal scripting interpreter in new programs. So you could just as well add a Nasal scripting component to the existing C++ source. That is fairly easy to do, I have done that myself a while ago, and I wouldn't mind providing the required help to get you started.

In addition, aircraft could be easily controlled just by using the setprop/getprop commands if all aircraft instances use the SimGear PropertyTree as the internal data structure.

Finally, keep in mind that fgms has (at least to my knowledge) not yet been ported to Windows, so it may be somewhat more complicated to get started on non *nix systems, because that would require some porting work in the first place. Under Windows you could obviously use a shell session to connect a Linux box or Cygwin though.

It is also possible to create virtual Linux system by using coLinux and developing with a "remote IDE" such as eclipse or BVRDE, both of which provide support for doing client-side source code editing and server-side building, debugging and profiling by using a SSH connection.

I am quoting a message I have exchanged with some other people interested in contributing to FG, who are Windows users:

you could also look for a linux server to do your development there.

There are a number of freely available "development servers" available for open source projects. For example the gcc project provides this list: http://gcc.gnu.org/wiki/CompileFarm

Most of these servers have between 8-32 gb of RAM, so they are really well suited for memory heavy stuff. You can also use distcc, ccache, valgrind, gprof etc like this.

Also, there are plenty of different architectures available - which is very useful for testing and cross-platform development.

These compile servers are available to all open source projects and developers, it's just a matter of sending an eMail and getting an SSH account approved.

You would only need to open a connection to one of the server's and could then run all your builds, debugging etc there.

If you are familiar with Linux (i.e. working via a shell), then that's an excellent option:
The GCC Compile farm project maintains a set of machines of various architectures and provides ssh access to free software developers, GCC and others (GPL, BSD, MIT, ...). Once your account application (see below) is approved, you get full ssh access to all the farm machines (current and new), architectures currently available:

* i686
* x86_64
* armv5tel
* armv7l (with vfp and neon FPU instructions)
* powerpc
* powerpc64
* Cell SPE (Sony Playstation 3)
* sparc
* sparc64 (sparcv9)
* alpha (currently offline)
* mipsel
* mips64el
* ia64
* hppa
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Sat Sep 17, 2011 1:36 pm

Hooray,

You are obviously brimming with fgfs/ms information, I just wish I could plug a usb cable into your head and download it lol!

Once again, I thank you for the information you have provided, although, I think that I am now in information overload. I think at this point, since you are being so helpful, I dare ask you for your specific advice, given some more information about me.

I am a software developer by trade. Although my main language is Java, I am familiar with pure C and am sure that C++ would not be too far of a leap. I primarily work on a *nix environment and rarely use M$!

My high level solution is to run several fgfs clients on a network that are interconnected via fgms. I would like to then do several things as follows:
1) create some new bespoke 'aircraft' models
2) extend the property tree to allow some 'custom' information to flow between the clients (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.
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.

With this information and your vast knowledge of the overall application, 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!

Thanks again

Robbo
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Sat Sep 17, 2011 4:38 pm

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.cxx

So, 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_System

2) 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.html
http://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.nas
Look 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 :lol:
  • 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
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Sun Sep 18, 2011 3:36 pm

Hooray,

Thanks once again for the advice. I have taken your advice and began to do some investigatory work. I downloaded the version1 fgmp and attempted to compile it (I had errors in simgear/degug/logstream.hxx relating to eof and in logstream.cxx relating to a sprintf command), anyway, i made some slight modifications and was able to compile (figured that debugging not important right now!). Then I compiled the fgms and mpdummy binaries.

I am able to run the mpdummy binary with my configured xml file, but i do not see any aircraft appearing on my fgfs client that is connected to the same server. I was wondering if you would look at my xml file and let me know if you see any issues with how it is configured?

Code: Select all
<?xml version="1.0"?>
<!--
************************************************************************
JSBSim Cessna 172P with 3D cockpit.

Started October 23 2001 by John Check, fgpanels@rockfish.net
************************************************************************
-->

<PropertyList>
  <multiplayer>
    <server>
      <name>mpserver05.flightgear.org</name>
      <port>5000</port>
    </server>

    <system>
      <!-- the protocol version we use -->
      <protoversion>
        <major>2</major>
        <minor>0</minor>
      </protoversion>
      <!-- resend reliable UDP packets after 5 seconds -->
      <resend_time>5</resend_time>
      <!-- maximum retries to resend reliable UDP packets -->
      <max_retries>3</max_retries>
      <!-- time to keep client information in list
           without updates in seconds -->
      <player_ttl>10</player_ttl>
      <!-- only forward data to clients which are really
           nearby the sender. distance in nautical miles -->
      <out_of_reach>100</out_of_reach>
    </system>

    <myself>
      <callsign type="string">robbo1</callsign>
      <password type="string">robbo1</password>
      <clienttype type="int">1</clienttype>
      <radarrange type="int">40</radarrange>
      <port>5000</port>
      <protospec>../../mp-proto-spec.xml</protospec>
      <CLIENT-ID type="int">0</CLIENT-ID>
    </myself>

  </multiplayer>

  <sim>
    <description>Cessna 172P Skyhawk (1981 model)</description>
    <author>Oliver Schroeder</author>
    <status>testing</status>
    <flight-model archive="y">jsb</flight-model>
    <aero archive="y">c172p</aero>
    <model>
      <path type="string" archive="y">Aircraft/c172p/Models/c172p.xml</path>
    </model>
    <position>
      <X type="double">53.2987226</X>
      <Y type="double">-0.564247251</Y>
      <Z type="double">4.401637107</Z>
    </position>
    <orientation>
      <X type="double">-2.053077</X>
      <Y type="double">-1.094549</Y>
      <Z type="double">-1.121333</Z>
    </orientation>
  </sim>

</PropertyList>


thanks,

Robbo
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Sun Sep 18, 2011 3:42 pm

I didn't yet take a look at your XML file, I suggest to simply use the default files for starters.

Besides, which version of fgms did you download/compile?

Keep in mind that there is a DEVELOPMENT version and the STABLE version listed at gitorious.
This also just occurred to me: I happened to reference the DEVELOPMENT repository all the time, but I think you should first of all try to get the STABLE version to work for you.

Also, with regards to not seeing any traffic, did you configure fgms properly?
Or rather, are you sure that it is working as is?
You could obviously just start two fgfs instances connecting to the same local fgms server and see if the traffic from both fgfs instances is properly transmitted.

Only once that it is working, i.e. once you know for sure that your fgms setup is working, I'd look into getting to work mpdummy and possibly custom XML files.

HTH
Last edited by Hooray on Sun Sep 18, 2011 3:50 pm, edited 1 time in total.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Sun Sep 18, 2011 3:49 pm

Hi,

Yes i used the development version, which is suspect is why there where compilation issues. I also thought that may be the reason for it not working so i checked out the stable version. When I looked at the stable version, there is no mpdummy so I began to wonder if it would work.

I went with the development version, but I am NOT running fgms. Instead i have configured the mpdummy binary to talk to one of the public servers (all other details in xml file are the same as the default). Is it the case that this will not connect to a public server?

My fgfs client is also connected to the same public server!

thanks
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Sun Sep 18, 2011 3:57 pm

Yes, I guess that should also work.

Okay, I am now in the process of testing this myself, BTW: I just noticed that you now need to specify --with-mpdummy when running the configure script - so that mpdummy gets build.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Sun Sep 18, 2011 4:02 pm

lol, yes i spotted that too!!

I chose a quiet location near to my home town, if you choose those coordinates also, i may be able to see any traffic that you generate!

Robbo

PS sorry to be taking time out of your day, but i really appreciate your assistance in getting me started!
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Re: Development Help

Postby Hooray » Sun Sep 18, 2011 4:14 pm

robbo wrote in Sun Sep 18, 2011 3:49 pm:Hi,

Yes i used the development version, which is suspect is why there where compilation issues. I also thought that may be the reason for it not working so i checked out the stable version.


Those EOF errors you mentioned are not critical, they are just a minor issue related to missing header files, you can apply the following patch and things should work as is:

Code: Select all
diff --git a/src/simgear/debug/logstream.hxx b/src/simgear/debug/logstream.hxx
index b19c603..17c0caf 100644
--- a/src/simgear/debug/logstream.hxx
+++ b/src/simgear/debug/logstream.hxx
@@ -34,9 +34,11 @@
 #ifdef SG_HAVE_STD_INCLUDES
 # include <streambuf>
 # include <iostream>
+# include <cstdio>
 #else
 # include <iostream.h>
 # include <simgear/sg_traits.hxx>
+# include <stdio.h>
 #endif
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby Hooray » Sun Sep 18, 2011 4:30 pm

When going to http://mpmap01.flightgear.org/ I can see your aircraft at the position specified in your XML file.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11317
Joined: Tue Mar 25, 2008 8:40 am

Re: Development Help

Postby robbo » Sun Sep 18, 2011 4:32 pm

Yes, that is my normal fgfs client, the test one should be robbo1
My output is as follows:

Code: Select all
fgms-fgms-1-x/contrib/mpdummy$ ./mpdummy mpdummy.xml
# This is robbo1 version 1.0.0-pre-alpha1
# using protocol version v2.0
# listening to port 5005 and sending to mpserver05.flightgear.org:5000
OneTime ID: 1200001
ID: 1200001 Path: '/multiplayer/myself/callsign' => Type 12
OneTime ID: 1200002
ID: 1200002 Path: '/multiplayer/myself/password' => Type 12
OneTime ID: 1200003
ID: 1200003 Path: '/sim/model/path' => Type 12
OneTime ID: 600002
ID: 600002 Path: '/multiplayer/myself/radarrange' => Type 6
ID: 1 Path: '/multiplayer/myself/CLIENT-ID' => Type 0
Unsupported property-type!
Unsupported property-type!
ID: 600001 Path: '/multiplayer/myself/clienttype' => Type 6
ID: 900003 Path: '/sim/position/X' => Type 9
ID: 900004 Path: '/sim/position/Y' => Type 9
ID: 900005 Path: '/sim/position/Z' => Type 9
ID: 900006 Path: '/sim/orientation/X' => Type 9
ID: 900007 Path: '/sim/orientation/Y' => Type 9
ID: 900008 Path: '/sim/orientation/Z' => Type 9
sending authentication...
OneTime ID: 1200001
ID: 1200001 Path: '/multiplayer/myself/callsign' => Type 12
OneTime ID: 1200002
ID: 1200002 Path: '/multiplayer/myself/password' => Type 12
OneTime ID: 1200003
ID: 1200003 Path: '/sim/model/path' => Type 12
OneTime ID: 600002
ID: 600002 Path: '/multiplayer/myself/radarrange' => Type 6
ID: 1 Path: '/multiplayer/myself/CLIENT-ID' => Type 0
Unsupported property-type!
Unsupported property-type!
ID: 600001 Path: '/multiplayer/myself/clienttype' => Type 6
ID: 900003 Path: '/sim/position/X' => Type 9
ID: 900004 Path: '/sim/position/Y' => Type 9
ID: 900005 Path: '/sim/position/Z' => Type 9
ID: 900006 Path: '/sim/orientation/X' => Type 9
ID: 900007 Path: '/sim/orientation/Y' => Type 9
ID: 900008 Path: '/sim/orientation/Z' => Type 9
OneTime ID: 1200001
ID: 1200001 Path: '/multiplayer/myself/callsign' => Type 12
OneTime ID: 1200002
ID: 1200002 Path: '/multiplayer/myself/password' => Type 12
OneTime ID: 1200003
ID: 1200003 Path: '/sim/model/path' => Type 12
OneTime ID: 600002
ID: 600002 Path: '/multiplayer/myself/radarrange' => Type 6
ID: 1 Path: '/multiplayer/myself/CLIENT-ID' => Type 0
Unsupported property-type!
Unsupported property-type!
ID: 600001 Path: '/multiplayer/myself/clienttype' => Type 6
ID: 900003 Path: '/sim/position/X' => Type 9
ID: 900004 Path: '/sim/position/Y' => Type 9
ID: 900005 Path: '/sim/position/Z' => Type 9
ID: 900006 Path: '/sim/orientation/X' => Type 9
ID: 900007 Path: '/sim/orientation/Y' => Type 9
ID: 900008 Path: '/sim/orientation/Z' => Type 9
OneTime ID: 1200001
ID: 1200001 Path: '/multiplayer/myself/callsign' => Type 12
OneTime ID: 1200002
ID: 1200002 Path: '/multiplayer/myself/password' => Type 12
OneTime ID: 1200003
ID: 1200003 Path: '/sim/model/path' => Type 12
OneTime ID: 600002
ID: 600002 Path: '/multiplayer/myself/radarrange' => Type 6
ID: 1 Path: '/multiplayer/myself/CLIENT-ID' => Type 0
Unsupported property-type!
Unsupported property-type!
ID: 600001 Path: '/multiplayer/myself/clienttype' => Type 6
ID: 900003 Path: '/sim/position/X' => Type 9
ID: 900004 Path: '/sim/position/Y' => Type 9
ID: 900005 Path: '/sim/position/Z' => Type 9
ID: 900006 Path: '/sim/orientation/X' => Type 9
ID: 900007 Path: '/sim/orientation/Y' => Type 9
ID: 900008 Path: '/sim/orientation/Z' => Type 9
robbo
 
Posts: 19
Joined: Thu Sep 15, 2011 9:38 pm

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 22 guests