[Flightgear-devel] dc3-yasim model
Attched find an xml file "dc3.xml" that includes edits that allow accelleration on the main gear and relativly easy wheel landings. With these changes, I can leave the tail wheel unlocked for take-off and landings. Changes: 1. Relaxed the stall width for both the wing and the hstab. A dc3 cannot possibly have worse stall characteristics than the c310. 2. Added 'effectiveness="nnn"' to the flap0 for both the hstab and the vstab as well as 'effectiveness="nnn"' for both hstab and vstab. As Andy Ross suggested, I could set the hstab effectiveness high and the hstab flap0 effectivness low to decrease the tendency to porpoise. This really helped a lot! See the file for the values. 3. I moved the main gear back to 6.9 (from 6.02). This had a very big effect and enables getting the tail up and accelerating on the mains. Without this, no matter what I did, by the time the tail came up, I had already set up the porpoise. Same on wheel landings. With these changes and good rudder pedals, the yasim dc3 handles more like a real tail dragger. At taxi speeds, you need differential brakes. I have toe brakes on my CH Pro-Pedals. Please fly it and then tell what you think. Dave
Re: [Flightgear-devel] Runway Lighting Questions
On Sun, 7 Jul 2002, David Megginson wrote: > patched FlightGear so that (a) runway edge lights are not visible from > improbable distances (like 50km or more), and (b) runway edge lights > are not visible at all while the sun is above the horizon, but haven't > committed these patches yet. I think this (6 mi) is a bit too restrictive. Runway edge lights ARE visable from considerable distances, even during the daytime hours. (Sorry , don't have any exact distances tho). jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
In the $fgroot/Lighting you can control the ambient and diffues lighting based on sun angle. Curt. David Megginson writes: > Norman Vine writes: > > > Probably more with the 'model' now being in it's own 'graph' which > > is called after other code has 'mucked' with the lighting after it was > > setup to use the proper 'ambient' and 'diffuse' valuse for the 'time of day' > > The model is not in its own graph in external view, and this problem > far predates the new model code in any case. Here's a thread from > December 2000, when it was already an old problem: > > http://www.menet.umn.edu/~curt/lists/fgfs/archive-200101/msg00085.html > > Just to recap, the bottom of an aircraft at night is shaded more > brightly when the sun is below the horizon; in effect, it shines > through the earth. > > > 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 -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS not working
Julian Foad writes: > The CVS server is not working for me at the moment. It was working > 10 hours ago when I last tried it. > > $ cvs diff > cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF > > - Julian Seems to be working for me at the moment. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
>Yes, I've had this discussion as well. The sun should stop being a >light source once it's, say, 15-30 deg below the horizon. IMHO it should be possible to have different rendering parameters for the aircraft than for the rest of the scenery, for example by having it in its own tree. Then, you could calculate whether it is sun-lit using its height. The formula for that is fairly easy. >All the best, > > >David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dumb suggestion
>Realistic night lighting would be great. I know how MSFS nightlighting works (Its fairly trivial), so if we could change the lighting parameters for the 3D model only (I guess we do not want MSFS lighting for the rest), we could have night-lit aircraft. Often, this looks really great, I experimentally implemented it in PPE. You have bright windows, an illumintade tail logo etc. >Best, > >Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] re: [Flightgear-cvslogs] CVS: FlightGear/src/Controls controls.cxx,1.21,1.22 controls.hxx,1.21,1.22
On Sat, 06 Jul 2002 13:49:36 -0700, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > ..(during the Falklands War, the Britts tested refuelling of > > Harriers and Sea Harriers, from ships, in-hover refuelling, > > believe I saw this in Air Progress magazine in the mid 80'ies.) > > I think what you're remembering is the "Sky Hook" gadget that was > developed but never installed on Royal Navy vessels. It was actually > a full-service landing system, not just a refuelling boom. The idea ..could well be both. Was possibly tested in North Norwegian waters, the Britts trained up here, the topography is pretty similar. ..correct afair, the articles mentioned commandeered/drafted tanker vessels, and not using standard issue naval vessels. > was that the Harrier would come to a stable hover alongside the boat, > and then be grabbed from above by the hook. It would then > (carefully!) decrease thrust until it was just hanging there, and then > be lowered onto the deck like cargo. ..the US Navy did hoist Boeing (or Grumman?) pursuit planes in thru the belly of an airship in the late 20-30'ies, climb into the hook, lock it, hoist it in, drop it onto the hangar deck. ..the US Navy also played with condensing water out of engine exhaust gas in at least one of these airships, I'm thinking of trying a wood gasifier in one. First things first, though. > I can't imagine this was very popular with the pilots. Imagine > sweating during the (already very difficult) hover as some 19 year > old sailor swats at you with a giant crane. :) ..uhmmm, yeah, we could model fly swatting too. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: [Plib-devel] Autogen/configure now fails, related to GL
I'm getting it too. Cygwin tree from 5 days ago or so... - Original Message - From: "Paul Deppe" <[EMAIL PROTECTED]> To: "FGFS-Devel" <[EMAIL PROTECTED]> Sent: Saturday, July 06, 2002 12:12 PM Subject: [Flightgear-devel] RE: [Plib-devel] Autogen/configure now fails, related to GL > > > In the last few days I can no longer build PLIB. I get (on CygWin): > > > > [...] > > > > > checking for glNewList in -lopengl32... no > > > configure: error: could not find working GL library > > > > > > - Julian > > > > That confuses me. Shouldn't glNewList be defined in libopengl32 with Win32 > > / Cygwin ? > > > > > > - Sebastian > > I'm getting the same error as Julian on my Cygwin system. I tried old > versions of configure.in and it works fine with 1.34 but fails with 1.35. > The new code in version 1.35 explicitly checks for glNewList() and > glLookAt(), while the old code simply checked for the presence of > libopengl32.a and libglu.a. The comment for version 1.35 says, "Let's hope > that this fixes building on OS-X". If this is true, perhaps we could put a > conditional around this code so that it doesn't break under Cygwin. > > Regards, > > Paul > > Paul R. Deppe > Veridian Engineering (formerly Calspan) > Flight & Aerospace Research Group > 150 North Airport Drive > Buffalo, NY 14225 > (716) 631-6898 > (716) 631-6990 FAX > [EMAIL PROTECTED] > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote: > Thanks for the info. I'd be reluctant to put together an > Input/Joysticks/Saitek/X45.xml file that I couldn't actually test. If > you have a chance to hobble one together some time, I'll be very > grateful. I was afraid you'd say that. :) Here is an X45.xml file that I've verified to work on my stick. I've removed all the hacks, leaving (hopefully) something that is generically useful. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) Saitek Saitek X45 Aileron property-scale /controls/aileron true Elevator property-scale /controls/elevator -1.0 true Rudder property-scale /controls/rudder Throttle property-scale /controls/throttle[0] -1.0 -0.5 property-scale /controls/throttle[1] -1.0 -0.5 Mixture property-scale /controls/mixture[0] -1.0 -0.5 property-scale /controls/mixture[1] -1.0 -0.5 Propeller Advance property-scale /controls/propeller-pitch[0] property-scale /controls/propeller-pitch[1] View Direction true property-adjust /sim/current-view/goal-heading-offset-deg 1.0 true property-adjust /sim/current-view/goal-heading-offset-deg -1.0 View Elevation true property-adjust /sim/current-view/goal-pitch-offset-deg 1.0 true property-adjust /sim/current-view/goal-pitch-offset-deg -1.0 Brakes property-assign /controls/brakes[0] 1.0 property-assign /controls/brakes[1] 1.0 property-assign /controls/brakes[2] 1.0 property-assign /controls/brakes[0] 0.0 property-assign /controls/brakes[1] 0.0 property-assign /controls/brakes[2] 0.0 Landing Gear Up/Down Toggle property-toggle /controls/gear-down Elevator trim down true property-adjust /controls/elevator-trim 0.0015 Aileron trim right true property-adjust /controls/aileron-trim 0.0015 Elevator trim up true property-adjust /controls/elevator-trim -0.0015 Aileron trim left true property-adjust /controls/aileron-trim -0.0015 Decrease flaps property-adjust /controls/flaps -0.34 Increase flaps property-adjust /controls/flaps 0.34 Rudder trim right true property-adjust /controls/rudder-trim 0.0015 Rudder trim left true property-adjust /controls/rudder-trim -0.0015
Re: [Flightgear-devel] Runway Lighting Questions
> I'm currently applying a range limit of 12,000m (about 6nm) to the > lights (the range is from the middle of each runway). Personally, I > suspect that that might be far too generous, but I don't want to make > the range too short for very long runways. What does everyone else > think? All the edge lights I've seen so far are incredibly directional, because they burn a lot of electricity and directionality saves on your power bills. I'd estimate that HIRL is brighter than normal city lighting out to 10nm when aligned with the runway. In the transverse direction, I can barely see the lights when 0.5 nm away (i.e. on downwind) at some airports. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
Norman Vine writes:
> globals->get_model_mgr()->draw();
> globals->get_aircraft_model()->draw();
That's mostly dead code. FGModelMgr::draw is now a no-op and should
be removed (Jim?):
void
FGModelMgr::draw ()
{
// ssgSetNearFar(_nearplane, _farplane);
// ssgCullAndDraw(_scene);
}
FGAircraftModel::draw() draws the plane in a separate graph in
internal view, but simply does this in external view:
_selector->select(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
Re: [Flightgear-devel] Small Scheme library
Tony Peden wrote: > On Wed, 2002-07-03 at 11:40, David Megginson wrote: > >>Tony Peden writes: >> >> > > I don't know how many interdependencies there are, but the js related >> > > source and headers total 142k. >> > >> > Check that, 212k. >> >>That's pretty close. I wonder how bad the dependencies are. > > > OK, I've gotten the compressed and uncompressed numbers confused. The > two numbers I quoted above are uncompressed. The original 360k posted > was for the whole library and was compressed. A quick look at the header declaration makes me belive it isn't possible to create you own objects/functions with this package. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
David Megginson writes:
>
>Norman Vine writes:
>
> > Probably more with the 'model' now being in it's own 'graph' which
> > is called after other code has 'mucked' with the lighting after it was
> > setup to use the proper 'ambient' and 'diffuse' values for the 'time of
day'
>
>The model is not in its own graph in external view,
I guess I really don't understand the code anymore as
I thought that the 'external model' was drawn by this code
in main.cxx
void fgRenderFrame() {
.
globals->get_model_mgr()->draw();
globals->get_aircraft_model()->draw();
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
David Megginson writes: > >Norman Vine writes: > > >The model is not in its own graph in external view, and this problem >far predates the new model code in any case. Here's a thread from >December 2000, when it was already an old problem: > > >http://www.menet.umn.edu/~curt/lists/fgfs/archive-200101/msg00085.html > >Just to recap, the bottom of an aircraft at night is shaded more >brightly when the sun is below the horizon; in effect, it shines >through the earth. Here is a 'fix' I submitted before that was 'almost' implemented :-) http://www.menet.umn.edu/~curt/lists/fgfs/archive-200103/msg00576.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] dumb suggestion
Norman Vine writes: > Probably more with the 'model' now being in it's own 'graph' which > is called after other code has 'mucked' with the lighting after it was > setup to use the proper 'ambient' and 'diffuse' valuse for the 'time of day' The model is not in its own graph in external view, and this problem far predates the new model code in any case. Here's a thread from December 2000, when it was already an old problem: http://www.menet.umn.edu/~curt/lists/fgfs/archive-200101/msg00085.html Just to recap, the bottom of an aircraft at night is shaded more brightly when the sun is below the horizon; in effect, it shines through the earth. 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] dumb suggestion
David Megginson writes: > >Norman Vine writes: > > > >Yes, I've had this discussion as well. The sun should stop being a > > >light source once it's, say, 15-30 deg below the horizon. Otherwise, > > >it lights up the bottoms of objects at night. > > > > I think all that is needed is to change to 'ambient' lighting only after the > > sun goes 'below' a certain point. > >Wouldn't this have something to do with shading? Probably more with the 'model' now being in it's own 'graph' which is called after other code has 'mucked' with the lighting after it was setup to use the proper 'ambient' and 'diffuse' valuse for the 'time of day' Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Runway Lighting Questions
I've sent mail to Curt about this point already, but while I'm waiting, I thought I'd throw out the question to the list. I've patched FlightGear so that (a) runway edge lights are not visible from improbable distances (like 50km or more), and (b) runway edge lights are not visible at all while the sun is above the horizon, but haven't committed these patches yet. I'm currently applying a range limit of 12,000m (about 6nm) to the lights (the range is from the middle of each runway). Personally, I suspect that that might be far too generous, but I don't want to make the range too short for very long runways. What does everyone else think? This change is important for people using FlightGear to practice cross-country flying and navigation. The edge lights as they are right now make it far too easy to find an airport at great distances during the day. I'll commit the patches when I hear back from Curt, since the runway lighting is his baby. 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] CVS not working
The CVS server is not working for me at the moment. It was working 10 hours ago when I last tried it. $ cvs diff cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
Andy: Thanks for the info. I'd be reluctant to put together an Input/Joysticks/Saitek/X45.xml file that I couldn't actually test. If you have a chance to hobble one together some time, I'll be very grateful. 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] dumb suggestion
Norman Vine writes: > >Yes, I've had this discussion as well. The sun should stop being a > >light source once it's, say, 15-30 deg below the horizon. Otherwise, > >it lights up the bottoms of objects at night. > > I think all that is needed is to change to 'ambient' lighting only after the > sun goes 'below' a certain point. Wouldn't this have something to do with shading? 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
