Ok, this is *way* better than what was there before!
Thanks so far!
What I have problems with is that, as long as you use a struct for the whole
message, the compiler is free to do alignment decisions different than your
expectations on it.
I posted, at the time of the first attempts to fix that, a xdr stream
implementation from the c++ journal.
That one would guarantee independence of struct alignment.
The ip address of the sender is redundant.
I do at the moment not know the actual implementation of the udp socket we use
here, but there must be a way to get them from the recv call (at least for
the udp/ip case).
Is that address used to send a reply?
If so, this will not work for everybody behind a nat gateway which rewrites
the ip headers but cannot know something about flightgears internals.
Also why do you use fixed length strings?
It seems better to me if there is a length field in front of the string data
which tells the implementation how much characters it can expect (within the
limits of the current udp connection of course).
Also that xdr stream would not have the problem with returning hardware
doubles if floats are returned by declaration (your comment in timy_xdr.h).
I have access to a DEC alpha. I don't believe that I can run flightgear on
that machine successfully and I doubt that there is a single alpha left on
this earth where flightgear will be run on.
So if you just want to be complete, I can help you with that, but my be we can
ignore the DEC's ...
Objections?
So all together this is good work, but as we are on it, we might be able to
make it fool proof :)
Greetings
Mathias
On Montag 15 August 2005 10:02, Oliver Schroeder wrote:
Hi,
I've written a patch that _should_ solve issues with endianess in
multiplayermode, which can be found at:
http://www.o-schroeder.de/fg_server/patch.php
Please try it out. Multiplayermode will still be broken on non
IEEE-encoding platforms (eg. Motorola 68XXX, vax, some DEC-alphas).
Since I have no access to those machines I can't help it. If you have
such a computer you may be able to provide the nessacary information
(ie. internal representation of floats/doubles), so I can fix this, too.
regards,
Oliver
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
