[Flightgear-devel] Re: Options
Well, I wasn't going to way-in until someone mentioned Scale and Mathworks. Just to set the record straight, for the 747 we'll be using FG-0.9.8 modified to handle all the 747 subsystems, engine models, synthetic voice, etc, etc. All the source files were provided to the primary authors, but for what ever reason they chose not to incorporate the code into CVS or ongoing releases. Bottom line, it has become a real pain in the *** to keep in sync, so why bother 0.9.9 does nothing new, great, or better for stand-alone sims. No wonder the whole world of cockpit builders prefers MS Windows. Packing and moving the sim requires time and expenses. For Scale and Mathworks it cost several hundred dollars which were not reimbursed; all we got from Mathworks was a free lunch. For all those complaining, my advice is put a sock in it JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Freeglut and game mode
I know you guys have taken care of this, but perhaps it bears repeating.. Check your XF86Config file(s). In some case incorrect monitor settings can result in X turning off the second monitor if the numbers for the desired unit don't meet spec or becomes confused if you have two different monitors for a dual headed card and don't call out the specific sync and refresh numbers. Regards John W. Bruce Benneke wrote: Curtis L. Olson wrote: I'm not expecting any issues with glut-3.7 on FC4 ... should I be? I'll try it, probably not till next weekI'll post...(assuming I haven't booted that box against the wall...having pesonal issues switching from mandrake to FC.) Bruce Benneke ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Net protocols
were there any changes to envoking the network/socket connections in 0.9.9? this works in 0.9.8 --native-ctrls=socket,in,30,,5700,udp but fails to start the code in FGNetCtrls2Props() with 0.9.9 Presence of control packets on the LAN has been verified as well as LAN integrity Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Net protocols
Curtis L. Olson wrote: John Wojnaroski wrote: were there any changes to envoking the network/socket connections in 0.9.9? this works in 0.9.8 --native-ctrls=socket,in,30,,5700,udp but fails to start the code in FGNetCtrls2Props() with 0.9.9 Presence of control packets on the LAN has been verified as well as LAN integrity Check the hardwired version number in the packet. That will get incremented when the structure changes. It's also there if you want to get crazy and build a system that can read the packet version and decode it differently for different versions. I suspect there probably was a change between 0.9.8 and 0.9.9 I've have the version numbers sync'd. If not, I should be seeing the version mismatch error msg at the start of the routine. There were a couple of changes at the front of the packet adding some trim numbers and rearranging the order. Have those accounted for in the sending host. If you have any additional ideas, fire away. It appears that the socket is not being opened/created and/or listening for UDP packets. I'll just try and step through through the code; not a gdb expert, but might just be on my way. Question: how do you start a program with a shell script, loading the executable is no problem but how to specify all the arguments without a lot of typing? some sort of addtional input/config file? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NetCtrls
Hi Curt, There is a mismatch in the length of the packet definition between the two sides. I should have enabled the error logs and I would have seen that. BTW, how do you do that, compile time, run time, and where are the logs stored? JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG, opengc, generic gauges
Hi Curtis L. Olson wrote: Bruce, There are many different ways to approach this problem. OpenGC is good if you want to get into glass cockpit modeling. But if you want to stick to traditional steam gauges, FlightGear has everything you need already built in. In fact FlightGear includes some nice hires C172-S gauges you could use to assemble your own 2d panel. The basic idea is to draw all the gauges on an LCD monitor, strategically placed behind your panel cutouts so that they look like real gauges. I personally do not know a whole lot about opengc, so if you wish to go that route, John W. is your best point of contact. If you are interested in this other idea of using FG to do 2d steam gauges, I can give you some more details on that. Poor Bruce :-), must feel like he his running in ever diminishing circles. After chatting with him, I suggested he repost on the FG mailing list lol. I think the 172 panel would be more in line with the program he is trying to develop for the aviation cadet program. A lot closer to what they will see when heading out to thenlocal airstrip and peering into cockpits. Regards John W. Best regards, Curt. Bruce Benneke wrote: It was suggested I repost this heresorry for the sloppy formatting of this message *_Summary of this project_*.. For students in air cadetstoo young for actual flight training, just trying to get them interested. Trying to build a 172 cockpit , having 'out the window' view handled by at least one system, just the panel handled by another... In essence, a network of systems, one segment handling view, another the gauges, and a third for an instructor to monitor the entire process. Eventually, on a simple motion base. Was trying to use opengc for this, but discovered that opengc and FG .9.9 dont talk so well under windows (not at all, apparently opengc becoming dormant in that area) Moved to linux boxes, and into a whole new set of issues with getting opengc to compile, etc. Is there a way to do this without using opengc? (or wiring 'actual' gauges...doable, but too expensive right now..._zero_ budget would be a good description...this is all volenteer) I'm not sure the 'glass cockpit' approach is what this project needs anyway for this simpler cockpit (I'd rather have them be able to scan the 'big 6' than glance at a PFD or HUD) Any advice or links to advice would be GREATLY appreciated. Bruce B (btw...I'll try and open source any software we come up with for the motion base...still a long way down the road, but any help here would also be appreciated) below I've attached some of the conversation I've had with John W. regarding this...it's kinda messy 'cause I just copied and pasted it...sorry!!! Actually, just thinking of the 172 for right now... a basic generic cockpit for now(might do a glider as well...air cadets offers a gliding program...) Is there a way to do this without opengc? (I have a tendency to look for the complicated solutions first.then kick myself later.) Just want to have the panel on a seperate screen(computer)...might expand the view to 3 screens if I have the time..even just the 'big 6' gauges on a seperate screen... You're right on the money with the virtual desktop solution for the InstructorI suppose I could just use VNC as well, that might just allow the instructor to point out things. btwFG running on a Fedora Core 4 box, fresh install. Can't get opengc to compile (with or without cmake), but I've heard theres more than one source? (kingmont/sourceforge?) I'm also having issues with cvs on this boxbut thats another story (my old mandrake box was so nice to me...FC4 hates me) The box I sacrificed is an Athlon xp 2000, Nvidia 5200, 512 MB ram, so not the highest amount of power out there. Thats why I want to divide this up amoungst a few older machines. I've been REALLY busy lately and haven't been able to do much research into this, but I'm hoping to get more involved over the holidays. I'm not the best coder out there either(self tought there...I'm a hardware guy since the late 70's) Sorry to keep buggin' you.. Bruce Benneke John Wojnaroski wrote: Bruce Benneke wrote: Great info... thanks... I'm going to bump the whole project over to linux boxes over the weekend and see what happens. 1 running FG, another running opengc and atlas. (maybe mirror it all to an instructors station if I can figure out how) We're also hoping to build a motion base for this sucker as well...any sage advice/warnings? Consider using the export DISPLAY=machine_name:0.0 command to set up X on a remote host? If you're running fvwm2 under X you can setup several virtual desktops on the instructors station. Are you trying to model any specific aircraft or just a generic cockpit? OpenGC is glass, others may have added the more conventional steam gauges but my contributions were only for modern glass
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Curtis L. Olson wrote: Ralf Gerlich wrote: Heh, I'd like to see you looking at the Autopilot _and_ out of the window in a real plane. ;-) As was mentioned, the nearest you could come to the flow in the cockpit IRL - not looking at the instrument and still changing its setting - is probably using the keyboard...at least as far as I see that as a pure simulation pilot ;-) You could have *perfect* flight dynamics that nailed all the numbers and all the nuances of the model exactly right, but if you are sitting at your desk, holding a $20 joystick in one hand and typing on your keyboard with another, while peering at a 17 monitor ... it's just not going to ever be all that realistic of an 'experience.' One of the knocks from the May show ( which is totally my fault) was the cheezy joystick. So here we were with a full scale 747 glass cockpit with a large screen plasma OTW display running top of the line flight dynamics (JSBSim), world class scenery (FlightGear), high fidelity subsystem models (Mathworks), and a noodle for control. If we had had a decent control system, we could have faked the rest ;-) JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Curtis L. Olson wrote: John Wojnaroski wrote: One of the knocks from the May show ( which is totally my fault) was the cheezy joystick. So here we were with a full scale 747 glass cockpit with a large screen plasma OTW display running top of the line flight dynamics (JSBSim), world class scenery (FlightGear), high fidelity subsystem models (Mathworks), and a noodle for control. If we had had a decent control system, we could have faked the rest ;-) Come on Jack, when are you going to drive up to Mojave with your hacksaw? I can get you past the fence, the rest is up to you. :-) I hear you. There is also a boneyard at El Mirage which has some hulks that go back to WWII. I understand the tv series LOST got some of the props from that site. I ought to give Tom a call now that the daytime temps up there have become bearable. Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Displaying Multiple Views/Using cockpit controls
Curtis L. Olson wrote: Ryan Kellar wrote: I am new to using FlightGear and am currently working on a project that involves a flight simulator with a Cessna cockpit and a screen that is divided into 3 sections in sort of a wrap around(not fully, but tilted to give a more panoramic view. Each board is displayed using a different projector run by three separate computers. Also, the cockpit controls are being read in as voltages to a separate computer. I am completely new to flight simulation and this software, and have some C++ software experience but never any software hardware integration so I’m a little lost. My questions are is there a way to display a simultaneous panoramic view using the three computers each running an instance of FlightGear and if so, how? Yes, mutliple displays are well supported in FlightGear. There is a document called README.IO that touches on this. If you need more help, just ask. Note to document writers: this might be a good subject to add to the manual. Also, how can I go about reading in the cockpit controls(which are now being read as voltage values) into the program to control the airplane? How are the voltages being read? Is there some sort of circuit and/or board in your computer that senses the voltage? A little more info on that topic would be helpful. If your hardware already exists, then this is something you will likely have to figure out on your own. You will need to write some glue code that can read the voltage values and translate them into a control input position. FlightGear uses normalized control input positions so yoke, wheel, rudder pedals, etc. are mapped to [-1, 1]. Throttle, flaps, mixture, etc. are mapped to [0,1]. Once you are able to read in your voltage values and normalize them, it is pretty straightforward to send that data over to FlightGear. It's possible to embed some code into FlightGear, or you could just write a separate application that sends the data to FG over the network. If you need some electronics to convert from analog to digital there are a number of products/boards to do the trick. Phidget now offers some boards that are supposed to work with Linux, you might check out www.opencockpits.org over in Spain (these are MS Windows based ATM), or www.lfstech.com (linux based) for more info on the topic. As Curt noted, you will then need some code to take the digital output of the boards and input that to the FG program. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Displaying Multiple Views/Using cockpit controls
Curtis L. Olson wrote: Ryan Kellar wrote: I am new to using FlightGear and am currently working on a project that involves a flight simulator with a Cessna cockpit and a screen that is divided into 3 sections in sort of a wrap around(not fully, but tilted to give a more panoramic view. Each board is displayed using a different projector run by three separate computers. Also, the cockpit controls are being read in as voltages to a separate computer. I am completely new to flight simulation and this software, and have some C++ software experience but never any software hardware integration so I’m a little lost. My questions are is there a way to display a simultaneous panoramic view using the three computers each running an instance of FlightGear and if so, how? OK, had an interrupt. To finish the topic... If the separate computer has the prerequiste interface hardware you have a couple of options: 1) Modify the FG source code to read and convert the voltage values into control inputs and run that as the primary server displaying the center screen and run the left and right as slaves as discussed in the README docs, 2) Connect the fourth machine with the control inputs via a LAN using one of the socket protocol defined in the Network directory, or 3) Define your own protocol and socket code. The existing source provides a fairly good template and structure to help you. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
bass pumped wrote: On 11/23/05, pmaclean [EMAIL PROTECTED] wrote: Well I got flight gear (version 0.9.8) to compile thanks to the posting by Erik Hofman. http://mail.flightgear.org/pipermail/simgear-cvslogs/2005-January/001011.html I am using Visual Studio dotnet (7.1) on Win2K. The only reason I have had any success building this environment is due to the following article: http://www.geoffmclane.com/fg/fgmsvc7.htm Now I am having an issue running the compiled code as freeglut.dll is not accessible. I'm sure it's a path issue... I am still interested in knowing the format of latitude, longitude and altitude with respect to flightgear's net FDM format. Does anyone know the 64bit description of these fields? Paul __ Is your .com Auracom? Best access rates on the web http://exclusive.auracom.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d hmm... I think I was able to read latitude and longitude properly over net fdm. Let me check and get back to you. look in net_fdm.hxx for the variable type and units, as in radians and meters ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.9 Build problems
In file included from /usr/local/FG-0.9.9/include/plib/ul.h:41, from /usr/local/FG-0.9.9/include/plib/sg.h:29, from /usr/local/FG-0.9.9/include/plib/fnt.h:29, from /usr/local/FG-0.9.9/include/plib/pu.h:28, from fg_os.cxx:14: /usr/include/stdlib.h:612: error: declaration of `void exit(int) throw ()' throws different exceptions /usr/X11R6/include/GL/glut.h:163: error: than previous declaration `void exit(int)' make[2]: *** [fg_os.o] Error 1 make[2]: Leaving directory `/usr/local/src/FlightGear-0.9.9/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/src/FlightGear-0.9.9/src' make: *** [all-recursive] Error 1 Using gcc-3.3.5, automake-1.8.5 on a Debian system Just finished upgrade to 3.3.5, did I forget something regards the libraries? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Feature/change/update/fix list since v0.9.8
Hi, On the subject of features... In general, It would be helpful if error msgs were a bit more informational For example: Incorrect path specified in configuration file doesn't really help much in tracking down the problem. Perhaps the author knows what it means, but not very efficient grepping through the code to find the code section in question and then analyzing what is happening. ;-) Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. I think most of the Phidget software is MS Windows based although some of it is being ported to Linux ( how much and when I don't know ) I might be wrong and have not examined any of the software or interfaces closely but I think you'll need to do more a bit more than just write FG values to a device. If Phidgets aren't the answer, might consider breadboarding up a circuit via a USB I/O port along with the software. I've been working on some electronics for a slightly different application, but this might be an interesting derivative. If you want to handle the physical stuff, I could find some time to help with the electronics and software. You can contact me off-list at [EMAIL PROTECTED] Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Curtis L. Olson wrote: Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. It's cheap and you get what you pay for. Not enough bits and resolution and you still face the problem of now writing some sort of driver that handles the USB connections and converts the GLUT mouse inputs to something meaningful to drive your gauges. And you still have to handle the physical design problem. Thinking it's better to start with a clean piece of paper. Again, phidgets are worth a look. The software problem is also cleaner than a X-11/GLUT hack and can be worked. John Wojnaroski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. The boards Curt refers to were specifically designed for a 747 simulator. They will read analog, discrete inputs, rotary encoders but are not designed to drive anything other than digital signals. Would need a bit more design and rework to handle the current loads of DC motors or servos, control, etc. (See earlier post) Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scale4x
a little late but they've finally announced the winners for Scale3x http://www.socallinuxexpo.org/past/2005 we'll be taking the 747 sim to the new show in February running with RT Linux by RTAI/Xenomai aka fusion If you're in the area plan to come over and talk real-time stuff or just some some sim time... Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenATC revisited??
Erik Hofman wrote: John Wojnaroski wrote: you might try http://sourceforge.net/projects/openatc It died a quiet death when no one showed up for the network field test Hmm, it looks like it started when the time wasn't right. I think we have enough momentum right now for a restart. Erik Well, the files and libraries are still there on the field test page. I'm pretty busy for the next few weeks, but might have some time in November unless someone wishes to step forward before then Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was
you might try http://sourceforge.net/projects/openatc It died a quiet death when no one showed up for the network field test JW Vassilii Khachaturov wrote I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Apparently the pcproxy is in Debian (which made me believe we can interface the protocol, too) because it just forwards the packets w/o examining their contents too much. Hopefully one day we'll provide an open source alternative to that. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..we're not re-inventing pcproxy?, was
Martin Spott wrote: Vassilii Khachaturov wrote: I wonder if the flightgear server though should support the fsd protocol at some future point of time to be a gateway between our and VATSIM/IVAO flying... It's not a matter if it _should_ or not. The relevant details of the protocol, at least as used by VASTIM, are 'closed', Security by obscurity, as far as I am reading the forums... stupid. Indeed, and I find it very annoying. Instead of developing our own ATC network strategies if would be terribly nice if we could simply jump on that train - without violating copyrights, NDA's or whatever Hopefully one day we'll provide an open source alternative to that. Yes, but we should take into account that it takes a while until we have such a network infrastructure that offers ATC service at almost every medium large airport areound the clock ;-) Cheers, Martin. But if it could be combined with Dave Culp's AI controller then you might have, at least, a 'silicon-based' based controller available on demand and plug-in when the 'carbon-based' controller was not available. Throw in some tts and speech recognition... Not a trivial task or something you build over a weekend. Probably a job bigger and more complex that eclipses all of effort put forth on Flightgear to date. Any volunteers???:-) Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Just my $0.02 John W. Curtis L. Olson wrote: Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. You' re reading my mind :-). It would be a great tool for training and teaching. Some of the MS ATC systems have a mentoring and training program for newbies and I suppose some sort of certification before one is allowed to go live. Again, a lot of work and dedication required Seems the only reason to include such a capability inside FlightGear would be for a centralized controller and a desire to operate in compliance with the appropriate rules. Otherwise let folks set up servers on their own, set the rules for participation, and press go and no need to engage FG. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] DME range
Does anyone know if the DME calculation to a VORTAC is based on slant range? Noticed when flying over a fix say at FL350, the range goes down to zero at station passage. It should be the AGLvalue of the aircraft over the station. OTH a waypoint based on radial intersections or GPS would go to zero. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Hi Jon Jon Berndt wrote: The version of FlightGear used for the MIADC show in May contains a fan/turbine model based on physics and thermo equations, a different approach to tank/engine selection to handle the 747 fuel system, changes in the control packet, and an update to the data packets. It might not be practical to try and incorporate these into the CVS baseline .I'm not sure and not all that conversant on how to create all the ifdefs and other compile/run time options or xml files to handle all the deltas. However, the source is there for anyone brave enough have a go at it or just to consider if it might be feasible. As I recall, Curt first created a diff file against the then current CVS baseline, next ran patch, and IIRCC the build was very clean. Go to http://www.lfstech.com and browse over to the download page. The file is miadc.tgz. John W. Hi, John: Very nice. I looked at FGTurbine.cpp. A couple of things: 1) Of course, it would be nice to incorporate the JSBSim changes into the current JSBSim CVS. However, as you may know, JSBSim has undergone major revisions compared to the version now in FlightGear CVS. Within weeks (maybe sooner) we should be moving the new JSBSim code into FlightGear development CVS. So, to incorporate your changes, the Load() method will need to conform to the use of the new XML parsing method. BTW your comment just pinged my memory. There are a few more changes to individualize engine performance like turbine/compressor efficiencies, hydraulics, etc. contained in the xml files for the 747. 2) Question: Is your turbine model generic, or specific to the 747? Its generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. 3) Did you make note (in code or whatever) of exactly which files you modified? The FGTurbine code is replaced en masse. No, sorry did not, but you should be able to run a diff. It's been a few months since I worked in that area, recall some changes in the FGEngine, and a few other areas to handle loading in the other engine parameters from the xml files. Probably makes more sense to wait for the next JSBSim release. I'll probably revisit that code in the next few months for another project and update it as needed. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Jon Berndt wrote: John Wojnaroski wrote: It's generic, but needs some massaging to handle things like compressor/turbine maps, engine parameters such as inlet area, fan size. Point in fact, the model is based on John Reed's paper for LeRC, but the actual numbers are my best guess to obtain some reasonable numbers for engine performance and response. The start sequence is kind of nice with the EGT showing the typical rise to a peak and then settling into the idle range. Is this the paper Might be or a derivative work, don't recognize the second author --- A Java simulator for teaching gas turbine operation John A. Reed and Abdollah A. Afjeh (Toledo, Univ., OH) AIAA-1997-850 Aerospace Sciences Meeting and Exhibit, 35th, Reno, NV, Jan. 6-9, 1997 --- I can't find it anywhere online. Hmm, neither can I and can't remember how -- it was a few years back. The link may be gone. At any rate, I uploaded a pdf file to the lfstech download page. You can find it there. Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Source code
Hi, The version of FlightGear used for the MIADC show in May contains a fan/turbine model based on physics and thermo equations, a different approach to tank/engine selection to handle the 747 fuel system, changes in the control packet, and an update to the data packets. It might not be practical to try and incorporate these into the CVS baseline .I'm not sure and not all that conversant on how to create all the ifdefs and other compile/run time options or xml files to handle all the deltas. However, the source is there for anyone brave enough have a go at it or just to consider if it might be feasible. As I recall, Curt first created a diff file against the then current CVS baseline, next ran patch, and IIRCC the build was very clean. Go to http://www.lfstech.com and browse over to the download page. The file is miadc.tgz. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
Oh, one more item, There is a synthetic voice module that will send Dave's ATC transmissions to the Festival TTS program. The voice quality is not all that great but at least you don't have to read the screen. JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
You might want to go back and check the email archives almost a year ago. We had discussions with the VATSIMfolks and it went nowhere. There was some thought of starting a development for FG using the TNL libraries, set up a small network test, but it all faded away due to lack of interest... JW Andy Ross wrote: It's not about security jvrvez wrote: Ok, They don't want that a GPL tools is used to interface their network for secutity reasons (I think this is understandable) anyway why can't we join their network with their own code? This is a non-starter. There is simply no way to make this work, sorry. They can make their code (or protocol) available under terms we can use, or not. It's not something about which we are able to compromise. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 747 Project update
Hi, Curtis just posted some new pics of the completed 747 throttle quadrant. Kind of proud about that piece of work :-) spoiler control, 4 independent throttles, fully functional flap handle with positions detents, and fuel cutoff switches; When the new throttle levers are installed will include reversing mechanism and TO/GA switches. Best part is that it connects via a USB port JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 747 Project
Greetings, Between the time spent getting ready for shows like Scale and MIADC and the myriad other things that consume our daily lives found some time to work on the Project. Curt posted a couple of pics detailing the '05 rebuild. The project for the summer is to finish the center pedestal. MCDU screens are cannabilized from Sony Playstations with a little added circuitry to handle standard VGA output rather than TV and create composite video sync signals. The pedestal panels are from Flightdeck Solutions, located in Toronto and led by Peter Cos --- a top notch, world class oufit. Great parts and super support. The MIADC show with Mathworks in May was a big success. Support was outstanding and the sim log was full from setup to teardown. We had a large premium room all to ourselvs along with hospitality bar -- talk about a deadly combination ;-) Still running with a modified version of Durk's code we used at Scale3x. we've been invited back for Scale4x and might just go to the AVSIM meeting in San Diego during September. See www.flightgear.org/Project/747-JW Enjoy Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747 Project
Oooops, that's www.flightgear.org/Projects/747-JW John Wojnaroski wrote: Greetings, Between the time spent getting ready for shows like Scale and MIADC and the myriad other things that consume our daily lives found some time to work on the Project. Curt posted a couple of pics detailing the '05 rebuild. The project for the summer is to finish the center pedestal. MCDU screens are cannabilized from Sony Playstations with a little added circuitry to handle standard VGA output rather than TV and create composite video sync signals. The pedestal panels are from Flightdeck Solutions, located in Toronto and led by Peter Cos --- a top notch, world class oufit. Great parts and super support. The MIADC show with Mathworks in May was a big success. Support was outstanding and the sim log was full from setup to teardown. We had a large premium room all to ourselvs along with hospitality bar -- talk about a deadly combination ;-) Still running with a modified version of Durk's code we used at Scale3x. we've been invited back for Scale4x and might just go to the AVSIM meeting in San Diego during September. See www.flightgear.org/Project/747-JW Enjoy Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747 Project
Durk Talsma wrote: On Tuesday 28 June 2005 18:36, John Wojnaroski wrote: Still running with a modified version of Durk's code we used at Scale3x. we've been invited back for Scale4x and might just go to the AVSIM meeting in San Diego during September. See www.flightgear.org/Project/747-JW Great to hear that you actually managed to use the code. Hopefully by the time of the next show, I have the taxiway following code in place. I have now added some basic AI network editing capability to taxidraw. Getting this to use by flightgear shouldn't be too hard to code anymore (provided I have time). Ground handling in FG is still lacking for the heavies. Having to deal with a few more moving objects on the apron and taxiways would be an interesting exercise in ground handling. What's the date of the next meeting? Have been thinking of the AVSIM show in September down in San Diego, but not certain they will provide the support ( space and power) needed at the low-ball rate for freeware exhibits. Next planned event after that is Scale4X here in LA around Feb '06 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Controls
2. Has anyone interfaced actual hardware, i.e. switches, etc. with flightgear? Again, are there any references for this? Adding to what Curtis has said. There is no standard per se regards connecting custom hardware to FlightGear. Off-the-shelf stuff like joysticks, throttle quadrants, ruddes, etc will work with the plib library. The 747 project uses the protocols defined in src/Network to communicate with FlightGear. All the hardware interfacing is done on the simulator side with circuits and electronics specific to the controls and functions of the 747. The circuit design is generic and can be adapted to any model by writing a new application (module) that communicates with the drivers and translates the hardware vectors and switch states into whatever the designer requires. The drivers for the hardware provide an interrupt-based connection via a parallel port for time critical tasks and USB ports for all other static and polled switches and events. Connections to FlightGear for receiving data and sending controls is done with the protocols as noted above and these have also been modified to handle unique aspects of the 747 models and subsystems. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mathworks Interface
I just got back from a Mathworks matlab/simulink symposium in LA this week. (Thank you John, Alex, and Trisha for all your efforts! And I have to thank Mathworks who went all out to help us get John's 747 sim down to the show and make it a success.) And don't forget those great lunches and the afternoon snacks!!! Mathworks has customers (plural) :-) requesting a direct interface to FlightGear which is why they implimented an interface in the latest release of their aero blockset (available yesterday) and invited me and John Wojnaroski to come be a part of their show. John brought his 747 sim along and it was (predictably) :-) one of the bigger hits there. This is probably 2nd or 3rd hand, but I hear that the unofficial ratio of FlightGear interface requests to X-Plane interface requests is about 5-1 which is why mathworks built the FlightGear interface first. That's music to my ears. :-) Just got the USB driver(s) for the 747 sim coded and running this morning. After we get all the network interfaces reworked to provide generalized support to Simulink it will be real close to a plug-and-play system. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Weather - Clouds
Harald JOHNSEN wrote: Hi, I did some research on 3D clouds for some time and finaly got something not too bad. I've started to add that to SimGear this week end, here are the first alpha screen shots : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-011.jpg http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-013.jpg I have alse some code nearly ready for rain, snow and lightnings. My next step will be the automatic generation of the cloud layers depending on the METAR data, I have allready found some plausible rules to generate the right kind of clouds based on altitude, wind, dew point, etc. Well, the idea is to have a visual environment almost realist and why not, not so far from real weather. Harald. Are you using the techniques and algorithms devleoped by Mark Harris that are currently in SimGear? You might want to read his dissertation posted on his web site. Mark has since gone on to greener pastures working for Nvidia. I don't think there are any snapshots on the website. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight sim jobs
Color me crazy, but it might be a way to help pay for some of this 747 stuff JW Curtis L. Olson wrote: I forget if we have a policy for posting job listing here, but if anyone is interested in taking a look at a 6-12 month contracting position in Santa Clara, CA for a large defense contractor doing simulation work, feel free to contact me offline and I can pass along details. This is not an endorsement of the position or the company or the recruiter (all of whom I know little to nothing about), but I thought I'd mention the oportunity in case anyone out there would be interested in taking a look. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] BoF Meeting about FGFS next week, in Anaheim California
- Original Message - From: Alex Perry [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: flightgear-users@flightgear.org; flightgear-devel@flightgear.org Sent: Tuesday, April 05, 2005 1:52 PM Subject: [Flightgear-devel] BoF Meeting about FGFS next week,in Anaheim California http://www.usenix.org/events/usenix05/bofs.html Title: Adapting the FlightGear Flight Simulator - Customizing your Cockpit Name: John Wojnaroski Affil: FlightGear project, Developer eMail: [EMAIL PROTECTED] Room: Salon 3, Tuesday April 12, 7pm to 8pm Site: Marriott Anaheim, 700 West Convention Way, Anaheim, CA 92802-3483. Within walking distance of Disneyland and California Adventure Parks. The 747 Simulator was a big hit at the recent SCALE3x expo held in Februrary. Integrating the best from the open source community with hardware has proved to be a daunting task. The author walks you through the steps and thinking behind the design decisions and details the integration of the hardware and software. Curt: Could you add this to the events page please ? Hi Alex, Do you have any details on the BOF meeting? Will they contact us? IDs/passes? Room facilities? A POC? Were you planning to present any materials? I'll be using my laptop connected to the projector. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flightgear and opengc data.hxx
Carlos Zaragoza Koblischek wrote: Hi all, As John W., I've downloaded the sources and compared the opengc_data.hxx in the two codes, and there are some parameters of the class ogcFGData in the FG side that are missing in the opengc source: int reserved; .. // position doubleelevation; .. // engine data doubleoil_temp[4]; doubleoil_quantity[4]; doublehyd_pressure[4]; ... // fuel system double main_tank; double tank[4]; With UDP the data packet should be read by opengc, but with the data structure mis-aligned the bits will not necessarily be reconstituted into the correct data variables and format One ploy you might try is to reduce the size of the data packet on both sides down to a few variables (say lat and lon) by editing the opengc_data.hxx files and see if the data channel is working. Use your favorite network tool to look at the traffic or dump/print out what FG is sending and OpenGC is receiving. The protocol is simple and straightforward and allows the user the flexibility to redefine the data structure on both ends of the interface I took a quick peek at the network code in OpenGC and it has been changed from the version I originally submitted. I'm not using it and have not had a chance to analyze exactly what was changed. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Some user-related devel topics
Carlos Zaragoza Koblischek wrote: 2. I tried to run opengc 0.54 and 0.56 with FG but it doesn't works. I configured FG to send the opengc data to the port 5800 of the opengc host in UDP. Is this an opengc problem or it is reported to work fine with FG under windows? Unfortunately, the interface between FG and OpenGC is most likely not in sync. I've not updated that code for almost a year. There have been major changes to the interface for the 747 Sim Project and I've intentionally not included those in either FG or OpenGC in order to reduce the impact to others. You might want to check the opengc_data.hxx file in both programs to see if the data packet is the same. And make certain the opengc.ini file has the correct address and port assignments. Are you running Linux or MS windows? If Linux, I might be able to help. 3. About the last question... It seems that some FG planes has better glass cockpit displays than opengc or others. I's possible to configure a FG client to render specific displays as opengc? I might argue that point :-) Take a peek at the 747 project page on the FG website... Regards John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speedbrakes/Spoilers
Hi, The aircraft file for the 747-100 provided by Jon for the SCALE3X expo does not contain a drag coeefficinet for the spoliers. I tried adding a value by copying that portion from the 737 xml file, but it does not appear to work. In that the value generated by the spoiler lever is passed from the 747 sim hardware to FG and on to JSBSim, but there is no visible effect on the airspeed. Tried tweaking the coefficient to a higher value, but still nothing. What did I miss? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
Jorge Van Hemelryck wrote: Have you been successful in implementing your asymmetric frustum hack ? It might be a good idea to add it to the official FlightGear code. It is one of the features that might fill in the gap between amateur flight simulation and a professional product. It might even be useful to have any arbitrary frustum, meaning that the screen could have any position with respect to the subject. The difficult part would then be to figure out which parameters to use. Maybe I could try and help with that. Actually, when I talked about FlightGear at work, our visual systems (screens, projectors, optical systems) specialist asked about asymmetric frustums right away. Not to mention projecting on a spherical surface, which would probably need work in the video board itself, not to mention the drivers and the software part (OpenGL doesn't do it yet, does it ?). For those who might have had trouble understanding (or explaining) what the problem was, I found a page a few weeks ago where it was put quite clearly: http://astronomy.swin.edu.au/~pbourke/projection/caev/ Yes, I think I was successful in adding support for asymmetric view frustums. It's a bit of a hack to get there, but the way I have set it up I think is slightly more intuitive than just passing l, r, t, b, n, f parameters to the glFrustum() function. For my specific need I wanted 3 monitors side by side in a straight line, and I wanted the projection plane to also be a straight line. So referencing your link, Example 1 is what we originally could do, but is not what I wanted. I wanted to do something similar to Example errr ... I guess there isn't an example on that page of what I wanted to do. Kind of like Example 5 I guess except with the red line (plane of projection) extending straight across. The center view frustum would be symmetic and the sides would be asymmetric. I realize this isn't correct but I need a compromise to build a display system that look reasonable from a large variety of perspectives at the same time. So anyway, here's my approach. Let's say I wanted 3 monitors, each covering 30 degrees FOV. 1. I added an --aspect-ratio-multipler=x.xx option. FG automatically calculates aspect ratio based on X, Y screen resolution. This option scales the Y FOV. 2. I created a super wide display with something like --fov=90 --aspect-ratio-multiplier=0.3 3. I added some options to select a portion of this wide screen to draw onto the individual monitor: --prop:/sim/current-view/frustum-left-pct=0.0 --prop:/sim/current-view/frustum-right-pct=0.33 This gives me the leftmost 1/3 of my wide (--fov=90) screen. And the aspect ratio multiplier option allows me to get the desired vertical field of view. I'm not sure that all makes sense. It is a little convoluted, but essentially it allows you to specify a larger symmetric frustum, and then select a portion of that to get your asymmetric frustum. Does this still require 3 machines to generate the views for each of the 3 monitors? And does each machine have to generate the full fov of all objects therein but only display the selected portion? A bit of a performace hit? A while back I set up a dual-headed video card to run two instances of FG on a P4 to create a left and right view and a single machine to generate the center view. I don't recall the specifics regards # of screen objects or other details other than it was KSFO. Peformance was not all that bad on the P4 machine -- around 20-25fps as I recall. Each FG instance had to calculate only the objects within the FOV defined by the frustrum -- a bit if an optimization there. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Camera/FOV/View Frustum question.
I should say though that most people will just want to point their displays perpendicular to the viewer and use a more standard/straightforward symetric view frustums. I had to do asymmetric view frustums for a particular project with specialized needs. We ended up with a combination of compromises that I wasn't entirely happy about. We were trying to achieve a middle of the road solution that wasn't perfect anywhere, but wasn't horrible anywhere either. Sounds kind of like the problem I'm facing with the left seat/right seat view perspective in the 747 simulator. Short of a fully collimated projection(s) and optics to handle a curved, wrap-around screen any solution will be a compromise. Understand there are electronics available to handle warping with CRT projectors by controlling the electron beam to handle frustum distortions and other projection artifacts. Have a feeling they're not cheap and probably some specialized software to handle all the geometry. Am I correct in understanding that the modified code has been added to CVS? Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear booth at Scale 3X
lol... I have a similar thought about the event. Nice simulator, pictures and videos, by the way. Actually, there were other interesting booths, the astronomy one was pretty nice and there was some good network stuff. but none as interactive as the FlightGear booth. I didn't have much time to explore as we were quite busy right up to the end. It was a fairly small show, nothing on the scale of a Linux World. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear booth at Scale 3X
Gotta love those credits at the end of the movie segment... I would like to also thank all who contributed to the show with their equipment, time, and support. It was a lot of work and a lot of fun and something I could not have accomplished alone. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
- Original Message - From: Frederic Bouvier [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Sunday, February 06, 2005 5:12 AM Subject: Re: [Flightgear-devel] SimGear CVS errors Perhaps John can enlight us on the system he use. My bet would be on cygwin looking the way the error was clipped. Debian with a Nvidia card and glut-3.7 which I thought included the gl extensions. I'll have to go back and review just what is on this machine. It's been a while since I messed with the configuration... Thanks John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear CVS errors
Hermann Schiffer wrote: I have the same problem on Debian. Theres two different glx.h residing on my system, one in /usr/include/GL and one in /usr/X11R6/include/GL. I tried several combinations of the two files in the two places, no luck though. On my debian system /usr/include/GL/glx.h is a link to /usr/X11R6/include/GL/glx.h -Fred I got it sorted: It seems like (on linux) the video driver comes with the GL(X) header files, in my case with an Nvidia card, I installed them using ' ./NVIDIA-Linux-x86-1.0-6629-pkg1.run --opengl-headers' : --opengl-headers Normally, installation does not install NVIDIA's OpenGL header files. This option enables installation of the NVIDIA OpenGL header files. This put the files in /usr/include/GL, but simgear picked them up from /usr/X11R6/include/GL, so i just copied glx.h and glxtokens.h (glxtokens.h is included by glx.h and contains the missing definitions). Not sure what other files are involved besides those two, but that did the trick for me so far. Hermann ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Yup, nicely done. worked here as well. Thanks John W ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Configure errors
Hi, boy, this is my day for weird errors.. Finished installing gcc-3.4.3 and downloaded latest CVS versions of SimGear, plib-1.8.4, and FlightGear Built and installed plib; no problems, but simgear configure reports wrong version when checking for plib-1.8.4 Okay, made sure there are no stale versions hanging around, cleaned out all libplib*.a files in /usr/lib and /usr/local/lib and rebuilt and reinstalled plib-1.8.4 simgear configure still reports wrong version. Copied all libplib*.a files to /usr/local/lib, same result tried ./configure --prefix=/usr/local and ./configure --exec_prefix=/usr/local and still failed. ./configure reports presence and usability of plib/ul.h. which, when examined, shows correct values for MAJOR, MINOR, and TINY Before I go and disable the test plib, thought to toss this up and see if anyone had any ideas why this is happening. Thinking it nust be some sort of path problem or environmental value, but I'm stumped Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] SimGear CVS errors
Started building a CVS version and bombed out in Simgear with the following: RenderTexture.cpp: In method `RenderTexture::Render RenderTexture.cpp:151: `GLX_RENDER_TYPE_SGIX' undec RenderTexture.cpp:151: (Each undeclared identifier RenderTexture.cpp:151: for each function it appears RenderTexture.cpp:152: `GLX_RGBA_BIT_SGIX' undeclar RenderTexture.cpp:153: `GLX_DRAWABLE_TYPE_SGIX' und RenderTexture.cpp:154: `GLX_PBUFFER_BIT_SGIX' undec RenderTexture.cpp: In method `bool RenderTexture::I RenderTexture.cpp:456: `GLXFBConfigSGIX' undeclared RenderTexture.cpp:456: `fbConfigs' undeclared (firs RenderTexture.cpp:460: implicit declaration of func RenderTexture.cpp:473: implicit declaration of func RenderTexture.cpp:480: implicit declaration of func RenderTexture.cpp:505: `GLX_WIDTH_SGIX' undeclared RenderTexture.cpp:506: implicit declaration of func RenderTexture.cpp:507: `GLX_HEIGHT_SGIX' undeclared RenderTexture.cpp: In method `bool RenderTexture::_ RenderTexture.cpp:611: implicit declaration of func RenderTexture.cpp: In method `bool RenderTexture::_ RenderTexture.cpp:1774: `GLX_SGIX_pbuffer' undeclar RenderTexture.cpp:1779: `GLX_SGIX_fbconfig' undecla make[2]: *** [RenderTexture.o] Error 1 make[1]: *** [install-recursive] Error 1 make: *** [install-recursive] Error 1 looks like a GL extension thingy for SGI machines. Any suggestions where to look or add or specify as an option or turn off Thanks John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI traffic heads-up
I'll try and make rudimentary parking.xml and rwyuse.xml files for KSFO later this week. I'll try and send you some documentation later today (and please send me a reminder in case I forget). Thanks, that will definitely help. Adding a even a few more aircraft will add to the ambiance of the scene. We'll also be demo'ing the festival synthetic voice system converting Dave's ATC transmissions into audio. That will also add to the immersion experience Thanks again John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI traffic heads-up
I'll try and post a few more screenshots on my website later week/weekend and expect to submit the code sometime next week. Just wondering what updates were included in the 0.9.8 release. We'll have a FlightGear booth at SCALE3x next week and would be nice to demo some of your excellent work. If you have the time and could crank out a short XML file that would be terrific. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear on IVAO
- Original Message - From: Martin Domig [EMAIL PROTECTED] To: flightgear-devel@flightgear.org Sent: Sunday, January 02, 2005 6:19 AM Subject: [Flightgear-devel] FlightGear on IVAO Hello IVAO is a very large, world wide multiplayer network of flight simulation enthusiasts that tries to provide a realistic environment for online flight simulation (check http://www.ivao.org for further details). Most IVAO users are using MS Flight Simulator, but the network supports a few other simulators and other platforms too. We would like to add FlightGear to the list. If anyone would like to write a program or plugin for FlightGear that would allow it to connect to IVAO, we would really apprechiate that and support the development as much as possible. Anyone interested? :o) You might want to browse the email archives starting in Sep 04 JW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Build on Cygwin
Hi, Could not find any info on the OpenAL website regards building the libraries on Cygwin. So tried the linux build. Well, it built, but thinking the install is suspect and Simgear complains as well. The headers are in /usr/local/include and the .a library is in /usr/local/lib along with a .dll file Any hints, info, suggestions on fixing the problem... Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Build on Cygwin
- Original Message - From: Norman Vine [EMAIL PROTECTED] To: FlightGear developers discussions flightgear-devel@flightgear.org Sent: Friday, December 31, 2004 8:09 AM Subject: RE: [Flightgear-devel] CVS Build on Cygwin attached find my home grown Makefile to use copy it into $OPENAL/win and excute make You will have to figure out how to install it dll(s) go into $BIN .a(s) go into $LIB $OPENAL/include/AL/*.* go into $INCLUDE/AL Okay, problem solved. Used the quicker version noted by Martin with built libraries. Need to download the DirectX SDK to get the header files like dsound.h to recompile. Do that later. Thanks John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Hi, Let us know what you come up with on the broadcast stuff. Regards, Curt. Was the broadcast fix included in the 0.9.8 pre-release? Recapping: plib expects the string to be broadcast in netsocket.cpp line#80; Simgear rejects either an explicit broadcast address xxx.xxx.xxx.255 or the above string, preferring broadcast which it dutifully passes on to plib which fails trying to resolve host named broadcast. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Curtis wrote: are special characters to the unix (and probably dos) shells. The shell will try to pass input from a file called broadcast as stdin to fgfs and send the output to whatever is after the . Try enclosing the entire option in double quotes to hide these characters from the shell interpreter ... fgfs --native-gui=socket,out,1,broadcast,5504,udp You *shouldn't* need these for options included in your .fgfsrc file. I'm not in a place where I can test if this actually works though ... Tried it, and the shell punted.. This aircraft model is a BETA release!!! This aircraft model probably will not fly as expected. Use this model for development purposes ONLY!!! --opengc=socket,out,32,broadcast,6000,udp: not found Using bash. Don't understand why pilb is coded in the manner it is, but I've hacked a patch into plib to just test for broadcast instead of broadcast and that works (at least for my purposes) Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS error msg
Curtis L. Olson wrote: John Wojnaroski wrote: Hi Curtis, When you have a moment. I may have sent this to you yesterday from one of my other machines, but can't find a copy. If a dup, my apologies. In file included from ../../src/Cockpit/panel.hxx:50, from ../../src/Cockpit/cockpit.hxx:36, from main.cxx:61: ../../src/Input/input.hxx: In method `const class SGPropertyNode * FGBinding::getArg()': ../../src/Input/input.hxx:123: warning: choosing `SGPropertyNode_ptr::operator SGPropertyNode *()' over `SGPropertyNode_ptr::operator const SGPropertyNode *() const' ../../src/Input/input.hxx:123: warning: for conversion from `SGPropertyNode_ptr' to `const SGPropertyNode *' ../../src/Input/input.hxx:123: warning: because conversion sequence for the argument is better main.cxx: In function `bool fgMainInit(int, char **)': main.cxx:759: assuming on overloaded member function make[2]: *** [main.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 Kind of lost on this one... Kind of lost on this one too ... I think this might be Andy Ross's code so he might be a good one to ask. What compiler version are you using? Curt. Running 2.95.4... Andy, if you're listening, any ideas. If this is due to using an older compiler, should there be a test in to check for that? Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Error?
Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Error?
That was it. The other modules explicitly call out the include directive and ifdef, but they appear to be excluded in the JSBSim files ? seems like something is missing/mis-set on my system , if others are not having this problem. At any rate, adding it in for the complaining files will work for the interim Thanks John W. Norman Vine wrote: #include stdio.h #if defined(WIN32) !defined(__CYGWIN__) #define snprintf _snprintf #endif -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Wojnaroski Sent: Friday, December 17, 2004 11:33 AM To: FlightGear developers discussions Subject: [Flightgear-devel] CVS Error? Hi, I may have posted this late last night, but seems to have been lost. If a duplicate post, my apologies Compiling the CVS pre-release error in FGNozzle.cxx complaining about snprintf as implicit declaration at line #74 Currently running 0.9.5 Did I miss something skipping over 0.9.6? Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Next error
Hi, back to main.cxx at line #759 in fgMainInit(...) main.cxx:759: assuming on overloaded member function Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS Build error
Hi, Building CVs pre-release: FGNozzle.cpp:74: implicit declaration of function 'int JSBSim::snprintf(...)' what's missing? library? upgrade compiler? still running with 2.95.4 Moving up from 0.9.5 which works fine, skipped 0.9.6. Did I miss something that happened in 0.9.6? Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
But when it comes to flaps, slats, and speed brakes it's not nearly so simple. There, normalized values make a lot of sense. But then to follow along with the logic, do we want to output our control surface positions in one consistent way, or do we want to mix and match units, and if we do, what if we come across some oddball aircraft where the control surface angle is a completely non-sensical concept? And then there are slats that deploy as a function of airspeed/AOA; e.g; Sabreliners Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] control surface normalization
- Original Message - From: Jon S Berndt [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, December 15, 2004 11:30 AM Subject: Re: [Flightgear-devel] control surface normalization On Wed, 15 Dec 2004 11:16:32 -0800 John Wojnaroski [EMAIL PROTECTED] wrote: And then there are slats that deploy as a function of airspeed/AOA; e.g; Sabreliners This is irrelevant, also - at least for JSBSim. In this case, the slats would be automatically deployed as directed by the flight control system control laws, and the actual position would be referenced by degrees. Not quite, these slats are air-loaded; i.e, there is no mechanical, hydraulic, or electrical actuation of the slats. There is no command or logic in the FCS, air data computer, or crew activation to extend the slats. Part of the walk-around is to physically push the slats up and see that they drop freely. I don't think there are any aircraft currently modeled that have this sort of slat system, so the point may be mute. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
- Original Message - From: John Wojnaroski [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Sunday, December 12, 2004 5:43 PM Subject: Re: [Flightgear-devel] Broadcast Address Curtis Olson wrote: Let us know what you come up with on the broadcast stuff. Regards, Curt. Okay, here's the answer... In plib line #80 Ooops, that's line #80 in netsocket.cpp JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Curtis Olson wrote: Let us know what you come up with on the broadcast stuff. Regards, Curt. Okay, here's the answer... In plib line #80 if (host[0] == '' strcmp(host, broadcast) == 0) sin_addr = INADDR_BROADCAST; expects the string argument as noted above. There does not appear to be any option to set the address expicitly, as in 192.168.2.255, which results in an error and program termination. SimGear expects the string argument to be broadcast and passes that on to plib. If you try to set the string in the command option; e.g. native-fdm=socket,32,broadcast,6000,udp then FG/SimGear complains and exits. So the fix can be in either place, change SimGear to pass the string as required or change plib to if ( strcmp(host, broadcast) ==0) you make the call Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
- Original Message - From: Steven Beeckman [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, December 10, 2004 2:08 PM Subject: Re: [Flightgear-devel] Broadcast Address Citeren John Wojnaroski [EMAIL PROTECTED]: I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. I'd like to mention RTAI (http://www.rtai.org), a Linux kernel patch to get the kernel working in real-time (even hard real-time!). RTAI is open source too, and even GPL if I remember correctly. I don't know how it fits with opengc, as I haven't found much info on the linux-port of OpenGC (which actually looks very interesting to me :-D). There is also http://www.rtlinux.org which links over to http://www.fsmlabs.com/ which has a version and source with a GPL license. Without going into a long recap of the history, there was a earlier version of OpenGC that ran under Linux that was my child. A few years back Damion made some major changes to the project and licensing to allow for commercial use in experimental aircraft. Something I was (am not) too keen on and that software was removed. For some pics of OpenGC running with FlightGear browse over to the Project page on the FG website. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RT Linux
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, December 10, 2004 1:35 PM Subject: Re: [Flightgear-devel] Broadcast Address RTLinux might give you some additional fine grained timing tools to throw at the problem, but it's still a hard problem. You still have to detect a situation where you aren't going to finish drawing in time, reliably identify the reason you aren't finishing in time (fill rate? too much geometry? texture thrashing? running 3 other apps in the background on the machine?) and come up with some way to resolve the problem ... are you going to draw less geometry? Pull in the far clip plane, go to a lower LOD on some of your objects (which ones?) Your solution needs to directly address the cause of the problem our your fix might not help you. In practice you can probably find some trends and narrow the problem scope significantly, but it's still not easy. The motivation to try RTLinux is related more to the control/feedback problem than any graphics issues. What has been achieved running FG on off-the-self commodity PCs is remarkable. The problems/issues with glass displays are trivial by comparison. ATM the FG data rate is set at 30Hz in both directions using sockets configured for non-blocking udp datagrams. Since the nominal display rate is around 100fps for each opengc machine, they have no problem gobbling up all the packets. Conversely, the FMC is running as part of the display graph and pumping out udp control packets at whatever rate the opengc code is cycling. And the sim displays are simply exchanging data by sending out udp packets in a similar manner. All very simple, very messy, and very unorganized. How that impacts the control loops, gains, and responses to control commands is a big TBD. What has been happening is as the FG data rate is increased to say 45Hz, some latency has been creeping into the displays resulting in CIOs (computer-induced-oscillations) with the flight control system when the display rate drops due to increased number crunching and/or symbol generation and a higher rate of data exchange across the sim machines Thinking if I can broadcast a small timing packet or the data packet itself from FG and use that as a sync pulse for each machine on the sim side. Now each of those machines can begin processing for the current frame, exchange whatever state data for the current frame, and return required control commands before the start of the next frame or at least raise a flag if there is any frame slippage. Result is a more deterministic system sync'd to the FG cycle. Of course, still need to understand how and when FG and JSBSim exchange data across the property system(s). Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
Let us know what you come up with on the broadcast stuff. Regards, Curt. I will do that... Your short discussion on timing brought to mind an interesting question. Since there is some unpredictability to the scheduling algorithms and device drivers and system calls, can the 60Hz rate really be locked. Short of going to a real-time OS like RTLinux, is this a case of where getting close is good enough... I've been thinking of moving over to RTLinux (there is an open-source GPL'd version) in 2005. It fits nicely with the structure of the opengc display code. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Broadcast Address
John, I seem to recall having this working once. There is an extra flag you have to enable on the socket to make it actually broadcast. Yes, that jogs the ole' brain cells. (See Unix Network Programming, H.R.Stevens, page 318) I don't recall if this had to be enabled at the plib level or the simgear level? I seem to recall it was working for a while and then didn't work, but I haven't looked into it for a year or two. plib's net libs are a bit strange. They seem to tickle a dns lookup even for local ip address connections. I haven't been able to figure that one out ... it's ok if you don't have a dns server configured, but can be an annoyance if you are configured to auto-dial on any net activity. For some reason it seemed like the workingness of broadcast was tied to dns availability or something ... but I'm grasping at fading memories here so I could be way off. Curt. Thanks, that helps -- guess I'll dig around in the plib and Simgear code Part of the question also relates to any penalty imposed on the FG frame rate by adding multiple socket options for each IP address and unique port. Any SWAG on the percentage for each additional socket? linear, geometric, exponential? Or is it in the noise? Given that the current data packet is about 700 bytes, the LAN is a long way from any performance limits, at least for datagrams. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: OT: Another FGFS PPL :-D
- Original Message - From: Ampere K. Hardraade [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, November 15, 2004 9:48 PM Subject: Re: [Flightgear-devel] Re: OT: Another FGFS PPL :-D Speaking of multiplayer support, whatever happened to the online ATC thing? There is a website http://openatc.sourceforge.net that has a draft document compiled by Boris that contains the collective musings of us all on the subject and starts defining a protocol. Plus some source using the TNL libraries for running a field test. There are some cross-platform issues due to a small amount of assembly code used to handle RPCs that are platform specific. Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cloud Rendering
Paul Kahler wrote: Has anyone looked into better cloud rendering in FGFS? There was some great work done by Mark Harris for his Ph.D. over at: http://www.markmark.net/ I couldn't remember his name, so I googled for 'cloud rendering' and his site was at the top of the list. It looks really impressive, and similar to something I saw in a Game Developer article by a MSFS guy. Mark provides source code under a free license. If that's not GPL compatible enough, perhaps someone could work out something with him for FGFS? It's just an integration problem right? ;-) Sort of... I cobbled a version for FG (with the help of Mark and Curtis) as a demo. It needs a bit of work .. ;-) See the clouds3d directory in SimGear. Mark's thesis and approach needs to be extracted and rebuilt into the FG scene graph structure. Rather than trying to patch what is there, it might be more appropriate to rework the entire cloud subsystem using Mark's algorithms. You can view the clouds by compiling in the FG code ( FG_USING_CLOUDS_3D ) and then --enable-clouds3d as an fgfs option Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiheaded video cards?
- Original Message - From: Curtis L. Olson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 10:37 AM Subject: [Flightgear-devel] Multiheaded video cards? I periodically get asked about multiheaded video cards for FlightGear. My standard answer is that I don't know for sure, but I suspect they wouldn't work well for FlightGear. However, the questions keep coming and I feel like I'm not able to give a really good answer. So can anyone help me out? For instance, has anyone tried one of these sorts of cards? http://www.matrox.com/mga/products/parhelia/series.cfm What kind of opengl support is available under linux? The displays on the 747 sim use GeForce 5200 multiheaded displays. Nvidia provides an XF86Config file that is just about plug and play for driving two monitors. As near as I can tell the opengl support is just fine, define the screen size to your taste (like 2048 x 768) and the hardware does the rest. For my displays that works great for positioning the PFD/ND/EICAS/ etc onto the flightdeck. Has anyone played around with any of these options who can report success or failure or something in between? What kind of performance are you getting? A while back I set up FlightGear on two machines where the master ran one copy of fgfs and used the network stuff to send data to the second machine with two distinct socket address that connected to the two slaved versions of fgfs with the view for the left monitor offset 55 degrees lect and the right monitor view offset to the right. I did not do any exhaustive testing or frame rate analysis based on what was being depicted. As I recall it was a bare KSFO field with most of the options like random objects, clouds, etc turned off. Can't remember the fps on the main but the two slaves fgfs's (running on a P4, 2.8Ghz, 512M memory) clocked around 26-30fps. And did not spend any time trying to analyze the geometry or rendering math to determine any distortions if you tried to stretch a 55 degree FOV over two monitors or the increased distortion away from the center if you changed the value to 110 degrees Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Quick report from AOPA
Curtis Olson wrote: John Wojnaroski stopped by and it was good to finally meet him. I went out to his place today in LA to see the 747 sim he is building in his living room. snip Another thing that a *lot* of people asked about was glass cockpits. John W. has done some really good work on this front for his 747 project, but it is kind of isolated and specific to his system. So this is another area where there is a lot of interest, but FG is a bit weak. Not to be defensive, but Curt and I discussed this briefly. High end aircraft, like the 747, have countless subsystems that are type specific and it's really hard to build something this complex with the one-size-fits-all approach and hope that things like XML and Nasal can handle any and all configs. Secondly, it will require more than one machine for a decent system; there is just soo much you can stuff into a five pound bag. FG used as a sim engine has no peers, but there are limits BTW, it's not the living room, ;-) I was going to use one of the guest bedrooms, but the icy stare that suggestion received quickly squelched that plan and I meekly settled for a corner in the upstairs loft over the garage. The up side is it has enough room and size to put in a reasonable projection system. And it was a pleasure to meet and chat with the father of FG. Curt and the folks at ATC have a very nice product for pilots interested in training and maintaining proficiency on instruments. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Saturday, October 09, 2004 3:41 AM Subject: Re: [Flightgear-devel] Buildiing/running the ATC network test OK, I had chance to have a look at configure.in and removed the section causing the problem - I've got the binaries built now, all start up ok, but the master segfaults when a pilot or controller connects: Starting program: /archive/Mirror/flightgear/OpenATC/ATC-0.1/src/Master/master [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 11705)] Socket created - bound to address: IP:Any:29002 UDP receive buffer size set to 32768. UDP send buffer size set to 32768. UDP socket non-blocking IO set. UDP socket initialized. Master Server created - listening on port 29002 Then you start the client: Pilot started - master is at IP:192.168.127.5:29002. Socket created - bound to address: IP:Any:32770 UDP receive buffer size set to 32768. UDP send buffer size set to 32768. UDP socket non-blocking IO set. UDP socket initialized. Connecting to master server at IP:192.168.127.5:29002 Client puzzle solved in 147 ms. And the master falls over: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 11705)] 0x080a3e68 in ?? () (gdb) bt #0 0x080a3e68 in ?? () #1 0x400e0974 in __dynamic_cast (from=0x80a3e68, to=0x807b740 typeinfo for TNL::Object, require_public=134723644, address=0x0, sub=0xbfffefb8, subptr=0x4000a490) at ../../gcc-2.95.3/gcc/cp/tinfo2.cc:282 #2 0x08056613 in TNL::NetConnectionRep::create ( name=0xbfffeb80 MasterServerConnection) at netConnection.cpp:50 #3 0x0805c458 in TNL::NetInterface::handleConnectRequest (this=0x809a520, [EMAIL PROTECTED], stream=0xb030) at netInterface.cpp:762 #4 0x0805b11f in TNL::NetInterface::processPacket (this=0x809a520, [EMAIL PROTECTED], pStream=0xb030) at netInterface.cpp:462 #5 0x0805affb in TNL::NetInterface::checkIncomingPackets (this=0x809a520) at netInterface.cpp:422 #6 0x08049cc6 in main (argc=1, argv=0xb7f4) at main.cpp:667 (gdb) Quite honestly, we ( I ) don't fully understand all the internals and detailed workings of the TNL libraries and protocols. Where it fails is clear, why is the question? I have had the master node running and have been able to connect in all four net configs --- internal on the same machine with 127.0.0.1, across a LAN with 192.168.xxx.xxx, across the Internet to 216.86.210.202, or on the same machine using either its LAN or internet IP address. ATM I don't have an answer for you and have been unable to duplicate the problem on my systems. Bummer... Once I get the server set up for the field test later today, I'll get back on this problem and try to find an answer for you. BTW, for those participating in the test later today, you can run multiple instance of the controllers and pilots which will help to increase the traffic load on the master server as nodes connect/disconnect and reconnect. The more, the merrier... Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] another vivid example for the guru syndrome :-]
Curtis L. Olson wrote: If someone wants to fund me full time to do FlightGear development and project management, I'm certain I could be orders of magnitude more responsive. add my name to the list ;-) okay, I'll be updating the tar files for OpenATC field test to enable the security features and data encryption and I'm trying to clean up those make files. If you are thinking of joining in, you might want to download the tar files and have a go at the build. Boris is also working on a few changes and cleaning up the make. The net is full of nasty (expletive deleted) looking for opportunities to hack into you system for whatever reason. Since we're not using any sort of versioning or CVS control for this quick and dirty test, you might consider the next point to check you have the correct software. If you do plan to participate, please look in the TNL library at the netConnection.cpp module at line #778 for two logprintf statements and in the controller and pilot programs around line #455, you should see the following: gMasterServerConnection-connect(theInterface, masterAddress, true, true); the last two boolean arguments turn on the security stuff and at line #307 or so in the RPC m2cArrange ConnectAccepted() conn-connectArranged(getInterface(), fullPossibleAddresses, nonce, serverNonce, theSharedData,true, true, true); The OpenTNL library has a some problems that need work to improve it's portability, but as far as the design. capabilites, and implementation it's about as good as it gets in the open-source world. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
Hi But even then it won't compile on Solaris/Sparc: Just upgraded to GCC-3.4.2 and it fumed and fussed trying to build the TNL library on my P4. So it's not all Solaris/Sparc... Don't have time left today to work it further, will have a go at it tommorrow Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
BTW, what is the relation between the files you placed on OpenATC and the OpenTNL project ? From there I could download only a '1.4.0rc4' source code package, the version on OpenATC carries the version 1.4 and the OpenTNL website claims they already reached version 1.4.3. All this doesn't fit together, The openTNL headers/library sources on openatc.sf.net/test are merely a downstripped/reduced version of the actual sources, simply because John figured we wouldn't need most of the stuff ... There was an update to OpenTNL at the end of September. The version currently used by ATC-0.1 is the 1.4.0 version prior to that update. The latest tagged revision, identified as HEAD, is the 1.4.3 version and it appears there are some binary files of the demo game zap tagged as 1.4.3. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] File names?
Hmmm Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
Fred wrote: John Wojnaroski wrote: Does anyone have a favorite network utility/packet sniffer? I'm looking at sniffit from the Debian package, but not all that happy with it. Ethereal but only on packets that transit through an ethernet card ( doesn't work on the loopback or on serial ppp ) neither does sniffit... trying to run some tests internally before going out on the Internet or a LAN Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] File names?
- Original Message - From: Boris Koenig [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Wednesday, October 06, 2004 10:01 AM Subject: Re: [Flightgear-devel] File names? Martin Spott wrote: John Wojnaroski wrote: Hope this hasn't confused anyone. There is a file on the SF page called tnl_head.tgz. This is a tar file of the header files for the network test build. it is NOT the tar file tagged as *HEAD* on the OpenTNL website. That's pretty clear. I'm mostly confused because OpenTNL apparently doesn't meet the conventions of FlightGear concerning portability, Yes, it looks somewhat problematic right now, but otherwise it's not yet really a problem, as there hasn't been much code written as of now - we might have to check other open source multiplayer/networking libraries out, though. Suggest we take the positive road and make it work. From my perspective it looks d--- good and since it is open-source as well perhaps the TNL folks would be willing to work with us. But when it comes to cross-platform issues, I'll defer to the experts. There was an attempt to make FG multi-player, but that seems to have receded. I think the TNL library has a better foundation and capabilities... Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 3:37 AM Subject: Re: [Flightgear-devel] ATC Network Test I'd be happy to help test it. Okay, let's tentatively plan for this weekend, it should be a fairly quick test. A master node will be available from 0900GMT to 1200GMT on 9 OCT 2004 at 216.86.210.202:29002. To run the master node requires a static IP and a broadband (DSL or higher) connection. If anyone would like to run as a master node we'll need info as to the IP address and a time slot when the master will be active. ATM there is no capability to share/exchange data between master server nodes. Again, I want to emphasize, this is a very rudimentary test using the TNL libraries and protocols. One of the objectives is to just see if it will work over long-haul networks. Realize some prefer not to reveal their private email address, so it probably makes sense to just upload the files to the SF site Boris established. Best guess, is check the site Wednesday and that will allow a few days to build and play with it. You can run an internal test using 127.0.0.1:29002 on a single machine or on a LAN. Regards JohnW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ATC Network Test
A quick disclaimer ;-) I'm no make wizard. It's basically a clone. In particular you will have to manually install the TNL headers files. Either in /usr/include/tnl and usr/include/tnl/encrypt or location of your choice and modify the Makefile files accordingly. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
Martin Spott wrote: John Wojnaroski wrote: To run the master node requires a static IP and a broadband (DSL or higher) connection. If anyone would like to run as a master node we'll need info as to the IP address and a time slot when the master will be active. If it compiles on Solaris, I'd be able to provide a server for that with enough bandwidth for several clients, Martin. Boris is editing the make files at this time to clean up some of my goofs. Once their uploaded give it a go. I'll post some notes on setting up. Good luck John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Buildiing/running the ATC network test
Hi, For those who expressed an interest in participating in the network test this weekend: After downloading the two tiles from SF, untar them in /usr/local/src/ and that will create two directories as ATC-0.1 and TNL-1.4. Note: For now, you will have to install the TNL headers files by hand: the following script should work #!/bin/bash cd /usr/include mkdir tnl cd tnl mkdir encrypt mkdir master cd /usr/local/src/TNL-0.1/src/encrypt cp *.h /usr/include/tnl/encrypt/ cd ../master cp *.h /usr/include/tnl/master cd ../tnl cp *.h /usr/include/tnl/ ## end of script Build the TNL libraries first which should produce three static libraries (libtnl.a, libencrypt.a and libatcmaster.a) which will be installed in /usr/local/lib/ Next build the libraries, the configure.in file conatains a lot of cruft used for plib/SimGear. We might wind up using some of that but for now Boris is working on a simpler version. If plib and Simgear is on your system you can use the *big* version. Next go to the ATC directory /usr/local/src/ATC-0.1 and build and install. Again, depending on your system configurations you can try aclocal automake autoconf ./configure make make install This will produce three binary applications ( master, controller, node ) located in /usr/local/bin. To run as a master simply type master at the commad prompt after checking that there is a small master.cfg file located in the same directory as the binary. To run as a controller or pilot you can enter the following commad controller IP_ADDRESS_MASTER:PORT or pilot IP_ADDRESS_MASTER:PORT The address(s) fo the master nodes will be posted on the OpenATC site http://openatc.sourceforge.net/test/ Again, don't expect anything dramatic or earth-moving, but hope you can join use ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Buildiing/running the ATC network test
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 1:48 PM Subject: Re: [Flightgear-devel] Buildiing/running the ATC network test John Wojnaroski wrote: Build the TNL libraries first which should produce three static libraries (libtnl.a, libencrypt.a and libatcmaster.a) which will be installed in /usr/local/lib/ Built, although I had to build libencrypt.a by running make in its own directory rather than at the top level. Yes, my fault. Just grabbed what was already there... should have mention that in the build notes I'll add that to the build notes and/or redo the makefile to work with configure.in. Thanks. Next build the libraries, the configure.in file conatains a lot of cruft used for plib/SimGear. We might wind up using some of that but for now Boris is working on a simpler version. If plib and Simgear is on your system you can use the *big* version. All there already - I just pointed configure to the correct paths. Next go to the ATC directory /usr/local/src/ATC-0.1 and build and install. Again, depending on your system configurations you can try aclocal automake autoconf ./configure I think I'm a victim of some of that cruft - configure is failing here with: configure: error: conditional ENABLE_XMESA_FX was never defined. Usually this means the macro was only invoked conditionally. Yes, more and likely. ATM there is no need for any sort of opengl library or graphics capability or plib/Simgear. Odds are some of those libraries will be used but you can comment all that stuff out for now. Plus there may be some macros or other things that happen between aclocal_to_make that I (quite honestly) don't fully understand. So things work on my system and may fail on others. When and if this becomes a living, breathing project all those items need to be dealt with and cleaned up Regards John W. P.S. Hope to have an update or two before the field test. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ATC Bug #1
Okay, see a small problem on deleting nodes that drop off the net. Seems the linked list shows one controller left even after all nodes have dropped off. A pilot node requesting an arranged connection will wait a very, very long time rather than a no controllers available msg. Small change to the login command string, one may now specify controller name and type Syntax is : controller addess:port [name] [facility] as in controller IP_ADDRESS:PORT Oakland Approach or controller IP_ADDRESS:PORT Miami Tower Use single word tokens, spaces are token breaks. No entries defaults to first example Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] ATC Network Test
A few details... Volunteers will get a package of software that contains the TNL libraries and a basic set of software to connect to the ATC net as a controller or pilot. Package will include ALL source code and make files for a Linux system. Sorry, I'm just not an MS type. However, it will build under Cygwin. Building will create two application programs --- controller and pilot During the time window for the test you can login to the master as a pilot or controller as in controller IP_address_TBS:port or pilot IP_address_TBS:port Both values to be provided at the time of the test... As a controller node, initially login will be ack'ed by the master and the node added to the master list. Loggin in as a pilot node (assuming a controller node is present) will receive a list of controller nodes from the master, at which point a controller node is selected from the list and a request is made to the master to arramge a connection with the selected controller. (NOTE: Current selection is random, scope criteria are TBS). Once the connection is accepted the controller and pilot exchange a string of secret data. After about 30-40 secs the connection will be broken by either node and a reconnect may or may not be attempted (Again a random event at this time to keep things somewhat dynamic and unpredictable) Test objectives are simple: 1) test network loading on the server 2) determine latencies issues 3) test robustness of master server and protocol for error recovery 4) identify/motivate interested participents as future developers and/or players 5) create a forum for ideas For example, it would be possible using FG with a view position from the tower to connect several flights from friends and observe their performance while doing circuits and act as the tower controller... Of course, that idea needs a bit more thought and probably a lot more development, but it is doable. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
- Original Message - From: Boris Koenig [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, October 04, 2004 1:46 PM Subject: Re: [Flightgear-devel] ATC Network Test Arnt Karlsen wrote: On Mon, 04 Oct 2004 11:17:07 -0700, John wrote in message [EMAIL PROTECTED]: A few details... Volunteers will get a package of software that contains the TNL libraries and a basic set of software to connect to the ATC net as a controller or pilot. Package will include ALL source code and make files for a Linux system. Sorry, I'm just not an MS type. However, it will build under Cygwin. ..GPL? Url? it's GPL. I still have a little work to do to create a clean build and install as well as reducing the size by including only the essential library files. TNL did a great job of creating docs and sample programs, but they tend to bloat the package and create unnecessary build issues. John isn't yet 'releasing' anything, rather he asks for people who would be willing to participate in some field tests. Boris is correct, not so much a release as a head count, but I'll probably upload it to the ftp server at kingmont or I might just set up a machine locally that I plan to also use as the master Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [OpenATC] Re: status
You might want to go to the TNL website (www.opentnl.org) and most of those questions are answered in the docs. There are error/fault recovery procedures to handle such things and its just a question of how robust we want to make the network. And that depends, in part, on the size and interest of the community to support on-going development and operations. Few users -- forget it!!! Lots of players, heavy net traffic -- we make it industrial strength!!! Regards John W. - Original Message - From: Ampere K. Hardraade [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Saturday, October 02, 2004 10:51 PM Subject: Re: [Flightgear-devel] Re: [OpenATC] Re: status Here are a few questions: What will happen if the ATC is disconnected? What sort of redundancies do you have in mind? Who will handle all the traffic when no one is the ATC? How does a client knows about the location of other clients? Will the ATC be the server in this case or will the clients be able to communicate with each other directly? What will happen if a pilot is disconneted due to a computer crashed or seg-fault? Should the aircraft be blinked out, or should the pilot be able to log into the network again to continue the flight? Assuming that each aircraft only has one crew, and that he/she can reconnect to the system to continue the flight after a disconnection, what will happen if the pilot gets disconnected during a take off/landing? Should the aircraft automatically abort the procedure or should a computer from somewhere handle the rest? Ampere On October 3, 2004 12:53 am, John Wojnaroski wrote: Well, there has been some progress on implementing an OpenATC protocol based on the tnl library. Putting together a package that will create applications for master server nodes, controller nodes, and pilot nodes. If your comfortable with the FG/SimGear directory structure and build process you should feel right at home with this package. ATM controller nodes announce their presence on the net to the master server which acknowledges their presence and logs them into the controller list. A pilot node request service from the master server by announcing a set of parameters( location, freqs, callsign, etc) and the master determines based on TBD criteria which controller node on the list has control. And establishes a two-way link for the pilot/controller pair, updates the log/connectivity/whatever tables. The master bows out and the pilot/controller pair now directly exchange data as required (for now, this is just a bunch of nonsense encrypted data, although the hooks are there to get FG data). There is nothing on the controller end that knows what to do with the data. We're still a long way from a functional system, but it looks like the underlying backbone network stuff will work. To that end I'm thinking of setting up a limited network test to watch the whole thing come crashing down ;-). Actually, I've brought up the network using a couple of IP addresses I control and several internal machines on a LAN. The protocols provide for a reasonably good level of security and will allow cooperating nodes to connect from behind firewalls and NATs in a secure manner. It needs a bit more work to make it look more ATC'ish, but it might be time for a proof-of-concept. So looking for a few good volunteers to act as pilots and controllers. Will need to work out the details of how, when, who, and what... Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [OpenATC] Re: status
Well, there has been some progress on implementing an OpenATC protocol based on the tnl library. Putting together a package that will create applications for master server nodes, controller nodes, and pilot nodes. If your comfortable with the FG/SimGear directory structure and build process you should feel right at home with this package. ATM controller nodes announce their presence on the net to the master server which acknowledges their presence and logs them into the controller list. A pilot node request service from the master server by announcing a set of parameters( location, freqs, callsign, etc) and the master determines based on TBD criteria which controller node on the list has control. And establishes a two-way link for the pilot/controller pair, updates the log/connectivity/whatever tables. The master bows out and the pilot/controller pair now directly exchange data as required (for now, this is just a bunch of nonsense encrypted data, although the hooks are there to get FG data). There is nothing on the controller end that knows what to do with the data. We're still a long way from a functional system, but it looks like the underlying backbone network stuff will work. To that end I'm thinking of setting up a limited network test to watch the whole thing come crashing down ;-). Actually, I've brought up the network using a couple of IP addresses I control and several internal machines on a LAN. The protocols provide for a reasonably good level of security and will allow cooperating nodes to connect from behind firewalls and NATs in a secure manner. It needs a bit more work to make it look more ATC'ish, but it might be time for a proof-of-concept. So looking for a few good volunteers to act as pilots and controllers. Will need to work out the details of how, when, who, and what... Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
Boris Koenig wrote: John Wojnaroski wrote: Will FlightGear provide a pilot entity, controller entity, or both? This is what I would PERSONALLY consider reasonable: 1) make FG export the necessary data from its property tree 2) interface FG with the network(s) - so that the flights show up on *normal* (already available) VATSIM/IVAO clients 3) incorporate a cross-platform VoIP tool, this would not need to be compiled by default, but should rather be optional = so far this is step #1 Accomplishing step #1 probably provides all that FG pilots would require. The third part (Voice IP) would obviate the need for ASR/TTS while working with carbon-based units. I'm guessing but would imagine that the protocol would entail some sort of initial handshake to establish FG on the network, initialization to establish location/state, and a set of data structures/classes laying out the number and order of data bytes. At this point we would already be able to use FlightGear with (one of) the major network(s) The rest might be optional, dependent on the level of interest regarding controllers (either carbon or silicon based) 4) think about implementing a cross-platform ATC client, possibly based on 'xatc' At this point one would also have the possibility to attract users of other platforms to the whole ATC thing And then there's of course still the possibility, to 5) think about ways to add TTS/ARS capabilities With a functional VoIP, this might only be required for AI controllers... These would not need to be directly linked to any of the networks, but it would certainly be interesting to be able to: 6) mix virtual 'real' controllers and AI controllers. But, I think it's still quite a task ... The needs are driven in large part by the scope of operations the individual wishes to perform -- from a few circuits around the local airfield, a short flight with the family to visit the grandparents, an IFR cross-county, a commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL... As you already mentioned, it would indeed be quite attractive to have an AI available, that can deal with the 'pilots' as they wish ... so, no need to really have people available who really do the controlling part in realtime. And there are portions of the ATC function that might be more amenable to automation -- issuing and validating clearance readbacks, ARTCC enroute facilities, ground operations, departure control -- while the most complex and intensive task, approach control/ tower, would be performed by live controllers. I like the idea of AI controllers in that one can also practice off-line, off-net ... Hence, it would probably be a better idea, to run the TTS/ASR locally on most FG machines, and simply transmit the actual ATC instructions to the AI part ? That was the direction I was going... The ASR converts the audio to text on the local machine and transmits text. The local machine can be trainedfor the individual(s) and with a little error checking for phrases and syntax send out a clean. correct text msg. Again this would only be required if the receiving entity was an AI type controller or was not VoIP capable, in which case either a text msg is displayed or synthized into acoustical speech via TTS. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
Arnt Karlsen wrote: ..what do we have right now? FG can be rigged to run as an ATC World Server now, right? We have xatc as a viable client to that FG ATC World Server, we have FG itself, so we need to come up a protocol to help the other people squak FlightGearese, what else did I miss here? ..FlightGear ATC World Animation Server = FATWA Server? ;-) Probably what FG is missing is a critical mass of players/developers... ATM VATSIM is running an event in SoCal with 24 controllers and 88 flights as of 08:15Z I'm all for trying it. And it will take some time to build up a following. At a minimum we will need a handful of dedicated volunteers who have experience as professional pilots and controllers or a working knowledge of ATC rules and procedures to act as experts and mentors for the rest of us. I'll be at the exit; so as you leave, if you would like to leave your name and telephone number we'll be in touch ;-) Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Torque Network Library
On Saturday 25 September 2004 21:53, Boris Koenig wrote: I think, mainly developers, testers, and security people would need to be available, as well as developers that can do cross-platform development using low-level networking libraries. Of course, one might indeed look for an opensource library that serves as an abstraction layer for the whole OS specific part. What do you think about this open source network library: http://www.opentnl.org/ http://sourceforge.net/forum/forum.php?forum_id=369903 It is a library created from the network code of the Torque Engine. The Torgue Engine was used by the famous and commercial multiplayer game Tribes 2 and this game had one of the best network codes out there for games and simulations. TheTorque Network Library is available under 3 licenses, one of them is the GPL, so it would be a library we could use for Flightgear. I like it... At first glance, the documentation is excellent. But we still need some form of a document that specifies a basic network architecture and protocol. I'll play with it the next few days. Regards John W. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight)
- Original Message - From: Boris Koenig [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, September 24, 2004 2:06 PM Subject: Re: [Flightgear-devel] IVAO vs. VATSIM (get it straight) Another thing: As I seem to be the only one so far, who's got in touch with them, I would not mind continuing the exchange to a point where things get specific, but I would appreciate some help concerning the things that we should get straight with them - I mean, I have already asked quite some stuff, but everybody has probably his/her own imaginations regarding a possible collaboration, so what I brought up so far is certainly far from complete, e.g.: - protocol should be open (?) - cross platform software - integration of VoIp software (?) ... ... So, why not collect these things and discuss the needs of the FlightGear project ? Will FlightGear provide a pilot entity, controller entity, or both? The needs are driven in large part by the scope of operations the individual wishes to perform -- from a few circuits around the local airfield, a short flight with the family to visit the grandparents, an IFR cross-county, a commercial 737 from KLAX to KDEN, a 747 flight from KJFK to EGLL... That way we can also determine what's acceptable and what's not. As soon as these things are clear, we'll see their *real* ;-) attitude. By all means, keep the dialogue open... As to the three points: 1) the protocol has to be open. Security should not be an issue, if it is then there is something wrong with the design and/or implementation 2) the protocol should be platform neutral (although there might be some issues with # of bytes for data type and big endian/little endian). 3) probably need both live voice and an ASR/TTS capability to handle a mix of live and AI controllers. If we ever get to the point that the AI controllers can pass the Turing test maybe we can shoot the live controllers ;-) or at least provide a more robust expanded controller population This almost begs to be a separate project under the FlightGear umbrella (aka JSBSim). It would not be all that hard to write a network module to output FG parameters -- there is a plethora of protocols defined in ../src/Networks adding one more won't cost that much. The AI/ATC module is another bigger question, and we need to hear from the author. it would also be interesting to hear how the virtual ATC community feels about the idea of mixing AI and live controllers. This would also complicate the protocol to some degree Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fw: Voice stuff (sans attached)
FYI if anyone wants the files (about 200k) give a holler you can run the whole mess on a single machine along with FG. The hit to the frame rate is TBD. - Original Message - From: John Wojnaroski [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 21, 2004 9:44 AM Subject: Voice stuff Hi David, Attached are two files: comm_747 is a really bad hack for the CMU Sphinx ASR engine to create a text string and sent it out on the network to the atc_server voice.tgz is more hacking to send a text string to the festival server.. lines 73 to 76 is my highly sophisticated AI /ATC controller ;-) it untars as /Voice You can run festival as a server ../bin/festival --server on the same machine you run atc_net_demo and the audio will be produced on that machine or you can uncomment lines 295-309 and also send a .wav file back to the client machine. A quick recap: Machine #1 runs sphinx2 which receives the audio input from the user, converts it to text and sends it over to Machine #2 which parses the text string into tokens and does it's AI/ATC stuff, formulates a text response and passes that to the festival server (in this case on 127.0.0.1) which creates the audio file and outputs it to the local soundcard. If you run the festival server on a seperate network machine or back on #1 you need to create a short .scm script to add the user to the festival access list as in atc.scm You need to upload the ASR sphinx2 stuff and TTS festival stuff from CMU or wherever. If you need some help or tips in that area give a holler... http://linux-sound.org/speech.html is a list of speech related websites you might find useful. In particular-- the Festival set, XVoice, Sphinx, and MBROLA. I'm using the You'll find http://www.speech.cs.cmu.edu/tools/lmtool.html quite useful for creating a LM and phonelist for the ASR program. With the smaller dictionaries voice recognition is very good but if you mumble a lot (like I do) the XVoice folks have a wiki page with instructions on how to add a voice trainer and improve/tailor the AM for individual speech patterns. Setting up the programs takes a little work. You can use the AM provided with sphinx2, but you'll get much better results if you upload and install the hub4-2000-11-17-1 model. And you will need to create a LM that contains ATC phrases and words Good luck, again you've got my email, don't hesitate if you need help or have questions. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
- Original Message - From: Boris Koenig [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, September 17, 2004 10:22 PM Subject: Re: [Flightgear-devel] A voice for FG John Wojnaroski wrote: Hi, The last month or so I've been working with adding synthetic speech and voice recognition to my 747 project. What type of project is that ? - (FlightGear related ?) See the FG Project webpage for details Lots of good thoughts, I'll need to digest them over the weekend, but four quick comments: 1) You could set up a festival server on the Internet, assuming you find the round-trip delay time acceptable. But just about any older machine might be faster. I'm using an old AMD-K6 chugging along at 366MHz and find the performance okay, in fact the delay of a one or two seconds feels a lot like the natural time delay in two-way radio communications 2) It might be just as easy to write a little C/C++ code to define the interface. Festival uses Scheme so all that is required is a text stream that mimics a stdin or file input in a Scheme syntax 3) One of the advantages of TTS (at least as I see it) is you don't have to create snippets or prestore anything. One has the luxury of total and complete freedom to create any and all possible combinations of words within the established language model and create the audio in real time. 4) Speech recognition for converting audio to text is just about perfect. The trick, as you noted, is having the machine understand what was said... Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] A voice for FG
Hi, The last month or so I've been working with adding synthetic speech and voice recognition to my 747 project. The results have been quite good; unfortunately it's kind of hard to demonstrate or display the results. Jim Brennan is preparing a corpus of messages and ATC phrases which will be used to create a LM (Language Model) for speech recognition and the synthetic speech voices come from a variety of sources -- most notably, the FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU. Both the ASR program and TTS program can run as applications (foreground or background) on a single machine interfacing with FG via the loopback IP address 127.0.0.1 or on additional machines connected via a LAN. Just wondering if there is any interest in adding this capability to FG. About all that is required is a socket-type (IPC) interface to send the text string to the TTS application in the specified wrapper, and the TTS program (Festival) running in server mode to create an audio signal. In addition to interactive inputs, the TTS program will receive comm traffic from other AI controllers that produce communications with other model entities active in the simulation. Installing, compiling, and configuring the TTS and ASR packages requires a little work, but it's not brain surgery. Both packages are open-source and available (see http://linux-sound.org/speech.html for some sources). The real body of work is in the code and logic to create the AI controller(s) that can respond to a real, live, unstructured input. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A voice for FG
- Original Message - From: Jon Stockill [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Friday, September 17, 2004 11:54 AM Subject: Re: [Flightgear-devel] A voice for FG John Wojnaroski wrote: Hi, The last month or so I've been working with adding synthetic speech and voice recognition to my 747 project. The results have been quite good; unfortunately it's kind of hard to demonstrate or display the results. Jim Brennan is preparing a corpus of messages and ATC phrases which will be used to create a LM (Language Model) for speech recognition and the synthetic speech voices come from a variety of sources -- most notably, the FestVox folks at CMU, MBROLA, and the OGI-Festival project at CSLU. I was working with the pre-release of festival 2.0 at work last week, and the new synthesis methods and voices that are available in that release sound particularly impressive. I did think of the possibility of using it for air traffic control, if not live then as an easy method to generate a batch of samples for use in a similar way to the way ATIS works at the moment. The approach that I've taken is to start a festival server on a networked machine and a small client program that receives a text message as a string , stuffs it into a festival protcol wrapper and calls the festivalStringToWave() method. This also will allow you to send control commands and files to the server to change voices, LMs, etc.. ../bin/festival --server loopback starts the server and any client on the local machine can connect by default. Connections over a LAN require a small Scheme script to add users to the festival_access_list as part of the argument list. The client program then has a few lines of socket code to connect to FG. On the FG side all you need is something to send a text string over the socket. Something like FGVoice::fg_say_mesg(this is a test); There are a couple of good examples in the /examples/ directory which I used to create a atc_net_demo.cpp application. The voice recognition is just as easy (actually easier to set up) but training the model, building the Acoustic model, and the dictionary plus any special phones is a little more envolved. If you don't mind a bit of a delay (around 2-3 sec) to decode the audio, you can use the existing models and get pretty good results. The resultant text string is sent to the AI controller where it is parsed into tokens and analyzed(compiled?). I'm not sure how all of this would fit into FG. I suspect the easiest way would be to create a voice object and a few methods and leave it up to the individual user if they want to setup the TTS festival package or ASR programs. Regards John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 'Nother Newbie.
i started looking at flight gear hoping that there would be a way to get at system internals from outside the box so that i could build my own simulated radio stack and hook it up. can anyone tell me if there is already a part of your project devoted to this, or if you think it's even worth trying? i don't want to drive your project members crazy reading email from someone who has an interest that your (really cool by the way) project doesn't support, or plan to. Take a look at the website project page, there are some examples of hardware projects. You can use the net-ctrls and native-ctrl structures in the Network directory to modify the properties to set radio/nav frequencies but that takes a bit of work to hack the code. Some of which may not be applicable for general use. Approach would be to add the frequency variables to the network packet and modify the source to load the values from the received packet into the appropriate properties in FG. Then you'll need to create the network program on the simulated radio stack client to build the packet, create the socket connection, and establish network communications. At least that's the approach I've taken for my 747 project. If you're modestly fluent in C++, the existing code serves as a good example and base to expand to meet your needs. One big problem ;-) The network packet loads at whatever rate you select via the socket options and overwrites any and all the property values called out in the net-ctrls data structure and that includes all the controls for flying. Which is fine if you plan to also control FG with an external machine. I suppose you could turn off updating those properties you don't want to update in FGNetCtrls2Props, but that's a messy hack. I'm assuming you don't need a lot of bandwidth. There are other options less envasive and unless you plan to expand your hardware at some future date those might meet your needs Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XMLSound Wish List
Looking at the xmlsound structure... Wondering if it would be useful to extend the structure and methods to add a second property and then define a set of additonal macro operators to combine the two properties with an arithmetic/logical operation to produce a result. One example; interior jet engine noise is a function of thrust and airspeed. It's at a max at takeoff and decreases during climbout as TAS increases; it's probably the loudest on landing when reverse thrust is applied. So one could take the rumble.wav sound file, increase volume/pitch for higher power settings and subtract some amount as a function of airspeed to arrive at a final value. Or is there a set of xml constructs to do the same? Just a thought John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] XMLSound Wish List
All volume related subsections have one thing in common, the actual volume. So it already is possible to to that. For example, the wind noise decreases as the aircraft gets higher, but also increases when the aircraft gains speed: wind namewind/name modelooped/mode pathSounds/wind.wav/path property/velocities/airspeed-kt/property !-- starts here -- volume property/position/altitude-ft/property factor-0.15/factor offset1.0/offset min0.1/min max1.0/max /volume volume property/velocities/airspeed-kt/property factor0.0015/factor min0.03/min max0.25/max /volume !-- ends here -- pitch property/velocities/airspeed-kt/property factor0.0035/factor offset1.25/offset /pitch /wind Okay, got it! I'll build an xml file and give it a try Thanks John W ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flight Instrument Accuracy
Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
