RE: [Flightgear-devel] B-737.org
Thanks Jon Looks very usefull. Jon Berndt http://www.b737.org.uk/index.htm Cheers Innis The Mad Aussi _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] DHL/EAT Crew Lands A300 With No HydraulicsAfter Being Hit By Missile
Jon Berndt wrote: DHL/EAT Crew Lands A300 With No Hydraulics After Being Hit By Missile Further reading suggests two things to me: 1) The two Belgian and one British crew displayed a remarkable job of airmanship. They sure did! 2) A hit on the outboard left wing of the A300 totally crippled the controls, brakes, etc.? Not the brakes: Ghyoot said he believes the aircraft had flaps retracted, but the brakes worked as they were powered by an isolated hydraulic accumulator. But about the same happened to the mentioned DC-10 which lost controlls after the fan of the tail engine exploded. I can imagine the controlls to be quite unusable when one side doesn't respond ( the way it should). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] field of view script
This works nicely, but I don't think you need to have a lower limit on the FOV (or it should be very low). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Jim Wilson wrote: This works nicely, but I don't think you need to have a lower limit on the FOV (or it should be very low). Actually, the lower limit is the coolest part: it matches typical visual accuity, and is tuned to the actual pixel resolution. When you zoom in to the maximum, you're seeing as well as an actual pilot would be. There is, IMHO, a strong realism justification for this. Imagine shooting a carrier approach and zooming in to see the meatball (without exception, ever carrier landing simulator I've seen has had to hack around the fact that you can't see the meatball with sufficient resolution on computer displays). Maybe we could predicate it on a /views/current-view/limit-fov property, or turn it off for views other than the cockpit view. All of that would be trivial; just put the appropriate if() in the view.nas script. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: This works nicely, but I don't think you need to have a lower limit on the FOV (or it should be very low). Actually, the lower limit is the coolest part: it matches typical visual accuity, and is tuned to the actual pixel resolution. When you zoom in to the maximum, you're seeing as well as an actual pilot would be. There is, IMHO, a strong realism justification for this. Imagine shooting a carrier approach and zooming in to see the meatball (without exception, ever carrier landing simulator I've seen has had to hack around the fact that you can't see the meatball with sufficient resolution on computer displays). Ummm...why does this matter? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Jim Wilson wrote: Ummm...why does this matter? Why wouldn't it? :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Andy Ross writes: Jim Wilson wrote: Ummm...why does this matter? Why wouldn't it? :) It would be nice to be able to at least be able overzoom and simulate a telephoto lens (as before.) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Curtis L. Olson wrote: It would be nice to be able to at least be able overzoom and simulate a telephoto lens (as before.) This is mind bogglingly easy to fix. But what is the desired behavior? What I want is a limit that will tell me when I've zoomed to as far as a human pilot would actually be able to see from the cockpit. What do you guys want? If you want to overzoom only from the non-cockpit views (which aren't realistic anyway), then we can predicate it on the current view number. If you want to ignore the feature, we can make a simple preference property. If you want both, then we need to decide on a more complicated interface. Again, IMHO it's a realism thing. Computer monitors don't have the spacial resolution that an eye does, so we have to allow for zoom. But pilots don't usually have telescopes in the cockpit, so it should by default be limited to something approximating real life. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Andy Ross writes: This is mind bogglingly easy to fix. But what is the desired behavior? What I want is a limit that will tell me when I've zoomed to as far as a human pilot would actually be able to see from the cockpit. What do you guys want? If you want to overzoom only from the non-cockpit views (which aren't realistic anyway), then we can predicate it on the current view number. If you want to ignore the feature, we can make a simple preference property. If you want both, then we need to decide on a more complicated interface. Again, IMHO it's a realism thing. Computer monitors don't have the spacial resolution that an eye does, so we have to allow for zoom. But pilots don't usually have telescopes in the cockpit, so it should by default be limited to something approximating real life. From my perspective the issue is flexibility and differentiating between policy and capabilities. I also don't think the realism argument should trump everything else. We do a *lot* of things for the sake of convenience. Is starting up in flight on a 7 mile final realistic? Is teleporting to the other side of the world realistic? Is accelerating time realistic? Is landing a helicopter on a 747 wing realistic? For that matter, is flying under a bridge something a person would realistically do in real life? Is being able to swivel my view (aka head) in multiple 360 degree circles a realistic thing? Perhaps it would be better not to answer that one. :-) There are a lot of cases where convenience, training value, or the limits of a PC computer will trump realism. There is other cases such as fidelity of the flight dynamics where we do want realism to trump everything else. Then there are grey areas where it's not exactly clear. Do we always want to fly at the real time for our current location, or do we want to be able to control the time of day and choose night when it's day to practice night flying, or select day when it is night so we can do some nice sight seeing? I think it's very clever to be able to figure out the maximum real world resolution a pilot would have, but perhaps the little poppup message would say overzoom xyz when you get past the real world physical limitation. Being able to zoom way in is at least useful for taking screen shots and debugging scenery construction problems. In real life there exists some pretty amazing cameras and telescopes so it's not entirely unrealistic to allow arbitrary zooms. Even from a cockpit view you might consider that a passenger has some super telephoto lens on their camera, and the air is still, etc. Maybe we want to some day simulate the camera view from a UAV. It's not inconceivable that such a camera would have significant telephoto abilities and be mounted on some sort of gyro stabilization platform. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] field of view script
Curtis L. Olson [EMAIL PROTECTED] said: Andy Ross writes: This is mind bogglingly easy to fix. But what is the desired behavior? What I want is a limit that will tell me when I've zoomed to as far as a human pilot would actually be able to see from the cockpit. What do you guys want? If you want to overzoom only from the non-cockpit views (which aren't realistic anyway), then we can predicate it on the current view number. If you want to ignore the feature, we can make a simple preference property. If you want both, then we need to decide on a more complicated interface. Again, IMHO it's a realism thing. Computer monitors don't have the spacial resolution that an eye does, so we have to allow for zoom. But pilots don't usually have telescopes in the cockpit, so it should by default be limited to something approximating real life. From my perspective the issue is flexibility and differentiating between policy and capabilities. I also don't think the realism argument should trump everything else. We do a *lot* of things for the sake of convenience. Is starting up in flight on a 7 mile final realistic? Is teleporting to the other side of the world realistic? Is accelerating time realistic? Is landing a helicopter on a 747 wing realistic? For that matter, is flying under a bridge something a person would realistically do in real life? Is being able to swivel my view (aka head) in multiple 360 degree circles a realistic thing? Perhaps it would be better not to answer that one. :-) There are a lot of cases where convenience, training value, or the limits of a PC computer will trump realism. Agreed. My feeling in fact, when it comes to visuals, is that the PC is drastically limited in that department (for most users anyway) and that it is appropriate to augment in other ways to give a reasonable flight experience. A good example is making the tires sqeak when you hit the ground, because it is otherwise difficult to tell on most PCs that you have touched down. I think it's very clever to be able to figure out the maximum real world resolution a pilot would have, but perhaps the little poppup message would say overzoom xyz when you get past the real world physical limitation. Being able to zoom way in is at least useful for taking screen shots and debugging scenery construction problems. In real life there exists some pretty amazing cameras and telescopes so it's not entirely unrealistic to allow arbitrary zooms. Even from a cockpit view you might consider that a passenger has some super telephoto lens on their camera, and the air is still, etc. Maybe we want to some day simulate the camera view from a UAV. It's not inconceivable that such a camera would have significant telephoto abilities and be mounted on some sort of gyro stabilization platform. Ways I use the zoom are as follows: 1) In cockpit view, to spot scenery objects that are ordinarily invisible. For example I found the sailboat the other day using telephoto zoom. 2) In external/chase view to examine geometry glitches in models. 3) In tower/RC view because I often loose the aircraft. In the real world it'd really be gone :-) But on my PC I've got a chance to get it back by hitting the zoom. Like I said at the start of this thread, this is a very nice feature. I'm also anxious to try some of the scripting out with the model animations as soon as real work eases a bit. As for FOV though, about 0.1 degree would be my choice for a min, without any other parameter tweaks. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scenery testing
I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] NMEA output (i.e. faking a gps receiver for use with other moving map/gps software)
I just commited some fixes to the NMEA output to make it more usable. This allows FlightGear to to pretend it is a gps and send fake gps sentences out the serial port. You can then feed the other end of the serial cable into something running some real moving map/gps software and that software thinks it is talking to a real gps located at your current virtual flightgear position. My fixed include: 1. I switched to the correct line terminators (\r\n) 2. I fixed a variety of careless formating errors. 3. I added a faked GSA sentence along with faked HDOP and VDOP and PDOP. From the FlightGear end, you can activate the nmea output using the following flightgear command line option: --nmea=serial,out,1,/dev/ttyS0,4800 (for the unix folks) --nmea=serial,out,1,COM1,4800(for the dos folks) Substitude with the actual serial port you are plugged into of course. Just for fun I downloaded FlightMaster which is a palm pilot application intended for real pilots. With my palm pilot in it's cradle and connected to the appropriate serial port it was able to receive the gps strings from flightgear and was properly tricked into thinking it was talking to a real gps. This isn't quite as good as connecting up a real Garmin 196 or 430, but if you already have a palm pilot or other pda, it's a lot cheaper. :-) FlightMaster is shareware ($40) so if you use it, definitely send them their $$$, they were very helpful in helping me track down my problems in the NMEA output code. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Jon Stockill wrote: I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) Heh, I noticed that too recently. I was mostly busy doing other stuff today, I'll see if I can get it updated soon. If some one else feels like doing some updates to it, then don't hessitate to do so. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi Al, On Mon, Dec 08, 2003 at 03:17:31AM -, Al West wrote: http://cockpit.varxec.de/electronics/PIC_homecockpit_control.html Wow, what you have done so far looks impressive. I've not even got off the Thanks :-) drawing board yet. At the moment I'm trying to work out the best trade off for hardware components vs. connectivity. However I'm getting drawn in to I've worked on my solution for quite some time. It really takes time designing stuff like that. The current solution grew out of several smaller things that I built. I just thought that I should put everything together and make one big solution out of it that can drive everything you might need in a cockpit. And I think its the cheapest solution out there. And since all the others don't support flightgear (the flightsim world is still so MSFS centered) I thought this is the best way. do a soft key panel using some a touchscreen 7 LCDs that I've just seen, £160 (UK Pounds) is quite tempting. But its so much more fun to actually flip switches and turn knobs :-) Really ;-) It would be interesting to have a place where the hardware people could talk. I'm not sure whether there are many people involved in hardware building around flightgear. So far you are the only person to respond saying you build hardware - not that doesn't mean there are more people there. Maybe it's something that the users would be more interested with. I've also talked to John Wojnaroski, He is also building hardware. Maybe we're just a few doing flightgear, but that'll certainly change over time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) If you want to talk off-list about hardware stuff, just email me. I'd be interested in what you are doing. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Perthon -- Python to Perl Language Translation
http://perthon.sourceforge.net/ :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery testing
Erik Hofman writes: Jon Stockill wrote: I've just been having a look at some of the new airports I've generated, and I've noticed an error with the new ufo model - the great big red anti-collision light from the front is missing ;-) Heh, I noticed that too recently. I was mostly busy doing other stuff today, I'll see if I can get it updated soon. If some one else feels like doing some updates to it, then don't hessitate to do so. Can we double the power, add some animation, and perhaps more loosely couple the power plants? Now is when we really could use the ability to drop ordinance. I don't have the POH in front of me, but I would think that those particular engines would certainly need to expel spent fuel now and then. Regards, Curt. (Unless you are the lead dog, the view never changes) -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Cockpit Hardware Building (was: Re: [Flightgear-devel] F-16 cockpit)
Hi Manuel, I've also talked to John Wojnaroski, He is also building hardware. Maybe we're just a few doing flightgear, but that'll certainly change over time. Just show those (mostly ignorant) MSFS crowds what flightgear can do :-) Let's just say they suffer from invincible ingnorance ( a theological concept associated with the idea of sin ) If you want to talk off-list about hardware stuff, just email me. I'd be interested in what you are doing. If you would, please include me. With the holidays fast approaching, won't have much time, but starting '04 should be able to free up more time. Still waiting for some AML-22 switches to complete the MCP. Jim Brennan might also be interested. Currently we have a lead on a 737 heading for the chopping block and trying to get our hands on the cockpit. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] field of view script
Andy Ross writes: Again, IMHO it's a realism thing. Computer monitors don't have the spacial resolution that an eye does, so we have to allow for zoom. But pilots don't usually have telescopes in the cockpit, so it should by default be limited to something approximating real life. The aircrew might have a telescope though ! http://world.std.com/~searle/IEEE6.htm Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.0 available.
On Monday 08 December 2003 12:00, David Luff wrote: http://www.nottingham.ac.uk/~eazdluf/TaxiDraw-0p1p0-src.tar.gz Source [74K], requires wxWindows to compile (wxGTK-dev on Linux). I tried it for the first time today, and I ran into some strange things: http://ivop.free.fr/fgfs/taxidraw.0.1.0.ksfo.png http://ivop.free.fr/fgfs/taxidraw.0.1.0.eham.png All runways and taxiways seem to get centered around the center of the airport and not where they are supposed to be. I also tried v0.0.8, upgraded wxWindows to v2.4.2 (instead of 2.4.0, which I had already installed on my system), but all combinations ended up with the same result. I'm running Linux, kernel 2.4.21, gcc 3.2.2 and glibc 2.3.1. I used runways.dat from a cvs checkout on december 2nd 6.31am. Am I missing something, as in how to use this program, or can this be considered a bug? Also, while viewing KSFO, I get a segfault when I zoom out 33 times with gridlines enabled, but not if they're disabled. File-Exit never works for me, whether I have an airport loaded or not. I always have to kill the window. Taxidraw looks very good and the screenshots I saw of Jon Stockill's work on UK airports were very impressing! --Ivo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.1.0 available.
On Wednesday 10 December 2003 07:05, Ivo wrote: [...] installed on my system), but all combinations ended up with the same result. I'm running Linux, kernel 2.4.21, gcc 3.2.2 and glibc 2.3.1. I used runways.dat from a cvs checkout on december 2nd 6.31am. I tried the Win32 binary of v0.1.0 on Windows 98(FE) in VMware and it works great. It displays the airport as it is supposed to be. Am I missing something, as in how to use this program, or can this be considered a bug? Also, while viewing KSFO, I get a segfault when I zoom out 33 times with gridlines enabled, but not if they're disabled. File-Exit never works for me, whether I have an airport loaded or not. I always have to kill the window. TaxiDraw does 'segfault' (the windows equivalent) while zooming out, but it takes one more zoom. Might be because my VMware window is 1024x768 and X runs at 1152x864. EHAM, for example, takes 31 zooms, probably because the airport is larger. --Ivo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
