Re: [Flightgear-devel] Changes in raw_ctrls.hxx
So Andy Ross says: John Wojnaroski wrote: Bottom line: trying to run fgfs and opengc across the network with different platforms (in this case linux and cygwin) results in each side having a different value for the class in raw_ctrls.hxx and the socket read operations fail. I think the problem is especially troublesome when ints, bools, and floats are inside variables bounded by double types. It looks like it really gets messy trying to line up the various types so both sides see the same data boundaries. What you're trying to do won't work. It might work, if the architectures and compilers on both sides of the wire happen to agree. But in the general case, it just won't work. Even if the sizes and layouts happen to agree, the byte ordering might not. You can't do network I/O by dumping memory to a socket; it won't work. :) Write up a wire protocol specification as your basis, and implement that portably. It's really your only choice. And it's not very hard, just a little tedious. XDR is a well-established protocol that does just that: http://stommel.tamu.edu/~baum/programming.html#XDR If you're on a UNIX box you should also be able to do man rpcgen. Don't let the references to RPC (Remote Procedure Calls) confuse you, XDR was created to support RPC but can also be used stand-alone. Groeten,- Jacco -- Think about it: | In Real Life: Jacco van Schaik If the wheel had never been | Mail me at: [EMAIL PROTECTED] reinvented, we'd still be | Spam bait:postmaster@localhost driving on logs...| See also http://www.frontier.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Changes in raw_ctrls.hxx
John Wojnaroski writes: Just updated local CVS. Note that some changes where made to raw_ctrls.hxx. There is a problem trying to get the various platforms to agree on how sizeof() computes the number of bytes in a data structure. I think this is a good argument for using an ASCII protocol rather than a binary one. Unless you're moving a lot of data (i.e. vertices for scenery or a 3D model), the extra overhead probably isn't noticable, and all big/little-endian and other problems disappear. For controls, all of the data should still fit in a single packet in ASCII. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.08 00:43]: I know for the general case an external graphing tool would be most useful (and I think Jon B. has stuff to do this already.) But, I was just thinking today that it might be cool to have a built in grapher for simple / quick graphing needs. With the property system it would be trivial to pick an arbitrary property from the property tree and graph it over time -- superimposed on top of everything else. Things get a bit trickier if you want to control scaling, how much time history get's graphed, multiple values, etc., but even graphing a single value (or maybe just two values) over time could be of some use. I would think that setting this up around our networking scheme would be ideal. We could just export what we want and have an external program graph the data that comes across the socket. Then we wouldn't have to embed a grapher into FG. Anyway, my 2 cents... -- Cameron Moore [ How's my programming? Call 1-800-DEV-NULL ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] idea ... (?)
I wrote a little routine that allows flightgear to read in the csv data from a previous flight (or from a standalone JSBSim flight) and replay it as a flight. I can use the joystick to adjust the speed and I can play it forward or reverse. Would that be useful to anyone else? Mark -Original Message- From: Jon S Berndt [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] idea ... (?) On Fri, 8 Mar 2002 10:00:54 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: I know for the general case an external graphing tool would be most useful (and I think Jon B. has stuff to do this already.) Yes, it's a very useful command line tool that plots files of CSV format (comma delimited value format) data, where the first line contains descriptions of the data. It can plot interactively or it can plot a standard set of graphs (producing .png image files) that are linked to via descriptive links from a main html web page. It is very slick. Unfortunately it uses a closed source library - the library is freely available for most platforms, but some people here don't like anything that is not completely open source. So, a nice alternative (in my mind) would be for someone to write a post-processor for the CSV files to plot (either interactively or via .XML input directive file, as I have now for simplot) the data using pgplot, or some other open source plotting program. In the near term, one of the quickie projects I want to do is to write a small routine that will produce color postscript reports as directed by a directives file. I've written several post-processing tools over the years (including one that used SGI GL to render 3D views of the Space Shuttle Orbiter separating from the External Tank in an abort study for NASA). Fun stuff. Anyhow, postscript is nice and simple, and GhostScript has some nice utilities for viewing them. Might be able to also convert them quickly to PDF format with pstopdf. There are lots of possibilities, but for me the important thing is to keep it simple, automated, and quick. Another nice thing to have would be a stripchart data display that could be run on a remote machine. If I only had a few more hours a week ... But, I was just thinking today that it might be cool to have a built in grapher for simple / quick graphing needs. With the property system it would be trivial to pick an arbitrary property from the property tree and graph it over time -- superimposed on top of everything else. I wonder if a remote (or even local) stripchart display program would be better? Things get a bit trickier if you want to control scaling, how much time history get's graphed, multiple values, etc., but even graphing a single value (or maybe just two values) over time could be of some use. You might want to do this via autoscaling, but with initial values suggested in a directives file. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
On Fri, 8 Mar 2002 10:27:16 -0800 John Wojnaroski [EMAIL PROTECTED] wrote: There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Such as test pilots. We could use a few on-staff! :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] UIUC planes below runway
John Check writes: I noticed that the UIUC planes are buried under the runway at startup. Is anybody else seeing this? Console output looks like this: FGLaRCsim::set_Altitude: 1.14496 (*) Current Altitude = -1.87 -1.85 forcing to 1.15 FGLaRCsim::set_Altitude: 1.14503 (*) Current Altitude = -2.09 -1.85 forcing to 1.15 FGLaRCsim::set_Altitude: 1.14519 Any Ideas? It probably has something to do with the UIUC gear code. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Alex Perry writes: Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. I've been playing with xoscope but it seems to be linux-only and limited. I've been thinking it might be worth porting its user interface to plib, to transparently address all FGFS targets, and give it a property input. Ok, sounds like a good enough excuse to me. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Yeah, but they're the ones who're selective about interpreting their flying impressions in terms of how they think it is supposed to work. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Dear Friends, Are we getting to a war? Flying experience and skill are grossly acquired..that is why hugecountries are spending great dough on that. Let us keep the distinctions apart,..and the disciplines united. - Misra MD, RealiSim Technologies Retd Fighter Pilot, Qualified Flying Instructor, Experimental Test Pilot, Scientist 'F' Present Managing Director Regards - Original Message - From: Tony Peden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 09 March 2002 00:44 Subject: Re: [Flightgear-devel] idea ... (?) --- John Wojnaroski [EMAIL PROTECTED] wrote: Hi, I also think that I know *too much* about the details of the aero and that pilots who don't have an in-depth understanding of aero engineering can oftentimes give better feedback than those who do. Careful there, are you saying pilots who don't have aero engineering backgrounds can give better feedback than pilots who have aero backgrounds?? Or pilots don't have a in-depth understanding of aero?? Yes, that's exactly what I'm saying. There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Yes, indeed. Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Sounds like it'd be useful for debugging aircraft and autopilot configs too. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Tony Peden writes: In my day job, my own experience has been that real-time plotting is useful when you know exactly what you are looking for and you only need to see a limited number of parameters. The rest of the time, recording the data and plotting after the fact works out to be better. That said, it *would* be a very cool thing to be able to do. Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. The immediate thing that comes to my mind is this: As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out. Something like a quick and dirty embedded graphing program would be pretty nifty. cout probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph. Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in. FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off. I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool. For instance, nosing over the c310 causes it to go into an infinite acceleration cycle. Hmmm I wonder of that is drag related? Ok, pop up a live graph of thrust, nose over, watch the graph with everything else going on. Nope, drag looks good. I wonder if it's thrust related. Oooo, look at that thrust go off the chart ... ok now let's graph some individual propellor/engine parameters ... etc. etc. That's how my mind works anyway ... :-) Curt. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Sure, you could use it to graph the value of any flight gear property over time ... not just FDM values. This could be useful for all sorts of stuff ... debugging panel actions, 3d model animations, environment modeling, etc. Curt. Jim Wilson writes: Sounds like it'd be useful for debugging aircraft and autopilot configs too. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Tony Peden writes: In my day job, my own experience has been that real-time plotting is useful when you know exactly what you are looking for and you only need to see a limited number of parameters. The rest of the time, recording the data and plotting after the fact works out to be better. That said, it *would* be a very cool thing to be able to do. Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. The immediate thing that comes to my mind is this: As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out. Something like a quick and dirty embedded graphing program would be pretty nifty. cout probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph. Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in. FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off. I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool. For instance, nosing over the c310 causes it to go into an infinite acceleration cycle. Hmmm I wonder of that is drag related? Ok, pop up a live graph of thrust, nose over, watch the graph with everything else going on. Nope, drag looks good. I wonder if it's thrust related. Oooo, look at that thrust go off the chart ... ok now let's graph some individual propellor/engine parameters ... etc. etc. That's how my mind works anyway ... :-) Curt. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Virtual cockpit notes
FWIW thought I'd make a few comments on the new 3D view stuff, realizing that it is still being worked on. While the commercial sims give a 3D feel to the cockpit they aren't always attempting to be true models. In this screenshot from fs2k, note that while the perspective (eye to panel) is ok, the left piller is missing to give better viewing with 3D mapped to 2D display...where the pilot cannot move their head to change the view. It looks like there are a lot of photo textures being used. It also appears that the perspective is not consistant with the exterior view angle. In some cases it makes sense to do this so that you can see the panel pretty much straight on (necessary to read the gauges) and be able to see the runway well. The yoke must get in the way though (you can't lift your chin and look down over to see a gauge): http://web.ukonline.co.uk/members/dmarch/images/fs2k.jpg This screenshot of a 747? panel shows little concern for 3D realism, but is a highly functional and usable panel. There's only so much you can do with guages anyway. The view perspective gives the computer pilot a straight on view of the panel: http://www.simaviator.com/screen/iam/30.jpg These are in Fly!. And I have to say that the Fly! panels are the ones I like the best. It isn't just the graphics and 3D modeling, but the fact that the panels are unrealistically close to the (in 3D world) pilot's nose and the perspective is always straight on (the same plane). What is rightly sacrificed in realism makes them look sharp, and of course readable. The panels scroll very much like the current 2D FlightGear panels: http://www.intelligamer.com/features/qa/fly/fly03.jpg http://www.avsim.com/pages/1299/fly/capt1pnl.jpg Note that when you change the 3D cockpit view angle in Fly!, the panel in effect becomes disabled and as far as I can tell is just a static texture on the front wall of the aircraft model interior. The knobs and controls are hard enough to see and control using a mouse with a straight on view, let alone when 3D perspective angles are mapped to 2D. Anyway, just thought I'd bring these ideas to the discussion in case they are of any value. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 9 Mar 2002 09:48, you wrote: FWIW thought I'd make a few comments on the new 3D view stuff, realizing that it is still being worked on. Note that when you change the 3D cockpit view angle in Fly!, the panel in effect becomes disabled and as far as I can tell is just a static texture on the front wall of the aircraft model interior. The knobs and controls are hard enough to see and control using a mouse with a straight on view, let alone when 3D perspective angles are mapped to 2D. I think we should be closest to Fly than to MSFS in this regard. The cockpit should be exactly the way it is in the real thing, minus the yokes because they get in the way. This will make FlightGear a usual tool for cockpit familiarisation. Fly's implementation of a 3d cockpit is a little lacking in a key area. It isn't really 3d. FGFS's is and should be a real 3d cockpit that is totally mouse scrollable. It can still have number keys locked to bookmark view positions, but it should be free scrolling. It should also have every single button doing exactly what it does in the real thing. That's my opinion anyway, FWIW. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8iXg5F2H7v0XOYBIRAnahAJ4w4lmvrzb1QJoyoYTBh6LKG6NAwwCdEPr4 Xk1mxmIh8DAAtmDto1Op62M= =m2z8 -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
