Frank,
Information on nearby multiplayer entities is provided in the property tree
so you can access this information at least within flightgear. You could
query this data via the property interface, or build some sort of nasal
script. You would need to add an extra "telnet/property" interface to your
external code to query this data, but it should be pretty doable.
Curt.
On 10/18/07, frank hadder <> wrote:
>
> I'm working on a UAV simulator using FlightGear. The goal is to make an
> autonomous UAV. We have written code that receives FDM input and sends the
> flight controls back to the FlightGear simulator ie. we have written a
> program to fly the plane. Now we want to add the data from the Multiplayer
> server to help make flight decisions (such as if we wanted an autonomous UAV
> to follow another plane). To do this, we need to have access to the data
> being sent from the multiplayer server to our local instance of FlightGear.
>
> The problem, at least as I see it, is that we cannot bind a socket to the
> port being used to send this information to our local FlightGear because it
> is already in use (by FlightGear). I'm searching for a solution to this
> problem. Listed below are possible ideas in order of preference:
>
> 1. Set some command line option in FlightGear to enable our program to
> have access to the FlightGear multiplayer information (namely the position
> of other aircraft). If there is such an option, I'm not aware of it.
>
> 2. Enable some kind of "port forwarding". If there is a way to do it, we
> could, at the OS level (linux), forward information coming in on a certain
> port to both the original port and a second port that my program can bind
> to. I'm not sure if this is possible. I know you can forward packets coming
> in on one port to another port but I assume the original port never receives
> the packet. I would need a kind of "copy" to be placed for access on a
> second port.
>
> 3. Change the FlightGear code to not only listen to the multiplayer port
> but to also forward those packets onto another port. This is perhaps the
> most straightforward option but I hesitate to introduce new code into as
> complex of a system as FlightGear.
>
> So, I ask the community, which of these options (or none of the above)
> seems like the easiest/possible solution? Thoughts? Are there any details I
> forgot to provide that you would need to know?
>
> Thanks,
> frank
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Flightgear-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
>
>
--
Curtis Olson: http://baron.flightgear.org/~curt/
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
