Oliver Schroeder wrote: > 2) A "visibility" range (Vivian called it "Radar Echoing Area"), > provided by aircraft model data. That way a eg. 747 can show up on > radar earlier than a cessna, making radar more real. > 3) A radio transmission range, i.e. the range a client is able to reach > via radio when sending (voice) messages > 4) A radio receive range, i.e. the range a client is able to receive > messages from. This may also be aircraft specific, not sure about that. > 5) the frequency a client is listening to (erm, there are two listening > frequencies, right?) > 6) the sending frequency of a client
While it sounds tempting, I'd strongly suggest *not* baking details of the radio model into the protocol. Eventually this is going to change in incompatible ways. I'd suggest simply allowing a set of "MP configuration properties" or whatnot, and leaving the implementation to more flexible code. Putting stuff like this into the protocol means that you're going to be making (incompatible!) changes very often as the implementation changes. As far as radio goes, I'd suggest using strings for the frequencies -- think of TACAN receivers, which have named "channels", or an administration/chat channel, etc... > > Anyway, this protocol is very error prone since it neither cares for > > alignment nor for endianess. I don't know of it still works for > > x86_64, don't talk about the sgi's in Erik's zoo ... > > What about converting the data to network byte order before sending, and > converting it back to host order when receiving? (using ntohl(3) and > htonl(3) on the buffer). Yes, this is not optional. All I/O should be cooked for byte order. You can use the socket.h macros if you like, or do it yourself, but you should never, ever rely on the fact that writing a struct out of or into memory seems to work. Andy _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
