Re: [Flightgear-devel] Re: Helicopters: wow!
[EMAIL PROTECTED] wrote: Because of my german keyboard layout i needed to press the ALT+0 key to get the } key pressed, that was a little irritating for me, because i looked for the corresponding german key by the key location and not by the key character, but that didn't work of course. FYI the key location for the } key button is the * button on a german keyboard, but the key character for the } character is available by pressing the ALT+0 keys. I'm concerned that you had to press *any* key. If you are using the current CVS, the helicopter should already be running when FlightGear starts. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Is the world round or flat ?
Danie Heath wrote: I just wanna find out how Simgear actually works. Does it generate the world as a sphere, or as a flat world ? An irregular WGS84 spheroid, I think, which is more accurate than either flat or spherical. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Helicopters: wow!
I just tried flying the bo105 around Ottawa a bit: FlightGear has made an incredible amount of progress over the past few weeks. All of the jitters in the heli flight model are gone, the 3D interior looks great (though it needs a bit of instrumentation -- I'm using the HUD for now), and the sound really helps to set the mood. I'm still not good enough to land on top of one of the little white apartment buildings, though. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Human conquers helicopter
Finally. On the roof, with the engine shut down, after taking off from a nearby airport: http://www.megginson.com/flightsim/roof.jpg Airspeed management is very different in a helicopter than in a plane -- I'm still trying to get a handle on it. By the way, I always have to put on the parking brake (!!) to stop the skids from acting like wheels. Is there an easy fix to the YASim model? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Human conquers helicopter
Jim Wilson wrote: Pull back on the cyclic stick. Depending on what speed you are going dropping collective too. I like to swoop down to create some downward momentum and then pull back. I'm not sure if this is a legal move :-), but if you are going really fast and want to stop quickly, pull the stick way way back and raise the collective all the way up for a few seconds. Kind of like reverse thrust on a jet. Thanks. I do understand that part, but I'm still trying to get a feel for the exact speed effects, especially through the transition from cruise to hover. Part of the problem is the ground effect isn't modeled. It is in FlyII and that helps quite a bit with hovering as for a landing. I've read that flight training in the real world usually involves hovering around the field at about 10-20 ft for quite some time (until it becomes second nature). It does, from what I've seen at airports: not just hovering, but hover-taxiing and (especially) gazillions of autorotations. To learn to control the bo105, I made up a little exercise for myself to climb to 5 ft, hover-taxi forward, land on the next runway stripe, and repeat to the numbers at the end of the runway. Anyway, I'm off to find a roof. :-) Try to make sure that you're down around 15 kt before you get too close to the roof. In the bo105, at least, if you have to raise to nose to lose speed, you can also lose sight of your landing spot. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Human conquers helicopter
Jim Wilson wrote: Yep, it is a feel, how much collective lift to add. The thing that usually screws me up is the tail rotor when hovering. In general the rudder control on my X45 sucks, partially because it is my left hand and I'm very right handed, but also because it is a rocker. How are the helos with the pedal controlers? I haven't tried that recently -- it's such a pain to set up the yoke and rudder pedals that I rarely bother. I just use the two little sticks on my WingMan, or alternatively, drag the mouse left and right for the rudder. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Human conquers helicopter
Andy Ross wrote: Never mind. Someone already added a skid attribute to the parser (or maybe I did long ago and forgot). Just set skid=1 on the gear objects and remove the brake mappings from the property tree. Done. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Easy-XML
Andy Ross wrote: I'd strongly suggest using the property tree parser. Me too, simply because it's at least an order of magnitude easier. However, I suspect that Jon wants to use EasyXML for parsing the coefficients, and I have to admit that the property-tree format will be fairly verbose for modelling long tables. Assuming, then, that Jon ignores our advice, I'm attaching a few hints for using EasyXML. EasyXML is what the XML community calls a SAX-like parser; the rest of the world would probably call it a fancy lexical analyzer. The parser reads a raw XML document and delivers a series of cooked parsing events to the client. For example, consider this document: poem lRoses are red,/l lViolets are blue./l /poem A SAX-like parser will report the document to the application as a series of events something like these: startDocument() startElement(poem) data(\n ) startElement(l) data(Roses are red,) endElement(l) data(\n ) startElement(l) data(Violets are blue.) endElement(l) data(\n) endElement(poem) endDocument() Note that the parser has no way of knowing what whitespace does and does not matter to your application, so it reports all of it. The application is reponsible for keeping track of the context, etc. etc. Like SAX, EasyXML reports these events to the application through callbacks. You create a class extending XMLVisitor and overriding the methods for the events that you are interested in, then you pass an instance of that class to readXML() as an argument. EasyXML will invoke the appropriate methods to report the parsing events, and that's all, folks. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Carrier taxi
Here's a simple command-line to start lined up for takeoff on the Saratoga aircraft carrier: fgfs --lon=-122.575412 --lat=37.726849 Unfortunately, all is not happy. A full-speed takeoff results in strange problems, so try a slow taxi to the ramp (say, 1000 rpm). The nosewheel sinks in about halfway and the plane ends up nose down, embedded in the carrier deck. Even if the plane could make it to the ramp, it wouldn't climb it properly, because JSBSim (and possibly YASim as well) does only one terrain-elevation calculation for the whole plane, rather than one for each wheel -- as a result, the plane will not slope on a sloping surface. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DC3-Cockpit
Erik Hofman wrote: http://home.arcor.de/iljamod/fg/dc3.tar.gz This looks very nice! If David agrees we should add this to CVS. I haven't looked at it yet, but no objections anyway. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] easyxml
Seamus Thomas Carroll wrote: Is it possible to then parse buffer using the property-tree code? I am looking at void readProperties( istream input, SGPropertyNode *start_node, const string base ) but i dont understand what the base is for. You could pass it an istringstream wrapped around the string (include sstream), except that not all compilers used by the project are ANSI C++ conformant yet. We haven't had occasion to parse XML from strings yet, but the capability shouldn't be hard to add. Please remind me in a couple of days if I haven't done it yet. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Landing Gear discussion
Jon Berndt writes: In the end, it could turn out that a physics-based approach is not worth the effort, and we should simply make the aircraft do what experience tells us a real aircraft would do. As either you or Andy mentioned before, the problem is the transition. Improving the steering gain might help a bit, though. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Erik Hofman writes: So now you've got: 1. friction calculate every wheel separately. 2. add all frictions for the landing gear. 3. make the friction for every wheel dependent to wheel spin and use the result for moments and force calculations. 4. calculate the moments and forces for the complete landing gear. 5. calculate the result by averaging(?) the results for the complete gear (add this for all wheels) and every separate wheel. Does this make sense? When standing still, you then have to clamp the forces and moments somehow so that they don't cause any previous force or moment to change sign: i.e. the ground reactions can reduce any previously-cumulated force or moment to zero, but they must not be allowed to make a positive force or moment negative or vice versa. When moving, of course, the situation is different, especially in the z-direction (they call student circuits bounce-and-go's for a reason). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Landing Gear discussion
Jim Wilson writes: So then what would happen if you artificially introduced resistance at the same time (near zero velocity) in a manner similar to a partially applied parking brake? The problem is that if the landing gear produces opposing forces or moments that are too great, the plane starts moving or turning in the opposite direction. They have to exactly balance for the plane to stand still. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Landing Gear
Andy Ross writes: Hrm... well that throws a wrench into the static spring force while stopped idea. Maybe it could be salvaged by doing the static spring computation only in the (1D) transverse direction... Again, I'm wondering if this is an aerodynamic problem (aside from the bouncing-around-sitting-still thing). Because of its lifting surfaces, a plane is certainly more vulnerable to the wind than a car, even when it is sitting on the ground; however, the coefficients we use in JSBSim are designed to deal with a relative wind near or above the plane's stall speed, coming straight onto the nose +- about 20 deg vertically or horizontally. They probably do a pretty crappy job of modelling (say) a 15 kt gust hitting the plane from 90 deg when it's sitting on the ground. I expect that the same applies to the assumptions made by YASim's solver. I don't speak physics/math/engineering, but I'm going to try to fake it and suggest that there's a strong jargondiscontinuity/jargon in the effect of relative wind on the aircraft once the wind falls more than a little below the stall, particularly when the wings are no longer bearing much of the aircraft's weight. Neither JSBSim's coefficients nor YASim's solver deal with that continuity well -- in the first case, there's probably very little data available; in the second case, it may not be possible to extrapolate it from the aircraft's in-flight performance. Here's something that would help: let's look at the total forces and moments acting on a the plane sitting on the ground during, say, a 20 kt crosswind. If they're moderate, then it's a weak-gear problem; if they're excessive, then it's an aerodynamic problem. For example, depending on tire pressure (etc.) I'd guess that it takes somewhere between 100-200 lb of force (is that the right term?) to start a small single-engine plane rolling on level pavement -- easy for two adults, difficult for one. Once the plane's moving on dry pavement, one person can keep it going by pulling moderately hard. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Landing Gear discussion
Jim Wilson wrote: Can't we bring in some sort of damping factor that would just render the aircraft stuck at very small velocities, but would still allow it to become unstuck if a great enough force was applied? A sort of automatic parking break that gets applied gradually starting at 0.01 fps and slower. The current brake seems to do a good job of holding most aircraft still. Rather being something that is realistic I'm thinking about some arbitrary value that would be derived through trial and error by the modeler. I was amazed at how tricky this got a year or so ago when I was experimenting with it. I agree that we need some kind of damping at slow speed. Essentially, the gear forces have to become a special case, reducing forces and moments towards zero but never beyond into the opposite sign. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] easyxml
Seamus Thomas Carroll wrote:
Is there a tutorial or can someone give or direct me to a simple example
on how to use easyxml? I am trying to work my way through props_io.cxx
but it is not an easy introduction.
Do you want to work with properties or raw, low-level XML? Properties
provide a higher level of abstraction that hides most of the messy XML
details from you. If you do want to work with low-level XML, look at
the documentation comments in simgear/xml/easyxml.hxx for details.
Essentially, you create a class that extends XMLVisitor, then pass it to
the readXML function as an argument, i.e.
MyVisitor visitor;
try {
readXML(foo.xml, visitor);
} catch (const sg_io_exception e) {
// deal with the error
}
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] easyxml
Seamus Thomas Carroll wrote: I figured out the what you mention. The part that confuses me is how to put the data from the xml file in a desired location. For example if I have the xml document: ... vehicle id1/id lon-128.553223/lon lat54.233123/lat /vehicle ... How does id, lon, lat initialize the variables int id, double lon, double lat? You would have the callbacks in your visitor take care of it, but it's a bit of work the first time. Why not just use the property-tree code instead? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Andy Ross writes: JSBSim and YASim do things pretty much the same way, using a coefficient of friction for gear as they slide over the ground. This integration works fine for a moving aircraft, Unfortunately, not -- when the JSBSim and YASim aircraft are rolling, they are still far too much affected by the wind. In real life, even with 30 kt gusts, you can usually taxi a 172 or Cherokee around as if it were a car. Personally, I do set the controls appropriately just in case (I'd hate for that one gust to get under the wing and flip me), but I have not seen it make a noticeable difference. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport vehicle (driving) sim
Paul Surgeon writes: I don't know about everyone else's experience but I haven't found one aircraft in FG that wants to sit still on the ground even with the engine off. I've never seen a stationary aircraft weather vane into a 10 knot wind in real life. It might be that the problem is not ground reactions but aerodynamics. Even if the ground reactions are accurate, the aerodynamic solver (YASim) or coefficients (JSBSim) may be producing *far* too strong forces and moments for low relative wind speeds and/or extreme values of alpha and beta. That's just a guess, though. In real life, my Warrior II (which weighs about the same as a 172) will sit perfectly still in a 30 kt wind from any direction, with no tie-downs and the brakes off. I wouldn't leave it unattended that way, of course, but it never moves during a walkaround in those conditions (even yesterday, when the 30 kt wind was hitting it from 90 deg). The control surfaces move in the wind, though, and sometimes hurl the yoke into my stomach if I'm not holding it. For a further example, the Ottawa Flying Club never leaves parking brakes on and ties down only at night, unless the winds are very strong. Planes -- even light ones like Cessna 150's -- simply don't roll around in sub-gale-force winds. In FlightGear, on the other hand, a JSBSim or YASim plane will happily start rolling, pitching, and yawing on the ground with sometimes only a 5-10 kt wind. Last time I flew in a PA28 she required a fair bit of throttle to get her rolling even on a hard surface. Check the tire pressure -- unlike Cessnas, Cherokees are notoriously hard to move on the ground if the nosewheel or mains are only a few pounds flat (i.e. too little to see). I actually keep a bicycle handpump and tire gauge in my plane for that purpose. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] AI aircraft carrier
David Culp writes: Ok, I got the Saratoga moving across San Fransisco bay at 30 knots. http://home.comcast.net/~davidculp2/saratoga_SFO_bay.jpg It can't be landed on because the deck is not solid (however you can fly inside and grab lunch). Is there a way to solidify the deck? The carrier would have to be in the main scene graph, where we do collision detection. Even then, however, the plane would not move with the carrier -- the FDM's know nothing about parking on moving surfaces. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Weight Balance data...
Gene Buckle writes: After looking through the various instrumentation files, I noticed that there is no weight data associated with the instruments. For those that don't know, each instrument that goes into the panel is labeled with its weight. This is done to make sure that an accurate dry weight can be calculated. Is there any interest in getting that detailed on the WB calcs? When duplicating a real-world instrument, the weights are easily available and a generic weight could be assigned to avionics that don't model a specific real world model/brand. I don't think we need to worry -- anything semi-permanently installed in the plane (seats, gauges, radios, intercom, etc.) is already included in the published empty weight and moment (which is ammended by an AME [Canada] or IA [U.S.] whenever anything is installed or removed). In a 172 or Cherokee, even the oil is already included in the empty weight. In fact, some things are easily removeable -- most avionics pop out of their trays so that you can bring them in for repair, take them home, etc., without any signoff from an AME/IA. I have also removed and reinstalled VOR and ADF heads, which are a little trickier, but mostly because of the limited working space on the floor under the panel (I needed an AME signoff to reinstall them, but not to take them out). In theory, pilots should ammend the WB whenever they take anything out temporarily or put it back in, but in practice, the weight is so small and so close to the CG that people don't seem to bother. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Airport vehicle (driving) sim
Curtis L. Olson writes: Today I had a chance to see a driving sim located at KMSP. They use it to train drivers for driving around on the airport grounds (taxiways, runways, service roads, tunnels, etc.) The really interesting thing about this sim is they had a beautifully done model of the airport. Every light, every sign, every painted line, every building, probably every tree and squirrel was modeled and placed accurately. You got a very good sense of being at the actual airport without having to rely on memory/imagination. If they ever need a volunteer to taxi around a virtual plane, getting in the drivers' way, let me know. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
Jonathan Richards writes: listgeo gives a whole shedload of information about the mapping, too much to report here unless anyone's interested, in which case mail me. I'd just like to take another opportunity to express my appreciation to the U.S. government for making so much geodata available free -- without their resources and (enlightened) policies, it would be awfully hard to do any free GIS work, much less a Flight Simulator (even the international projects are often mainly U.S.-led and -funded). FlightGear users who are Americans need to remember how important this kind of free information is. Those of us who are not Americans need to press our own governments to follow suit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
Paul Surgeon writes: The USGS is unfortunately a rare example of good governance. Where I live the tax payers pay to get the government to do surveys and then the government sells us the data. :( Ditto for Canada. Fortunately, the U.S. is making more and more data free for our countries as well. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Scanned sectional charts online
There are raw, scanned sectionals and terminal charts available online. I haven't downloaded and unpacked the zipfiles yet, so I'm not sure of the format. Sectionals, at 1:500,000 scale, are the most commonly-used charts for VFR flying -- in Canada, we have the same thing, but call them VNC's (Visual Navigation Charts). For busy terminal areas, there are also special 1:250,000 scale charts available. The other popular charts are the World Aeronautical Charts (WAC), at 1:1,000,000 -- it's harder to make out small details, but there's less chart folding and switching for a long flight. Here are the U.S. 1:500,000 Sectionals and 1:250,000 terminal charts, in TIFF format: http://aviationtoolbox.org/raw_data/FAA_sectionals/East/ Here's the 1:250,000 chart for the SFO area: http://aviationtoolbox.org/raw_data/FAA_sectionals/West/Terminal-Area-Charts/San%20Francisco%20TAC%2063.tif I'm just downloading now, so I'm not sure about the quality yet. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Static objects in scenery and performance
Olivier ABILLON writes: Turning on static objects in the scenery decreases a lot the frames per second rate (about a 33% penalty!) whereas random objects (trees, small buildings, ...) are rather fast to render: There is only a 10% or less penalty on the fps rate. Why there is such a difference ? I designed the random objects small -- tiny textures, only a few polys each. They look fine up to 1000m away, which is as close as most users usually get. It's frustating because the SF area is so nice, especially the Golden Bridge! But on my iMac, the fps rate goes down to about 2-3! There's your answer. Big textures and hundreds or thousands of polys look great, but really hurt the system. We need to make sure that we're displaying static 3D models with, at most, a few dozen triangles each (and even that only for the most famous buildings) unless the viewpoint is very, very close. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Combat anti-flame
Andy Ross writes: In an attempt to depoliticize the combat flame war as much as possible, it's worth pointing out that, irrespective of people's opinions on the matter, there are not a lot of combat features we can really avoid implementing: I've been deleting the combat thread unread, but I got the impression that there was a lot of heated discussion about military stuff. I'd hate to see FlightGear become nothing more than another shoot-em-up game, but I think we've already gone too far for that to happen. I also (personally) think we're a little heavy on the warbirds (especially U.S.) and would like to see more civilian aircraft, but I'm too lazy to get off my behind and make them, so I guess I don't have a right to complain. Otherwise, please wake me up when the discussion is over. All the best, David (peaceful but non-dogmatic Canadian) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Curtis L. Olson writes: If you are running low on video ram, enlarging the window can kill your performance (due to needing to reallocate and shuffle ram.) You can try starting with the window maximized and see if that works. There's also a problem with the NVIDIA drivers on some systems, just generally. For example, if I start with a very small window (say, 320x240x16) and shrink it by a few pixels, that's it for hardware rendering -- we're down to a frame every 30 seconds or so; on the other hand, I can start at 1600x1200x160 and get about 18 fps. I've had that problem for a year and a half, ever since I started using a notebook with a Geforce2Go. I don't have the problem with other 3D programs like the plib demos, only with FlightGear. We must be enabling something that triggers the driver or hardware bug. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: Well what do you define as eye candy? If people don't want eye candy then why do we have ground textures in FlightGear? They are just wasting framerates. I'm not taking a stand in the eye-candy-vs-simulator debate, but this particular statement is not true. Textures (and auto-placed objects like trees) are critical for simulating VFR flight, since they give you a reference point for judging altitude, distance, and ground speed. The different texture types also help a bit with pilotage, particularly the water and urban textures. I just tried this and it does go to VNE. In my experience (a few hundred hours PPL, mainly C172 and C152), the C172 is modelled very accurately. Did the OP chase the VSI? It has a several-second lag, esp when changing attitude quickly (again, this is modelled accurately), which could account for him not hitting VNE. I held a 1500 fpm decent for 3 minutes from 6000 ft at full throttle. It seems that I have an old model although I thought 0.9.3 was a recent build. How did you start FlightGear? Were you using the default 172 that comes up when you start FlightGear with no command-line options? You can end up with an old model if you use --aircraft=172r-3d All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Jim Wilson writes: That's pretty ancient. Our current 172 looks a fair bit better. U... that release is less than two weeks old ;-). I'm losing track of release numbers, then, but the clunky 172 model with the yellow tint on wings has not been our default for a long time. Maybe he got it by specifying --aircraft=c172r-3d or something similar. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: BTW : I took the Cessna 172 for a flip and was dissapointed. The visual model is really rough - looks like it taxied into a brick wall to get into those funny shapes. What release is it? The 172 changed a release or two ago. At full throttle and a 1500 fpm decent it wouldn't go over 140 knots. In real life it would hit VNE very quickly. Is that true? I've never taken a 172 that fast in real life, but they are very draggy. In fact, when someone in a slick gets into a spiral, one of the recommended emergency procedures is to drop the gear (which will then have to be inspected before further flight). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some thoughts and ideas (LONG)
Paul Surgeon writes: 0.9.3 - The one with the nice ready to run Windows installer. It's the 172 with the 3D cockpit and nice yellow tints on the wings. :) That's pretty ancient. Our current 172 looks a fair bit better. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Terragear-devel] SRTM 90 for Europe and Asia
Norman Vine writes: SRTM 90 meters dems for Europe and Asia are now available at http://edcftp.cr.usgs.gov/pub/data/srtm/Eurasia/ Fantastic. I guess that the Aussies, Kiwis, and S. Americans will still be stuck in flatlands, though -- serves 'em right for spinning the water down their drains backwards. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Terragear-devel] SRTM 90 for Europe and Asia
James A. Treacy writes: Since there are probably a few folks here who don't know that David is joking (I hope he is :), check out the following: http://www.urbanlegends.com/science/coriolis/coriolis_force_sci_physics_faq.html It's actually a (probably too-subtle) Simpsons reference: http://www.snpp.com/episodes/2F13.html All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: First real flight
Matthew Law writes: I agree :-) In a C152 with one aboard it certainly gets a little bumpy around the circuit even nauseous sometimes. The worst turbulence I've been in so far was just beneath a bank of fluffy cumulus clouds. I thought the airframe was going to fail and for the first time since I started flying I wished I had my parachute on! I know that's a joke, but I wonder what the odds of successfuly exiting a falling 152 would be -- assume that you're already well below circuit altitude by the time your brain has processed the failure. You'd probably be better to stick with the plane unless the structural failure were total (i.e. a lost wing rather than just a bent one). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: First real flight
Frederic Bouvier writes: I am trying to avoid to fly on the afternoon in summer. It even happened that my head hit the top of the canopy. I wouldn't imagine what could happen if I'd forgot to fasten my seat belt. Been there -- I bruised my head on the roof of my Warrior during a practice instrument approach one afternoon. When I'm flying VFR, I can stay high and then come in on a fairly steep approach path, limiting my time in the worst of the turbulence; IFR, I'm stuck at the ridiculously low step-downs and approach slopes designed for big airliners. In real-life, the kind of low IFR that I can fly in safely tends to be fog, which means calm air, so the real problem is flying under the foggles on VFR days. I noticed that it is more difficult to maintain straight and level with low powered planes (100hp) than with more powerful planes. My Warrior is more stable in turbulence than a 172 at the same weight and hp -- I think it's because the wing loading is higher (hence, the slightly higher stall speed as well). I often have to maintain the stick frankly on the left ( with no trim ) to avoid the plane to tilt. And with a heat bubble hitting only one wing on occasion, you are assured to get sensations. In a Cherokee (and most or all other low-wings), you have no choice but to burn fuel from one tank at once -- I always start with the left tank when I'm flying alone. Since the fuel is further out on the roll arm than you are, a little fuel can make a big difference for balance. I don't know how you feel about not using the BOTH setting in a Cessna, but for a long cross-country, it might be worth thinking about (just make sure you set a timer so that you don't forget to switch tanks). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] First real flight
Martin Spott writes: Lee Elliott [EMAIL PROTECTED] wrote: Sorry this is OT but there isn't anyone else who'd really understand. Still worth reading. Absolutely. I missed the original posting, so I had to yank it out of the archives: http://baron.flightgear.org/pipermail/flightgear-devel/2003-October/022083.html It was an interesting narrative, thanks. Most noticable difference - my seat here at home doesn't move. You don't feel the lift and sink through your backside:) Or the gusts and turbulence... Turbulence sucks: when I'm flying, I usually try to climb out above it. Turbulence often means thermals and updrafts, though, so I imagine that soaring types actually go looking for it. The gusts disappear usually a few hundred feet above the ground. The turbulence disappears anywhere between 1,000 and 10,000 feet above the ground, depending on all kinds of factors. The faster you go, the less you feel the gusts and turbulence. In a slow glider, I imagine that the effects are very pronounced. Most disconcerting difference - there was little sense of forward motion so when in moderate bank it felt more like we were tipping over rather than turning. In steeper banks there was a bit of G and it actually felt a bit more secure. If you felt any sideways pull, then the turns were not coordinated. Slipping turns are good ways to lose altitude, and I'd guess that soaring pilots use them quite a bit to get down to the field. Approach and landing was not what I'd expect either - stick out the airbrakes while still several hundred feet in the air and then dive down to the ground, level off and flair. Sadly, there are powered-plane pilots who try to do the same thing, even through flaps aren't exactly air brakes. Sorry this is OT but there isn't anyone else who'd really understand. On the contrary, it was an excellent posting. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim propeller fix
Jon Stockill writes: Actually it really helps getting your head around all the engine controls to do in-air starts. If you're feeling particularly sadistic don't bother setting vc either. That's our being-dropped-from-a-giant-helicopter simulation. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] YASim propeller fix
I've fixed the YASim code so that you can set the starting RPM from the property tree -- that means that it is now possible to start YASim propeller planes with the engine running, just like we do with JSBSim planes. This is a minor convenience on the ground, but it is very significant for in-air starts like fgfs --aircraft=dc3 --offset-distance=2 --altitude=1000 --vc=110 Here are the aircraft configs I've tested (and fiddled with, when necessary): dc3-yasim p51d-yasim j3cub-yasim pa28-161-yasim c310-yasim I'd appreciate it if people could let me know about any others that need updating. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
Martin Spott writes: Very different here. The indicators on the HUD were moving and the heli flies very calm. Did you recompile the stuff from scratch ? That's worth a shot -- I'll try a make clean; make in SimGear and FlightGear. I'll just confirm that it is the bo105 that everyone else is finding so smooth -- I actually got motion sick last night from all the yaw osciallations. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] YASim Heli bug ?
Frederic Bouvier writes: MSVC found the problem below at compile time. - fcw==0; + fcw=0; OK, after all the MS bashing we've been doing, it's only fair to mod MSVC +1 for finding this problem. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Innis Cunningham writes: While mapping the collective to the throttle would work. It is a bit like mapping a variable pitch prop to a throttle. It's just a terminology problem, not a flight-modelling problem -- it sucks using /controls/engines/engine[0]/throttle (or whatever) to manipulate the collective, but the alternative is to have separate Joystick bindings for helos. Ditto for using a control named rudder for the anti-torque rotor. In the actual model, the anti-torque rotor seems to do what you'd expect, i.e. you can hover and turn circles in either direction. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
David Luff writes: FWIW, I got sudden yaw oscilations as you describe for no apparent reason as well. I've no idea how to fly a heli though!!! Nor do I, but I'd expect any strange oscillations to happen at very low or very high airspeed, not at a medium cruise speed. I just rebuilt everything from scratch, and it's still happening. Usually, I can stop it with only a tiny change in control position (often pitch), but then it will start again a while later. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Helicopter: First Impressions
I've been been playing with Maik's most excellent helicopter model, now in CVS: fgfs --aircraft=bo105 I can (just barely) fly it -- I'll try hooking up my rudder pedals to see if that makes it easier. One thing I don't understand is that I get a lot of small, rapid fishtail oscillations, even when the controls are perfectly still and the forward airspeed is 60 kt or higher (i.e. I'm nowhere near a hover). Is this a reflection of a real aerodynamic effect in heli's, or is it something we need to hunt down? Let's all give Maik a round of applause for this one. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter: First Impressions
Jim Wilson writes: This isn't happening here. How are you controlling the antitorque (rudder)? Maybe the problem is in the control input? I've tried it with two different controllers and seem the same effect -- furthermore, the control-position indicators on the HUD are not moving, suggesting that the flutter isn't coming from there. Are you sure that you don't see yaw flutter at all? Try cruising around for five minutes or so -- it always shows up for me. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Curtis L. Olson writes: It also loops quite easily ... not saying that was the first thing I tried. How do you run the collective? How about yaw control? The rudder seemed to act more like an aerodynamic rudder ... not that I know anything about how a helo is supposed to fly ... Try this page: http://www.helicopterpage.com/ All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:
Jon S Berndt writes: On Thu, 16 Oct 2003 17:15:02 -0400 David Megginson [EMAIL PROTECTED] wrote: There are still some problems we need to work out. For example, if you set the wind to 0 and turn off the engine, the helicopter still slides backwards and turns -- we'll have to figure out why there are forces acting on it. To test: fgfs --aircraft=bo105 [EMAIL PROTECTED] --prop:/controls/engines/engine/magnetos=0 This does not happen with fixed-wing JSBSim models. Sorry, once again s/JSBSim/YASim/g. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Richard Bytheway writes: R KABC 29.650236 -96.579416 176.00 SL Is that example meant to start with a W rather than an R? Yeah, that would do the trick. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] IMMERSIVE HELMET implementation.....HELP ME!
[EMAIL PROTECTED] writes: Can youu answer some of my question about the code, dave.. But for the future if I will be albe to afford the time to learn some driver programming I could try it. We take mouse input from GLUT and handle it in src/Input/input.cxx. Take a look at the method FGInput::doMouseClick() for details. For the moments, to embed the helmet view, i need to write thirty-forty lines od code, I don't think it is so simple to write a driver Is this a helmet you made yourself, or one you bought? If it's one you bought, and has a USB connection, then it probably already works with the Linux hid driver (and thus, the plib Joystick library). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Java FlightGear airport viewer (very alpha)
David Luff writes: However, I'll see your Java airport viewer and raise you a C++ one :-) Excellent -- I'll take a look. Do you plan to make it into a full-fledged editor, like the one in XPlane? I've had a lot of fun learning the Java2D API for my Java viewer, but I won't go through all the work needed to support creating and dragging around runways and taxiways if you're already planning to do it in C++. Thanks, and all the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: Proposed Changes to Airport Data Files
I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Comments? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
[EMAIL PROTECTED] writes: Maybe we should also think about adding another entry, the continent. If we want to use a search by continent feature in the airport dialog, then of course, it is possible to find the continents by country. But history showed that this is not a reliable value. For example 15 years ago, you could say that the UDSSR is more in Asia instead of Europe, but when you would check for the moscow airport your programm would assume asia because of UDSSR=Asia, but that's wrong because, moscow is still in Europe. For the very few countries that straddle continents, like the Russian Republic or Turkey (any others?), the region/state code will (hopefully) be adequate to make the distinction. If there are 10 or 20 airports that are still ambiguous because of states/regions that also straddle continents, we could put them into a special-case table if necessary. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Jon Stockill writes: The problem there is that we don't need to keep a list of windsock locations in RAM all the time. *YES* we need the data - I'm just not convinced that that's the place to put it. There's no need to load it into RAM in FlightGear -- TerraGear can use the information, and FlightGear can simply skip over it (as it does with taxiways, I hope). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
Julian Foad writes: It seems *awfully* redundant given that there is already the Id *and* the geographical location. The lat/lon would be fine for searching inside 10 deg x 10 deg chunks, but it would get very expensive if we had to store polygons for all country and region boundaries and do point-inside tests for every airport. On balance, I think that this is a reasonable optimization. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Java FlightGear airport viewer (very alpha)
I've been hacking around with Java Swing classes during free moments over the Canadian Thanksgiving weekend, and I have managed to come up with a minimally-used FlightGear airport viewer. I'm using JDK 1.4, but 1.3 might work as well (if it has the Java2D graphics API bundled). To try it out, follow these steps: 1. Copy $FG_ROOT/Airports/basic.dat.gz and $FG_ROOT/Airports/runways.dat.gz to some other location and unzip them. 2. Download http://www.megginson.com/flightsim/apteditor.jar (14K). 3. Type java -jar apteditor.jar basic.dat runways.dat to start. You can also add a fourth argument containing the ID of the default starting airport, as in java -jar apteditor.jar basic.dat runways.dat KSFO I'm going to try to make this into a proper editor, but for now, it just makes for a cute, minimalist viewer. I'll package up the source code when I have time -- so far, it's not commented or even sorted into packages. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] IMMERSIVE HELMET implementation.....HELP ME!
Agusmag writes: The virtual hemet is madeup by two elements, the visor, wicha has a simple RGB connector, and the motion tracker (intersense inertial CUBE). The motion trackers has its developer kit in C++ and collect three angles, roll,pitch and yaw.so I was wondering to feed the angles directly to the functions like, setgoalview and so on.. Have you considered writing a Linux (or Windows) device driver, so that it will just look like another joystick? That way, you'll be able to use it with *any* software rather than just FlightGear. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] IMMERSIVE HELMET implementation.....HELP ME!
[EMAIL PROTECTED] writes: I'm trying a way to switch the mouse mode view to a virtual helmet driven view. How does the virtual helmet feed into the computer? Does it just look like a joystick? If so, then you need to set up bindings for the different movements. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] .AC files?... I need INFO or DOCS to custom....
[EMAIL PROTECTED] writes: Excuse me, where do I find informations about the commands and the format for .AC files, especially the files for the instruments? I'm not sure where the format is published, but it's not too hard to puzzle out if you understand how 3D files usually go together. People usually create the *.ac files with AC3D or Blender. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] AC file loader (Was: AN225)
Christopher S Horler writes: Presumably this would only affect the time it takes to run ssgStripify, having no detrimental performance issues? I'd be surprised if it even had much of an effect on ssgStripify. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] AC file loader (Was: AN225)
David Megginson writes:
Here's what I think is the offending PLIB code, at the top of
src/ssg/ssgOptimiser.cxx:
static float optimise_vtol [3] =
{
0.01f, /* DISTANCE_SLOP = One centimeter */
0.04f, /* COLOUR_SLOP = Four percent */
0.004f, /* TEXCOORD_SLOP = One texel on a 256 map */
} ;
Unfortunately, this array is not accessible from outside, so we cannot
simply modify it -- we'll have to patch. Try changing the first one
(DISTANCE_SLOP) to something like 0.001f and see if most of the
problems disappear.
Yep, that did it. I just tried rebuilding with the patched plib, and
my own problems with small mangled objects vanished: just change 0.01f
(1 cm) to 0.001f (1 mm), or even smaller, if you prefer. If this
change works for everyone else as well, let's start bugging Steve to
apply our patch and put out a new plib release.
I think that Steve must have originally optimized for the 3D arcade
games he was working on, where none of the objects was small enough
that 1 cm granularity would matter. On an airplane panel, on the
other hand, many knobs and switches are smaller than 1 cm across.
All the best,
David
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_SCENERY with multiple path elements ...
Jon Stockill writes: ... sort of works now, after a few small bug fixes. You can do something like FG_SCENERY=/usr/local/Scenery:/usr/local/Scenery/Objects Excellent - that makes life a lot easier :-) Thanks. Obviously, we'll want to make things smarter soon, but for now, should we consider moving all of the custom buildings to their own directory hierarchy, so that we don't have to reinstall them whenever there's a new scenery build? What does everyone think? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_SCENERY with multiple path elements ...
Frederic BOUVIER writes: Yes, this is a good thing. But when the terrain change, we have to land the buildings again because their vertical position is AMSL not AGL. I tried fixing that a few weeks ago by providing an option to set objects on the ground. Unfortunately, I didn't manage to find a way to calculate ground level at load time. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_SCENERY with multiple path elements ...
Erik Hofman writes: FlightGear/data/Scenery/Terrain FlightGear/data/Scenery/Cultivation How about this? $FG_ROOT/Scenery/Terrain $FG_ROOT/Scenery/Objects All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_SCENERY with multiple path elements ...
Jon Stockill writes: I tried fixing that a few weeks ago by providing an option to set objects on the ground. Unfortunately, I didn't manage to find a way to calculate ground level at load time. How are the random objects placed on the ground? Surely it's the same calculation? I had thought so initially, but it turns out that there are quite a few differences. Pseudo-random objects are generated when the scenery mesh is fully set up and are placed not by lat/lon but only relative to the centre of each mesh triangle. Static objects need absolute coordinates, so they don't start out associated with any specific mesh triangle, and their loading is often deferred through a special wrapper. I'd like to take another shot at it, but the scenery-loading code is particularly obfuscated, and I find it slow going. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_SCENERY with multiple path elements ...
Erik Hofman writes: How about this? $FG_ROOT/Scenery/Terrain $FG_ROOT/Scenery/Objects No problem, It's just a name. Great. In English, at least, cultivation generally means agriculture rather than man-made works in general. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] I am new here/ helicopter flight model
Maik Justus writes: So there is still some work, but if someone want to have this (alpha-)source just let me know where to mail it (but let me first search for bugs a few days...). Thank you for your work. You can mail the YASim patches and your first config file to me, Curt ([EMAIL PROTECTED]), or Erik ([EMAIL PROTECTED]), and we'll see if it fits smoothly into the codebase. The changes are based on the 0.9.2 Version (I hope, that there are not so many differences to the development Version). In that case, we're probably better off with your diffs against 0.9.2 than with the full files. What I could need is a helicopter (the 3D-Model), the c172 looks a little bit strange when flying like an helicopter. We have a few 3D modellers available, and I'm sure that one of them would be happy to take on a heli model. Do you have a YASim config file for a specific helicopter type? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] web site updates
Curtis L. Olson writes: Hmmm, something tells I replied to the wrong message, oops, too many things going on here at one time ... but yeah if any one cares, kid #2 is on his or her way. Congrats! All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] [OT] PalmOS/GPS Moving Map?
Norman Vine writes: Google( palm moving map) That was the first thing I did, but I didn't see what I was looking for. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] PalmOS/GPS Moving Map?
I just bought a (relatively) cheap clip-on GPS for my Palm Vx. It came with Magellan mapping software containing a database of detailed U.S. city street maps, but nothing for outside city areas (!!). Does anyone know of a simple PalmOS low-res moving map program, that just shows coastlines, lakes, rivers, towns and cities (as points), and possibly a couple of major highways? Even lower-res than vmap0 would be fine. Thanks, and all the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] OT latex2html??
Carsten Höfer writes: Hi, due to the size of the current flight school (pdf=5.6MB), I would like to change it to HTML. I tried to use latex2html, but was more or less disappointed by the result (same with pdf2html). Any suggestions for a 1:1 converter or a different format to PDF or HTML? If you have the time and patience, do a one-time conversion from LaTeX to Docbook SGML or XML. Every Linux distro that I know of has tools to produce decent HTML, PDF, and even ASCII from Docbook (it's the standard format for Linux documentation). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] PalmOS/GPS Moving Map?
Wendell Turner writes: Does anyone know of a simple PalmOS low-res moving map program, I use the cumulus program http://cumulus.kflog.org/ on my Zaurus. It looks very interesting, but unfortunately, doesn't run under Palm OS. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: [Flightgear-cvslogs] CVS: source/src/Scenery tileentry.cxx, 1.28, 1.29 tileentry.hxx, 1.8, 1.9 tilemgr.cxx, 1.24, 1.25
Curtis L. Olson writes (in a CVS log entry): VASI/PAPI lights are generally always on. I remember reading somewhere that they are typically turned off in very low visibility when a precision approach is in use, unless explicitly requested by the pilot -- unfortunately, I cannot locate the source. Also, the red/white VASI coloring has never worked right. This is also a step towards fixing that problem. I will look forward to that. I land at night with VASIS/PAPI quite often in real life, and would like to be able to practice with FlightGear. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Beyond presets
Norman Vine writes: Not really -- the difference is that the actual values (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, and these tell us only where we should look for them. Sounds to me like what is needed is a way to do $MY_TREE = which branch I want / sim / $MY_TREE / *** / ** I don't think that's it either -- we have too many different ways to set the initial position, velocity, etc. Simply selecting a branch of the property tree won't do it (unless we want to duplicate all of the information in that branch, in which case we're back to presets again). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Beyond presets
Unfortunately, while the presets hierarchy brought some benefits, it also broke saving and restoring flights. I think that it's time to consider doing away with the presets hierarchy, and trying something like this: 1. Make an in-memory copy of the property tree that we can revert to when the user wants to reset; we could even keep a stack of reset points, if that was useful to anyone. 2. Add a few /sim/startup properties to indicate what information should be used for position, orientation, etc. For example, /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) etc. I'm sure that people can think of a better classification. From this point on, then, our initialization code can simply look at these to decide whether to initialize based on the airport, etc. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Beyond presets
Tony Peden writes: /sim/startup/init/position-type : (latlon|airport|navaid|runway) /sim/startup/init/altitude-type : (msl|agl|glidepath) /sim/startup/init/orientation-type : (rph|runway) /sim/startup/init/time-type : (utc|local|sunpos) This sounds awful close to /sim/presets, so it sounds to me like we may always need the functionality. That being the case, why change it? Not really -- the difference is that the actual values (lat/lon/alt/hpr/airport/navaid/etc.) live in the main property tree, and these tell us only where we should look for them. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 717-200 progress
Manuel Bessler writes: Sure, if a model flies 'by the numbers' is a good start, but there are other properties that need to be simulated well for a good model, esp. outside of cruise (cruise is probably the simplest part). It's all numbers, of course: it's just that the numbers for the moments, etc., are not as easily available. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Slightly OT: Crosswind landings and turbulence.
Matthew Law writes: I experienced my first bout of real fear yesterday doing my second hour of solo circuits. I was operating from 06/24 and after a precautionary couple of circuits with my instructor he let me loose in a crosswind situation. The wind was initially 220/10-12Kt, but by the end of the hour was 180/10-18kt. With the wind in this direction, there are Hangers and buildings causing turbulence around the numbers, so I took heed of what my instructor had said and aimed to touch down just after the numbers with plenty of speed to aid in controlling the aircraft. A few extra knots for gusts or turbulence is a good idea, but for a crosswind landing, it only makes things worse: while you'll need smaller control deflections during the approach, it guarantees you a long flare (you still have to bleed off the speed somewhere), and the flare is the hardest part of a crosswind landing. Talk to your instructor first, obviously, but if he agrees, try coming in for a crosswind landing with full flaps at the slowest safe speed (taking gusts and turbulence into consideration) -- you'll have to use some pretty dramatic control deflections during final, but the plane will touch down quickly and firmly with almost no flare. Retract the flaps as soon as the wheels touch the ground to keep the wind from picking up the plane again. I found myself putting in some pretty big yoke and pedal deflections to keep anywhere near the runway. Absolutely right -- to land in a crosswind, you have to be willing to take the rudder right to the stop, and to put in some pretty dramatic banks as well. I've never landed the 150/152 (my instructor took the controls in our intro flight, and I always flew bigger planes afterwards), but once you get into a 15-20 kt crosswind, you'll feel like you're landing on your wingtip rather than the gear. This kind of unnerved me more and more as the flight went on. I slammed it in almost every time. At one point it seemed to me that I was running out of right rudder at the end of the flare to keep the aircraft down the runway as the wind was trying to 'weather cock' me into it. I've felt that way too. The important thing is to keep over the centreline at all costs, even if you're in a bit of a crab. Your plane can handle touching down in a slight crab if worse comes to worst (you might have to pay for a new tire or two), but normally, you can release the rudder a bit and then wham it back to full just before touchdown to realign the plane with the runway. If that doesn't work, then you're too far past the plane's crosswind-landing ability, and you need to find another runway (possibly at another airport). This was mainly bad technique on my part, but got me thinking if it would be hard to code in automatic and realistic turbulence near upwind buildings in FGFS? Or even better, how about modelling the cover from the wind of a building near the runway - so that when you emerge from the cover of the building you are immediately hit by the full force of the crosswind? This would help me get some practice in on crossed controls landings and make me feel more at home - just like a lightly loaded 150/152 in a high, gusty crosswind :-) That would involve a very large amount of computation. In real life, you cannot *always* count on the gusts and turbulence in the same places, so you're just as well off training with pseudo-random stuff. Maybe someday we'll get into air-current computer, when we have a lot more computing power. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: 200 hours
For everyone who's been following my real-life flying experience since my agonies over the first intro flight, on my way back from Brampton (CNC3) to Ottawa (CYOW) with my family last night, my logbook rolled past 200 hours. The second 100 hours has gone fast. This flight was memorable in other ways as well -- I've never taken off IFR from an uncontrolled field before (unless you count on-field FSS, which acts a lot like a control tower). Last night, I had to take off into a 600 ft ceiling under Canada's busiest airspace, flying directly towards the final approach path for the active arrivals runway at Toronto Pearson/CYYZ, a few miles away. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Killing Zone (was OT: 200 hours)
Arnt Karlsen writes: ..the 200'th hour is also the most dangerous period for average pilots according to the stats, these usually _assume_ things instead of _preparing_ for them, because their 200 hour experience may be construed to have taught them this is allways ok to do. That might be a bogus statistic. One of the most popular sources of it is a book called THE KILLING ZONE, by Paul Craig. He uses NTSB statistics to show that pilots with 50-300 hours of experience (his killing zone) account for many more fatal accidents than any other group; however, since the FAA does not release statistics about the number of pilots and hours flown at different experience levels, his numbers are meaningless. For example, private and student pilots with 100-149 hours accounted for 309 fatal aircraft accidents in the U.S. from 1983 to 2000, while private and student pilots with 350-399 hours accounted for 109 accidents. Who's more dangerous? It depends on how many pilots there were in each category and how much they flew. If there were three times as many pilots with 100-149 hours as 350-399 hours -- or, more importantly, if pilots in the 350-399 hour category flew three times as many hours as the less experienced pilots -- then the fatal accident rate for the more experienced pilots was actually higher. That's not to say that such a blip doesn't exist, and that 200 hours isn't a dangerous place -- I worry a lot about how easy it is to get in over my head fast now, especially with a new instrument rating and the confidence boost from passing the IFR flight test and flying in the system with the big airliners. As a result, I second-guess myself too much before every flight and get quite nervous and even nauseous (until I start the engine, and a calm focus settles over me). Taking off after dusk right into gloomy, low, grey cloud is much different psychologically from taking off in the morning into a clear, blue sky. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Killing Zone (was OT: 200 hours)
David Megginson writes: For example, private and student pilots with 100-149 hours accounted for 309 fatal aircraft accidents in the U.S. from 1983 to 2000, while private and student pilots with 350-399 hours accounted for 109 accidents. Who's more dangerous? It depends on how many pilots there were in each category and how much they flew. If there were three times as many pilots with 100-149 hours as 350-399 hours -- or, more importantly, if pilots in the 350-399 hour category flew three times as many hours as the less experienced pilots -- then the fatal accident rate for the more experienced pilots was actually higher. OK, I'm obviously sleepy today after my flight last night. Everywhere I wrote three times, replace with a third, and the math might actually make sense. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Killing Zone (was OT: 200 hours)
Arnt Karlsen writes: however, since the FAA does not release statistics about the number of pilots and hours flown at different experience levels, his numbers are meaningless. ..huh??? Why the hell not??? They indicate nothing about what level of experience is really the most dangerous: the real killing zone could be at 100 hours, or 900, but we cannot tell. To take a different example, if I could show that more people die every year from falling off chairs than from high-altitude mountain climbing without oxygen, would that prove that sitting on a chair is more dangerous? That's no reason to let those _same_ accidents repeat themselves over and over again. I agree absolutely -- it is absolutely critical for everyone, pilots, car drivers, joggers, cyclists, etc. -- to know what the dangers are. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Killing Zone (was OT: 200 hours)
Arnt Karlsen writes: To take a different example, if I could show that more people die every year from falling off chairs than from high-altitude mountain climbing without oxygen, would that prove that sitting on a chair is more dangerous? ..reminds me of the safest mode of human transportation counting passenger mileage: babies crawling on the floor is a close 2'nd, _despite_ the Hindenburg. ;-) Even though this is off-topic, I'll continue just a bit further with some fun but totally unconfirmed numbers I've heard, since they're probably of general interest. First, while flying on a scheduled air carrier is much safer than driving per passenger mile, flying with a private pilot is seven times more dangerous than driving -- in other words, it's roughly comparable to riding a motorcycle. Gender equality does not rule in private flying. While a male driver is only about twice as likely as a female driver to get into a fatal car accident, a male private pilot is eight times more likely as a female private pilot to get into a fatal plane accident. That suggests that you're safer per mile flying in a small plane with a female private pilot than you are driving in a car with a man. It also suggests that flying accidents are much more under the pilot's control than driving accidents, since the gender gap is so much larger. Some day I'll do the proper research to see if the numbers I've heard are accurate. We know that it's young male drivers who cause the most car accidents, but many private pilots are older, so it's unlikely just to be the young-buck thing. My guess is that (on average) men just have a harder time admitting they're wrong than women do. Fatal plane accidents can happen gradually, as the result of a long chain of bad decisions and other problems -- there are often many points where the pilot could have saved him or herself by turning back, waiting a couple of hours for better weather, choosing a different altitude or route, making an extra fuel stop, etc. Maybe women as a group are just better at doing that kind of thing. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New option: --failure
I've added a simple --failure option to help set up quick scenarios from the command line. The allowed values are vacuum, electrical, pitot, or static. It would be nice to add various flight controls as well, once we come up with a scheme to support that. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] By god, we're good!
Matevz Jekovec writes: simulators and are hot on the tail of the more recent. More cockpit detail is needed on many of the other aircraft, which is on my short Speaking of cockpits, do we have any 3D clickable cockpits planned? I'm not aware of any sim supporting that (at least not Falcon 4, Flanker 2.x, LO-MAC, F/A-18). This feature would be no doubtly cool. The only question is how big will be the FPS hit. There should be no hit except when you're actually clicking. We have sort-of pseudo fake clickable cockpits now (try the 172). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] By god, we're good!
Jim Wilson writes: Would elevation be helpful in splitting into different default types? Ocean shoreline vs. everything else? It won't help you with lakes, and it might turn the whole of the Netherlands into shoreline. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] scenery update
Curtis L. Olson writes: They are simply data files. There's nothing executable in there at all. As far as I know, MS hasn't added VB script support to .tar.gz files [ yet :-) ] so I can't imagine how they could ever be infected with anything. I'm guessing this has to be a false positive ... I hate virus checkers with a passion only slightly less than the passion with which I hate a certain e-mail program that I won't name again. While the initial fault lay with the e-mail program, it was all the false virus-warning e-mail messages from that idiotic software that finally physically shut down my account. I imagine that they have a catch-all rule, along the lines of If it's not text, and it's not a binary format I recognize, then it's a virus. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] San Francisco city lake
Curtis L. Olson writes: The real issue here is what texture should we choose for default areas for which vmap0 has no coverage opinion? It would be nice if we could do some kind of weighted average of the surrounding areas, excluding water. At least we'd be less likely to get something out of place (like an evergreen forest in the middle of the desert). We could also default to the 1 arcsec landcover raster. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Dutch Scenery
Ivo writes: But tonight I tried one anyway and I am surprised about how it looks. Not too bad at all for a texture that's only 150 pixels high. I have put some sample images here: http://ivop.free.fr/fgfs/fgfs_rembrandt1.jpg http://ivop.free.fr/fgfs/fgfs_rembrandt2.jpg 32 pixels is usually fine for a generic building, and 64 pixels for a customized one -- maybe 128 for something really prominent and detailed. Consider how few pixels the building actually takes up on the screen unless you're flying within a few dozen meters of it. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] By god, we're good!
Jim Wilson writes: Owners of low-wing planes are manly? H...so what are bi-plane owners then? You made that one too easy. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] OT: Linux environments
Lee Elliott writes: I've been using Gnome for years but I'm finding it increasingly idiotified and un-controlable, not to mention less reliable. Just out of curiosity, what problems are you finding? I'm using the latest Gnome from Debian unstable, and it doesn't seem to cause any problems. I've tried KDE a few times but it just rubs me the wrong way and ends up getting uninstalled (even though I'm sure it's just as good technically). Hopefully, in another year or two, the two developer communities will come together. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: Linux environments
Lee Elliott writes: I'm on Debian unstable too. Included in the problems I've experienced are incorrect panel icons that I can't corrected, problems with icons in some Gnome apps, panel entries loosing properties after I've set them and an inability to re-configure old gnome apps such as gmc, together with the reduced level of control and configuration in general. I haven't tried gmc for a long time, but otherwise, I'm not seeing these problems. It might be that something is screwed up in your installation, perhaps some left-over crud. Try setting up a new account and logging into it, and see if you have the problems with icons and lost properties there as well. Personally, I hope that the Gnome and KDE teams never merge because monocultures are never a good thing. As long as they each make sure their own stuff works with the other's environment, which in general it does, I'm happier with them going their own ways. I think I'd be happier seeing both as competing flavours within a single desktop environment. There will never be a monoculture as long as we have alternatives like ratpoison. apt-get install ratpoison if you've never tried it -- you'll never have a cleaner desktop. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] By god, we're good!
In FlightGear, I just paused in the middle of a climb out from Brampton (NC3) towards the Simcoe VOR (YSO). I'm nursing the climb, trimming the 172's nose down to 85 kias to keep the engine cool and settling for 600 fpm through 4500 for 5000 ft. I caught myself looking at the clouds getting closer and wondering if I was still going to be below them at 5000 or if I would end up inside. Suddenly I felt just like I was doing the climb for real, watching the DME flicker in and out (I'm at the edge of its reception range) and looking around at the lights of roads and small towns north of Toronto becoming more visible as the twilight fades. I don't know how we stack up against the latest versions of MSFS and X-Plane, but I never experienced anything like this in FLY! or MSFS 98 -- I even started to have imagined physical sensations, like the cool evening air blowing out the floor vent over my feet, the vibration from the engine, and the headset squeezing my ears. Good work, guys. We rock. Stuff like this doesn't happen unless *every* contribution (documentation, colour, texture, flight model, sound, animations, modelling, sky, scenery, you name it) comes together perfectly. I'm going to go back to FlightGear now before I start crying and spoil the whole thing (not that owners of manly low-wing planes ever cry, of course ...). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] *awk
Tony Peden writes: I don't know, maybe it's just me but I've written a lot of perl I couldn't read a month later ... You just haven't rewired your brain chemistry yet. After about 12 years, perl code starts to look normal and everything else (C/C++, the sky, your family) looks strange. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Animation documentation
Erik Hofman writes: Jim Wilson wrote: Erik Hofman [EMAIL PROTECTED] said: Can someone point me to the most recent document that contains information on how to animate FlightGear models? Want to add a description of the new blending animation, but although I found it on three different locations, none of them include the scale animation which Curtis added recently. In CVS it's docs/Model/fgfs-model-howto.html. Thanks. I've found it. I wonder if we should call the animation transparency instead of blending, just in case we do add an animation for texture blending later (say, to animate ice accumulating on the airframe). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery update
Erik Hofman writes: They are billboards. But my machine definately can't handle more billboards right now (how does the 3d clouds code do that? I looks like the trees and clouds together doesn't make a hughe difference). Imposters might work for distant trees as well. Implementing imposters is beyond my skill, however. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Curtis L. Olson writes: For what it's worth, when I was looking into this, I found some examples of runways with their ends literally at least 100' different in elevation. Most aren't nearly that far off, but there are a few. For a 10,000 ft runway, that would require less than a 1% continuous grade, so it's not all that surprising. It will be a very good thing when we can take threshold elevations from FAA and DAFIF data. The SRTM/DEM data, however, is just too coarse -- that's why I'm suggesting flattening for now. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Re: [Terragear-devel] Flattening Stuff
Martin Spott writes: Further to Curt's last post about flattening rivers, how would everyone feel about flattening airports? When you look at large airports, say with runways over 3 km, you'll find quite a few where the runways follow the terrain at least over a difference in the elevation of several meters. Absolutely -- at my home airport, for example, runway 14/32 (10,000 ft) has a significant hump in the middle. We have one old 727 that flies up north to Baffin Island every day, loaded so that it can barely climb. You can tell it's starting its takeoff roll because you see a cloud of smoke over the horizon -- a few moments later, the plane itself comes into view, struggling its way off the runway with the nose hanging high in the air. With all the drag, we give that one at least three minutes (instead of the normal two) when it takes off across our runway. The problem is that we're not generally getting that right now anyway -- we're just getting incorrect elevations. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: missing the runway
Curtis L. Olson writes: David, I lined up fine in the yf23-yasim with the scenery I generated last night. I'll try rebuilding the airports with the latest CVS, then. Thanks, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] new scenery samples
Curtis L. Olson writes: I have been fiddling around with the scenery building tools to incorporate 30m SRTM data for N/S america, updated/current airport/runway data based on the latest DAFIF cycle, updated taxiways, lighting, and approach data, etc. Also included is vmap0 roads, railroads, rivers, lakes, landc over/land use data. This is a big improvement for VFR flying and makes the world a lot more interesting to explore. Sounds great. Are you using all of the available SRTM-3 (including Canada)? All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
