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