Re: [Flightgear-devel] multiplayer / AI property tree - questions
Curtis L. Olson writes: Don't say that. You know what'll happen _now_ when you next fly ... Also, although I've said it before, don't forget to practice a bit, before flying to an airshow or other event with _many_ spectators ! Would you like to buy a pair of slightly used C172 wing tip scuff guards? Protects the paint and the red/green lights, guaranteed not to break off before the wing. Now available in a trendy neon color assortment. Fortunately, I've never seen a landing where the wingtips even came close to touching the ground -- the excursions are usually pitch or yaw rather than roll. The danger to wingtips is hangar rash (i.e. fender benders) from other aircraft taxiing around the parking area. In real life, it's also much harder to do a tail strike than it is with the JSBSim 172 -- it's quite safe to pull all the way back on the yoke to keep the weight off the nosewheel. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
John Check writes: Dunno. I checked a few revisions back and didn't see anything. I'm committing wet tanks shortly. Remember that I just fixed FlightGear to stop picking up defaults from c172.xml. Hmm. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
David Megginson writes: Andy Ross writes: I have limited experience here, but the nosewheel shimmy I noticed in a friend's PA-180 was only a rumble. It didn't seem to effect the orientation or handling of the aircraft. If it's bad enough, the whole plane shakes (we've had trouble with the nose strut on C-GPMR at the Ottawa Flying Club, and it had to be rebuilt); of course, since I'm holding the yoke, I feel it through that first. That should have been the rudder pedals, not the yoke. Don't worry, people, I do know how to steer the nosewheel. Really. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Curtis L. Olson writes: John Check writes: Also, what happened to the runway lighting? I'm a little out of touch since I've spent the last week (at least) installing Gentoo It should still be there, isn't it? I have been working on building more infrastructure for doing runway/approach lighting and working on using environment mapping to simulate directional lights which (except for VASI/PAPI) is working out very well. It's still there for me, but it appears as 3-point triangles now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: The JSBSim config files have fuel loaded for the X15, the X24B, the C310, the C172, etc. But NOT the shuttle (we just use it as a glider). I don't know what this consumables thing it, but JSBSim loads its aircraft with fuel in the JSBSim config files. If it has no fuel, the FlightGear is screwing around with the fuel, after the aircraft is already loaded by us. Right. We allow the users to change the fuel level, so the default in the JSBSim config file doesn't matter. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] spot landings
Alex Perry writes: This coming Saturday is the annual safety competition for San Diego and, as one of the organizers, I've been thinking about the spot landings task. It occurs to me that FGFS should be able to do that really well, except the touchdown report is minimal. How much hassle would it be, to have the existing gear message (to console) report the (u,v) and name of the texture which the wheel hit, or some other relative-to-runway numbers ? That would enable sim pilots to fly TnG series, with automatic scoring. It should be possible to specify a lat/lon and then get the distance and bearing of first wheel contact. In fact, given sufficient update frequency, you might even be able to do this with an external program (poll the WOW property). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Erik Hofman writes: Jon Berndt wrote: Who emptied the fuel tanks? I took it out for a trip on thursday. I must have forgotten to fill it up again. Sorry guys. Damn -- do you know how much condensation there must be in the tanks? I'll be draining water for half an hour. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Martin Dressler writes: IMHO in steam module should be added some reality switch. When /instrumentation/steam is true then it cook all values, when /istrumentation/steam is false then it simply copy /orientation/heading-deg to /instrumentation/magnetic-compass/indicated-heading-deg and etc. The steam module is just about finished, since most things have already moved to /instrumentation/. I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Starter problem: solved
The /controls/starter[0] property is being forced to true by the new
electrical-system code, which automatically sets all switches on:
} else if ( cname == switch ) {
// set default value of switch to true
// cout Switch = child-getStringValue() endl;
fgSetBool( child-getStringValue(), true );
add_switch( fgGetNode( child-getStringValue(), true ) );
}
Instead, we should set the appropriate switches to 'on' in
preferences.xml or c172-*-set.xml so that the user can override. For
the starter, a default to 'on' is clearly not what we want.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: Right. We allow the users to change the fuel level, so the default in the JSBSim config file doesn't matter. H. I don't like this at all. Why was this done? 1. We have several different FDMs and need a common mechanism for setting and displaying fuel levels for all of them. 2. Users need to be able to select an initial fuel level with each run, just as in real life -- flying a small plane is often a tradeoff between how much fuel you'd like and how much weight you can manage. 3. When we restore a saved flight, we want to be able to start with the same amount of fuel we had when we saved the flight. We've done it this way for a year (maybe two) and it generally works well -- Tony did a good job interfacing it. Soon, we'll also need an FDM-independent way of specifying the payload positions. Note that the FDMs still manage fuel consumption themselves -- FlightGear just tells them how much the user wants to start with. Overriding the config file value will confuse people, and make people think something is broken. We tracked this one down easily enough. It would be much worse if there were a different mechanism for fueling JSBSim, LARCsim/UIUC, and YASim planes. Please remember that FlightGear is not just a visualizer for batch-mode aero runs -- people use it to fly interactively. A fixed setting in an FDM-specific static init file isn't sufficient. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
Norman Vine writes: Instead, we should set the appropriate switches to 'on' in preferences.xml or c172-*-set.xml so that the user can override. For the starter, a default to 'on' is clearly not what we want. NIT *-*-set.xml so that the user can override. The Sim is more then a C172 simulator Correct, but the C172 is the only one that Curt has modelled an electrical system for so far. When he has done others, then their *-set.xml files will need to be changed as well. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. http://gps.faa.gov/Programs/WAAS/waas.htm Norm, Norm, Norm -- I'm very disappointed. You're the one who has spent the most time drilling into everyone's head that GPS receiver readings are *not* the same as true values. Certainly, we'll want to be able to slave the autopilot to a GPS receiver as well as the HI, VOR, etc., but then we'll be modelling the GPS altitude errors and sampling-rate lag and adding a slight fuzzy factor (a significant one for altitude); if we get fancy we might even let the receiver have trouble locking on to satellites sometimes. In fact, even the C172R (which we're modelling) comes with a KLN89 or better GPS receiver, together with an autopilot that can be slaved to it instead of the VOR gauge for lateral control. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Norman Vine writes: Please remember that FlightGear is not just a visualizer for batch-mode aero runs -- people use it to fly interactively. NIT: Please remember what it says on our Home Page The FlightGear project is working to create a sophisticated flight simulator framework for the development and pursuit of interesting flight simulator ideas. We are developing a solid, basic sim that can be expanded and improved upon by anyone interested in contributing. OOPS -- I see that this has changed too. The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing. I'm not sure I follow: we're using a common mechanism to pass user requests for initial fuel level to all FDMs, just as we use a common mechanism to pass user requests for aileron deflection to all FDMs. We did this a long time ago, before there even was a YASim (for example). It's also worth noting that we are (very slowly) spinning off the framework part into SimGear, so that FlightGear will eventually be the a specific flight simulator built on top of the framework rather than the framework itself. When the original mission statement was written, there was no separate SimGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
Curtis L. Olson writes: I did this as a stop gap until we can get master bat/alt and avionics master switches on the panel, but yeah, starter[0] shouldn't be on by default. As an alternative, you can set the default position for each switch in the *-set.xml file so that users can override. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Norman Vine writes: FGFS should be able to answer simple flightplan questions like I am leaving from KSFO flying to KLGA show me all airports that are large enough to handle a 747 within 100 miles of my flightpath. Indexing makes this trivial That's still an out-of-the-main-loop problem, though, so it doesn't matter to the to top-level code whether it's sitting on top of some moderately complex indexing code or some moderately complex linear-search code. We will need to be able to do fast searches on ATC frequencies, as we do currently with navaids, so we'll need some kind of indexing for that. There may be a reason for constant airport searches in the loop as well; I just haven't thought of it yet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Some little bugs report from an enthusiast new user...
Tommygio writes: 1) The swtch --cloud-disable disables the default cloud layer, but not the puffy effect at the layer altitude. OK, I've just fixed that -- the changes will appear in CVS shortly. 2) In the chase view with the default airplane, the cockpit's textures can be seen throught the wings. I think this problem started when the 3D clouds were added, but I'm not sure. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help: Current Ground Elevation
Norman Vine writes: David - You still haven't answered my question about your problem Is the points containing tile loaded when you are trying to get it's elevation ?? I've temporarily abandoned that effort, since it was taking too much time for too little benefit. I do plan to go back to it soon, though. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Loading static object problems.
Frederic Bouvier writes: I noticed that textures for scenery static objects are not loaded anymore for a few weeks. Static objects have absolute path while random objects and aircraft have relative path but fgLoad3DModel unconditionally prepend fg_root to the model path. This patch test the beginning of the model path to choose if fg_root has to be prepended to the model path. I've added the patch as a temporary kludge, until we have time to fix cross-platform path handling. It should appear in CVS shortly. Thanks, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some little bugs report from an enthusiast new user...
Norman Vine writes: If we are refering to the 'opaqeness' when flying through a 'layer's altitude', then this has been a long standing issue. That I kept meaning to look into No, I mean the 2D panel display showing through the fuselage. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Wright flyer
Jim Wilson writes: Thanks. It's getting there. I'm still trying to figure out from Orville's description how the elevator mecahnism works (for animation). Might need to go down to Owl's head again to take a another look at their replica. Still thinking about wing warping... (hints to the animation code guru :-)) You will need to make two versions of the wings, one fully warped in each direction, with exactly the same number of vertices in exactly the same order. Given that, it will be trivially to add support in FlightGear for the SSG tween animation. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wright flyer
Martin Spott writes: The UIUC folks did a very good job on the flight dynamics. My gut feeling is that this is probably very close in terms of performance to the original. Yep, you have no chance to gain terrain with '--random-wind' enabled ;-) I'll grant that crosswind landings are a challenge without a rudder. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Numeric Terminology
Are there simple technical terms to distinguish the digits on the left side of the decimal point from those on the right? Thanks, and all the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] ADF change?
John Check writes: I see that tuning the ADF radio is now done on the standby channel. It was my understanding (which ain't much) that at least on some units you can tune the active channel My experience is limited, but the only units I've seen where you tune the active frequency directly are radios without a standby frequency (the ones I've used are big cold-war jobs that have a nob for each digit on a physical wheel). 2 questions. 1) Would anybody object to me activating a switch so we can have both? It depends on what we're emulating. Before you go ahead and add it, though, why do you want it? For radio navigation, you generally want to be able to tune your next station in advance without losing the current signal as you move from one NDB to the next. Typical examples include following a Romeo air route between two NDBs (not that uncommon in Canada -- I've done it a few times already) and flying an instrument approach that uses one NDB for the FAF and another NDB for the missed approach (I'll be doing that soon). Its the same principle that you use with the VOR and the VHF radio -- try to stay one step ahead of the plane by having your next frequency already tuned it (for example, I usually have Ottawa Terminal ready on standby while I'm still talking to Ottawa Tower after departure). 2) Should we just switch to the KR87 thats sitting in cvs unused? Sure. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
Curtis L. Olson writes: Yes, I dont' know what it would take to get a momentary mouse click mode working, but that would be really helpful. David: is this possible? Easy? Hard? Someone else is going to have to work on this though since I have my hands full with other things. Please explain. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
Curtis L. Olson writes: What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. That would be only a slight variant of our current code that keeps modifying a value (i.e. turning a knob) as long as the mouse is held down. I'll try to look into it this weekend. It would be useful for the C172 starter as well. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
John Check writes: In reality I can't think of a case, because you'd know what stations to tune in advance, but if you classify fgfs as a game, you might want to be able to search for ground stations. I seem to recall something about some units having an AM reception mode also. It's not a separate mode -- the AM frequencies just happen to fall in their range: instead of DAH-dih-DAH-DAH dih-dih-dih dih-dih-dih-dih you get Bob the DJ or the baseball game. If anyone has a lot of spare time and nothing else that interests them, we could emulate that very roughly with a few short nonsensical audio loops and a recording of each letter of the alphabet being sung (for station identification on the hour). Before GPS receivers were common, I think that people actually tracked to AM transmission towers sometimes in VFR cross-countries off the airways. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Built-in Commands
Bernie Bright writes: There was a discussion some months ago about adding command properties, that is, tying a property to a command such that writing to the property triggers the command. Such commands then become available to external scripts as well as the binding interface. Should we investigate this further? The alternative is to make the commands available through the external interface as well. Let's develop some examples and use cases and see which works best -- I'm not strongly prejudiced either way. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: Panel interaction (was Re: [Flightgear-devel] ADF change?)
James Turner writes: One feature I'd love is the ability to spin dials by hovering over and using the mouse wheel, though I assume GLUT may not support this (unless the wheel is mapped as buttons 4 and 5, which I think is common under X?). MSFS does this (at least the newest version) and it's very intuitive and quick to work with. Currently, I have the mouse wheel in X mapped to the trim wheel, which is very useful. I don't know if we could usefully mix the two. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Jim Wilson writes: The new airport lighting is really impressive. At dusk it looked pretty good on the screen so here's a couple shots: http://www.spiderbark.com/fgfs/cubsightseeing.png http://www.spiderbark.com/fgfs/towerview.png They do look great, but I find it disturbing that the lights float so high above the runway (especially when they come flying through the window during the takeoff roll) -- could it have to do with a disparity between the published airport elevation and the actual DEM elevation? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson writes: We artifically raise the lights a bit to attempt to avoid zbuffer fighting. The formula is based on the altitude above ground and the distance away ... however, it's rough and imperfect ... I'm still working on understanding the code. First, you have point_list geod_light_nodes = calc_elevations( root, light_nodes.get_node_list(), 0.5 ); That means that the base elevation for each light is already 0.5m above the runway. Does FlightGear have ssg do further elevation adjustments at runtime? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson writes: Yes ... a 0.5 elevation difference just isn't enough to maintain zbuffer separation from common viewing distances and angles. This gets significantly worse on a card with a 16 bit depth buffer (i.e. voodoo-1,2.3) I believe the code to lift up the runway lights (and ground cover lights) is in tileentry.cxx:prep_ssg_node() I'll do some experimentation. On the ground right now, in a C172, the runway lights are at about eye height. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Erik Hofman writes: Now we can do two things, have duplicate code by keeping the 2D HUD, or creating the functionallity of the 2D HUD with the nee 3D HUD code. I'm not for including two sets of code doing basically the same. Speaking of dead code, is anyone still using the old DCS support from main.cxx? I think that it can be completely replaced with the newer 3D model animation code, but I want to make sure I'm not going to break anyone's apps before I rip it out. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross writes: Norman, this isn't constructive. Here are some things I'm quite certain you don't want: + A velocity vector that doesn't point where the aircraft is going + HUD scaling that breaks with changes of aspect ratio + HUD scaling that breaks with changes of resolution + A horizon line that doesn't lie along the horizon Perhaps the best solution will be to fork between the actual HUD (which should be 3D) and a screen-oriented 2D overlay module that uses the same configuration code to display things like frame-rate, network-connection status, etc. The beauty of configurability is that if Norm still wants to see the HUD ladder, etc. in 2D, it should be a simple matter to whip up an XML configuration file for it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Jim Wilson writes: That's great! Has anyone thought about how to do mouse click support with the 3D instruments? Thought, yes; succeeded, no. Steve Baker is very hostile towards the idea of providing simple plib support for this kind of thing, and the only help I've got so far is look at the ppe source (it didn't help me). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Yeager [OT]
Jon Berndt writes: I tried to go faster but at 79 years old it was the best I could muster. - or - I wanted to fly the F-20 but my walker wouldn't fit in the cockpit. Now, now. When my grandmother was 90, I could barely keep up with her on a walk. The last few years it's gotten easier, but my dad still cannot keep up with her. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] I've got a few minutes to spare
Curtis L. Olson writes: So did one of the pilots think they saw the runway and let themselves decend too low and by the time they realized that wasn't the runway they were too low, too slow, out of whack, maybe a little ice??? Not if they had a serviceable DME, unless they completely lost situational awareness. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Jim Wilson writes: It looks pretty good with this patch: RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v retrieving revision 1.9 diff -r1.9 tileentry.cxx 891c891,893 * SG_FEET_TO_METER - globals-get_scenery()-get_cur_elev(); --- * SG_FEET_TO_METER - globals-get_scenery()-get_cur_elev() - 30; if (agl 0) agl = 0; Unfortunately, not for 16bpp -- the lights are still so high that I have to use to mouse to look up to see them. I tried commenting out the 16bpp detection and using the 32bpp lift, but the lights were still floating high in the air. This looks like it's going to take a fair bit of work. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] screen shots lights
Curtis L. Olson writes: Unfortunately, not for 16bpp -- the lights are still so high that I have to use to mouse to look up to see them. I tried commenting out the 16bpp detection and using the 32bpp lift, but the lights were still floating high in the air. This looks like it's going to take a fair bit of work. It's a very tough problem. A 24 bit depth buffer helps a lot, but a 16 bit depth buffer makes it a *really* hard problem. Note, though, that even with 32bpp the lights are floating very high. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
Andy Ross writes: When you say very high, how high do you mean? It looks like about 2m to me. Yes, that's about right. The lights pass well over the top of the plane during the takeoff roll, which looks quite silly. Even 0.5m is too high on the ground. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
Jim Wilson writes: Yes, that's about right. The lights pass well over the top of the plane during the takeoff roll, which looks quite silly. Even 0.5m is too high on the ground. What I'm seeing is more like the 0.5m...a little high but hardly enough to look way wrong (it isn't going to be picture perfect anyway). Can anyone explain why I don't get the 2m effect like Andy and David? It's scaled to a lower height with 32bpp, but it's still obviously off. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] OT: XML Question
Jonathan Polley writes: Any recommendations? This is not an immediate need since I have a temporary work around for my type definition problem, but I would like a better long-term solution. My main recommendation is to build an abstract library on top of the XML, like our property manager (only perhaps simpler) -- that way, XML parsing is completely separate from program logic, and if you need to change the XML details, you can do it all in one place. p.p.s., David, were you aware that http://www.saxproject.org/ has expired? Thanks -- I'm renewing it now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: XML Question
Norman Vine writes: If you are comfortable with Python You can define your objects in Python and then dump their XML representation :-) http://www-106.ibm.com/developerworks/xml/library/x-matters15.html?openl=810,t=grx,p=rpc There is similar code for Java, but I've never been happy with it -- a serialized Java object in XML is still a serialized Java object, and has little value for someone using C++, Perl, or Python; you might as well just serialize into a native format (perhaps Python's native serialization format is XML-based, but the point still holds). A useful XML spec is one that abstracts out the implementation differences among various programming languages and applications, so that it can be used in ways not originally planned. For example, this is useful and usable by many apps (and human-readable): airport id=CYOW nameMacDonald-Cartier International Airport/name icao-airport-codeCYOW/icao-airport-code iso-country-codeCA/iso-country-code position lat-deg45.318783/lat-deg lon-deg-075.669678/lon-deg elev-ft374/elev-ft /position /airport but something like this (which I made up but is typical), much less so: java:object id=obj12345 java:classcom.megginson.apt.Airport/java:class java:data java:member java:namename/java:name java:object-ref ref=#obj54321/ /java:member java:member java:nameicaoAirportCode/java:name java:object-ref ref=#obj65432/ /java:member java:member java:nameisoCountryCode/java:name java:object-ref ref=#obj76543/ /java:member java:member java:nameposition/java:name java:object-ref ref=#obj87654/ /java:member /java:data !-- and then repeat for each referenced object -- All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] DEM, sigh
Erik Hofman writes: After a long search I finally found the digital elevation model data of The Netherlands (up to 5 meter resolution!), but then discovered it isn't free. :-( Canada has a set of digital geodata available -- high resolution line graphs, DEMs, the works -- for only CAD 1,000,000 (about USD 650,000). Of course, if you want to redistribute any derived works, you have to talk to them about different pricing. For free, you can download some 30-arcsec DEMs and some free low-res geodata, roughly equivalent to what we already have world-wide in gtopo30 and vmap0. To the rest of the world, it seems backwards that the U.S. (home of software patents, the DMCA, and perpetual book copyright extensions) got something about intellectual property so right while the rest of us got it so wrong, but there you have it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DEM, sigh
Norman Vine writes: To the rest of the world, it seems backwards that the U.S. (home of software patents, the DMCA, and perpetual book copyright extensions) got something about intellectual property so right while the rest of us got it so wrong, but there you have it. it keeps getting better too :-) http://seamless.usgs.gov/viewer.htm I have a feeling that we won't have good, free geodata for the rest of the world until the U.S. decides to provide it for us, sort-of like military defence (not that I doubt that the Canadian navy or French army, for example, could actually fight a war on their own -- no, on second thought, I do doubt it). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable panel and zooming
Curtis L. Olson writes: Does it make sense to remove the 'x' and 'X' bindings and make them available for soemthing else? Yeah, but I don't want to get yelled at. It makes sense to change a lot of the keybindings, if people don't mind. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
Jim Wilson writes: Finally, I did look at the code closer. Took all of 1 minute to figure out what was going on :-). Maybe something similar can be done with the distance...which could make sense and avoid adding a few extra steps. Also, knowing what is happening, I now have no problem finding an aircraft position that shows the lights being screwy. When I get a build on the Voodoo machine I'll see what I get, and play around with some ideas on that and the gforce2 before making any more half baked suggestions. The biggest problem comes when something is far away but at a low angle (i.e. the lights at the other end of the runway). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] screen shots lights
Jim Wilson writes: The distant lights seem about right on my display. Is this looking bad on the 16bit cards? What is the problem? Are you seeing z-fighting or do they look strangely positioned? They seem to slope upwards. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] building models
Jon Stockill writes: But implementing them in a different format, with much reduced detail, as would be required for flightgear, using the original ones only for inspiration, and basic dimensions? Why not start with a 3-view of the real Eiffel Tower, then? (Is there one online?) Personally, if I make a complex structure, I'll probably start with the Golden Gate bridge, since it's so close to out default starting point. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] building models
Christopher S Horler writes: Never modelled any scenery, but the idea of flying through a large train station or something else kind of appeals to me (is this possible?) Yes -- to confirm, add Models/Airport/hangar.ac to your scenery somewhere and try taxiing into it. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] First hold; first ILS approach; first night circuits
If you all noticed I wasn't posting yesterday afternoon and early evening, it's because I was very busy. I'm working on my night rating. It requires an extra five hours of instrument time under the hood (beyond the five required for the PPL), and since I plan to go on and do my instrument rating, my instructor has moved on to IFR topics like VOR holds and (last night) a proper ILS approach under the hood. FlightGear-related observations follow: 1. FlightGear was excellent prep for a real hold, much more useful than Elite, and behaviour right around the VOR itself is a tough test. The only thing we don't have right is the (substantial) needle lag when tuning a new radial, but that's not part of the hold proper. 2. On the actual approach, our LOC/GS and the real LOC/GS behaved pretty-much the same -- again, FlightGear was excellent practice (I didn't try an ILS approach with Elite). Off the approach path while we were being vectored in, the CDI flew back and forth at about the same rate as a child on a swing, rather than staying glued to one side (it was almost hypnotic), and the GS was a little funky as well. We should try to model that. 3. Most of the panel instruments had no lighting of their own, except for the VOR 1 gauge, which was quite bright, and of course the LEDs in the radios. Otherwise, there was just the one red light, which barely (but adequately) illuminated the panel, much more dimly than our current 2D panel. There wasn't enough light to read the labels on the electronic switches, for example. 4. Unless you're lined up, you really cannot see the runway lights. On downwind, it's *hard* to see the runway you're tracking, and these were big jet runways -- usually, the approach lighting and parallel taxiway lights were the only clues. On the approach path, the runway lights are very bright as in FlightGear. 5. From three miles away, off the approach path, you can barely see the airport at all -- the streetlights on city streets and in subdivisions are much brighter (again, this is a major airport). I lost it a few times while we were orbiting to let a regional jet land ahead of us. Forget about seeing the airport beacon in a well-lit city. 6. While the runway edge lights are bright, the runway itself is very dark. The yellow taxiway lines are almost invisible, even under the taxi and landing lights, and turnoffs and intersections are very hard to find (the double blue lights are the only clues). Landing before or after a runway intersection was especially tricky, because you cannot see the intersecting runway even from a mile away. Taxiing around the airport was almost like driving on a country road shining a flashlight through the windshield. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] building models
John Check writes: Personally, if I make a complex structure, I'll probably start with the Golden Gate bridge, since it's so close to out default starting point. The TA pyramid wouldn't be a bad pick for somebody just starting to mess with 3D modeling.. Absolutely, though I wouldn't call it a complex structure (four polys). It will look a little silly without the surrounding tall buildings, though. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] update
Curtis L. Olson writes: I will be going out of town for the weekend, and most likely the first part of next week. The exact details are still up in the air. I'll try to get caught up when I return. OK, guys, what do you want to change while Curt's away? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Airport Lighting
The airport lighting is looking great -- the light lifting problem is much better after the recent patches, even on a 16bpp card. Since the basics are out of the way, it's time to nitpick: the taxiway lights need to be about half as bright as they are. A quick peek at tileentry.cxx didn't show me what line to change -- any suggestions? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Lighting
Curtis L. Olson writes: I was tempted to put taxiway lights into their own scene graph and use a higher fog value on them so they fade out sooner ... that would hopefully prevent the taxiway lights from dominating the airport and even the runway lights from a distance ... I'll be going up for more night work this evening if weather permits. During my first time on Wednesday, I noticed that the taxiway lights (and sometimes, approach lights) are *all* you can see from a mile or two away, unless you're lined up with a runway. We just need to make them dimmer. They're not all that bright, even when you're taxiing right beside them. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] First hold; first ILS approach; first night circuits
Jim Wilson writes: 2. On the actual approach, our LOC/GS and the real LOC/GS behaved pretty-much the same -- again, FlightGear was excellent practice (I didn't try an ILS approach with Elite). Off the approach path while we were being vectored in, the CDI flew back and forth at about the same rate as a child on a swing, rather than staying glued to one side (it was almost hypnotic), and the GS was a little funky as well. We should try to model that. Interesting. That's something I haven't noticed in a sim before (note that I haven't taken more than a passing glance at the last few MSFS releases). Is that normal behavior for all CDI? Unknown -- I'm working from a sample of one. Where is the taxi light mounted on the c172? I was flying a 172M, with both the landing and taxi lights mounted on the nose under the propeller. I think I've also seen the light in the wing on some 172's, but I'm not sure. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] View defaults
I just finished setting up configurable default viewing properties, and implementing them for the C172P 3D model. Look near the top of preferences.xml for an example. The recognized properties are as follow, with vanilla defaults in parentheses: /sim/view/config/default-field-of-view-deg (30) /sim/view/config/default-pitch-deg (0) /sim/view/config/front-direction-deg (0) /sim/view/config/front-left-direction-deg (45) /sim/view/config/left-direction-deg (90) /sim/view/config/back-left-direction-deg (135) /sim/view/config/back-direction-deg (180) /sim/view/config/back-right-direction-deg (225) /sim/view/config/right-direction-deg (270) /sim/view/config/front-right-direction-deg (315) These are particularly useful for the view from inside a 3D aircraft model. I've also modified FlightGear to use the defaults with the /sim/current-view/axes/(long|lat) properties. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] KJFK at night
Here is a screenshot of KJFK from 3900ft with a 16-bit buffer: http://www.megginson.com/flightsim/jfk-night.png First of all, it looks wonderful. Many of us can remember when the whole world was a desert, and then when we had only forest and grass airport areas with no runways. It's nice to see how far we've come in a short time. Now, with that out of the way, when you look closely, you'll notice that the lights are clearly floating 40 or 50ft above the runways. I wonder if there's any formulation we can come up with that could avoid this. For example, let's say that at a certain distance we need the lights to be 50 ft away from the ground to avoid z-buffer problems. If I'm looking at the airport from 2 miles away at 1,000ft AGL, then my view has slope of about 1:10, so the lights need to be lifted only about 5ft from the ground to get 50ft between them and the ground directly behind (from my current viewing angle). Does this make sense to the math types? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KJFK at night
Erik Hofman writes: Now, with that out of the way, when you look closely, you'll notice that the lights are clearly floating 40 or 50ft above the runways. I wonder if there's any formulation we can come up with that could avoid this. David, There is one thing to remeber; Approach lights usually are above the field (at least 2 meters). Thanks. I'm talking about the runway edge and centre lights and taxiway lights, though. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KJFK at night
Jim Wilson writes: That's a little too small to resolve differences at 16bpp. Try the patch below. It decreases the lifting substantially. You will see a slight increase in z-buffer flickering but it isn't bad. Note that we removed the distance component the other day, the purpose of it was to lift the lights higher when viewed at shallow viewing angles. Shouldn't the lights be lifted less at shallow viewing angles? The extreme case is sitting on a horizontal runway looking directly between the lights and the ground. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerial photos
Erik Hofman writes: I've always wanted to take a ride in a hot air balloon myself, but haven't done it yet. Good to hear it's a great experience. A while ago,we had a hard-coded balloon model. I don't think it works any more, but now that we have wind and weather, it would be nice to whip one together in YASim or JSBSim if they can support it. I could do a bit of work on a 3D model. We have a lot of balloon traffic around Ottawa; amazingly, they let them drift right through the Class C (= U.S. class B, I think) control zone around and over CYOW. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Andy Ross writes: This is tedious to fix (for me, anyway -- I don't have a registered AC3D copy that can save), so no one has bothered. There's also the question of whether it should be fixed in the YASim file or the model file. I contend that the nose is a much better origin, since a c.g. value is meaningless unless you have the mass distribution handy. Along the longitudinal axis, I think that we should use whatever the published weight-and-balance reference is for each aircraft, since that's what any published figures and distances will use. For single-engine Cessna's, it's the firewall; for some Piper Cub data I found, it's the leading edge of the wing at the fuselage; and so on. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross writes: FWIW, I still haven't been able to duplicate the rogue mouse click problem. Try this: fgfs --aircraft=c172p-3d Don't change the view direction or FOV. Click on the ident switch or the hi/low/off knob on the ADF and watch what happens. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross writes: Heh, hard to argue with that. Indeed, there was no check for panel visibility in the input code. I guess we've never noticed because nothing was fighting for the same real estate in the past. This one-liner appears to fix the problem. Committed. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson writes: Ok, yes as long as the origin is in sync, and the fdm rotates correctly. Just the same if the FDM origin was at the c.g. (geometry or gravity?) instead of the cockpit there would be a better chance of actually having the thing on the runway. The CG moves around quite a bit -- that's why aircraft have a fixed reference point for calculating weight and balance. Use the reference point, Luke. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] model.h usable for multiplayer
ace project writes: Is the class FGModelPlacement a good class to inherit to be used for drawing other multiplyer planes ? You probably don't need all of that -- just place it like any other 3D model using FGModelMgr. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747-yasim Questions
Jim Wilson writes: One advantage of switching to the tail would be that just about any aircraft would position reasonably on the runway without special configuration. Don't know if there are any disadvantages. I think that's the wrong reason to make the choice -- it's a permanent kludge to solve a temporary problem. We need to configure per-aircraft anyway, so that the 747 doesn't start on the 1500ft grass runway instead of the 12000ft concrete one. I do have a licensed AC3D here, so once a decision is made the 747 and A-4 models will be fixed. For these two, it's easy -- use the same origin that Andy used. For models used by both JSBSim and YASim, we'll have to coordinate. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] model.h usable for multiplayer
ace project writes: I just looked at FGModelMgr. How can I add models to it in runtime ? Calling init() everytime the number of multiplayers clients changes if very inefficient (but might work) and risks memory leaks(?). 2 create a method to add/remove models(instances) (also fixes all and is more effecient) Yes -- I had forgotten that they weren't already there. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Aircraft lights: navigation lights and beacon
The C172P model now has fixed navigation lights and a flashing red beacon on the tail. The beacon is on by default and the nav lights are off. Here's a screenshot of a long final approach to CYOW 07 at night: http://www.megginson.com/flightsim/night-approach.png (It's more dramatic when you actually see the beacon flashing.) You can control both lighting systems using properties: /controls/lights/beacon /controls/lights/navigation The beacon uses a new timed animation that switches among objects at a selected framerate (duration-sec): animation nameBeaconFlasher/name typetimed/type object-nameBeaconOff/object-name object-nameBeaconOn/object-name duration-sec1.0/duration-sec /animation I created two versions of each light, one with emission enabled and one with emission disabled. The nav light animations look like this: animation typeselect/type object-nameLeftNavLightOn/object-name object-nameRightNavLightOn/object-name condition property/controls/lights/navigation/property /condition /animation animation typeselect/type object-nameLeftNavLightOff/object-name object-nameRightNavLightOff/object-name condition not property/controls/lights/navigation/property /not /condition /animation I'll have to tweak this a bit for strobes, but it shouldn't be too hard. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] data logging
Boslough, Mark B writes: Is there documentation on the current data logging feature? I have been logging and playing back flights using JSBSim, but it looks like there is a general FlightGear feature that records CSV files now. I just can't quite figure out how to use it. docs-mini/README.logging All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: Looks good, does this tie into the electrical system model at all, or does it just respond to switch position ? So far, just the switch; I'll work on integrating it more fully later. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] data logging
Boslough, Mark B writes: I wrote my own little playback routine (so I can replay flights from a .csv file). Do you all have plans to incorporate such a thing in FlightGear? I can run forward or backward using the joystick to control the speed. That sounds great -- we'd probably want to add it as an FDM. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: starting the XML GUI; early implementors needed
I've committed CVS changes to begin an XML-configurable GUI. It's far from ready for end-users, but I need early implementors to start playing with what's there so far and to try making their own, simple dialogs using XML markup. To see an XML-configured dialog for a fancy FlightGear hello world, type Ctrl-D. The XML configuration is in $FG_ROOT/gui.xml. There is a new subsystem named gui, and a new command gui which takes the argument name for the name of the dialog to run, like this: key n=4 nameCtrl-D/name descDummy dialog/desc binding commandgui/command namehello/name /binding /key So you can already bind a dialog to any keystroke, mouse action, panel action, joystick button, etc. etc. Only a few components are present so far: group An invisible container holding a group of child components. dialog A group that will appear centred on the screen, with a visible background. The 'modal' subproperty controls whether the dialog is modal (puDialogBox) or non-modal (puPopup). input A text input field that can display the value of a property specified in the 'default-value-prop' subproperty (current read-only, but soon it will allow you to change the property value). text An uneditable text field. The text appears in the 'label' subproperty. button A push-button widget, with its text in the 'legend' subproperty. Currently, pushing any button simply closes the dialog, but soon other types of actions will be available. The 'default' subproperty controls whether the button is the default when the user presses Return, and the 'one-shot' subproperty controls whether the button pops back up on its own. Here is a rough outline of my future plans: 1. Allow users to modify property values and to add user-assigned actions to buttons. 2. Add more widgets, including at least sliders and check boxes, linked to property values. 3. Integrate the XML-configurable menu system into the new system. 4. Completely replace the existing GUI code with the new GUI subsystem and delete the old GUI code. 5. Allow dialogs to invoke other dialogs recursively. 6. Integrate Steve Baker's new PSL (PLIB Scripting Language) into the dialogs to allow complex, scripted behaviour. 7. Allow eye candy like icons and different fonts and colours. 8. Maybe introduce some simplistic layout managers to make it easier to design dialogs and place sub-components. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: Let's see, from the c172-electrical.xml I have: /systems/electrical/outputs/landing-light /systems/electrical/outputs/beacon /systems/electrical/outputs/strobe-lights /systems/electrical/outputs/taxi-lights You need to add the navigation lights (required by law at night), cabin lights, and (for some aircraft) panel lights, map light, and so on. There is a scary number of different permutations, even for a single C172 model -- for example, each separate gauge may or may not have its own internal light, depending on options chosen by the owner, replacements, etc. The VOR gauges seem the most likely to be separately lit. I believe these all default to on, unless there is a switch some place that is explicitely turned off. OK, then we need to wire these into the switches in the /controls/lights/* hierarchy. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RFD: /controls/engine/ reorg
A while ago, Curt suggested moving from /controls/afterburner[0] /controls/afterburner[1] /controls/afterburner[2] /controls/afterburner[3] /controls/mixture[0] /controls/mixture[1] /controls/mixture[2] /controls/mixture[3] /controls/propeller-pitch[0] /controls/propeller-pitch[1] /controls/propeller-pitch[2] /controls/propeller-pitch[3] /controls/throttle[0] /controls/throttle[1] /controls/throttle[2] /controls/throttle[3] and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/ with 'afterburner', 'mixture', etc. as subproperties of each one. This change would certainly make life easier in the property browser, but it would require changing quite a few bindings. I'm willing to make the change myself throughout the FlightGear source code and base package, but it will break some local customizations. How does everyone feel about the change? We could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further. All the best, ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
Christopher S Horler writes: I found a Flight International around work today when I was waiting for someone. It has an article about an emergency parachute system on some plane (I forget which), and I think it said you could get them for C172's and another Cessna... It's called the Ballistic Recovery System (BRS), and is still a little controversial. They're used mainly on ultralights (which have an unfortunate tendency to fall apart in flight), but also come standard with the Cirrus SR20 and SR22, and have been certified for use as an add-on with the C172. While the company claims hundreds of lives saved in its ads aimed at Cessna and Cirrus pilots, all of the saves were actually ultralights until a few weeks ago when a Cirrus pilot deployed the chute after losing an aileron. He lived; it's impossible to know how he would have managed without the chute, but it's worth noting that the plane was still under control when he deployed: http://www.avweb.com/newswire/news0241b.html So how long before I can land my fgfs C172 by parachute? That's what a lot of people are afraid of -- my engines running a little rough, better pull the chute. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
David Luff writes: I'm working on getting the small plane to taxi back in after flying a circuit, so I'd appreciate some input from the pilots from the list on real-life taxiing. What sort of speeds are typical during taxiing on the runway, on a large taxiway, on a small taxiway between rows of parked planes, and when turning corners. The rule I learned is never taxi faster than you can jog comfortably (10 km/h or about 5kt for me), and usually more slowly, especially at night or in bad weather or gusty winds. The ASI isn't all that useful at low speeds on the ground, so we usually gauge it by power setting: I was told to taxi a 172 at about 1000 RPM, but I end up riding the brakes that way -- I find that 800-900 RPM is more suitable (and even then, I brake more than I'd like to). What's a typical turn radius at a 90degree junction. That's easy -- follow the yellow line. Seriously, rwy 4/22 at CYOW is 75 ft wide, and we usually backtrack on 04 from taxiway papa to get the full length for takeoff. When I go back right along the edge (say, 5 or 6 feet in), and turn very tightly with a lot of differential braking, I can just bring it onto the centreline without an s-curve and without stopping my forward roll. That's a minimum turning diameter of about 30 feet (15 foot radius) while actually rolling forward -- a 25 foot radius would likely be much more comfortable. You can turn much more tightly if you stop your forward motion and just pivot around one wheel, but that's not good for the plane. Are major taxiways such as the one parallel to the rwy that normally seems to be called Alpha 2-way or is the traffic normally directed one-way on them by ATC depending on the rwy in use? That would be very airport specific, but note that almost every case ends up being a special case. People are always requesting a different runway, a different taxiway, a different intersection takeoff, etc., and ATC is usually pretty obliging. When I taxi on taxiway alpha at CYOW, there is sometimes a big 767 or Airbus heading straight towards me -- I have an instruction to hold short at delta and the big plane will turn onto the main apron before there, so there's not conflict, but it would look quite frightening to a new passenger. So the short answer is to let your AI plane take the shortest route back to parking. Note that it should stop for a while before crossing any runways -- even when you're precleared to cross, you still stop and look. The C172 should also stop to do a runup just before it goes to the hold-short line runway -- that can take 3-5 minutes for a single and longer for a twin. Allow another minute or so for tower clearance before taxiing out for takeoff. Do most light plane parking spots have a designated direction when parked or is either way fine? Light planes are almost always parked facing into the prevailing wind, especially if they're out on the field. On the apron in front of our hanger, they're facing any which way. The easiest choice would be to have the AI plane just stop in front of the pumps. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] re: ANN: starting the XML GUI; early implementors needed
I've just added the ability to modify property values: we can now construct very simple dialog boxes that actually control FlightGear (the demo can control roll, pitch, and heading). More interesting stuff like pick lists, value constraints, etc. will follow. Again, I need feedback from early implementors -- try making a dialog for something you care about and let me know what you need the most. Enjoy, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
Julian Foad writes: No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. It also makes life easier for programmers, since we can pass around one node containing engine settings and nothing else. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Engine models: start-up and commonality between FDMs
Julian Foad writes: Much of this code in JSBSim is very similar to FDM/IO360.cxx which seems to be only used by LARCsim even though it is not in the LARCsim subdirectory; presumably one was derived from the other. I really don't like duplication; I feel that any work I do on one of them is half wasted if it isn't automatically shared by the other. And then there is Yasim's engine code. Three piston engine models, each specific to its own FDM. So I started thinking about deriving them all from a common PistonEngine interface with the aim of making the engine models interchangeable. Haven't gone anywhere down this road yet, though. Thoughts? I like the idea as well: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs (let's try the J3 cub with 180HP). Unfortunately, the FDM people haven't been too enthusiastic: in particular, JSBSim is supposed to run standalone as well as inside FlightGear, so they need some kind of internal engine model. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: I don't know where the navigation lights are powered from in real life. I'm guessing maybe this is the same thing as the beacon (?) I don't see a specific reference to navigation lights power in the C172 electrical diagram. Here's a quick overview of the external lights in a 172: navigation lights: A red light on the left wing tip and green light on the right wingtip, visible from the front and (relevant) sides, and a white light pointing backwards from the tail. Required for night flight. beacon: Big flashing/rotating red light extending above the vertical tail and visible from every direction. Optional for night flight, and not on every aircraft, but pretty commonly used. Note: at our flying club, the policy is always to leave the beacon switched on; that way, you can tell from a distance if someone's forgotten to turn off the masters after shutting down the plane. strobes: Flashing lights on the wingtips (and other places for bigger planes). Optional for night flight, and not on every aircraft. Note: pilots usually turn the strobes off on the ground or in cloud or fog, for obvious reasons. landing light: Bright spotlight in the nose or left wing, aimed a bit forward of the plane. Required for night flight with passengers, optional otherwise (I've already done practice landings without it). Note: pilots often leave the landing light on continuously night and day for visibility, except when taxiing facing a plane making an approach (to avoid confusing the pilot). taxi light: Bright light usually located right beside the landing light on the nose or left wing. Optional for night flight, and not on every aircraft. There is a separate switch for each of these on the control panel. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
Curtis L. Olson writes: The opposite is also a problem ... pilots not pulling the chute because they think they can save the plane or successfully land it and then getting themselves hurt. I recall some time back a Cirrus pilot being critically injured and totalling his plane when he crash landed in a corn field. Made me wonder why he didn't pull the chute, but he probably thought he could save a few bucks (the parachutes are one shot only I believe) if he just glided it in. Was it a crash landing (structural damage and loss of control) or just a forced landing (engine failure)? A forced landing in a cornfield should be pretty routine; when pilots die after an engine failure in VMC, it's usually because they a) try to turn back to the airport immediately after takeoff (it didn't work for the last 2,000 pilots who tried it, but maybe it will work for me...); or b) try to stretch the glide to make a runway (ditto). I spend more time reading accident reports than is healthy, and I haven't noticed many reports of fatalities (if any) when the pilot simply set the plane down in a nearby field instead of trying to make an airport; sometimes the plane is wrecked up (i.e. nosewheel goes down a gopher hole or into a ditch and the plane flips over), but the crops and the airframe usually absorb most of the energy. Note that the SR22 pilot who did use the BRS damaged his plane pretty badly as well, and he had no control over where he landed (at a very high descent rate). If it had hit high trees rather than low ones before it nosed over, he might have been badly injured as well. If I had an engine failure around Ottawa in good VMC, I'd certainly choose a routine forced landing in a field over a 2000fpm vertical descent, possibly onto the edge of a tall building, a power line, 100ft trees, the railway tracks, the middle of a freeway, etc. etc. If I was in a midair and the plane was not controllable, or perhaps if I had an engine failure in IMC over hostile terrain with high obstacles, then I might take my chances with a BRS. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Curtis L. Olson writes: So I'm probably miss reading something in the diagram. I assume you have a similar C172 manual ... perhaps you could find where the navigation lights are powered from on your model and we could work from that. In the 1981 C172P, there is a circuit breaker off the primary bus labelled NAV LT that goes to the navigation lights, control wheel map light, and audio muting relay. Here's the complete list of breakers: Primary Bus --- AIR COND CIR FAN - to air conditioning system or circulation fan system ALT FIELD - to master switch FLAP - to wing flap system PITOT HEAT - to pitot heat system INST - to ignition switch - to oil temperature gauge - to low-voltage warning light - to fuel quantity indicators and carburetor air temperature gauge INT LT - to door post map light - to dome and courtesy lights - to instrument, radio, magnetic compass, and post post lighting NAV LT - to audio muting relay - to navigation lights and control wheel map light BCN LT - to flashing beacon [cigar lighter has a direct connection to the primary bus] LAND LT - to taxi and landing lights STROBE AVN FAN - to strobe lights - to avionics cooling fan TURN COORD - to turn coordinator Avionics Bus [connected to primary bus through avionics master switch] RADIO 1 - to radio RADIO 2 - to radio RADIO 3 - to radio RADIO 4 - to radio or transponder and encoding altimeter RADIO 5 - to radio AUTO PILOT - to autopilot Note that many of the components, like the strobes, autopilot, and air conditioning, are optional extras. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
Curtis L. Olson writes: My impression was that it looked like a routine forced landing in a corn field due to engine failure. Thus I was surprised by the amount of damage to the aircraft and the severity of the injuries. In my head I thought, if things were that bad, why didn't they just pull the chute? My guess at the time was that it was a routine forced landing in the corn which is why they chose not to pull the chute, but perhaps they tried to stretch the glide out too far, or misjudged something, and ended up hitting *much* harder than they should have. What was the date of the accident? We might be able to find a preliminary NTSB report. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Parachute for C172
David Megginson writes: My impression was that it looked like a routine forced landing in a corn field due to engine failure. Thus I was surprised by the amount of damage to the aircraft and the severity of the injuries. In my head I thought, if things were that bad, why didn't they just pull the chute? My guess at the time was that it was a routine forced landing in the corn which is why they chose not to pull the chute, but perhaps they tried to stretch the glide out too far, or misjudged something, and ended up hitting *much* harder than they should have. What was the date of the accident? We might be able to find a preliminary NTSB report. Here's another one involving the BRS where it failed to deploy in IMC: http://www.ntsb.gov/NTSB/brief.asp?ev_id=20020326X00393key=1 All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SR-20 in a corn field
This looks like it might be the one: http://www.ntsb.gov/NTSB/brief2.asp?ev_id=20010921X01977ntsbno=CHI01LA318akey=1 The problem was that he had only seconds to pick a landing site and set up a final approach once he broke out of IMC, and given those constraints, it's quite impressive that he managed to put it down in a field at all without doing something stupid like spinning out or a controlled flight into terrain. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] No rule to make target `new_gui.cxx'
Martin Spott writes: make[2]: *** No rule to make target `new_gui.cxx', needed by `new_gui.o'. Stop. Somethings not rebuilding properly. Make sure you have a fresh CVS checkout, then touch src/GUI/Makefile.am and do a new make. If that doesn't work, try sh autogen.sh from the root first, then a new ./configure. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: ANN: starting the XML GUI; early implementors needed
Norman Vine writes: If we could build a version of the property viewer that would attach property nodes into the 'builder's' callback slots It might just 'come alive' :-) I'd love for FlightGear to be runtime configurable through a GUI -- just drag and drop a property onto a drop-down menu, a keyboard diagram, etc., and build new dialogs while the plane is flying. We probably need someone very committed to build that, though. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] data logging
Boslough, Mark B writes: 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). I have no clue how to check them in. Sounds great -- send them to me and I'll take a look. I prefer patches against the current CVS from the top-level source directory, i.e. cvs diff -u new-fdms.dif I'm with extended family this weekend, so delays are possible. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Aircraft lights: navigation lights and beacon
Dave Perry writes: The lights look great! Thanks. The rear facing white light on the rudder is switched on with the red and green wing tip lights as the nav lights. Is there a RearNavLightOn and RearNav LightOFF object name? I haven't got around to adding the rear light yet. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
Julian Foad writes: Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. While that's the sort of thing I do at work, I'm not yet in a position to do it here. We can already override parts of JSBSim's internal implementation (such as its weather model). There's no reason we couldn't rig up JSBSim and YASim to take engine parameters from properties as well. The engine model needs basic information like fuel available, outside air temperature and humidity, static and dynamic pressure, etc., all of which are accessible from outside the FDMs. It would have to feed back fuel and oil consumption, location and direction of thrust, amount of thrust, and information about gyroscopic effects. 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. At a certain point, friction should take over. I added a kludge in JSBSim to make that happen. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Sopwith Camel model added
Michael Selig writes: I have just added a Sopwith Camel to the CVS. Not only does it include the flight dynamics model, but also there's an external model from A.F. Scrub! He has granted permission for us to use and release these with FlightGear under the GNU GPL. There's a readme file on the external model from A.F. Scrub in: ~/fgfsbase/Aircraft/sopwithCamel/Models/uiuc/sopwithCamel/ Thank you very much. It might be a good idea in the future to put 3D models directly into Aircraft/*/Models/ rather than Aircraft/*/Models/uiuc/, since 3D models are usable by all FDMs (all four major ones use the same C172 model, for example). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
Andy Ross writes: I'd *love* to see good numbers for propeller acceleration, however. If one of the Real Pilots out there could go out with a stopwatch and get us graphs of RPM vs. time for full throttle acceleration and cut-power deceleration I'd be eternally grateful. :) I don't want to get banned from the flying club (or demonstrate my limited forced-landing skills), so I'm not going to abuse the engines by jamming the throttle in hard to full from idle and timing it. Here are some unofficial observations, however, from various 172's: 1. The prop accelerates and decelerates very quickly. You're supposed to move the throttle smoothly so that the changes don't happen too quickly. 2. During runup, I push the throttle in from 1000RPM to 1700RPM -- the lag between throttle movement and tach indication is barely perceptable (under 0.25 sec). 3. Next, I pull the throttle from 1700RPM to idle. The drop on the tach from 1700RPM to about 600RPM is nearly instantaneous (again, under 0.25sec). 4. At shutdown, I set the engine to 1000RPM, then pull the mixture to shut it down. The engine continues to fire for a couple of seconds until it burns off all its fuel, but once it stops firing, the propeller stops in well under a second. During takeoff, I have other things to worry about, but I'll guess that the lag between 1000RPM and max static (2200-2400RPM) takes less than 0.5sec, possibly again less than 0.25sec. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Keyboard braking power
Julian Foad writes: It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? I used to use a different approach -- instead of slamming the brakes right to 1.0, pressing my joystick buttons (works for keys as well) would repeatedly increase the brakes by a small amount like 0.05, while releasing would immediately reset to 0. You could get a sort of anti-lock brake by pumping the buttons. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] C172 Taxiing speed
David Luff writes: So basically they're 2-way, but sequentially, with planes never passing wing-tip to wing-tip in opposite directions each side of the yellow line? The yellow line is where your nosewheel is supposed to be. That said, little planes pass each other all the time on taxiways -- it's just like a country road, where one plane pulls far over to the side (even onto the gravel) to let the other by. During daylight with good visibility, ground control basically clears us to taxi to a runway and leaves us alone to work out the details. Big planes, of course, have to be more organized and wouldn't have room to pass on the same taxiway (there are also issues with jet blast -- taxiing too close behind an idling 737 could flip your Cessna upside down). Even runways are two-way in the real world -- in light winds, one plane might land on 32 as soon as the previous one turns off from a landing on 14 and just before another takes off on 25 right through the intersection with 14/32. In good VMC during the day, everyone (especially the big transports) takes straight-in if they can get it. In fact, the other night my instructor and I took a (long) runway with a 5kt tailwind to save ten minutes getting home. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: new aircraft aliases and 'include' attribute
I've introduced an aliasing arrangement into $FG_ROOT/Aircraft/, so that we can use simpler identifiers, and so that JSBSim isn't treated differently from other FDMs. Here's an example: --aircraft=c172 is now an alias for --aircraft=c172r which is an alias for --aircraft=c172r-jsbsim If, in the future, we happened to prefer the UIUC or YASim c172r as the default, we could simply change --aircraft=c172r to be an alias to --aircraft=c172r-yasim etc. This change depends on my patch to SimGear this morning to allow the 'include' attribute on the root element of an XML config file. You'll have to update to the latest SimGear CVS and make sure FlightGear is relinked with it. The main user-visible benefit is shorter names, like fgfs --aircraft=dc3 or fgfs --aircraft=sopwithCamel This also means that we can create new *-set.xml files by subtyping existing ones. For example, if someone made a DC-3 model for JSBSim, we could subclass the YASim config file like this: ?xml version=1.0? PropertyList include=dc3-yasim-set.xml sim descriptionDC-3 (JSBSim)./description flight-model archive=yjsb/flight-model /sim /PropertyList All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 747 question
Curtis L. Olson writes: Cruising in the 747-yasim at 18,000' (altitude holding me steady) and with throttle adjusted so I'm stable at 490 kts, I'm seeing a -3 degree pitch down (/orientation/pitch-deg) From what I can find, the 747 is supposed to be able to cruise at around 490 KTAS between FL280 and FL350. At FL280, 490 KTAS true would be about 314 KIAS; at FL350, it would be a bit lower, but you're getting near the tropopause and things get screwy. At FL180, 314 KIAS would give you only 427 KTAS. If you're trying to fly at 490kt *indicated* at FL180, then you're pushing something like 666kt true -- it would be no surprise that you'd have to push the nose down and abuse the engines to maintain that. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 question
Andy Ross writes: So basically, you have the plane in an unusual flight environment. Real planes are almost never flying this fast at this altitude; they'll be at ~300 KIAS or so and using the extra available thrust for climbing. Counter-example: a few years ago, I flew from Ottawa to Heathrow direct in an Air Canada 747-400. It made a stop at Montreal Dorval to pick up more passengers before starting the transatlantic leg. CYOW to CYUL is about 85 nm, and we stayed below the flight levels for the whole way. Second counter-example: 767s often fly between Ottawa and Toronto (196 nm), usually no higher than FL180. Still, the point is valid -- a 747 doesn't cruise that fast at low altitudes. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 747 question
David Megginson writes: If you're trying to fly at 490kt *indicated* at FL180, then you're pushing something like 666kt true -- it would be no surprise that you'd have to push the nose down and abuse the engines to maintain that. You also have to allow for compressibility effects in calculate TAS for something that fast -- that's not an issue with the spam cans I fly. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
Michael Selig writes: Any idea on the status of this? I assume this is the tool of choice for making models? It is Open Source, while AC3D is commercial, but FlightGear really doesn't care which tool you use. I was repulsed by Blender the first few times I ran it and immediately removed it from my hard drive again. A couple of years later, I invested an hour or two in some of the online tutorials (castle, pencil), and was hooked. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest CVS Crashes
Jonathan Polley writes: I updated plib, SimGear, and FlightGear before rebuilding. I cleaned everything on Windows because there were some changes to plib headers (MSVC isn't always smart enough to properly handle header changes if they are not in YOUR project). I haven't cleaned the MacOS build because gcc hasn't had such problems. You have to make sure that FlightGear rebuilds. When there's a SimGear change that doesn't touch any headers, FlightGear might not automatically rebuild -- you have to delete the fgfs (or fgfs.exe) binary and then do a make. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
