[Opengc-devel] Flightgear status(!) & request for help (resend)

[Damion S. <dam...@ho...>]

The original version of this message bounced, so I'm re-sending.
----------

> Is there any version of the prebuilt windows OpenGC.exe that will
> communicate with flightgear that I can get my hands on?

Actually, as it so happens I rewrote the FlightGear data source last night
using Plib and it works great. This was much simpler than I thought; since
Plib is cross platform, the FlightGear data source now works under both
Linux (see below) and Windows. I had to replace the FG packet header with
the one from the FlightGear 0.80 repository but other than that there
weren't any unexpected problems. So far I've tested the system with both
FlightGear and OpenGC running on Windows XP machines.

BUT... here's where the help request comes in. It looks like Windows and
Linux are handling object sizing differently. Under Windows,
sizeof(ogcFGData) = 696 while on Linux sizeof(ogcFGData) = 692. I'm not sure
where the extra 4 bytes are going. This makes things awkward since the comms
built into flightgear dump this data structure out as the network packet,
and the size differences are making it impossible to cast the memory block
as the correct pointer type when mixing different machines on a network.

Any people with cross-platform network experience have advice? As of now,
things work correctly when both the source and target machines use the same
OS (or at least I'm assuming the Linux side works - it compiles and receives
packets from my Windows machine correctly, but segfaults on the cast
operation - I don't have a second Linux machine to play with). It seems like
this might be a buffer offset issue; perhaps by lopping 4 bytes off of one
end of the buffer I can solve the problem.

Once this issue is ironed out, the only remaining piece of "disabled" code
is John W's FMC. Re-enabling FMC is a more involved process, since it
involves some fundamental changes to the DataSource base class; this why
I've started using macros in the code - in the future, they will define
"Set" functions for variables that can be written out over the network. I'm
a little up in the air about how this will be pulled off at this point. A
common engineering trick would be to define a Current state/Next state pair,
with the current state being read only and the next state being writable
(but a limited subset of the current state). If anyone has a particular
preference about how this should be organized, let me know.

A final note: if you download the updated CVS to acquire Flightgear support,
please be aware that I changed the opengc.ini keywork for the FlightGear
data source to "FlightGear" from "Flightgear" to agree with the
capitalization from the official web site. This interface should be
considered somewhat experimental until the packet size issues are resolved.
Instructions on how to start Flightgear with opengc support can be found in
the opengc.txt file in the CVS repository. The short version is to add the
following switch to the command line when starting flightgear:

--opengc=socket,out,24,xxx.xxx.xxx.xxx,5800,udp

replacing the x's with the target IP address. For example:

--opengc=socket,out,24,192.168.1.255,5800,udp

to broadcast to all machines on the 192.168.1 network.

Happy flying...
-Damion-