Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Curtis L. Olson writes: Christian Mayer writes: In my case it effects - simgear/sg_zlib.h, and 2 other headers - no problem. I usually 'fix' them locally and get on with the compile ... What is the issue here? I think that there might be some confusion about whether zlib is still part of SimGear or not. 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] msvc6-win32-0.7.9 (minus)
Andy Ross writes: Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) The first thing I'd do is make sure that the throttle is set up correctly, but looking at the property browser and ensuring that it's at 1.0. 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] Open Source Nvidia Driver
Sergio wrote: I mean Netscape project was reduced 300% of its souce code after becoming a open source an Mozila starts. So before that we coul'd also think they were doing the best. Wouldn't it be some presumptious they are really doing the best. I don't understand why the don't open all especifications so the open source community coul'd maybe improving the code. After all they just developing the architecture. The boards are made by manufacteres. 3D Accelerators get sold due to their performance. So the benchmarks are nearly the only argument for selling a card (cf. how poorly Matrox performes in that sector; they can only sell to bussines people not to the mainstream). So the most important marketing fact are good benchmark results (under Windos). Thus the drivers get very much attention. NVidia cards have nearly (i.e. +/-) the same performance under Linux as they've got under Windos. So we can assume that the Linux drivers are getting the optimum performance. No need for OpenSource in this case. To the point that nVidia might drop OpenGL support: I *really* doubt that. nVidia doesn't only produce the mainstream chips, they also produce the Quadro workstation chips (which are basically the same; just take your soldering iron and change one resistor...). DirectX doesn't count a bit on workstations. Oh, and they are actively contributing to the devolpment of the OpenGL spec. No need for OpenSource in this case. I hope you get an ATi card. So that keeps nVidia from getting a monoply and thuse the prices down, so that I can afford my next nVidia based card ;) CU, Christian PS: That discussion is actually extremely offtopic. -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Disused Airfields and an Intro
Alex Perry writes: Disused airfields are fairly common in the UK, can I suggest the ability to handle these is something add to the 'to do' list? Basically, we just need to support closed (X) runways, then make airports where all the runways are closed. CYOW, my home airport, has one closed runway itself. Yeah, then there is the little instructor trick of changing a runway from open to closed in the database while the student is enroute and looking to see whether the student doesn't notice and lands on it anyway. Hmm -- that gets me thinking (again) about the idea of generating airports dynamically at runtime rather than statically at scenery-build time. 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] Re: Open Source Nvidia Driver
Melchior FRANZ wrote: * Martin Olveyra -- Friday 25 January 2002 04:08: The specifications of nvidia drivers are not available for public so it is not posible to do that, but Nvidia distributes its own driver freely and works very fine. Why can be somebody interested on an open source nvidia driver under such conditions? Because SGI recently sold a couple of 3D-graphics patents to Microsoft and Microsoft could be interested not to license these to companies that support anything else than DirectX. So Nvidia could drop OpenGL support for their cards in the next years and you can throw your card into the bucket ... given that you want to upgrade your Linux kernel some day. Neh, most of the hardware designers of Nvidia come from SGI ... No worry about that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] [OT] Re: Open Source Nvidia Driver
* Erik Hofman -- Friday 25 January 2002 15:50: Melchior FRANZ wrote: Because SGI recently sold a couple of 3D-graphics patents to Microsoft and Microsoft could be interested not to license these to companies that support anything else than DirectX. So Nvidia could drop OpenGL support for their cards in the next years and you can throw your card into the bucket ... given that you want to upgrade your Linux kernel some day. Neh, most of the hardware designers of Nvidia come from SGI ... No worry about that. ... which doesn't buy them anything, if MS owns important patents and wants to push DirectX and hurt other OSes. And don't tell me that they wouldn't! Neiter Nvidia nor SGI is in control then, and certainly not the owner of a Nvidia card. I am not paranoid and I don't think that my scenario will become reality soon, if at all. I just wanted to explain why it =does= make sense to prefer open solutions over closed ones. As long as you don't get the specs you are not really owner of your graphics cards. You depend on the good will of your 'master'. Nvidia decides what you can do with the product that you paid for. It's like if your only rented it. No problem for Windows users, of course. They are used to it and don't deserve better. But there's a better world out there. :- m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DME FYI
In case anybody has been wondering where the DME display has gone on the C172 According to David M, DME on a C172 is a rarity. The C182 has it. The old vfr and ifr panels are still there, just not as the default. TTYL John ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Re: Open Source Nvidia Driver
Melchior FRANZ writes: ... which doesn't buy them anything, if MS owns important patents and wants to push DirectX and hurt other OSes. And don't tell me that they wouldn't! Neiter Nvidia nor SGI is in control then, and certainly not the owner of a Nvidia card. I am not paranoid and I don't think that my scenario will become reality soon, if at all. I just wanted to explain why it =does= make sense to prefer open solutions over closed ones. As long as you don't get the specs you are not really owner of your graphics cards. You depend on the good will of your 'master'. Nvidia decides what you can do with the product that you paid for. It's like if your only rented it. No problem for Windows users, of course. They are used to it and don't deserve better. But there's a better world out there. :- I think the only thing that would change nVidia's approach right now would be if ATI (or someother 3d card vender) started kicking nVidia's butts and if open-source opengl drivers were perceived to be a contributing factor. Otherwise I think nvidia will be quite happy to continue doing things how they are doing them now. Certainly I agree that open source solutions are preferable to closed source solutions, and it is good to lobby and pressure companies for open-source. But at the same time, a company has a right to make money, and has a right to decide the best way to do that (within the limits set by law.) And since the product nvidia is putting out is pretty much the best quality, most stable, fastest thing available, and 'reasonably' priced for consumer PC's, it's hard to be too critical of them. But if nvidia ends up being a monopoly, they will have less motivation to maintain quality, stability, performance, and reasonable prices, and for all the reasons mentioned in previous messages, it is still good to be cautious about closed solutions and push towards more openness in the future. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] DME FYI
John Check writes: In case anybody has been wondering where the DME display has gone on the C172 According to David M, DME on a C172 is a rarity. The C182 has it. More specifically, the DME is not on a stock C172R panel (nor is the MP gauge, which is also gone). We stuck the DME on the C172 panel originally because the C172 was the only plane we had. The old vfr and ifr panels are still there, just not as the default. There's also a half-finished, experimental C172 panel you can try with fgfs --prop:/sim/panel/path=Aircraft/c172/Panels/c172r-panel.xml This panel doesn't change the viewport size, so you'll have to hit Ctrl-O ten or fifteen times to look down at the runway (Ctrl-P to look back up). Some instruments are still missing, but the layout is based very closely on a photo of a C172R panel. 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] DME FYI
On Friday 25 January 2002 11:40 am, you wrote: John Check writes: In case anybody has been wondering where the DME display has gone on the C172 According to David M, DME on a C172 is a rarity. The C182 has it. More specifically, the DME is not on a stock C172R panel (nor is the MP gauge, which is also gone). We stuck the DME on the C172 panel originally because the C172 was the only plane we had. True. I do recall MP on pix of the 172R(G?) Alex flies. That reminds me.. Does cylinder head temp work under JSBsim? I know LaRCsim has it. Do any of the current planes have it? The old vfr and ifr panels are still there, just not as the default. There's also a half-finished, experimental C172 panel you can try with fgfs --prop:/sim/panel/path=Aircraft/c172/Panels/c172r-panel.xml This panel doesn't change the viewport size, so you'll have to hit Ctrl-O ten or fifteen times to look down at the runway (Ctrl-P to look back up). Some instruments are still missing, but the layout is based very closely on a photo of a C172R panel. All the best, David Y'know I really like the way that background looks, but I wonder why you didn't make it full width. TTYL J ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
John Check writes: Y'know I really like the way that background looks, but I wonder why you didn't make it full width. I did. Use Shift-F7 and Shift-F8 to scroll sideways, Shift-F5 and Shift-F6 to scroll down and up. 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] Disused Airfields and an Intro
Alex Perry writes: Disused airfields are fairly common in the UK, can I suggest the ability to handle these is something add to the 'to do' list? Basically, we just need to support closed (X) runways, then make airports where all the runways are closed. CYOW, my home airport, has one closed runway itself. Yeah, then there is the little instructor trick of changing a runway from open to closed in the database while the student is enroute and looking to see whether the student doesn't notice and lands on it anyway. Hmm -- that gets me thinking (again) about the idea of generating airports dynamically at runtime rather than statically at scenery-build time. Nah; when we do the support for forest fires and other parametric drop-ins where the object is allowed to _replace_ triangles from the scenery file, substitution of the runway numbers will be easy to implement. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
From my research on the Web, the C172R default panel configuration (and the typical C172R for sale on the Web) comes with a simple GPS (not yet modelled), two NAVCOMM radios, ADF, transponder, and autopilot (no altitude control). There are two VOR gauges, one of which has a glidescope, and one ADF gauge. There are OMI marker lights, but no DME. Bear in mind that the panel and engine model change for fuel injection! It's a reasonable combination. Check whether the GPS is IFR approved; if it isn't you (a) cannot do approaches with it and must file /U and (b) it needs to be able to drop offline occasionally due to lack of RAIM. I think we'll have a bunch of existing simulator pilots being a bit surprised how hard navigation is, when you omit DME and have no moving map... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 Ok
It's in FG CVS now. fix it forever ... death to QNAN = bliss :-)) JSBSim - ok, got the new FGInitialCondition.cpp with vers 1.33 2002:01:24 ... I certainly 'like' the few added protective if( vt 0.01 ) return 0; Let's see if that helps ... Also some other small updates - httpd.cxx, light.cxx, options.cxx, etc. Just a small list today ... Must look again how to 'fix' options.cxx instead of adding - char * envp = D:\\FGFS\\FlightGear\\Scenery; Something was said about 'setting' props??? But for now will try the default FDM using only the cvs fgfsbase scenery files ... small sub-set. And i remember to 'comment out' my system.fgfsrc - ie add # to beginning of each line. It WORKED! Great stuff ... with patients it only took 3 mouse clicks to get mags both on - Shift-1, then space bar kicked the motor into life ... Ok, now where's the parking break so I can run the motor up, and test left and right mag drops? Nah! I'll do that next time ... anyway the chief has just brought it back from a check-out so think the motor's ok today (i says to myself) ... Push the throttle open (=back slider on my MS SideWider js) and watching the IAS rise is always a great feeling ... A little difficult to correct the left swing when zillions of HDD io events are also happening ... But get the nose up, IAS holding, we're FLYING ... Great stuff. Tried a simple 1,000 ft circuit, like KSFO was my own small private field ... As always the tiling and scenery means you have to sort of 'freeze input' for several seconds now and again ... But this is not the FDM's fault alone ... Well noted the new log output is (many of) ... f3-f1= 1701.6777 f3-f1= 1701.6777 f3-f1= 1701.9759 Now that we've seen this maybe it can be turned OFF :-)) Do not quite 'understand' the stream after - f3-f1= 1701.8808 Trim successful JSBSim State Trim complete 0: GEAR_CONTACT 1 1: GEAR_CONTACT 1 ... on and on and on ... Actually I was never able to STOP the FDM. Maybe if I shut the engine off? But the brake seemed not to work ... right to the very end of the session I got ... Program exit requested. 123: GEAR_CONTACT 1 124: GEAR_CONTACT 0 Updating light parameters. Sun angle = 56.4362 ambient = 0.252872 diffuse = 0.996426 sky = 0.991851 125: GEAR_CONTACT 1 126: GEAR_CONTACT 0 Program exiting normally at user request. Sort of bumping forward over the ground ... but this is MINOR compared to the QNAN which seems to have died ... thank's again, and phew ... a gremlin bites the dust ... Many thanks for keeping on with this ... Rgds, Geoff. PS: Time is running, but will try YASim over the next few days again. Maybe if it is the 'first' fdm to run after the system boot ... and back to magic ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
Alex Perry writes: I think we'll have a bunch of existing simulator pilots being a bit surprised how hard navigation is, when you omit DME and have no moving map... One interesting suggestion you (Alex) gave to me about a year ago was to hide the panel and the HUD, then try to make a complete flight from one airport to another (preferably airports I'd never been to before) following only a VFR map. In some ways, it was harder than it would be for a real pilot, since I didn't have the peripheral vision or the motion cues (I cannot feel when I'm in a slip, for example, or when I'm descending rapidly, and I cannot feel any force feedback from the controls). 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] msvc6-win32-0.7.9 Ok
Geoff McLane writes: Must look again how to 'fix' options.cxx instead of adding - char * envp = D:\\FGFS\\FlightGear\\Scenery; Something was said about 'setting' props??? There is a command line option you can specify at run time, or put in your system.fgfsrc file. Curt. -- Curtis Olson Intelligent Vehicles Lab 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] DME FYI
In some ways, it was harder than it would be for a real pilot, since I didn't have the peripheral vision or the motion cues (I cannot feel when I'm in a slip, for example, or when I'm descending rapidly, and I cannot feel any force feedback from the controls). Don't be too sure; once you're in cross country cruise, you're trimmed and flying using tiny control inputs to maneuver very gradually. Can't feel it. When you're going mostly in a straight line, there is no point using faster turns than quarter standard rate and climbs/descents beyond 200fpm or so. After all, you're following a road lane and could shortcut corners any time. This isn't true for IFR, of course, or when in terrain or near the ground. The most realistic way to do that with a simulator is to use the keyboard, since an 8-bit joystick travel is _much_ too coarse for that kind of thing. However, remember to change the property settings to give you fine control. I find the artificial square cutout of the monitor provides similar attitude cues to the peripheral vision in an aircraft and don't miss it at height. So, I (personally) suggest that taking advantage of the monitor edge is 'ok'. Your body adapts to the forces of a slip and stops considering it something unusual that needs to be corrected, so the seat-in-butt sensation cannot be trusted (one of the things you have to learn for instrument flight). Instead, you are taught to look left and right at your wingtips and compare their position to the horizon to determine whether the aircraft is truly wingslevel. That's something you can still do with FGFS, with a lot less neck-ache too. Also, most aircraft make a noise when seriously uncoordinated (FGFS does not). Ascent/Descent and course (not heading) are things you detect visually by watching how the scenery flows towards and past you. A framerate of 20 or higher is needed to get the effect right, unless you've had real-life practice. The biggest problem I have is that our textures are too homogeneous to judge speed well enough to control height. I don't know what we can do about that. I end up having to you the 'other' way, comparing my height to hills and such. Try those elements and let me know what your next difficulty is ... 8-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
Alex Perry writes: Bear in mind that the panel and engine model change for fuel injection! We never properly modeled a gravity-fed carburator in the first place, so I guess we've always had fuel injection. It would be neat to model an O360 (say), and have the engine splutter whenever there's too much upwards force. We haven't got around to fuel pumps and the like. It's a reasonable combination. Check whether the GPS is IFR approved; if it isn't you (a) cannot do approaches with it and must file /U and (b) it needs to be able to drop offline occasionally due to lack of RAIM. I've seen ads referring to the KLN-89, KLN-90, and similar. I don't think they're approved for approaches. 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] DME FYI
Alex Perry writes: Also, most aircraft make a noise when seriously uncoordinated (FGFS does not). We can, though -- what kind of a noise should it be? The biggest problem I have is that our textures are too homogeneous to judge speed well enough to control height. I don't know what we can do about that. Automatic object placement will help somewhat -- we can add transmission towers, utility poles, etc. based on available data, the same way that Curt added night lights. We could also add a few random buildings, etc. 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] DC3 3D Model
Jim Wilson wrote, Check this out: http://aviation.sosu.edu/aircraft/c310.html and these http://aviation.sosu.edu/aircraft/aircraft.html Cool! Thanks Jeff ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
At 05:39 PM 1/25/2002 -0500, you wrote: Alex Perry writes: Also, most aircraft make a noise when seriously uncoordinated (FGFS does not). We can, though -- what kind of a noise should it be? Kind of a fluttering noise; lots of burbling. Hey, how about dual air jets to blow air on one cheek in an open cockpit...;-) rj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Re: Open Source Nvidia Driver
Open source software may also be tested, legally, also to airworthiness standards. And, by the FAA too. ..which leaves closed source software behind as, _un-certifiable_. That's true for various categories of avionics, which have coverage tests, but not for inspection and training tools, which only have functional test. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6-win32-0.7.9 (minus)
Andy Ross [EMAIL PROTECTED] said: Geoff McLane wrote: JSBSim stops after the QNAN's, and now YASim c172 seems unable to get speed to lift off ... Just one of those days ... Odd. Jim Wilson also reported a not enough power situation (with the YASim 747) that I couldn't reproduce. I didn't think to ask about platform. Does anyone using MSVC have correct power behavior with the YASim planes? Does anyone see such a problem using non-MS builds? This kind of platform bug gets really scary. :) Andy Andy, I'm running linux. My apologies for not having read the whole thread yet...if this has been alrady been discussed further. The 747 seems to have about the right power for take off. But it seems as though the thrust decreases disproportionately as altitude increases to the point that I can't get above the mid teens for altitude from a near sea level takeoff. I upped the thrust to 63000lb per engine (PW spec) and that helped get it a few thousand feet more. I'll have to try again but I think the c172 seemed a little underpowered here as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DME FYI
We can, though -- what kind of a noise should it be? Kind of a fluttering noise; lots of burbling. In high engine power conditions for prop planes, there is another sound that is due to the prop disk loading being asymmetric when uncoordinated. The other reason for prop asymmetry is due to angle of attack, of course. You also get the sound cue for vertical and horizontal gusts, which is useful when flying in turbulence. For a simulator, the sound cue is especially important (for turbulence) because we don't have motion cue. The additional sound is similar to the normal engine, shifted down one octave. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
