Terry Reinert wrote:
First: Network Question.
I am an amateur programmer - self taught in C++ and Java - and have only recently started with sockets so bear with me (and I like Windows XP so I must need help!!).
I setup Flight Gear to dump airspeed (V=#) and throttle position (T=#) to my laptop at 1Hz. I whipped up a server in C++ w/ wxWidgets to capture the data. As I understand it, FG is sending everything in ascii format. Now, making a quick assumption, I figured that if I am pulling in 6 characters from the buffer when I am sitting still with 0% throttle - I would define my buffer as buf. As you are thinking to yourself right now, I was getting a lot of other characters print to the screen when I displayed the buffer. I assume this is because between FG and my program I am not accounting for the bit/byte process of the network traffic. I was 'hoping' I wouldn't have to worry about it and just let the socket interface worry about all the 1's and 0's. Maybe I can and something else is wrong. Any ideas?
You'll have to figure out how many decimal places the generic protocol dumps out. Usually when you do a read() call you specify the max size of your buffer, but read() returns the number of bytes read. These *should* come to you in ascii format in the proper order (i.e. you shouldn't have to do byte swapping with ascii data, especially if you are reading/writing from the same machine.)
As far as displaying the data ... the C/C++ string functions usually use character '\0' (ascii value = 0) to mark the end of a string. It might be a simple matter of noting the number of bytes read() returns and setting that position in your buffer to '\0' before printing it out.
Second: Networking Stuff Again
I am not sure if I am going to go with the generic interface for when I design the program that will be running my simulator. How is the data sent across when using the native interface? What would be the fastest way to get data across the pipe, interpretted, and acted upon? When I worked on F/A-18's in the Marines, we had a massive array of bit codes where one line would be 8 bits. You look each bit up on your little fancy chart and each one corresponded to a certain aspect of the aircraft. Quick Example: Punch in one of the flight controls address and... say... the third bit (0 or 1) means the gear is down or up. Would it be beneficial to create my own array or is that a perfect case of over engineering due to lack of true operational knowledge? :-)
This sounds like the sort of thing you'd do if you were talking to real hardware. Once the data get's mapped into FlightGear, we can afford to be a bit more verbose and give each "bit" it's own nice name in the property tree ... such as /controls/gear/gear-down. This is a much more convenient way to reference the data once you extract the values out of your cockpit hardware interface.
Third: New Guy
I'm new to Flight Gear and the list. I've spent quite a bit of time looking through the archives and I am looking forward to the discussions on the list.
Semper Fi - Terry
Hey, always glad to have more people digging into and asking questions about the code. Good luck with your project.
-- Curtis Olson http://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
_______________________________________________ Flightgear-devel mailing list Flightgearemail@example.com http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d