Re: [Flightgear-devel] Landing Lights (was Re: Release of v0.9.9 source code)
On Monday 21 November 2005 11:43, Buchanan, Stuart wrote: Where are they located on the C-172, C-182, C-310 - on the wing or on the nose like I've seen in pictures of a C-210? It varies depending on year of production, model and production location ie: France / US. For example, Our default '81 172p would have a single unit in the nose fairing under the prop. (although the texture seems to suggest the earlier model) The earlier 172p's would have two larger lights behind a perspex screen in the leading-edge of the port wing around the last rib before the wing tapers. One light (the outboard one) was angled to illuminate the area immediately infront of the aircraft when on the ground (taxi) and the other (inboard) was angled to illuminate the nominal glideslope (landing). Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Landing Lights
On Monday 21 November 2005 14:29, Buchanan, Stuart wrote: Ouch... OK I deserved that. I thought I was doing quite well - avoiding top-posting, snipping etc. My sincere apologies that you had to be part of my learning process. It seems that there have been a few instances lately like this, were newbies like myself have caused offence by missing out on some netiquette. Could we put a couple of lines on the mailing list pages explaining the conventions so newcomers don't start on the wrong foot? Well, it's mainly common sense. (especially on not posting e:mail addys) Just use Common Sense(tm) and you'll do fine. Even better would be a filter on the mailing list software to parse out email addresses in message bodies. Well, there's no arguments there -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On Wednesday 02 November 2005 01:53, Innis Cunningham wrote: Hi All Now that I have been converted to 3D instrument making I am wundering if we should start an instrument repository like we have for the Aircraft and Scenery.This way a panel could be built quite quickly as people would not have to start from scratch every time. For this to work each instrument would have to be totally self contained like the instruments in the 747 and hunter and a few others that don't come to mind. The Beech b1900d system would appear not to be able to be used in this way because all the instruments use only a couple of texture sheets which would appear to me to mean you could not take an instrument in isolation and use it in another panel without having to modify it.Please correct me if I am wrong on this. Anyway thems is my thoughts what do you think Sounds like a good idea. I don't know if you'd be interested in finishing them, but I have a set of fairly generic 3D GA instruments that I made (IIRC, they mainly need animating) Few bits of eye-candy: http://www.cyfinity.com/fgfs/3dins2.jpg (shows bezel glasses) http://www.cyfinity.com/fgfs/3dins2.jpg (sun on glass) http://www.cyfinity.com/fgfs/kx155.jpg (radio stack) Unfortunately, if you try to use textures to show digital instruments you get results like this: http://www.cyfinity.com/fgfs/navcomerror.jpg Should read 120.50 and 118.85 etc but we never found a way to fix this. For eg: The B1900 instruments now utilise 2d panel elements to render the digits, hence you can't easily seperate 2d and 3d elements. Anyway, when I finally gave up my project (ran out of time and have none now), I'd done a full-panel mockup of the instruments I had made: http://www.cyfinity.com/temp/3dkitmockupfinal.jpg I *think* the models and .xml files might still be kicking around on another system (or even worse) a backup CD!! *somewhere*. If someone is genuinely interested in working with them, I'll look them out and put them somewhere they can be grabbed (assuming they still exists) Let me know, cheers. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instrument Making
On Wednesday 02 November 2005 11:34, Dave Martin wrote: Sounds like a good idea. I don't know if you'd be interested in finishing them, but I have a set of fairly generic 3D GA instruments that I made (IIRC, they mainly need animating) Few bits of eye-candy: http://www.cyfinity.com/fgfs/3dins2.jpg (shows bezel glasses) http://www.cyfinity.com/fgfs/3dins2.jpg (sun on glass) http://www.cyfinity.com/fgfs/kx155.jpg (radio stack) Unfortunately, if you try to use textures to show digital instruments you get results like this: http://www.cyfinity.com/fgfs/navcomerror.jpg Should read 120.50 and 118.85 etc but we never found a way to fix this. For eg: The B1900 instruments now utilise 2d panel elements to render the digits, hence you can't easily seperate 2d and 3d elements. Anyway, when I finally gave up my project (ran out of time and have none now), I'd done a full-panel mockup of the instruments I had made: http://www.cyfinity.com/temp/3dkitmockupfinal.jpg I *think* the models and .xml files might still be kicking around on another system (or even worse) a backup CD!! *somewhere*. If someone is genuinely interested in working with them, I'll look them out and put them somewhere they can be grabbed (assuming they still exists) Let me know, cheers. -- Dave Martin http://museum.bounce-gaming.net Last screenshot corrected link: http://www.cyfinity.com/fgfs/3dkitmockupfinal.jpg -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear as a real time synthetic view
On Saturday 29 October 2005 19:20, Curtis L. Olson wrote: There is a neat flightgear connection here which I've probably mentioned before, but would like to mention again (with pictures.) http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ This is a manually flown UAV (also pictured on the same page.) It has an onboard camera angled 45 degrees down. It also has a gps/imu sending data to the ground via a radio modem, so we can feed that into flightgear and show a live synthetic view from the aircraft perspective. We can angle the flightgear view 45 degrees down and it matches pretty darn close with the real camera view. We had a guy create a small chunk of photo real scenery for the area so it's really neat to see the synthetic and video views match tree for tree, road for road, building for building. That is extremely nifty. I'm suprised you can get that sort of 'resolution' in the GPS/IMU downlink. Glad you got back in the air so soon too :) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
..one check before reaching 650' QNH and turning crosswind. Just re-read my mail this-morning. Worryingly, thats not the first time I've confused QNH and QFE. Hmm, I don't remember the ground being *that* close in the circuit. ;) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
On Thursday 27 October 2005 14:19, Vivian Meazza wrote: What happened to the poor reindeers' antlers? V. I take it you're not aware of Reindeer Service Bulletin 63-11-05 SE 15? The antlers were removed to improve 'engine out' characteristics after the infamous 'Rudolph food-poisoning' incident. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Santa's r[ae]i?ndeer
On Thursday 27 October 2005 15:18, George Patterson wrote: Correct me if I am wrong but isn't there supposed to be eight reindeers? What became of the other four? George Patterson Cutbacks. The Lapland Reindeer Union fought it but Santa Inc. won in the end. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] c150 low G.
Just been having a muck about with the C150, apart from the low weight due to lack of pilot mass, I've been flying it much like I used to fly the real thing. One thing we used to do on climbout was 'clear ahead', just push the nose down for a moment to check we weren't about to eat another aircraft. When this is done on the FG c150, the engine stutters (FDM program fuel starvation on neg-G?) According to the HUD, it stutters at about +0.30G. In the real aircraft, we could make 0G manouevers that could last for a couple of seconds without the engine missing. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
On Friday 28 October 2005 02:03, Vassilii Khachaturov wrote: In a real gravity-fed Cessna, there are 2 aspects relevant to the engine problems resulting from negative Gs that I was told about by the instructors. One is the fuel flow (tanks/carb/engine intake manifold) and the other is the oil flow that has gravity-induced return of the oil into the sump. If that stops, it's as disastrous as oil leak --- permanent damage can be done. (As opposed to just engine out due to momentary fuel absense which goes away as soon as one pulls back up and the gravity is restored). This is quite true but it only becomes a problem after a few seconds of sustained *negative* G as opposed to zero G. (Some 152 Aerobats have inverted oil systems to prevent this all together). I have more information on the survivability of engines starved of oil but it's probably not relevant here ;) As for the clearing the climb path, I was told to do some gentle S-turns rather than pushing over the nose in order not to screw up the airspeed and hence the time-to-climb calculations, as well as be less nauseating for the passengers (of course, if executed in a properly coordinated matter). We were training in a busy traffic area (EGBE UK) where other aircraft in unexpected places were a regularity. Typically we would make one check before reaching 650' QNH and turning crosswind. The trick to making the check is to leave the trim set to climb and just push forward momentarily while scanning ahead for anything resembling your own aircraft. Typically, aircraft would re-stabilise in its nominal climb in 10 seconds or so - not an issue when climbing for the training circuit. I can quite safely say that while you would have 'your heart in your mouth' as you pushed forward, it was certainly not even a zero-G motion and the engine certainly wouldn't waiver. Also, in low-G manouvers such as a high-AoA entry to an incipient spin or a 0-G pushover where very low positive G (certainly lower than 0.3G) is sustained for maybe 2 to 3 seconds, the engine would behave as in the cruise. Having flown the manouvers during PPL training (not required but none the less useful) I am adamant that the IO-200 will experience no power-loss down to a small fraction of a G even when sustained for several seconds. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Driving real instruments.
Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? Cheers -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. I did think of this trick too :) Although it also threw up a problem.. The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) It might be a little time consuming to get all the pieces in place and working, but once you figure out how to generate the PWM servo signal, there's nothing technically difficult there. Curt. The problem being the 'setting' of an instrument. If you wanted to directly set an instrument you'd need some sort of encoder (eg: to rotate a VOR direction wheel). This could be done easily enough, of course, in the case of the LCD behind the panel, the major hurdle being the depth of the control in the panel. When it comes to physical gauges, the system itself would need to know the precise position of a direction wheel so it would have to be read from a sensor in the instrument (SimKits do this). The only way forward I spotted was using 'Phidgets' interface cards to run the servos and also read from analog sensors in the instruments. 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. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? Thanks -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
A really good setup requires the following: * The server, displaying the panel and running the FDM. * A dual core machine for every display as a slave to the main server. Erik What is the reason for using a dual-core machine for each 'out the window' view? (Asking out of ignorance) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 15:34, Curtis L. Olson wrote: There are adjustments in the proper place on the panel. I'm just a software guy, so I don't know all the hardware tricks that are being done. But I do know the end result has a nice solid feel and is very convincing. Curt. 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. Cheers. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 16:45, Curtis L. Olson wrote: We are using multiple machines, one for each display. My feeling is that if it is a bit excessive, it is only a small bit excessive and I can put up with it. :-) You are welcome to try running a multiheaded machine (with support for opengl on all your displays.) I'd be interested in hearing your results. I had a go at this a while back using the nvidia proprietary driver's TwinView option. TwinView can be configured to stretch the X display across 2 screens and provide acceleration on both. The nvidia driver hides the fact that the display spans two screens. So 2x 1024x768 displays are presented to the X server as a single 2048x768 wide screen. Using FlightGear across both of the displays is as simple as launching with --geometry=2048x768 and the performance is the same as you'd expect displaying the same size window on a single display. You can adjust the FOV to say 90deg to give a realistic panorama and I'd love to try it with two projectors :) Note that I tried --enable-game-mode but didn't get it working, however I'm sure this was down to my setup at the time and not the TwinView config. For displaying a panel (and avoiding the performance hit of two instances) perhaps you could configure the TwinView as 'top and bottom' monitors, the top one providing the out-the-window view and the bottom one showing the panel. The panel would probably have to be specifically designed to only fill 1/2 your display area - the 610x panel seems to scale to the longest edge in all circumstances. Personally, I'd favour the aforementioned 2 systems, one for panel, FDM, input and sound and one (or more) for the out-the-window view. (Hopefully thereby boosting the 3d display's performance a bit?) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Ouch! :( Just a thought, many years ago I watched a demo of a BRS for a model plane at Cosford in the UK. Apparently it was very lightweight but had clever triggering. In the event that the radio signal (controller to plane) was lost, the system cut the fuel off to the motor and released a spring loaded BRS which brought the model down for a vertical but gentle landing. Could you fit something like this on the UAV for loss of contact events? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 20:07, Curtis L. Olson wrote: It's definitely an interesting thought. Anyone know what size parachute a person would need to gentle let down about 15 lbs (7kg)? Many R/C receivers have a failsafe mode so you can trigger the servos to go to preset locations in the event of a transmitter signal loss. The danger is probably similar to the danger the full size BRS units have ... if you deploy the chute at a high speed, you are going to tear your airplane to shreads. Not sure on weights for the chutes but from my school days I remember only needing a few grams of parachute to retard the fall of a 3kg rubber brick. The speed risk issue would probably have to be dealt with like the real BRS systems which cause a pitch-up when deployed to share the aerodynamic load between airframe and parachute. You could perhaps experiment with a 'slider' to hold the chute partly closed until the speed drops. Just on the subject of BRS; there was a Flight Designs CT on a test-flight which exceeded Vne in a dive causing the wing to fail; The BRS was opened at 195mph and worked! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash carnage
On Saturday 24 September 2005 16:28, Curtis L. Olson wrote: This is somewhat off topic, but in the spirit of open source I'd like to share the tragedies as well as the triumphs ... http://www.flightgear.org/~curt/Models/Special/Rascal110_1/ This is part of a university project I'm helping out with. We have a backup plane and our expensive instrumentation survived intact, so this shouldn't be a severe setback to us. Just done some more reading of your page and incident analysis; I was just thinking that a useful tool would be a couple of camcorders. (and a friend to operate one of them). If you set one up on a tripod looking at the transmitter, you could at least see what control positions you were *trying* to get at any given time. The second camera could be kept on the aircraft itself. Both cameras would need to be synced to keep the correct time (for comparison with your UAV data). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
On Wednesday 14 September 2005 18:03, Curtis L. Olson wrote: I have a question I'd like to toss out to the group for discussion/comment. What would people think of abandoning our mailing lists and converting over to online/web-based forums? I quite like the idea of forums at least for the 'average' FG Userbase. If anything, just in order to make Flightgear more 'accesible' to the masses. I'd like to offer to host / administer a forum for FlightGear as it is something I have experience in / am good at. Curtis: feel free to e:mail me directly if you'd like to discuss further. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Saturday 10 September 2005 10:25, Jon Stockill wrote: Here's a couple of pics, the first is looking west over the gherkin, and the second is looking out over regents park. Generation time was over an hour for that tile on a 1GHz athlon (the resource limits in fgfs-construct needed a significant increase). Memory usage was ok at around 140MB. http://flightgear.stockill.org.uk/scenery/osmroads1.jpg http://flightgear.stockill.org.uk/scenery/osmroads2.jpg It shows up a few limitations in the source data. The road segments are currently all represented seperately and not tied into a road object, this results in lots of short roads, and visible breaks on the outside of corners. This will improve as the open streetmap system matures (it's still very early days). Jon That's really impressive Jon! I have a feeling as we get more road data, we're going to be seeing slight placement errors at the airports. Currently EGBB is placed over the A45 on the 0.9.8 scenery. If I can get that road mapped by GPS and a few others around it, we can probably move the airport to its correct location. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover
On Saturday 10 September 2005 15:39, Martin Spott wrote: We have to be careful about simply dropping a shapefile into our landcover database. Wenever we add a road, river or some other data to the database we'll have to have a look if the respective object is already represented there. Is it possibly to remove the existing shapefile for a certain area from the landcover DB? Perhaps the UK landcover generated by Jon via openstreetmap.org could be kept seperately until more or less complete and then used to generate UK scenery. Interestingly, I did a bit of poking around the openstreetmap documentation and it does actually provide for defining areas such as woodland/built-up/lakes etc. Further to this amateur cartography, it might be interesting to try to start a 'community' of people in the UK who can use a GPS to map their local area - maybe 150 or so 'adventurous' cartographers could get the majority of the UK's road layout done in a year or so (being a small island ;) ) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Friday 09 September 2005 12:47, Jon Stockill wrote: Excellent - I'll give it a try. I'm also experimenting with some early data from openstreetmap.org to add accurate roads to scenery. Don't know why I didn't find openstreetmap.org when I was searching about for 'royalty free' mapping last week. Now that you've mentioned the site I'm all grins. Thanks very much Jon. :) -- Dave Martin museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
On Friday 09 September 2005 18:36, Jon Stockill wrote: There's anot a huge amount of data there yet, it's still in the very early stages, but if you own a GPS you could help change that ;-) I think I can get access to a suitable GPS but with fuel prices at £1/litre I think I'm going to be dusting off my bicycle and getting some much-needed exercise ;) I've just finished downloading and processing all the data to get my scenery build system back up and running after a disk crash, it's building tiles for a test of the OSM roads at the moment. I'll grab some screenshots when it's done. I look forward to seeing that. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter and Citation Information Needed)
On Saturday 03 September 2005 17:43, Vivian Meazza wrote: the deal? :) No idea. I suppose flameouts and relights could enliven a dull mission. Then we could do compressor surge, and bird strikes ... nah, forget it :-) Vivian Would it be a first if FlightGear implemented a real-time AI flocking bird hazard? ;) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
On Sunday 14 August 2005 21:56, Erik Hofman wrote: [EMAIL PROTECTED] wrote: Hi all! Yes, I know this topic has already been discussed and I know also that someone of you is working on the FG multiplayer code... anyway I think that it will be an advantage to the FG comunity to interface to IVAO and/or VATSIM networks. Ok, They don't want that a GPL tools is used to interface their network for secutity reasons (I think this is understandable) I'm opposed to it because it imposes a security risk to FlightGear. There's no way of knowing how secure their code is without the possibility to look at it. Erik I'd be opposed to it to for the above mentioned and that VATSIM appear to only cater for the Windows OS. FlightGear has a diverse userbase using everything from SGI thru Linux to Mac so it would seem to be somewhat unsuitable for FlightGear. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
On Thursday 11 August 2005 11:54, Jon Berndt wrote: We used red and green in Europe :-( Erik Did you look at it, anyhow? The blue and green channels both are set for the right eye. Red/Green glasses should work, too. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I had a look with a red / green pair and it's quite an impressive effect. I'd love to have a go at making a true stereo HMD (dual display) because the immersion effect 'feels' great. The cockpit itself is stunning; top marks to its creators. Just one point on the anaglyph; the difference in the seats is too great (doesn't work visually) - I think this is probably down to the selected FOV and proximity of the viewpoint to the seats. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D Cockpit view, L410 Turbolet
On Thursday 11 August 2005 14:23, Jon Berndt wrote: The red and green/blue images could be registered better in the post-processing phase. However, had I done that, I would have had to crop the images more horizontally. I didn't feel like doing that at the time. It was sort of a quick-and-dirty post-processing effort. I agree, though, that it would be cool to have a stereo flight simulator. I've got no idea on the mechanics of the visuals though - how that could be implemented. Jon I was looking into driving a stereo HMD thru FlightGear a while back (all theory - nothing practical yet). One idea I had was to produce the offset visuals using a dual-cpu system with 2 instances of FlightGear's 'out-the-window' engine running as if the cpus were 2 networked systems doing the same. The advantage (I presumed) would be that the video frames would be closer to being synced than if 2 seperate machines were used. Either 2 video cards or one very-high performance one running 1 display per framebuffer could be used. The FDM and everything else could be run a networked machine or you could maybe step up your main system to quad cpus and use the same 'locally-networked' trick. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns
On Sunday 31 July 2005 14:34, Martin Spott wrote: Jon Stockill wrote: http://www.voip-info.org covers practically everything out there. Just an idea: In order to stick to 'standard' interfaces it might make sense to integrate a simple SIP or IAX (Inter Asterisk Exchange) client into FG with just enough features to connect to an Asterisk VoIP server, Martin. I noticed a while back that openh323.org had a tool called openmcu. openmcu is basically a conference server for h323/sip etc clients and it also supports 'rooms' which could be viewed as 'frequencies'. Most h323 clients support 'rooms' and switching with the notable exception of Netmeeting on Windows. IIRC openmcu can handle packets produced by speex etc. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
I don't know if anyone has brought this up yet but the 1.0-7667 driver from NVIDIA for linux breaks the drawn shadows as in they don't appear at all. This tested and confirmed on a FX5800U and 6600GT PCIE Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Saturday 30 July 2005 15:40, Oliver C. wrote: No, it works here. You just need to start flightgear in 24 bit mode. fgfs --bpp=24 Best Regards, Oliver C. Thanks for that :) Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricoloriaerobatic jet
On Friday 29 July 2005 14:18, Arnt Karlsen wrote: ..and, this latter bit can get us some seriously fat funding: FlightGear helps war game authors teach soldiers how to prevent war crimes. Or even just helps Fight Pilots avoid Friendly-Fire incidents ;) Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Congratulation to the Author. The flight is wonderful, very accurate. Only little difficulties under Linux with the Upper-case, Lower-case mixing (direct.xml = Direct.xml, *.ase = *.ASE, instruments name, and flap = Flap). Arrh MS Windows. I would fix the faults and make a cross-platform version available but apparently the License doesn't allow this :( Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Is it better to ask to the Author to solve it? I did it on my side We could wonder about the License compatibility with GNU. FlighGear Team should probably discuss that with HCI Lab of the University of Udine, before official FG distribution. That licence goes against our up to now policy. The HCI Lab licence look like many External developers MSFS Aircraft. Quite probably better to ask; my 'get stuck in' mentality is getting the better of me :-) The license is obviously not GNU/GPL compliant but then it doesn't have to be because the a/c is not part of the FlightGear 'distribution'. (although it would be nice ;-) ) Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Any pictures of the 747 simulator at Scale 3x?
Hint hint Curtis :-) Really hope you remembered the camera last weekend :-) Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any pictures of the 747 simulator at Scale 3x?
Just to follow up on my own thread. I found 1 picture from day 1. http://www.socallinuxexpo.org/images/pictures/scale3x_day1_7.jpg Must say, that is *extremely* impressive! Think the 747 simulator could do with an 'F10' key somewhere on the panel tho ;-P Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flightgear to demo 747 at Scale 3x.
Just found this at http://www.linuxgames.com Although the news story appears broken / mislinked, it states that someone will be demoing a full-scale 747 cockpit driven by FlightGear at Scale 3x this coming weekend. Any idea who's hardware / project it is? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flightgear to demo 747 at Scale 3x.
On Monday 07 Feb 2005 20:18, Erik Hofman wrote: Dave Martin wrote: Just found this at http://www.linuxgames.com Although the news story appears broken / mislinked, it states that someone will be demoing a full-scale 747 cockpit driven by FlightGear at Scale 3x this coming weekend. Any idea who's hardware / project it is? It's the topmost item at Curt's weblog: http://www.flightgear.org/~curt/ Erik Thanks. I hope it goes really well for them :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flightgear to demo 747 at Scale 3x.
On Monday 07 Feb 2005 23:40, Curtis L. Olson wrote: Finally, there is a little bit larger description of the project with a few pictures here: http://www.flightgear.org/Projects/747-JW/ I hope to have a few more pictures and info after the event is finished. John will be the first to point out the flaws and shortcomings of his sim (it's a lot of work to fully replicate a 747 cockpit and he's not quite done yet.) But to the average flight sim enthusiast or aviation enthusiast (and hopefully to the average linux geek) this is going to be a really awsome demo. John has done some really impressive work with his cockpit both in software and hardware. Regards, Curt. Please take plenty of pictures :-) Hope all goes well for you. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Moving to 0.9.8 kills model rotations
On Wednesday 02 Feb 2005 18:35, Vance Souders wrote: I've been working on an aircraft model under 0.9.5 and after moving it over to 0.9.8 the model's rotating parts fail to move. This includes all of the gauges, although the parts of gauges animated with textranslate still function properly. I'm building Flightgear against plib 1.8.4 and the latest release of simgear. Any idea what might be causing this? -Vance Are they 3d instruments? If so do the 'faces' (which you want to rotate) have more than 1 surface? I got stuck trying to animate single-faced polys; it just doesn't work. Simplest test is just to subdivide one face. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: Dreamcast porting competition]
On Tuesday 01 Feb 2005 20:26, Curtis L. Olson wrote: I suspect a flightgear dreamcast port is outside the realm of possibility, but I am forwarding this to our developers list in case someone wants to take a whack at it. It looks like you can get a dreamcast unit for pretty cheap, and it looks like the development tools are open source. However, the dreamcast has pretty wimpy specs by today's standards and I'm not sure the amount of main RAM and video RAM is even close to big enough to run flightgear without severe modifications or rearchitecting the code. There appears to be an SDL port for the dreamcast, but I suspect that there is no opengl available. If anyone is interested, feel free to run with this and contact Max directly for more information. Regards, Curt. You been smoking the 'whacky-baccy?' ;-P The Dreamcast is RISC based which may be a hurdle but the specs are *really* low. SH-4 RISC CPU @ 206Mhz 8MB PowerVR2 Graphics 16MB RAM 12speed GD-ROM. Who knows, perhaps FG would 'run' but I can't see it running 'fast' ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Alcatraz
On Friday 28 Jan 2005 16:01, Curtis L. Olson wrote: With help from Thomas Markowitz, I have posted a side by side comparison of the FlightGear Alcatraz model versus a real photo here: http://www.flightgear.org/Gallery/ Good work Frederic! Regards, Curt. It really cuts the mustard. Was the terrain at Alcatraz designed 'by hand' or is it the regular terrain data? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Friday 28 Jan 2005 17:25, Drew wrote: Well, FYI, it can be done with Windoes. The difference is I want the instructor station on the PRIMARY display, but right now I get the unsightly window border on the secondary display. Does Windows allow you to switch the 'border' attribute on a window? I use this on Linux to switch FlightGear from Windowed to fullscreen without needing any 'locking' control over the WM. If you can do that on Windows, just start FG with the correct geometry and then set the window as 'borderless' or something along those lines. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting - What happened to the new terrain engine?
On Friday 28 Jan 2005 21:21, Paul Surgeon wrote: Yes, I'm sure there are plenty of users who are happy with the current scenery engine and one of the advantages it has is that there is no paging of huge textures while flying. This allows for high speed flights without any pausing and can also be run on older hardware or where CPU cycles are best used elsewhere like instrument updates or FDM's. Last time I tried a Mach 5 flight in FS2004 I ended up with blank/grey scenery tiles because it couldn't build and page the textures fast enough. :) For sub-sonic speeds and VFR flight an eye candy terrain engine would be very much appreciated. Paul One of the drawbacks of *photographic* scenery is manky shadows on flat buildings / bridges etc. The 'suspension of disbelief' tends to be better when the scenery is less 'realistic' but has no shadows etc to spoil the mental picture. I believe that satellite photos can be used well in certain circumstances but on the whole 'blanket coverage' can look far worse - you literally get the feeling that you are flying over a 'polaroid'. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Indicated Turn Rate.
I'm working on a new aircraft model and have just come to putting some instruments in place. I discovered a problem with the turn-coordinator which takes input from /instrumentation/turn-indicator/indicated-turn-rate Unfortunately, as soon as FG starts, this value quickly drops to -2.50 and holds there. (regardless of how you move the aircraft). Has anyone got any ideas how I broke this? The TC doesn't need to be an electrical system does it? Thanks Dave Martin. Note: I'm using a weekend CVS build and the TC works in the other aircraft. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Indicated Turn Rate.
On Thursday 27 Jan 2005 18:06, Curtis L. Olson wrote: I believe the default TC is designed to run off an electricly driven gyro ... so if you have no juice, the gyro will spin down (or never spin up) and you'll see symptoms like you describe. I would suggest dropping in the generic electrical system config to see if that takes care of the problem. Curt. Thank's that fixed it :-) I think I should probably look into making a good electrical system for this model. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Thursday 27 Jan 2005 23:39, Ivo wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo IIRC Xinerama doesn't yet work with OpenGL. I'm actually running a multi-head system but I use a 2nd card and normal x.org definitions for the second display; the drawback is that x.org doesn't (yet) support dragging one window to the other. So, unless I'm pleasantly mistaken, I'd have to presume Ivo is running Windows? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Secondary display - game mode
On Friday 28 Jan 2005 00:02, Dave Martin wrote: On Thursday 27 Jan 2005 23:39, Ivo wrote: On Thursday 27 January 2005 23:08, Drew wrote: Does anyone know the easiest way to run flight gear in game mode on a secondary display. It runs just fine if I drag the window over and maximize it on the secondary display, but I can't figure out how to make it work in game mode. As I don't have Xinerama running here, it is just a guess, but I suppose this should work: export DISPLAY=localhost:0.1 fgfs If the window appears on the secondary display, then enabling game-mode should run it fullscreen. --Ivo IIRC Xinerama doesn't yet work with OpenGL. I'm actually running a multi-head system but I use a 2nd card and normal x.org definitions for the second display; the drawback is that x.org doesn't (yet) support dragging one window to the other. So, unless I'm pleasantly mistaken, I'd have to presume Ivo is running Windows? Dave Martin Just to correct myself, that was mean to read 'Drew' not 'Ivo'. :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..Groklawyers warns GPL developers against
On Friday 28 Jan 2005 01:34, Arnt Karlsen wrote: Did Sun do anything wrong to you, did they steal your sandwitch ? ..no, they haven't done me any harm except as a member of the F/OSS world and except for funding TSCOG's scam lawsuit by buying a US$ 12 mill license, forcing me to spend time at Groklaw to learn enough to save my own wee business, it's what funds my gasification work, without Groklaw, I probably would have had to liquidate my linux business, 2 years back, TSCOG etc was all over the media here. Well, here's thanking you for having the backbone to look after your operation. Its a shame that (the) Sun is slowly burning away. I just hope that not too many more *nix based business are going to go the same way. (I'm still trying to buy a good SGI 02 but I'm having no luck) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: Open Source 3d video card
On Wednesday 26 Jan 2005 03:33, Oliver C. wrote: This might be very interesting for people who are looking for a new 3d video card with full open source drivers: http://kerneltrap.org/node/4622 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm buying one when they reach market :-) But thats only to find out what they're really like. The cards are to be powered by Xilinx Spartan III FPGA cores. Now, I'm told, the top of the range Spartan III has 5 Million transistors on (90nm) die. A quick comparison with the first generation GeFarce with 23 Million on die and things don't look so good. While the cards should be reasonably capable - I wouldn't expect better than Geforce (1) performance. (and hence FlightGear might be a stretch for this card). Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 13:37, Oliver C. wrote: On Monday 24 January 2005 11:05, Erik Hofman wrote: Vivian Meazza wrote: Thanks for this explanation. Why does it only seem to work one way? The description 'enhanced lighting' is not particularly helpful. Oh, this is about enhanced (runway) lighting. That's a different story, I was talking about specular highlights which the original was talking about also. No, i was talking about enhanced runway lightning, this is what i get when running flightgear with this option: --enable-enhanced-lighting I was not talking about specular highlights. Why is it so expensive of frame-rate? This is very hardware and driver dependent. Some OpenGL features are just not implemented in hardware on some display adapters. The only consumer videocards we have today are from Ati and NVidia, do their newest models support this? If not, then we should move it to the advanced options. I also want to mention, that MS FS2004 has something similar, but without framerate drop, so there must be another way to display runway lights in such a way. Best Regards, Oliver C. I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:01, Oliver C. wrote: On Monday 24 January 2005 15:05, Dave Martin wrote: I've also been confused by the monumental frame drop that even the simple runway lighting can produce at airports such as EGLL. And I do have a fairly hefty system which has been known to run graphical behemoths like Doom3 at a fair lick. The obvious response from the 'non-programmers' perspective ie: 'user' is: Why on earth do these little dots bring my new Model-X video card to its knees? So what's the crack? ;) Dave Martin I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:24, Erik Hofman wrote: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How about basic poly with a tiny texture set as 'spherical' (much as is done with the bo105 lights) Would that allow for better performance on consumer hardware or is that too simmilar to the method in use? (I really don't know the first thing about this and I'm guessing) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 14:47, Erik Hofman wrote: Dave Martin wrote: How about basic poly with a tiny texture set as 'spherical' (much as is done with the bo105 lights) Would that allow for better performance on consumer hardware or is that too simmilar to the method in use? It might be a good idea to test both methods and see which one looks best and/or has the best performance. Erik It's probably a bit beyond my abilities to do either - I assume it would need some coding to place the polys on the runway light locations without loading *every* one individually from an XML file. It would be nice to find a 'solution' to better frame-rates at illuminated airports tho because landing at EGLL at night can be near impossible even on 'good' hardware. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 15:44, Vivian Meazza wrote: It would be nice to find a 'solution' to better frame-rates at illuminated airports tho because landing at EGLL at night can be near impossible even on 'good' hardware. This is a good question: just haw are people managing this one? It's OK for me, but I've got good hardware tied to a 21 in screen. Regards, Vivian Well, I'm basically showing it the sharp-end of an AMD 3200XP with 1GB dual-channel and a 128Mb GeFarce FX5800 Ultra-Leaf-Blower and hoping for the best. ;-) I'm also driving a 21 screen @ 1600x1200x32bpp so it does flog its guts out to hold 15-20fps on approach to London Heathrow at night. (even w/o the 'enhanced' lighting) At any other time (no runway lights in sight) I can expect 100fps or more - rarely dipping under 50fps when there are many buildings etc in sight. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 17:50, Jim Wilson wrote: Erik Hofman said: Dave Martin wrote: On Monday 24 Jan 2005 14:01, Oliver C. wrote: I assume that this feature is not supported by the hardware on the consumer video cards. So OpenGL falls back to software mode. That's why we get 1-3 fps here. Well, thats interesting; would that also explain why the normal 'point' lighting has such a crippling effect on the frame-rate? To be honest, I don't exactly know why it has this effect on framerate (or why it isn't supported very well). An alternative might be to use pentagonal vertex-fans and alpha blending which supposedly should perform quite well on all modern hardware. That might work quite well. I've kind of wondered myself what the deal is. It does not seem logical that adding that property should cause the driver to drop into software rendering. It ought to just ignore it. If its of any interest, my GeFarce spits out that it is using OpenGL version 1.5.2 (NVIDIA 6629) and uses glx 1.3 and glu 1.3 Don't even know if thats useful tho :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 19:39, Curtis L. Olson wrote: Something about runway lighting has changed recently. Either newer nvidia drivers/cards have intentionally slowed down some things, or we are doing something different. I don't recall a change on our end, but previously, I never saw any where near the slowdown I'm seeing now when runway lights come on. Regards, Curt. I will 'regress' my way back through the Nvidia drivers and check :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 20:15, Dave Martin wrote: On Monday 24 Jan 2005 19:39, Curtis L. Olson wrote: Something about runway lighting has changed recently. Either newer nvidia drivers/cards have intentionally slowed down some things, or we are doing something different. I don't recall a change on our end, but previously, I never saw any where near the slowdown I'm seeing now when runway lights come on. Regards, Curt. I will 'regress' my way back through the Nvidia drivers and check :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I'm getting roughly the same fps hit due to runway lights with Nvidia drivers down to 4496. Would anyone else like to try and then compare notes? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On Monday 24 Jan 2005 20:22, Vivian Meazza wrote: Erik wrote: Vivian Meazza wrote: Erik Hofman An alternative might be to use pentagonal vertex-fans and alpha blending ^^^ And in English that is ... ? :-) Is that some voodoo? Oh sorry, just a disc constructed from five polygons. OK I'm trying pentagonal vertex-fans and alpha blending for the nav lights I'm just doing for the Hunter. Regards, Vivian Any chance you could stack-up a hundred or so of them and see how the frame-rate goes ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nav radio and 3d instrument output.
I noticed that you (Curtis) added a different output format for the Navradio frequencies in CVS. I had a quick play with this on both my own NavCom and the Citation's - unfortunately it still displays the wrong value on the panel. Last time I asked about this here, the discussion went into 'floating point' issues (and sailed clean over my head). ;-) Is this the same issue causing this and does anyone have an idea for an alternative? ***If you missed the discussion before: When taking a value from say /instrumentation/nav/frequencies/selected-mhz-fmt[0] and using it to texture translate a number on the frequency display of a 3d instrument (nav radio) the value will be shown incorrectly. ie: if the frequency is 110.10 the 3d instrument will display 110.09 - at some frequencies it may read correctly; at other frequencies the error is greater. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
On Sunday 23 Jan 2005 19:35, Jon Stockill wrote: I've recently produced a model of a wind turbine, which I'm in the process of adding to the scenery, but when they're clustered together in groups it looks rather unnatural as they're all spinning round in perfect synchronisation. Is it possible to introduce some random offset to make things look a little bit more natural? If so, how? If you're modelling them individually can you give them an angular offset for their starting point (of rotation?) Alternatively, would it be possible to use 2 or three versions of the same model with the initial rotation 'hard-coded' by the modeller? Also, I was actually thinking about Wind Turbines earlier today; are you having them face into-wind and altering the rotation speed depending on windspeed? They don't vary that much in real-life (they are governed) but obviously they stop at a certain point. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
On Sunday 23 Jan 2005 21:30, Jon Stockill wrote: Frederic Bouvier wrote: Jon Stockill a écrit : I've recently produced a model of a wind turbine, which I'm in the process of adding to the scenery, but when they're clustered together in groups it looks rather unnatural as they're all spinning round in perfect synchronisation. Is it possible to introduce some random offset to make things look a little bit more natural? If so, how? I did something for the radio towers. they don't blink at unisson. I introduced the use-personality tag but this is done only for the timed animation. What animation do you want to have personality ? spin, rotation ? this must be implemented in animation.cxx Spin. I'd like to be able to have either a random rotational offset, just so all the blades don't line up, or preferably a small percentage variation in the speed. I'm not in the know but could 'property-randomize' be used to slightly vary the spin rate? I think it is formatted: commandproperty-randomize/command property/thepropertyyouwantouse/property min1/min max10/max Or something along those lines. I'm not even sure if that is usable because it looks like it writes to the property rather than making it available for an effect (if you follow me). Anyone in the know on the above? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Model animation
On Sunday 23 Jan 2005 23:39, Frederic Bouvier wrote: Jon Stockill a écrit : Frederic Bouvier wrote: If you look at the tower-medium.xml, you will have an idea on how it is made. Jon, I will see if I can do something during the week for the spin animation. Soon on your screen : http://frbouvi.free.fr/flightsim/fg-spin-perso.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Brilliant :-) Self destructing radio masts no less (they cut their own guy ropes) ;-) Any insight into the method you used for the randomisation? Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] EU Software Patents *Fisheries* A-List Monday (Again)
Sorry to be spammy again but I'm still firmly of the belief that this is something that could affect FlightGear or any other FOSS in future. The EU Council is once again pushing the patent bill back onto the A-List of the *Fisheries and Agriculture* meeting on Monday. This is *extremely* underhand and I am personally furious at such erosion of the democratic system in Europe. The Council has obviously realised that they could push this for a Monday meeting without having it discovered until the preceeding Friday making counteraction hard. From the FFII: On Monday, software patents are likely to be passed by the Fisheries and Agriculture Ministries. Dear FFII supporter [1], at the Agricultural Council's meeting next Monday, the Software Patent Directive is likely to be inserted into the list of agenda items in the last minute. The aim seems to be to preempt ongoing efforts in the European Parliament for a restart of the procedure. [2] Please write today to your minister of Agriculture, Fisheries and other political representatives, and ask to have the software patent directive taken off the agenda. Usable argumentation can be found on the webdemo page at http://www.ffii.org/index.en.html Kind regards, Felix Klee, Holger Blasum Please note, this method is being used (abused) to get an entirely unmoderated bill passed. If you are an EU Citizen and feel you want/need to help then please, at least sign the FFIIs protest letter: http://demo.ffii.org/cons0501/support_ltr.php Text of the letter: http://demo.ffii.org/cons0501/letter.html Many Thanks Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rain and snow videos or photos
On Saturday 22 Jan 2005 01:14, Roman Grigoriev wrote: Thanx Martin for you reply! I looked on pc7 - so good but you understand that it's simple texture scrolled over cabin. The main problem for fgfs - refuse to use shaders and over cool things and we have not state-of-the-art rendering for uor super flight dynamics. I don't want to offend you but it's true. to my rain simulation: thing i've done - blur OTW view based on distance (render to texture and then gaussian blur on fragment shader ) looks good but haven't seen rain drops. to simulate it I deside to use particle system that will be connected to aircraft. Thanx Dave for your observations I try to implement it. But I think the main problem will be simulate drops on wind screen and windscreen wipers. My question here: When does pilots use them(whipers)? only on take-off and landing or on route too? Thanx in advance Bye Wipers are typically only used during takeoff / landing and taxying for large jets. IIRC, on the early 737s, the wipers don't have the 'guts' to counteract the airflow over a certain speed. Most light-aircraft are not fitted with wipers and instead rely on direct airflow from the prop (SEP) or often on multi-engine they have a ducted air-blower but this is mainly for keeping the screen clear of ice regardless of the aircrafts known-icing clearance. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Rain and snow videos or photos
On Thursday 20 Jan 2005 18:48, Roman Grigoriev wrote: Hi guys! I try to model rain and snow in flightgear but have some difficutlies because I haven't seen it in real flight from cabin of aircraft. Maybe someone can explain me some features when you have take-off or landing in rain and snow. Is it similar to car? Or maybe someone have videos or photos? Thanx in advance Bye ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I think it was Erik had a model working with the PC-7 for rain. Essentially, rain or snow almost immediately appears to be coming straight at you in 'tunnel' effect the moment that the aircraft begins moving into it. If you slip the aircraft, the centre of the tunnel effect moves toward the direction of slip. Rain specifically also has the effect of an 'upward waterfall' on windscreens which are not actively cleared - spreading towards the outside edges at the top. Another thing is scenery textures for snowfall - I had a go at looking for ways to make the default scenery appear to be covered in snow but I haven't found anything all that convincing yet. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 14:42, Jim Wilson wrote: getting an aircraft working is about 2 parts theory and 1 part voodoo (the part that the basic formulas don't cover). Best, Jim Any sufficiently advanced technology is indistinguishable from magic - Sir Arthur C Clarke. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings (was: Aircraft included in basepackage)
On Thursday 20 Jan 2005 15:38, Jon Berndt wrote: I hear you. Coincidentally, I was thinking of this last night: what do we (JSBSim) need to do before we finally call it a production 1.0 release? The gear problem is the first thing I thought of, as well. Right now I am so focused on getting the new configuration file format ready I had not had time to visit (or revisit) other problems. I also recall that Mathias has worked on this with (as I recall) a lot of success. Jon As an outsider to JSBSim, I do agree that the gear issue would make operating JSBSim FDMs a lot more pleasant. Some YASIM FDMs are actually nicely taxiable now so you can do the whole flight from apron to apron which helps greatly with perceived realism for extended sessions. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 16:13, Jim Wilson wrote: Dave Martin said: On Thursday 20 Jan 2005 14:42, Jim Wilson wrote: getting an aircraft working is about 2 parts theory and 1 part voodoo (the part that the basic formulas don't cover). Any sufficiently advanced technology is indistinguishable from magic - Sir Arthur C Clarke. Ok wrong word. Let me just say that it seems to lack some magic. Setting up the p51d in Yasim was not my original intention as Jon S. Berdnt was claiming at the time I started the 3D that he had a nearly working JSBSim model. Doing the yasim model was a juggling act that started with geometric specifications, a couple software patch submissions, and then an endless number of tweaks. The tweaks were really comprimises that ended up producing something that was sort of close to performance specifications, but not really accurate in any respect. Best, Jim Thats litterally what I've just been doing with the B1900D FDM. The numbers in the FDM file don't all match up to the numbers in the POH but the FDM does now match with the *performance* figures in the POH - Which I hope is the right thing to aim for. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 16:43, Christian Brunschen wrote: Hi, The Mac OS X build of FlightGear 0.9.8, as available from http://prdownloads.sourceforge.net/macflightgear/FlightGear-0.9.8.dmg? download, contains a file called 'How to Get to Heaven.rtf', at the root level (beside the OpenAL installer package and the FlightGear application directory), with bible quotes and essentially religious proselytizing. Here's a screenshot of the Mac OS X Finder window for the FlightGear-09.8 disk image: I find it rather bizarre if anything. Although third party distributions of FG are compiled / packaged independently I can see how it leave a 'bad taste' to have someones unrelated morals not neccesarily *inflicted* but certainly presented to you. Technically it could be called 'spam' as it is unsolicited ie: You wanted FlightGear for OSX - You were given FlightGear for OSX + religious spam. And anyway, everyone knows how to get to heaven; just keep pulling up! :-P Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 17:35, Melchior FRANZ wrote: * Christian Brunschen -- Thursday 20 January 2005 17:43: Is it really a good idea to have essentially religious propaganda shipped in the semi-official build of FlightGear for Mac OS X? No! I'm utterly disgusted by this abuse! It's an offense to all Jews, Muslim, Hindu, etc. and it has *nothing* to do with FlightGear. I don't want to see my name and my contributions in the context of religious or other propaganda. 1. The responsible person should be asked to *immediately* remove the offending religious content. 2. If he refuses (which the GPL lets him), he should not be given any further support. He should be banned from the mailing lists. 3. The project should note on the homepage that it is in no way affiliated with and distances itself from any religious or other propaganda that is distributed together with FlightGear. m. :-( Although in not such vociferous terms I am inclined to agree. I have not made any significant contribution to FlightGear yet, I would be disappointed to see my name associated with rhetoric to which I do not subscribe. I would also suggest that upon the insistance of the inclusion of this document, the best option would be disavowment. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 17:37, Jim Wilson wrote: Yes, I'm aware of the theory behind fixing these issues, but from the beginning I was compensating for them and getting reasonable thrust numbers (I think you are thinking of Vivian with the spitfire). On the last round Andy made some code changes, but I got stuck with solver issues when trying to crank up a little more power. Also I did not mention that there are some subtle problems that affect handling the aircraft during takeoffs that come into play when you start tweaking. I vaguely remember a further problem with Yasim in connection with engine power, but it'll require getting my head back into it before I know for sure. Best, Jim I'm dealing with such problems in getting the b1900d to perform in the cruise. Unfortunately, while it handles well in the circuit, the cruise speed is stuck at 200kts @ 20,000ft (70 below POH) :-/ Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 17:52, Erik Hofman wrote: It almost makes me want to some citations from James Bond (as described by his godfather Ian Fleming) and the holy spirit (shaken not stirred) which undoubtedly will be the next religious trend due to the spectacular ways he hes been saving the world. But then again ... Erik That reminds me; I must get a technical drawing of the Wallace Autogyro - thanks for that :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 18:01, Dave Martin wrote: On Thursday 20 Jan 2005 17:37, Jim Wilson wrote: Yes, I'm aware of the theory behind fixing these issues, but from the beginning I was compensating for them and getting reasonable thrust numbers (I think you are thinking of Vivian with the spitfire). On the last round Andy made some code changes, but I got stuck with solver issues when trying to crank up a little more power. Also I did not mention that there are some subtle problems that affect handling the aircraft during takeoffs that come into play when you start tweaking. I vaguely remember a further problem with Yasim in connection with engine power, but it'll require getting my head back into it before I know for sure. Best, Jim I'm dealing with such problems in getting the b1900d to perform in the cruise. Unfortunately, while it handles well in the circuit, the cruise speed is stuck at 200kts @ 20,000ft (70 below POH) :-/ Dave Martin Aha! My mistake - it appears that the ASI in the b1900d is not pressure compensated. According to the GPS, the aircraft is achieving its expected GS of 270kts. Am I understanding that correctly? Thanks Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 19:24, Arthur Wiebe wrote: Hi Everyone, In case you don't know I'm the one who created the distribution in question. First of all I believe that the contents of the RTF file should be welcomed by everyone, and I also believe they are true. You have every right to believe that, but not to expect it. But I also realize that it may be harmful to this project by turning people away from it. What I will do and am in the process of doing is update the package to include this in an About.rtf file: The following contents have been included by Arthur Wiebe and may not reflect the views of any of the contributors or developers of the FlightGear project. O hope that satisfies this issue. My personal opinion is that if you must include such a file, it would be better if you included that text at the start of the file itself. However, I do not see that there is any place for religious rhetoric in a package which I'm sure we would all be happy for all of the religions of the world to download and enjoy. I have personal reservations about any work that I provide being included in a package which includes religious views. As I licence anything I contribute here under the GPL I have no say in this matter. I can only hope to distance myself from such potentially polar views. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 19:45, Curtis L. Olson wrote: Dave Martin wrote: Aha! My mistake - it appears that the ASI in the b1900d is not pressure compensated. According to the GPS, the aircraft is achieving its expected GS of 270kts. Am I understanding that correctly? Yes, you have to input true airspeed into the cruise section, not indicated airspeed. At high altitudes there is a significant difference. :-) Curt. Is there any way to get a compensated 'TAS' output to drive the ASI because I *think* the B1900D's ASI is compensated (but I must check) Cheers Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 19:44, Lee Elliott wrote: On Thursday 20 January 2005 17:03, Jon Stockill wrote: Downloading Lee's Canberra model first may help :-) I don't think it quite reaches it's altitude performance yet (I've been thinking about a PR version sometime). However, I once got the YF-23 200,000 ft (and still climbing at a fair lick). Both fdms still need a lot of work. LeeE Is there a 3d model for that Canberra? - If so is there any chance of some eye-candy? :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 19:47, Jim Wilson wrote: We'd be a lot further or at least I'd have accomplished more along the lines of 3D modeling and enhancing animation/rendering code if I hadn't spent so much time working on something I know hardly anything about (flight modeling). This isn't to take away at all from the great work that folks have done with the FDM code. Is there any chance someone out there is interested in focusing on improving the flight model definitions for the 3D art that we already have? Best, Jim If you mean working with the figures in the definition files then yes, I'm having a fiddle here and there (mainly B1900D at the mo to get it flyable). Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 20:10, David Megginson wrote: On Thu, 20 Jan 2005 20:06:13 +, Dave Martin [EMAIL PROTECTED] wrote: Is there any way to get a compensated 'TAS' output to drive the ASI because I *think* the B1900D's ASI is compensated (but I must check) I'd be pretty incredibly surprised to see an ASI doing that. Some ASIs do have a circular sliderule (or similar) around the edge to calculate true airspeed, but all ASIs necessarily show indicated airspeed because that's what has the most aerodynamic significance for the plane (i.e. it's going to rotate, climb, approach, stall, etc. at the same indicated airspeeds at 10,000 ft density altitude and at sea level, even though the true airspeeds are significantly different). What is the density altitude is the TAS for the Beech 1900 specified at? 25,000 ft? If so, then divide by about 1.5 to find out what number you should see on the ASI. All the best, David I couldn't find any further info on the ASI being compensated and you're undoubtedly right so I will go with that. Thanks :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] EE CanberraBI8 (FAO Lee E)
WOW! I don't know where you find the time or where you keep that bottomless bucket of talent but this is another gorgeous model! It seems that you will soon have covered the majority of Britains best jet-age aero-engineering heritage. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.8, Mac OS X build
On Thursday 20 Jan 2005 21:11, Curtis L. Olson wrote: If we want to hop on the bandwagon and start stamping things out let's go after the big problems like aids, or poverty, or Jennifer Lopez/Ben Afflec movies. Regards, Curt. I'll go with all of the above especially the latter ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D
On Wednesday 19 Jan 2005 02:24, Curtis L. Olson wrote: Yasim has a magic solver that is sometimes sensitive to specific inputs. In the back of my head I imagine a little robot trying to climb to the highest point on the map by always going up ... but then coming to the top of a smaller hill and getting stuck. The solver tunes the lift and drag coefficients to make the aircraft hit the numbers you specify ... so if you provide engines that are too weak, you will end up with a super slick model which an incredibly efficient wing ... thus it can still hit the numbers but has really slow acceleration and climb. On the other end of the spectrum, if you provide too much power, you end up with a high drag, low lift model (so you don't blow past the provide performance numbers.) This will give you great ground acceleration and probably great climb, but will still top out at whatever numbers you specify. So once you have your basic YAsim model flying, you can tune things like rate of climb by adjusting actual engine output. You can tune roll/pitch rates by adjusting the size or effectiveness of the control surfaces. I'm not convinced you could get a YASim model close enough in every area to get FAA level 3 certification or higher, but you can get a really fine flying model in most regimes with a bit of tweaking and understanding (at least at a simple level) how various configuration options relate to each other. The other thing that confused me early on was how YAsim handles weight. I don't remember the rules well enough off the top of my head to summarize them here, but the solver solves at 80% fuel load I believe. This means that unless you are very careful with your fuel load and the weight the solver uses, you won't hit your performance numbers exactly ... those number only are for one particular aircraft weight. Once you figure out how to control the weight the solver uses and figure out how to configure the aircraft at that exact same weight, you do hit the performance numbers dead on. For someone like me with zero aeroengineering background, YAsim is a *really* fun tool to play around with. After a few hours with it, I almost feel like I understand it enough to build pretty plausible numbers. When it comes to stability derivatives and aero coefficients, I'm still pretty much as clueless as the day I was born. Curt. Thanks for the advice; the B1900D FDM is really coming on now. I've got her flying the 'envelope' and I'm managing to balance out the flight characteristics nicely. Something I noticed early on is that the mass needed distributing for things like Engine+Gearbox sets and Maingear etc as Yasim just evenly places the dry mass otherwise. I do agree that Yasim is great fun to work with - feels like I'm learning a lot. A bit more flight testing and then I will show what I have got and you can all 'shoot me down' ;-) Dave Martin Footnote: It appears that the B1900D props *do not* counter-rotate after all. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday 19 Jan 2005 20:36, Paul Surgeon wrote: If the authors released their work as GPL those low lifes wouldn't even have to change the credits and what sort of recourse would the authors have then? Paul The authors would have no recourse then. If they had willingly licenced their work under the GPL, they are permitting anyone to make commercial use of their models / work providing that credit is not removed and the source of the work and any modifications to it is also made freely available. It is the Authors choice to use this licence. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday 19 Jan 2005 20:59, David Megginson wrote: The redistributors either have to include the full original distribution, unmodified (including any README files, etc.) or else they have to provide a way to get it -- that tells their customers that there's a way to get the same stuff for free, so unless they're adding some other kind of value, they're not going to make any money. All the best, David Thats a good example. If someone were to stick *all* of FG onto CD / DVDs and sell it, there is added value in terms of the bandwidth saved (What is FG now? 12GB or more inc scenery?) Of course, anyone doing so would need to make clear that FG is GPL software and freely available on-line. This is rather like the Open-Office.org resellers guidline policy. Whether it would even be profitable or wothwhile to do such a thing is another matter; it must surely be a shrinking market with the uptake of broadband. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday 19 Jan 2005 21:21, Chris Metzler wrote: On Wed, 19 Jan 2005 21:02:10 + Dave Martin wrote: The authors would have no recourse then. If they had willingly licenced their work under the GPL, they are permitting anyone to make commercial use of their models / work providing that credit is not removed Just for clarification, you have to be careful about that last bit. The GPL allows this because you copyright your creation and you write a copyright notice in your name. The GPL requires that all the copies come with a copyright notice. However, things like CREDITS files and so forth are not protected under the GPL; the GPL does not require that credit not be removed, apart from protecting the copyright notice. In fact, the GPL prevents such a restriction from being placed on a work released under it. That fact was at the heart of the conflict over the new XFree86 license; most Linux distributions have dumped XFree86 over its subsequent incompatibility with the GPL. -c I think I misworded that a bit. I was meaning the 'one liner' that is often added to the GPL copyright notice which includes the originating Author's name. one line to give the program's name and an idea of what it does. Copyright (C) name of author I was always under the impression that was the notice to remain intact? Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Licensing (was Re: [Flightgear-devel] Aircraft downloads)
On Wednesday 19 Jan 2005 22:29, Curtis L. Olson wrote: Oh, and please, those who need to eat or feed their kids, please continue to do so. :-) Curt. I find it vaguely disturbing that you feel it is okay for people to consume their offspring. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] B1900D FDM (Test pilots req'd)
I've been working up the FDM for the b1900d and I have it flying quite nicely now. The numbers are no longer 'book' but rather ones that allow the aircraft to perform within the parameters of the FDM. Changes of note: The ailerons are more effective; with the 'infinite human strength' effect, full deflection (hence drag) is no-longer neccesary. The props are less 'massive' The props on the B1900D are actually very lightweight composite units. The reduced mass has alleviated the horrendous torque-induced roll. (The b1900d does not have counter-rotating props). Mass distribution is now in place for the nosewheel, avionics, engines, gearboxes and maingear. This reduces the pitch instability and the nose lifting at the start of the takeoff roll. Wings are now 'twisted' 3deg camber at the root to -1deg camber at the tips. The flat-rate is now 1000bhp/engine rather than the book figure to fit the POH characteristics rather than numbers. Flying it: Full power to take-off, 2-stages of flap, rotate at around 95kts, unstick 105kts. contine to rotate to prevent speed building too fast. Once the flaps are in and the gear is up, the aircraft should climb at a bit over 2000fpm at 160kts. Stalling: Clean occurs around 100kts with a fairly sharp wing-drop. Dirty (gear flaps) occurs 85kts or less sometimes with a *nasty* wing-drop if still heavily loaded - be careful! ;-) Landing: Once inside the flap-arc, 2 stages flap, 130kts gear-down, full flap, establish 120kts. Fly it all the way down like this and flare very gently while bringing the throttles back. (The nose will only be up a little compared to many other aircraft). To compare the landings with the real-thing, check http://www.flightlevel350.com for videos. Also note that the ASI doesn't appear to read dead-on at all speeds (or perhaps the HUD is on ground-speed??) Let me know what you think :-) FDM: http://www.cyfinity.com/fgfs/b1900d.xml - copy to your Aircraft/b1900d/ directory after backing up the original. Cheers! Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft included in base package
On Thursday 20 Jan 2005 01:57, David Megginson wrote: In combination with this change, I'd like us to start thinking about changing the starting airport to Palo Alto (KPAO) rather than KSFO. It's more in proportion with the C-172, and with a few buildings, etc., we could have it looking quite nice. A few minutes after taking off from there and flying in a straight line, a new user will pass over KSFO, which will be more exciting to look at from the air, and then San Francisco, adding a nice sense of discovery. All the best, David Sounds like a great idea :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Missing scenery
On Tuesday 18 Jan 2005 13:11, Jon Stockill wrote: I've just noticed something a little odd while testing out my objects export code - I'd accidentally removed a chunk of scenery, and noticed that shared and static objects are not displayed when there is no terrain available in a tile. While this isn't a problem most of the time it means that it's not possible to place oil and gas rigs in the sea unless they're close enough to the coast to be on the same tile as the land. Aha! I wonder if that is why I couldn't find the Morcambe field? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] b1900d FDM
Is anyone currently working on the b1900d FDM? The reason I ask is that while the model is gorgeous, the FDM is relatively broken. I've tried fixing the FDM before a couple of months ago but I didn't get anything acceptable. The aircraft accelerates at a hell of a rate on the ground but wont unstick until about 160kts with flap and when it does, the torque effect requires full right aileron to counteract until the airspeed reaches 200kts. (which takes a matter of seconds). Also, if you fight the aircraft level and then apply full-flap, cut the throttles and hold your altitude to the stall, you find that the stall occurs at 120kts and immediately causes a vicious spin. For the Torque, don't the b1900d's have counter-rotating props? As for the FDM's aerodynamics, I've yet to work out exactly what is wrong (the numbers look right but the result is rather like a dragster without wings). Any thoughts? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] QuickSilver MX - anyone making this?
On Tuesday 18 Jan 2005 18:45, Don Oliver wrote: Is anyone in the process of making a QuickSilver MX ultralight for Flight Gear? If not, I would like to combine learning to make 3d models in Turbocad with learning to make an aircraft for Flight Gear. The MX is a very simple aircraft, with no instruments, and only a lever for throttle, and a joystick for rudder/elevator. The ones that I flew in the early 80's didn't even have brakes. Don I was mucking about with a flexwing design for a while. I did think of doing a Quicksilver but I decided against it because I like 'navigable' aircraft ;-) It'd be really good to have a fairly detailed aircraft like the Quicksilver with an 'ultra-open' cockpit to check out the scenery that we are starting to build. I also wondered about trying to simulate a BRS system that you see on many Quicksilvers but I'm not sure if the FDMs would support such a thing. Look forward to seeing it :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Tuesday 18 Jan 2005 22:07, Lee Elliott wrote: By all means have a go at tweaking any of the a/c I've done:) Be aware that flight testing is a very time consuming process though;) The point about the low fuel load for displays is pretty important - with a very low proportion of fuel on board the TOW is going to be around 700,000 lbs but the total thrust available i still going to be around 300,000 lbs - that's a pretty good thrust to weight ratio. On that other hand, at MTOW the AN-225 can't even taxi i.e. turn on the ground. In the video it looks like it's getting roll rates of about 20-30 deg/sec - I'll have a look into it myself a bit later. One thing that's just occurred to me is that I'd expect the roll rate to be higher at low TOWs because there's less mass to move. Has anyone any idea of what the minimum required roll rate would be for something like this? Another important factor with the AN-225 in the low speed regime are the slats but they don't seem to produce the pitch-up I'd expect. Dunno... LeeE I've been trying to get the aircraft to do the display detail with the outer tanks empty and light fuel load on the inners. Does the FDM accurately model roll inertia when the outer tanks are full? Fantastic model btw :-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On Tuesday 18 Jan 2005 22:31, Lee Elliott wrote: I loved the entry for the ufo:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Dammit! Its a conspiracy! Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900D
On Wednesday 19 Jan 2005 01:14, Syd wrote: Hi all ... I see someone else is having problems with the B1900D. It was my first attempt at a yasim aircraft ... and I still cant get it to fly right ! I dont know about the counter rotating props ... it was a LOT of guess work. So if someone can find a cure for it or give me specs , I'll be happy to attempt to fix it . ( It is a long way from being finished). I did read somewhere that it had a wing incidence of about +3.5 at the root and -1 at the tip , but it crashes the program every time I try to implement it . Im currently fixing the panel for plib 1.8.4 , should be able to send an update tonight. Im afraid Ive tweaked the FDm to the point where it crashes FGFS AND FGRUN :) ... so I'll leave that out .Cheers Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Lovely model! Well, so far, I've counter-rotated the props for now till I can find out if they do in real life. I've got the thing flying reasonably and the stall normalised at about 80-85 dirty / 100ish clean. I've already experienced what you mention with the incidence at the tips (the twist of the wing). I'm trying to work out if I can make an average between the two that wont make Yasim throw the toys out of the pram. I've also managed to reduce the 'dragster' runway performance a bit but it needs more work to match up things like rate-of-climb etc to the real figures. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Antonov AN-225.
I've just been poking round for information on the Antonov AN-225 specifically regarding roll-rate. I initially found a few references made by the pilots of this aircraft that it is as responsive, if not moreso than the Ruslan. The FDM for FGs AN-225 has incredibly sluggish roll response and sometimes you can find yourself unable to lift a wing from 45deg bank with flap and low-fuel load. (170-200 knots) So, with a bit more poking, I found some videos of the AN-225 at airshows where they really shove it around. In the video linked from this page: http://www.planestv.com/planestv/an225.html the roll rate is very quick and there is no evidence of maximum aileron deflection (although only the port wing is visible as the roll commences). Also of note in that clip is the very 'positive' landing ;-) I estimate the speed to be around 170kts based on leading edge slats and 75% flap setting along with anecdotal evidence that the display sorties are flown around this speed for manouvering. There are a few more videos flying the same detail with possibly even quicker roll rates here: http://www.airshowphotography.com/videos/videos2.html One of which shows a touch-and-go followed by an enthusiastic roll to 30deg immediately after takeoff. Of note that a single aileron on an AN-225 is more than the total span of a 172's wing :-O So what do you think? - Shall I have a go at the FDM or is someone else better qualified? ;-) Cheers. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Monday 17 Jan 2005 15:31, Martin Spott wrote: Dave Martin wrote: http://www.airshowphotography.com/videos/videos2.html Nice, a 45 degree turn just one wing-span AGL :-) Martin. I've been playing with the FDM and changing the line in the yasim file: flap1 start=0.75 end=0.95 lift=1.15 drag=1.3/ to flap1 start=0.75 end=0.95 lift=2.0 drag=1.3/ seems to give a realistic response at low speed. Just changing the lift factor of the aileron makes the detail in the videos flyable and doesn't seem to give any unrealistic behavior at full deflection etc (50% deflection seems about the same as 100% at low speeds). If anyone else would like to try her out with that lift factor change we can compare notes :-) Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Antonov AN-225.
On Monday 17 Jan 2005 17:06, Vivian Meazza wrote: Dave Martin wrote On Monday 17 Jan 2005 15:31, Martin Spott wrote: Dave Martin wrote: http://www.airshowphotography.com/videos/videos2.html Nice, a 45 degree turn just one wing-span AGL :-) Martin. I've been playing with the FDM and changing the line in the yasim file: flap1 start=0.75 end=0.95 lift=1.15 drag=1.3/ to flap1 start=0.75 end=0.95 lift=2.0 drag=1.3/ seems to give a realistic response at low speed. Just changing the lift factor of the aileron makes the detail in the videos flyable and doesn't seem to give any unrealistic behavior at full deflection etc (50% deflection seems about the same as 100% at low speeds). If anyone else would like to try her out with that lift factor change we can compare notes :-) The AN-225 is Lee Elliot's pet, but remember that air-shows are very often done with minimum fuel and no load. Heuristically, a lift factor of 2.0 is perhaps too high for a plain aileron. 1.2 - 1.5 would be normal, and with drag to match. But I agree that as it is the aircraft seems on the sluggish side. Regards, Vivian I was originally testing with absolute minimum fuel and I could still get it into situations where it wouldn't lift the inner wing from 45' bank at 170kts. I'm going to have a go with a figure of 1.5 for lift. One thing tho; the lift figure is the 'maximum' ie: at full deflection. Could we expect that the Aeileron might make that much at full deflection but such a deflection would also be structurally damaging to the aircraft at above takeoff / landing speeds. In the videos, the aeileron deflection used to induce high rates of roll doesn't appear that much. Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] more google adds
On Sunday 16 Jan 2005 09:34, Christian Mayer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Curtis L. Olson schrieb: I did another round with google adds today and here's what I've come up with which seems (to me) like it could work out. 1. No adds at all on the main/front page of our site. Adds only on the subpages. Sounds fair 2. I've had mixed results filtering out MSFS stuff, but that's mostly because there is a lot of it. I think if I continue to add sites to the filter rules, I can get most of them. I've looked at the different pages. The ads are mostly the same - and of good quality (i.e. no advertising for other sims; the ads are for interesting stuff) The only ad I didn't like was www.ebay.de PC and video games can be found here cheaply reasons: - - if I want to visit ebay I'll do it directly, so the ad is taking away space - - at ebay you'll find MSFS and not flightgear... - - personally I don't line their aggressive marketing policy (they tolerate search engine spamming; probably they are supporting it even) Quick! Lets flood ebay with FGFS cds ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Any info for Chalgrove UK?
I've just flown over Chalgrove (near RAF Benson) at night. Except I didn't know it was Chalgrove I then spent 2 hours trying to work out what this huge 3 runway centre-intersecting airport with full runway lighting and PAPIs was. ;-P Its obviosly very mis-laid in FlightGear (maybe by DAFIF)as Chalgrove in real life appears as a classic RAF undeveloped 3-axis triangular airfield with very minimal infrastructure. I know the basic layout but it would be good to have accurate details - although I assume it is non radio and unlit. Cheers Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Any info for Chalgrove UK?
On Friday 14 Jan 2005 21:08, David Megginson wrote: On Fri, 14 Jan 2005 20:59:23 +, Dave Martin [EMAIL PROTECTED] wrote: I then spent 2 hours trying to work out what this huge 3 runway centre-intersecting airport with full runway lighting and PAPIs was. ;-P It looks like the runways are fairly large in real life as well: http://worldaerodata.com/wad.cgi?airport=EGLJ Martin Baker uses the airport for testing ejection seats, and flies a Meteor jet out of it (that would explain why one runway was extended to 6000 ft): http://groberson.members.beeb.net/Chalgrove_Airport.htm I haven't downloaded that scenery, but the fact that the runways intersect in the middle suggests that we have the centre LAT/LON for the airport rather than for the individual runways. I haven't been able to find any information about lighting, but I wouldn't be surprised to see a VASIS or PAPI with the jet there. All the best, David Well, what I'll do is move the runways out to their approx locations about the centre of the current FG layout and leave the lighting intact. I'll submit that to David Luff and then at least we have a basic layout to build upon. Cheers Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
