Re: [Flightgear-devel] Windows Build Problems
Jonathan on those four lines (thats all there is) change the text from "sgMat4 &get..." to "sgVec4 * get...". If you bring up lines 96-99 you'll see where the change is required. Sorry about that. I should be able to get a patch done sometime tomorrow. Best, Jim Jonathan Polley <[EMAIL PROTECTED]> said: > With the latest updates to CVS, MSVC is having problems. > > c:flightgearsrcmainlocation.hxx(96) : error C2440: 'return' : cannot > convert from 'float [4][4]' to 'const float (&)[4][4]' > Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' > There is no context in which this conversion is possible > c:flightgearsrcmainlocation.hxx(97) : error C2440: 'return' : cannot > convert from 'float [4][4]' to 'const float (&)[4][4]' > Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' > There is no context in which this conversion is possible > c:flightgearsrcmainlocation.hxx(98) : error C2440: 'return' : cannot > convert from 'float [4][4]' to 'const float (&)[4][4]' > Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' > There is no context in which this conversion is possible > c:flightgearsrcmainlocation.hxx(99) : error C2440: 'return' : cannot > convert from 'float [4][4]' to 'const float (&)[4][4]' > Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' > There is no context in which this conversion is possible > > Since the compile dies at this point, I don't know if there are any more > hiding in the background. > > There are older issues with building under MSVC: > > Main/viewer.cxx has a #include that should be either > "fg_props.hxx" or , which ever you prefer. > > Both Network/raw_ctrls.hxx and Network/net_fdm.hxx have static constants > defined as a part of their classes. MSVC does not want them to be used to > define structures, but will take the enumeration equivalent. > > > As always, I have no problems with Linux. > > Thanks, > > Jonathan Polley > -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Windows Build Problems
With the latest updates to CVS, MSVC is having problems. c:\flightgear\src\main\location.hxx(96) : error C2440: 'return' : cannot convert from 'float [4][4]' to 'const float (&)[4][4]' Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' There is no context in which this conversion is possible c:\flightgear\src\main\location.hxx(97) : error C2440: 'return' : cannot convert from 'float [4][4]' to 'const float (&)[4][4]' Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' There is no context in which this conversion is possible c:\flightgear\src\main\location.hxx(98) : error C2440: 'return' : cannot convert from 'float [4][4]' to 'const float (&)[4][4]' Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' There is no context in which this conversion is possible c:\flightgear\src\main\location.hxx(99) : error C2440: 'return' : cannot convert from 'float [4][4]' to 'const float (&)[4][4]' Reason: cannot convert from 'float [4][4]' to 'const float [4][4]' There is no context in which this conversion is possible Since the compile dies at this point, I don't know if there are any more hiding in the background. There are older issues with building under MSVC: Main/viewer.cxx has a #include that should be either "fg_props.hxx" or , which ever you prefer. Both Network/raw_ctrls.hxx and Network/net_fdm.hxx have static constants defined as a part of their classes. MSVC does not want them to be used to define structures, but will take the enumeration equivalent. As always, I have no problems with Linux. Thanks, Jonathan Polley
Re: [Flightgear-devel] My Second Flight
David Megginson <[EMAIL PROTECTED]> said: > I've signed up for ground school and for more lessons and > have joined the Ottawa Flying Club as a student member (about US > $60/year) -- I'll introduce them to FlightGear when I'm better > established. Yep, your in it now. Congratulations! Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Second Flight
On Wed, 10 Apr 2002 20:22:41 -0400, John Check <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > On Wednesday 10 April 2002 04:26 pm, you wrote: > > > Again, thanks everyone, > > > > w00T! Congrats David! > > > > g. > > > > > > Hear hear ..we have him hooked now. ;-) -- ..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] My Second Flight
On Wednesday 10 April 2002 04:26 pm, you wrote: > > Again, thanks everyone, > > w00T! Congrats David! > > g. > > Hear hear > > ___ > 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] segfault (linux)
Curt, The new default properties set up the various views. So the problem is if running the new code, and none is defined there would be no view to access. I'm going to submit some patches that consolidate some of the matrix math for models and views, which included some patches to the view manager. After this I've got a little more cleaning up to do in the view manager. Should I hard code a default pilot view in there (ie if none is defined)? Alternatively, if you can lead me to a graceful way of printing a message and exiting... Thanks, Jim Curt said: > Make sure you have the latest base package ... I think some default > properties changed. I don't think this should lead to a segfault, but > apparently it does ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
Jon S Berndt writes: > I'll try and have a look this evening, but Tony's probably > the better one to look at this. But, IIRC he's very busy > this week. Basically, Frederic's loosing elevator authority before he loses lift. I don't have my C172 POH yet (the flying club usually has students train on the 150, and they have to order a 172 copy for me), so I'll quote from a much less authoritative source, the FLY! User Manual: Either way, you've "stalled" according to the FAA. In the first case, there's been an actual separation of the airflow over the wings, and the airplane has started to drop. In the second case, you've run out of elevator control; the airflow is at least partly separated, and you're not producing enough lift to hold the airplae up (hence the rapid rate of descent). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
On Wed, 2002-04-10 at 14:43, Frederic Bouvier wrote: > From: "David Megginson" <[EMAIL PROTECTED]> > > Frederic Bouvier writes: > > > > > The c172 is flyable now but I thing the stall don't reproduce the > > > real behaviour. I thing it should dive more frankly. Now it seems > > > to stay flat ! > > > > My changes shouldn't affect the stall, except for any roll component. > > I've read that the C172 often stalls very gently, so it might not be > > right to expect a screaming dive -- I haven't tried stalls yet on the > > real thing. > > > To stall, I try to keep my altitude while the engine is put idle. So I > should see an increase of the AoA while pulling the stick before the > stall and then a decrease to a negative number. Now in real life I would > release the stick and push the throttle to recover 300ft lower. > >With the JSBsim model, I don't see the decrease of AoA at stall. This is due to the lack of stall hysteresis modeling. We'll need to do some infrastructure work before we can support this. > Instead, > the plane keeps it AoA with the stick completely pulled. It does actually lose some as it goes over the top of the lift curve, but I do agree that it's not nearly enough. > It do not swivel > aroung its CG like a real plane ! > > -Fred > > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit transparent to RWY lights
"Curtis L. Olson" <[EMAIL PROTECTED]> said: > Frederic Bouvier writes: > > I don't know how a scene is drawn now but by drawing : > > > > 1. the scenery, > > 2. the lights, > > 3. the cockpit, > > 4. the panel. > > > > in that order, we should avoid this kind of anomaly. > > > > Am I missing something ? > > If we draw the outside scenery followed by the 3d model / panel of the > aircraft we should avoid this problem. > I've already changed the order. We were having some problems with the model appearing to disappear into the clouds (at low elevation) as well. The change will be in my next patch (probably later tonight). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault (linux)
Yep, that apparently fixed it. Curt said: > Make sure you have the latest base package ... I think some default > properties changed. I don't think this should lead to a segfault, but > apparently it does ... > Alex Perry writes: > > ... > > Cannot open file: /usr/local/lib/FlightGear/Scenery/Objects.txt > > Initializing splash screen > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1024 (LWP 1748)] > > fgReshape (width=1024, height=768) at main.cxx:1243 > > 1243 viewmgr->get_current_view()->get_v_fov() ); > > (gdb) bt > > #0 fgReshape (width=1024, height=768) at main.cxx:1243 > > #1 0x4007e245 in __glutRegisterEventParser () from /usr/lib/libglut.so.3 > > #2 0x4007e4ab in glutMainLoop () from /usr/lib/libglut.so.3 > > #3 0x08053854 in mainLoop (argc=1, argv=0xbb54) at main.cxx:1563 > > #4 0x0805404e in main (argc=1, argv=0xbb54) at main.cxx:1622 > > #5 0x4030c6cf in __libc_start_main () from /lib/libc.so.6 > > (gdb) print viewmgr->get_current_view()->get_v_fov() > > Cannot access memory at address 0x0 > > > > ... it's trying to get the parameters for the call to ssgSetFOV() ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
On Wed, 10 Apr 2002 23:43:03 +0200 "Frederic Bouvier" <[EMAIL PROTECTED]> wrote: >With the JSBsim model, I don't see the decrease of AoA at stall. Instead, >the plane keeps it AoA with the stick completely pulled. It does not >swivel around its CG like a real plane ! I'll try and have a look this evening, but Tony's probably the better one to look at this. But, IIRC he's very busy this week. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit transparent to RWY lights
Frederic Bouvier writes: > From: "Curtis L. Olson" <[EMAIL PROTECTED]> > > Frederic Bouvier writes: > > > I don't know how a scene is drawn now but by drawing : > > > > > > 1. the scenery, > > > 2. the lights, > > > 3. the cockpit, > > > 4. the panel. > > > > > > in that order, we should avoid this kind of anomaly. > > > > > > Am I missing something ? > > > > If we draw the outside scenery followed by the 3d model / panel of the > > aircraft we should avoid this problem. > > > Perhaps different far/near clip planes for interior and exterior are fooling > the z-buffer ? That shouldn't matter if the outside scenery is already drawn. A fooled zbuffer would only affect things that were drawn after the time the z-buffer was fooled. 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] Cockpit transparent to RWY lights
From: "Curtis L. Olson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > I don't know how a scene is drawn now but by drawing : > > > > 1. the scenery, > > 2. the lights, > > 3. the cockpit, > > 4. the panel. > > > > in that order, we should avoid this kind of anomaly. > > > > Am I missing something ? > > If we draw the outside scenery followed by the 3d model / panel of the > aircraft we should avoid this problem. > Perhaps different far/near clip planes for interior and exterior are fooling the z-buffer ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
From: "David Megginson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > > The c172 is flyable now but I thing the stall don't reproduce the > > real behaviour. I thing it should dive more frankly. Now it seems > > to stay flat ! > > My changes shouldn't affect the stall, except for any roll component. > I've read that the C172 often stalls very gently, so it might not be > right to expect a screaming dive -- I haven't tried stalls yet on the > real thing. > To stall, I try to keep my altitude while the engine is put idle. So I should see an increase of the AoA while pulling the stick before the stall and then a decrease to a negative number. Now in real life I would release the stick and push the throttle to recover 300ft lower. With the JSBsim model, I don't see the decrease of AoA at stall. Instead, the plane keeps it AoA with the stick completely pulled. It do not swivel aroung its CG like a real plane ! -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cockpit transparent to RWY lights
Frederic Bouvier writes: > I don't know how a scene is drawn now but by drawing : > > 1. the scenery, > 2. the lights, > 3. the cockpit, > 4. the panel. > > in that order, we should avoid this kind of anomaly. > > Am I missing something ? If we draw the outside scenery followed by the 3d model / panel of the aircraft we should avoid this problem. 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] Cockpit transparent to RWY lights
From: "David Megginson" <[EMAIL PROTECTED]> > Frederic Bouvier writes: > > > Do you notice that : with the modified KSFO.btg.gz provided by Curt to > > demonstrate runway light and the 3d cockpit, you can see the light points > > thru the panel ! > > Yes. I also noticed that you cannot see the runway lights through the > translucent propeller disk until you are very close. We can try to > fiddle, but in the end, we may have to accept some z-buffer silliness. > I don't know how a scene is drawn now but by drawing : 1. the scenery, 2. the lights, 3. the cockpit, 4. the panel. in that order, we should avoid this kind of anomaly. Am I missing something ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
Frederic Bouvier writes: > The c172 is flyable now but I thing the stall don't reproduce the > real behaviour. I thing it should dive more frankly. Now it seems > to stay flat ! My changes shouldn't affect the stall, except for any roll component. I've read that the C172 often stalls very gently, so it might not be right to expect a screaming dive -- I haven't tried stalls yet on the real thing. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] stall horn?
David Megginson writes: > Curtis L. Olson writes: > > > Sorry, 'almost' is a figure of speech. My cultural heritage doesn't > > allow me to get too excited about anything. I wouldn't want to make a > > scene and stand out. :-) > > That's why Minnesota elected its current governor, I guess. It's the difference between in theory and in practice I guess ... and maybe the complete lack of a competitive opponent. If politicians were allowed to better leverage their positions for their own personal financial gain, then perhaps better qualified candidates would compete for office. :-) 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] stall horn?
Andy Ross writes: > Curtis L. Olson wrote: > > Jon S Berndt writes: > > > Curtis L. Olson wrote: > > > > I originally did a *very* simplistic model of wheel spin down. This > > > > was for the purpose of audio effect only and had nothing to do with > > > > modeling actual ground behavior. > > > > > > Do you want this? I had intended to do wheel spinup and > > > the effects on the aircraft, but decided nobody cared. > > > > Well we need *something* to make the audio behave right. > > Putting on my lazy FDM author hat... > > Is it really worthwhile to force the FDMs to model wheel spin? This > is going to be really hard to do with any degree of accuracy. The > existing duel-coefficient friction models break down badly at very > high slip speeds when the tires are literally melting. And we'd have > to have a moment of inertia for every wheel; I wouldn't even begin to > know where to look this up. And brake handling would have to be > modified to work in torque space, instead of the simple interpolation > of friction coefficient that happens now. > > Why not just put a simple hysteresis threshold in the audio code > instead? If wheel N has already been on the ground within the past M > seconds, then don't play the sound. To my mind, this gets 95% of the > effect for 20% of the effort. Right, that's what I had originally implimented and what I am proposing we recover and put back into the code. Regards, 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] stall horn?
From: "Jon S Berndt" <[EMAIL PROTECTED]> > "Curtis L. Olson" <[EMAIL PROTECTED]> wrote: > > >BTW, the newly trimmed C172 behaves much better it is almost flyable > >again. :-) > > Almost? What are the remaining caveats? Besides, that is, > no propeller drag at the higher airpseeds and propeller > overspeeds? > The c172 is flyable now but I thing the stall don't reproduce the real behaviour. I thing it should dive more frankly. Now it seems to stay flat ! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Cockpit transparent to RWY lights
Frederic Bouvier writes: > Do you notice that : with the modified KSFO.btg.gz provided by Curt to > demonstrate runway light and the 3d cockpit, you can see the light points > thru the panel ! Yes. I also noticed that you cannot see the runway lights through the translucent propeller disk until you are very close. We can try to fiddle, but in the end, we may have to accept some z-buffer silliness. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cockpit transparent to RWY lights
Do you notice that : with the modified KSFO.btg.gz provided by Curt to demonstrate runway light and the 3d cockpit, you can see the light points thru the panel ! -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My Second Flight
> > Again, thanks everyone, > w00T! Congrats David! g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RGB Texture Editing Tools
Jon wrote: >On Tue, 9 Apr 2002 12:45:47 -0400 > "Paul Deppe" <[EMAIL PROTECTED]> wrote: >>Windoze developers - What tool(s) are you guys using to >>edit .rgb files? > > >IIRC, won't Gimp for Win32 handle those? Yes, it does. >Jon Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] My Second Flight
Thank you to everyone for your followups to my "My First Flight" posting last Saturday. I was very discouraged after my intro flight in a Cessna 150 on Friday, and had pretty much decided not to go any further. The encouragement and advice in the messages (both private and public) pushed me to give it a second try. I won't be posting about every flight, of course, but I thought I'd describe just this one in detail as a reward (or punishment) for everyone who helped. This time I booked CG-PMR, a C172N, for the extra space and stability. We started with a pre-flight briefing where we reviewed basic stuff like the aircraft axes and movements, and I was able to recite most of the equation of lift (thanks, JSBSim guys). We also talked about what we'd be doing in the lesson then looked over the plane's logbook. The previous student had booked a different plane and mine was still in the air, so we waited outside for a few minutes, watching other traffic land and take off. When Papa-Mike-Romeo landed, I did most of the preflight inspection this time -- we needed an extra quart of oil -- then the instructor radioed for clearance and we taxied to an empty area for run-up. We taxied back out to the hold line for runway 22 and watched another plane land, then the instructor radioed tower and we taxied out onto the runway. Takeoff was fairly smooth, though I didn't hold the centreline so well and pulled the nose a little too high at first. We had to use some right aileron during the takeoff roll to counter moderate crosswinds. The C172 climbed nice and steady, but had a tendency to roll left (it showed this tendency through the whole flight, in all attitudes and power conditions including glide). It took a reasonably large amount of aileron pressure to keep level. I took it up to 2,000ft staying more-or-less on course (but with slightly fluctuating airspeed) and used the trim-wheel productively this time. I had no trouble looking around for traffic and kept a relaxed grip on the yoke with my left forefinger and thumb. At Bells Corners, we turned right towards Constance Lake, which is the start of our practice area west of Ottawa (apparently 911 calls about crashing planes are common, since Canada requires spin recovery for the private pilot's license). I had to hold the plane well under 2,500 ft, since that's a different control area and is full of nasty things like big airliners and their wake turbulence -- in the event, it was not that difficult to maintain 2,000 -- after a little initial fluctuation, I kept it within 10 or 20ft. Once in the practice area, the instructor radioed to any other traffic, then I applied full throttle and climbed to 3,000ft to practice maneuvers. So far, I was feeling great -- no serious vertigo and no anxiety -- and I was even letting myself look out the window and enjoy the view. Once in the practice area, we worked on glides, coordinated turns, weaves (I don't know the right word -- the idea is to follow a highway and zigzag without letting the nose show any adverse yaw), and climbs -- the basic maneuvers I'd need for landing. My first airsickness started when the instructor took the controls to demonstrate some of the maneuvers, but it wasn't bad enough to interfere much with the lesson. I did a good job holding heading and altitude (even during turns), but I did chase the airspeed indicator a bit during climbs and descents and tended to trim prematurely afterwards. I scanned for traffic constantly but wasn't great at spotting it. My instructor called out our position periodically, and near the end we were sharing the area with a Katana, which we spotted fairly easily. I was starting to feel a little ill near the end but was still able to enjoy flying to some extent. We left the practice area and I flew the plane back down to 2,000 ft and along the Ottawa River to the Champlain Bridge, right over my house and my girls' school. The instructor called the tower, then we turned right toward's Mooney's Bay on our way back to CYOW. I was still in control during final, and that's when the real excitement started. When we were on short final, not far above the trees, the tower mistakenly cleared a Katana onto the runway ahead of us. The instructor took over the controls and watched closely. By the time the tower realized its mistake, we had already crossed the numbers and the Katana was lifting off the far end of the runway -- the instructor waved off their offer to go around and set us down safely, then I took over to bring the plane onto the taxiway and stop for the post-landing checks. At that point, my stomach was catching up with me from jostling during the descent and landing, and as I ran the checklist I swallowed hard between each item and calculated how long it would take to open the door and lean out. I was a fair bit better in a minute, though, and did the radio work myself to ask ground for permission to taxi back to the flying club. Now, a few hours
Re: [Flightgear-devel] stall horn?
Curtis L. Olson wrote: > David Megginson writes: > >>Curtis L. Olson writes: >> >> > Did we lose the stall horn somewhere along the way? It seems to be >> > missing from the default C172. >> >>As long as we're bitching, I've noticed the slight nosewheel-bouncing >>(during the takeoff run) are producing loud squeals again. >> > > I originally did a *very* simplistic model of wheel spin down. This > was for the purpose of audio effect only and had nothing to do with > modeling actual ground behavior. But it was enough to keep track of > an approximate wheel spin speed so if you the nose was bumping along > up and down, you wouldn't get a skid sound every time it retouched the > ground (unless it was actually airborn long enough to stop spinning > and your ground velocity was fast enough when it retouched down.) > This actually worked pretty good. > > Anyway, this code appears to have been lost (probably when Eric > reworked the audio code?) Eric? For some reason I think it might be a good thing to be able to get FlightGear compiling again, before I can look at this. Anyhow, I didn't make it time depandand, but instead used only the down force to calculate this. And it worked quite well. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] stall horn?
David Megginson writes: > Curtis L. Olson writes: > > > Did we lose the stall horn somewhere along the way? It seems to be > > missing from the default C172. > > As long as we're bitching, I've noticed the slight nosewheel-bouncing > (during the takeoff run) are producing loud squeals again. I originally did a *very* simplistic model of wheel spin down. This was for the purpose of audio effect only and had nothing to do with modeling actual ground behavior. But it was enough to keep track of an approximate wheel spin speed so if you the nose was bumping along up and down, you wouldn't get a skid sound every time it retouched the ground (unless it was actually airborn long enough to stop spinning and your ground velocity was fast enough when it retouched down.) This actually worked pretty good. Anyway, this code appears to have been lost (probably when Eric reworked the audio code?) Eric? BTW, the newly trimmed C172 behaves much better it is almost flyable again. :-) Regards, 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] stall horn?
Curtis L. Olson writes: > Did we lose the stall horn somewhere along the way? It seems to be > missing from the default C172. As long as we're bitching, I've noticed the slight nosewheel-bouncing (during the takeoff run) are producing loud squeals again. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC planes below runway (current CVS)
At 4/10/02, you wrote: >Michael Selig wrote: > > I can ask this differently. What sets the height above the runway of > > the hud-ladder target spot (wrt the 3D model view) --- ie the center > > spot? For c310-yasim and c172-larcsim, it's above the runway. For > > UIUC models, it's below the runway (a recent change). > >Where are you placing the coordinate origin of the aircraft? There >was a confusion/unification about this recently, with the consensus >being that the origin should be, by convention, at the front of the >aircraft (either the nose or the firewall, depending on who you ask). >Strictly, the coordinate origin of the aircraft and the 3D model >should be exactly coincident (or as coincident as practical, given >that there are multiple FDMs and a model file that all have to agree). > >If the UIUC models are reporting an altitude of zero while on the >ground, you'll see this effect. The real altitude should be a few >feet -- however high the nose rests off the ground. > >Andy When I am sitting still at the default airport, I get this: Runway_altitude = -.00053 Altitude = -.39 ft (from ls_generic.h) Here's what it looks like: http://amber.aae.uiuc.edu/~m-selig/tmp/beech.gif The hud diamond (target spot) is below the runway by -.39 ft. To help pinpoint code, we have not changed our uiuc_* code nor LaRCsim wrt altitude/gear. The UIUC models are all below the runway, but the other models going through LaRCsim are not below the runway. As for the aircraft coordinate system, we've never done anything with that wrt viewing. As usual, there's the body axes which is our aero reference point and we can place the cg anywhere we want wrt the body axes origin. >-- >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) > > >___ >Flightgear-devel mailing list >[EMAIL PROTECTED] >http://mail.flightgear.org/mailman/listinfo/flightgear-devel ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim piston engine
> It is gradual. In fact, if you think about it, it has to be. A > propeller that presented the same AoA at every point along the blade > would have to change its degree of twist as the advance ratio changed. I was just wondering whether the twist happened to correspond to the AOA-plus-advance so that large fractions of the blade would stall all in one go ... which would certainly be disconcerting to a governor. > I didn't mean to imply that YASim is actually modelling the airflow > around the propeller; it doesn't. What it does do is try to mimick an > "idealized" propeller torque and efficiency curves (functions of the > advance ratio). These have a "kink" at some point -- they don't > continue to increase as the advance ratio drops to zero, because the > blades reach an AoA of maximum lift. Is the kink blunt, like the one for a main wing with twist in it, or is the kink sharp enough to be really conspicuous ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] UIUC planes below runway (current CVS)
Michael Selig wrote: > I can ask this differently. What sets the height above the runway of > the hud-ladder target spot (wrt the 3D model view) --- ie the center > spot? For c310-yasim and c172-larcsim, it's above the runway. For > UIUC models, it's below the runway (a recent change). Where are you placing the coordinate origin of the aircraft? There was a confusion/unification about this recently, with the consensus being that the origin should be, by convention, at the front of the aircraft (either the nose or the firewall, depending on who you ask). Strictly, the coordinate origin of the aircraft and the 3D model should be exactly coincident (or as coincident as practical, given that there are multiple FDMs and a model file that all have to agree). If the UIUC models are reporting an altitude of zero while on the ground, you'll see this effect. The real altitude should be a few feet -- however high the nose rests off the ground. 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) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim piston engine
Alex Perry wrote: > I've never noticed it, but that doesn't mean it doesn't happen. For > most throttle transients, the combination of prop momentum, throttle > pump and induction system effects will hide the blade stall > transition. Especially true if you have a controllable prop. > > Have you checked whether the blade profile implies that the whole > blade stalls and unstalls at the same time ? It may be gradual. It is gradual. In fact, if you think about it, it has to be. A propeller that presented the same AoA at every point along the blade would have to change its degree of twist as the advance ratio changed. I didn't mean to imply that YASim is actually modelling the airflow around the propeller; it doesn't. What it does do is try to mimick an "idealized" propeller torque and efficiency curves (functions of the advance ratio). These have a "kink" at some point -- they don't continue to increase as the advance ratio drops to zero, because the blades reach an AoA of maximum lift. 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) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault (linux)
Alex, Make sure you have the latest base package ... I think some default properties changed. I don't think this should lead to a segfault, but apparently it does ... Curt. Alex Perry writes: > ... > Cannot open file: /usr/local/lib/FlightGear/Scenery/Objects.txt > Initializing splash screen > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1024 (LWP 1748)] > fgReshape (width=1024, height=768) at main.cxx:1243 > 1243 viewmgr->get_current_view()->get_v_fov() ); > (gdb) bt > #0 fgReshape (width=1024, height=768) at main.cxx:1243 > #1 0x4007e245 in __glutRegisterEventParser () from /usr/lib/libglut.so.3 > #2 0x4007e4ab in glutMainLoop () from /usr/lib/libglut.so.3 > #3 0x08053854 in mainLoop (argc=1, argv=0xbb54) at main.cxx:1563 > #4 0x0805404e in main (argc=1, argv=0xbb54) at main.cxx:1622 > #5 0x4030c6cf in __libc_start_main () from /lib/libc.so.6 > (gdb) print viewmgr->get_current_view()->get_v_fov() > Cannot access memory at address 0x0 > > ... it's trying to get the parameters for the call to ssgSetFOV() > > ___ > 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
[Flightgear-devel] segfault (linux)
... Cannot open file: /usr/local/lib/FlightGear/Scenery/Objects.txt Initializing splash screen Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 1748)] fgReshape (width=1024, height=768) at main.cxx:1243 1243 viewmgr->get_current_view()->get_v_fov() ); (gdb) bt #0 fgReshape (width=1024, height=768) at main.cxx:1243 #1 0x4007e245 in __glutRegisterEventParser () from /usr/lib/libglut.so.3 #2 0x4007e4ab in glutMainLoop () from /usr/lib/libglut.so.3 #3 0x08053854 in mainLoop (argc=1, argv=0xbb54) at main.cxx:1563 #4 0x0805404e in main (argc=1, argv=0xbb54) at main.cxx:1622 #5 0x4030c6cf in __libc_start_main () from /lib/libc.so.6 (gdb) print viewmgr->get_current_view()->get_v_fov() Cannot access memory at address 0x0 ... it's trying to get the parameters for the call to ssgSetFOV() ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FTD
YEah, well knowing Austin, I'm going to avoid any flight piloted by someone trained on his software. I'll live longer that way. g. On Wed, 10 Apr 2002, Cameron Moore wrote: > Looks like X-Plane beat us to the punch, but I'm still impressed. > http://www.x-plane.com/FTD.html > -- > Cameron Moore > :wq > > ___ > 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
[Flightgear-devel] stall horn?
Did we lose the stall horn somewhere along the way? It seems to be missing from the default C172. Regards, 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] FrameRate !!
> but 2.0 is in part a 'rconciliation' of the various 'propriatary' extensions > and the inclusion of things that almost all of the manufacturers have done > to support M$oft DX#. And this driver has more of these upcoming features > then any of the previous ones. So this driver is Nvidia's tool to create facts how the upcoming OpenGL-2.0 standard should look like !? ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
