[Flightgear-devel] FG/Opengc Interface
Hi, A question was asked last week on running FG and OpenGC on the same machine. Well, theone way is to run each app in it's own window and use the loopback address of 127.0.0.1 to communicate via sockets. fgfs .. --opengc=socket,out,24,127.0.0.1,5800,udp ... Depending on how the 2 glutMainLoop(s) share the frames from the video board, performance can be spotty for low-end boards. Running a Geforce2 MX will probably provide about 30fps to share between FG and OpenGC. You can get more fps by reducing the parameters that suck up frames (clouds, vis, anti-aliasing, etc). You will also need to scale the display gauges and theie relative positons in the file ogcAppObject.cpp (Sorry, at some point this will all be files based similar to FG, for now it happens at compile time, but it only takes about a minute).Start the displays first, for some reason starting FG first starves the display app for frames. Shift-1 opens the socket and inits the displays after a short test sequence, Shift-2 makes the connection and starts data reception, Shift-4 starts internal computations and the navigation functions, Shift-5 engages the Flight Mgmt Computer (FMC) which will not work in the stand-alone mode. Keep the focus in the FG window and fly via the keyboard/joystick/yoke Hey, it's a kludge, not a rose garden ;-) Like the commercials say, demonstration by a professional driver under controlled road conditions... do not attempt without proper supervision... void where prohibited by law . your results may vary... and so forth. The OPenGC rendering structure issimilar to the panel code and could be inserted directly into fgfs, but I just haven't had the time or inclination to tackle the problem ATM. question for the FDM jocks. Sort of got my brain around this property stuff and got the info regards flap and gear properities coded into the interface Before sending the files off to Curtis for CVS insertion wanted to consider one additional feature. In earlier pre-releases of 0.7.9 the gear (and flaps?) had extension and retraction delays that modeled the time delays for moving the parts. Glass display functions are dynamic in nature changing shape and color when surfaces/gear are in transition.Before I spend a lot of time looking for something that may not be there or building a gear/flap model that is redundant (and not coupled to the flight dynamics); what modeling is done in the FDMs, are those values available , and the access methods. Por favor. On the 747 YASim model, have not been able to slow to a resonable approach speed 150kts and maintain altitude, run out of elevator authority around 184 kts and flap settings seem to have no effect. The numbers I have in my 747 flight manual don't match up with what I'm seeing in the sim. For example, for 450k lbs, landing speed at full flap/slat setting is 128kts. It won't fly at that speed! Or any of the reference landing speeds for that matter. Realize the model is not intended to be *right-on*, but closer would be nice. (Using the 0.7.9 official release) Regards John W.
[Flightgear-devel] Re: Odd character bug in property manager.
* Martin van Beilen -- Saturday 23 February 2002 02:54: If I type ls -l (reflex :-)) to the property interface, fgfs locks so hard that my voodoo card doesn't get reset to its off state. If I type ls blah (literally) I get an ERR message as required. It seems to happen with all characters that aren't allowed in property names. I'll try to hunt this bug down This isn't a bug, but a feature. :- Well, OK, it =is= a bug, but one in gcc. Simgear's property handler correctly thows an exception for every input failure. But gcc disagrees about which information to let throw put on the stack and which to let catch read from there, so it crashes. Exceptions are simply broken in gcc around version 2.95.2, they don't work across modules. Of course, one could work around that gcc bug for now, but I think it's better to write code for working compilers, rather than to fill up the code with weird workarounds. It was already on my TODO list to catch the exceptions and output proper error messages (ERR ...) in fgfs' telnet handler, as soon as I have a gcc that has the exception bug fixed. On the other hand, these crashes never locked my voodoo card, so you are possibly talking of another problem. (?) m. PS: You get another crash if you type cd .. at root level. This throws the exception Attempt to move past root and leads to the same crash. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: [Flightgear-devel] Problem report on release 0.7.9
Hi, For what it's worth: I made an extended test of several German/Austrian airports after installing the most recent CVS version including Curt's patch. These are the results: Working (no mishap): EDDM LSZR EDDS EDDN LOWI LIBP LSZS LSPM These require scenery packages e000n40 + e010n40. All these work fine. They even include some quite spectacular airports like LSZS, LSPM with considerably tilted runways. On the other hand, the couple CL77 LOWI still does not work by producing a mishap. There must be something special about them. At least I know LOWI situated in a valley does not have a strongly tilted runway. This is even more a pity as LOWI is quite a famous and spectacular approach (I once had a chance to do it in a real simulator :-). Finally: Dave, your textured C172 is highly welcome. While I fortunately did not have to see it from the inside most of the time, I hated that glider. Sincerely, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 20:52, Curtis L. Olson wrote: This may or may not be related but when I start up at an airport for which i have no scenery, the elevation is below 0. At EHAM it is -17 ft as shown in /position/altitude-ft. Actually, when an ocean tile is automatically generated, we use really big triangles (i.e. two triangle to cover the whole tile.) If the elevation is 0 at the corners, the surface of the tile forms a sort of 3d square 'secant' so the elevation within the ocean tile will be 0. -17 sounds reasonable for an interior position. I don't suppose this is relevant (since it was already pointed out that true airport elevation is not used), but EHAM (Amsterdam schipol) really is below sea level; there have been some notable problems with this in FS200X. And seventeen feet sounds plausible (I have seen 11ft to 15ft in different places) It's a feature, not a bug :-) Having said that, I just took off from their (with scenery) no trouble. HH James msg02961/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Problem report on release 0.7.9
On Fri, 2002-02-22 at 11:25, Curtis L. Olson wrote: I believe I have found/fixed the initialization order problem. Flightgear has a concept of an 'absolute' view position in cartesian coordinates where (0,0,0) is the center of the Earth; and a 'relative' view position where (0,0,0) is the center of the current tile. (This is to work around limitations in 'float' precision in OpenGL.) To get back a valid terrain intersection, you need both the absolute and relative view positions to be set correctly. But, you can't set the relative view position until after you know the center point of the current tile. So, in some starting locations by pure chance, we were getting a scenery intersection for a wrong location because the relative view position hadn't been set correctly yet. The next time through the loop the relative view position was correct and the scenery intersection point was the also correct. The problem was that the FDM initialization was handed a wrong starting altitude which could understandably confuse the FDM. I have commited fixes to CVS for this problem. Tony - Even after these fixes though, JSBSim flips upside down and flags a 'mishap'[1] at CL77. There is something about this airport that still confuses the JSBSim initialization code. Perhaps it is the steep slope of the runway? [1] note the careful use of wording to avoid confusing with an application or computer crash. :-) OK, this is what I found at CL77. From the console log, the terrain altitude JSBSim gets at init time is 1924.47 ft: Starting and initializing JSBsim Start common FDM init ...initializing position... FGJSBsim::set_Longitude: -2.13148 FGJSBsim::set_Latitude: 0.646962 cur alt (ft) = 0 FGJSBsim::set_Altitude: 1924.47 lat (deg) = 37.0682 Terrain altitude: 1924.47 ^^^ ...initializing ground elevation to 1924.47ft... ...initializing sea-level radius... lat = 37.0682 alt = 1924.47 ...initializing velocities... FGJSBsim::set_V_calibrated_kts: 0 ...initializing Euler angles... FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.51524 End common FDM init However, putting an output statement just before the ground trim ( in the first call to FGInterface::update() ) is run shows that it has changed: Loading tile /home/tony/FlightGear/Scenery/w130n30/w123n37/942018 token = OBJECT_BASE name = 942018.btg Ready to trim, terrain altitude is: 1928.41 ^^ Ground Trim Initial Theta: 0.9126 Trim successful JSBSim State Trim complete I put in code to update JSBSim's terrain altitude right before the trim and it does improve matters, but not 100% as the final terrain altitude doesn't always seem to be available at that time. As noted yesterday, setting --altitude works around the problem. What seems to be more interesting about that is that JSBSim gets initialized with the final terrain altitude very reliably. Might be a clue to what's really wrong. I didn't look at LOWI, though I suspect the problem there is similar. 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 Cameron Moore writes: * [EMAIL PROTECTED] (Curt Olson) [2002.02.22 12:26]: Jim Wilson writes: Hope they disconnected the usb Flamethrower first :-) I'm getting the same thing with CL77. Some screwy looking airstrip. There still seems to be some problems with altitude between fg and jsbsim. A workaround is to add a --alititude=(runway elevation) to the command line. This perhaps is a naive question, but why aren't we kicking in the FDM after the plane is on the runway during initialization? We are actually doing this. We don't initialize the FDM until the scenery subsystem is reporting a valid ground elevation. However, for some starting locations it appears that the initial reported elevation is incorrect the first frame and then updated to the correct elevation the second frame. This may be totally unrelated, but ... The FPE issue I posted about the other day is triggered when the tile manager is initialized. Could it be that tile manager is getting a bogus starting point due to this FPE bug, and that bogus value is making it's way to the FDM's? -- Cameron Moore / If a person with multiple personalities threatens \ \ suicide, is that considered a hostage situation? / ___ 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 -- Tony Peden [EMAIL PROTECTED] We all know Linux is great
Re: [Flightgear-devel] - Important -
The down side of this is that with the monitoring tools our network admins have, we are most definitely no longer under the radar screen. In fact the network traffic to/from the flightgear server dwarfs the traffic for any other machine here in the department. Oh, I know what you're talking about. Fortunately the machine I'm running the German ftp mirror on has been declared as the 'official' ftp server of our university several months ago (you'll reach the identical contents via ftp.uni-duisburg.de). So I don't have to care about the radar even though I experience heavy traffic since tuesday after release. Maybe you can ask some nice guy who's running the main ftp service of your university to do the 'official' FlightGear ftp site for you ? Maybe there's someone else with lots of bandwidth, willing to set up a virtual server which gets the official 'ftp.flightgear.org' name, running a mirror twice a day ? 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
Re: [Flightgear-devel] - Important -
Curtis L. Olson wrote: If you use flightgear in any academic or research context, please read this message through and please send me a response. (Directly to [EMAIL PROTECTED] is preferred.) -- Request -- I would like to be able to do a better, more definitive job at justifying our existence here. I haven't been specifically asked to do this, but I can see it coming down the pipeline. I sense there might be some pressure to boot us off the net if for no other reason than the network admins don't like their sense of symmetry thrown out of wack by an outlying data point. If flightgear is just a game, then flightgear is no better than some random mp3 server a student set up and (in the eyes of our network admins) we are just wasting bandwidth. Just give them a FlightGear CD for free, and you won't hear them anymore (I know admins, I've been one) ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FGEnvironment [not] vs. WeatherCM
Hi, first I want to say that there's nothing personal in this 'case'. And I don't care too much if it's my code or David's code (or both) that 'survive' at the end. I've written WeatherCM in an attempt to learn the ++ of the C++ and thus it did it's job for me. But what puzzels me is the 'style' in which David added his code. There must be a reason why my code isn't good enough for David (my it be lack of functionality, lack of documetaion, compiler errors, something totally different, none of that, all of that, what ever - the reason doesn't matter). So I'd expect that anybody who's got a 'problem' with some other code ask about it first before going through all the trouble to reimplement it. I can't remember such a mail (perhaps it's been in another thread; due to a very sad event I didn't have time this week) Perhaps we should focus on the technical issues: Looking at the environment code it looks quite similar to mine. That's no surprise as it's doing the same task. Apart from the class interface (FGEnvironment == FGPhysicalProperty), accessing the stored data is also very similar: The rest of FlightGear won't have to know about that -- all it has to know is how to get an environment object: const FGEnvironment * env = globals.get_env_mgr()-getEnv(lat, lon, alt); FGPhysicalProperty wdbpos = WeatherDatabase-get(position); (where position[0] = lat, position[1] = lon, position[2] = alt) And the weather values at the current position are alredy visible through the property system: /environment/weather/wind-north-mps /environment/weather/wind-east-mps /environment/weather/wind-up-mps /environment/weather/temperature-K /environment/weather/air-pressure-Pa /environment/weather/vapor-pressure-Pa /environment/weather/air-density gives you everything you need at the current position of the plane. Through the basepackage/current.txt.gz it's possible to have worldwide current weather settings. As I didn't recieve a message about the limitations that the WeatherCM does have, I don't know the reason for creating a new one. The limitations I know about are quite easy to fix in a very short period of time (anybody who want's to help: here is a opportunity to get a lot of functionality with very little work): - there's no intuitive way to set the weather - write a new FGWeatherParse that reads a intuitive file format (e.g. XML) - Write a PUI menu that allows you to change the weather data during the running program - the FDMs don't react to the weather - Modify them to read the properties that are already there (NB: that's *easy* and the most noticeable change) - the WeatherCM is too complex - It's not. Any weather system that tries to have worldwide coverage with the ability to interpolate between the stations will have that complexity. Conclusion: It doesn't matter if it's FGEnvironment or WeatherCM or both in the end. The GPL will allow us to have the best solution. But as the project is run on our free time we should try to be as efficient as possible. So we should try to work together. If it's not possible to work together (eg. because someone wants to try a totally different approach - YASim vs. JSBsim) it's OK to 'split'. In my humble opinion FGFS would profit much more if David (who's a great coder!) would try to fix the remaining limitations of WeatherCM than to try to invent the wheel the 2nd time. CU, Christian -- 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: AW: [Flightgear-devel] FG/Opengc Interface
Michael Basler wrote: John Wojnaroski wrote: A question was asked last week on running FG and OpenGC on the same machine. Well, the one way is to John, that might have been me ;-) The picture in the Gallery is just fascinating. I tried downloading OpenGC stuff, but http://opengc.sf.net/ seems to be dead (might be temporarily, though). Is the FG related stuff under that same address (I recall it was integrated, right?) or somewhere else? It looks like the .sf.net domain sometimes doesn't work. Try uding opengc.sourceforge.net instead. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
AW: AW: [Flightgear-devel] FG/Opengc Interface
Erik, It looks like the .sf.net domain sometimes doesn't work. Try uding opengc.sourceforge.net instead. ...which does not work either :-( But thanks for the hint, anyway. I'll try again later; it should return sometime. Regards, Michael -- Michael Basler, Jena, Germany [EMAIL PROTECTED] http://www.geocities.com/pmb.geo/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
I tried downloading OpenGC stuff, but http://opengc.sf.net/ seems to be dead (might be temporarily, though). Is the FG related stuff under that same address (I recall it was integrated, right?) or somewhere else? Try http://www.opengc.org. If the problem persists, I can upload a package to the kingmont site. there is a bit of a glitch with the CVS. In the FMC directory the Makefile.am was moved to the atttic, and a new version is being rejected by CVS. You need to have/install the freetype and ftgl/gltt font libraries also. The build process is not as slick as FG's but getting better... Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
Christian Mayer writes: The rest of FlightGear won't have to know about that -- all it has to know is how to get an environment object: const FGEnvironment * env = globals.get_env_mgr()-getEnv(lat, lon, alt); FGPhysicalProperty wdbpos = WeatherDatabase-get(position); (where position[0] = lat, position[1] = lon, position[2] = alt) Christian -- I'm developing my own weather DB in a separate stream (--with-new-environment) partly to give you and others a chance to integrate your code. If you can tie it in to the rest of FlightGear (including the FDMs), I'll happily stop my own work and write off the couple of hours I've spent on it. Here are a couple of suggestions: 1. We now have an FGSubsystem base class declared in Main/fgfs.hxx (this didn't exist when you wrote your code). Your top-level access class, whatever it is, should extend this interface and implement the abstract init(), bind(), unbind(), and update(int) methods. That way, we can move the bindings out of fg_props.cxx, which is a kludge. 2. You should consider storing the top-level pointer to your subsystem in FGGlobals. 3. Concentrate on JSBSim and YASim for the FDM integration at first. LaRCsim is pretty much deadweight now (except for some of the UIUC stuff). I wouldn't worry about GUI stuff for now. 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] Temperature and air pressure
On Fri, 22 Feb 2002 15:29:18 -0800, Andy Ross [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: David Megginson wrote: I've added two new properties tied to the FGEnvironment class (you'll see these only if you compile with --with-new-environment): /environment/temperature-sea-level-degc /environment/pressure-sea-level-inhg I'm sticking with sea-level-equivalent values for now, because I know that the FDM people are pretty possessive of their atmosphere models. Later I might add properties and methods for the values at current altitude as well. Possesive? Heh, I hereby declare that I'd be extraordinarily happy to dump the YASim atmosphere model in favor of a standard one. The reason it's there at all is for the solver -- it's nice to be able to specify a cruise altitude instead of an air temperature and pressure, and there has to be some way to convert altitude to these values. ..for flight in other atmospheres (Mars, Venus, Jupiter, or in fluids like water), which atmosphere model is easier to work from? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) 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
[Flightgear-devel] Here's a worthy web site
http://www.chuckyeager.com/ Jon Chuck Yeager.com.url begin 600 Chuck Yeager.com.url M6T1%1D%53%1=#0I05-%55),/6AT='`Z+R]W=WN8VAU8VMY96%G97(N8V]M M+VEN95X+FAT;6P-@T*6TEN=5R;F5T4VAOG1C=71=#0I54DP]:'1T#HO M+W=W=RYC:'5C:WEE86=EBYC;VTO:6YD97@N:'1M;`T*36]D:69I960]03`T 1-D0V-D)%14)0S$P,3DR#0H= ` end ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower view
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.02.22 18:40]: Is there no longer a tower view option? 0.7.8 could toggle from pilot to chase to tower view, I believe. 0.7.9 does not seem to have this feature. I think you're mistaken. FlightGear has never had a tower view. -- Cameron Moore [ Why is a boxing ring square? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: FG/Opengc Interface
Hi, A question was asked last week on running FG and OpenGC on the same machine. Well, the one way is to run each app in it's own window and use the loopback address of 127.0.0.1 to communicate via sockets. fgfs .. --opengc=socket,out,24,127.0.0.1,5800,udp ... Shift-5 engages the Flight Mgmt Computer (FMC) which will not work in the stand-alone mode. Keep the focus in the FG window and fly via the keyboard/joystick/yoke Point of clarification. the FMC can be enabled if you have a network interface card (NIC) in you machine. You need to set the IP address in ogcFMC.cpp to your card's address. change the define in ogcFMC.cpp from #define SERV_HOST_ADDR 192.168.2.10 to #define SERV_HOST_ADDR your_NIC_address for the machine running fgfs. then the command line becomes fgfs .. --opengc=socket,out,24,127.0.0.1,5800,udp --native-ctrls=socke t,in,24,,5700,tcp The source in the repository is a little behind my local copy, but it should work. Check ogcRenderWindow.cpp for the keyboard callback routine and keyboard commands/functions. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OpenGL/Plib rotation
I'm having a mental block right now, and would appreciate help on a simple question. How do I rotate an object (in raw OpenGL or preferable, plib/ssg) around a point other than the origin? Do I have to transform the object to the origin, rotate it, then transform back again? Thanks, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
David wrote: 3. Concentrate on JSBSim and YASim for the FDM integration at first. I still think sailing planes need a good weather database the most. While JSBSim and YASim may be the best flight models we have generally, AFAIK neither JSBSim nor YASim has a sailing plane (in the works). All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower view
At 2/23/02, you wrote:
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.02.22 18:40]:
Is there no longer a tower view option? 0.7.8 could toggle from
pilot to chase to tower view, I believe. 0.7.9 does not seem to
have this feature.
I think you're mistaken. FlightGear has never had a tower view.
In my 0.7.8 main.cxx I have this snippet of code:
// Tower View
FGViewerLookAt *tower_view =
(FGViewerLookAt *)globals-get_viewmgr()-get_view( 2 );
tower_view-set_view_forward( pilot_view-get_view_pos() );
if (!tower_view_initialized) {
tower_view-set_geod_view_pos( cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Lat_geocentric(),
(cur_fdm_state-get_Altitude()+200)*
SG_FEET_TO_METER );
tower_view-set_sea_level_radius( cur_fdm_state-
get_Sea_level_radius()*
SG_FEET_TO_METER );
tower_view-set_pilot_offset( npo[0], npo[1], npo[2] );
tower_view-set_view_up( wup );
tower_view_initialized = true;
}
... and I can toggle the 'v' key to go from cockpit, to external rear view,
to a tower view (when flying at the default airport) --- works great. Is
this not part of the standard fgfs? I mentioned to Mark that we have this
working in our fgfs 0.7.8. I don't see this same piece of code in 0.7.9,
however.
--
Cameron Moore
[ Why is a boxing ring square? ]
___
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] Temperature and air pressure
..for flight in other atmospheres (Mars, Venus, Jupiter, or in fluids like water), which atmosphere model is easier to work from? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) I started work some time ago on making JSBSim accept a different gravity model. This was specifically for flight over the surface of other planets. The atmosphere, of course, needs to be modeled differently. Right now we model a standard atmosphere within JSBSim, and perhaps soon a variable, weather-aware atmosphere. I would like (someday) to model other atmospheres. I do have a copy of an older Gramm model of the Mars atmosphere in Fortran. JSBSim will likely have (*if* we someday do model other planetary atmospheres) at least a rudimentary standard model for those planets we choose to model. This is not something we (or at least I) am currently spending any thought on, other than that it is something I'd like to do. Of course, the things one needs to keep in mind are the constituent gases, the specific heat ratio will differ from that of earth, etc. I am not sure how this would fit into JSBSim's FGAtmosphere, though. Perhaps as a table read-in? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Feb 22, 2002 at 05:46:11PM -0500, David Megginson wrote: I'd suggest something like this: /environment/cloud-layer[0]/enabled /environment/cloud-layer[0]/type I'll stick to /environment/clouds/layer[n] for now. There's more to clouds than just layers. It can always be changed later. and so on (I'm not sure exactly what sub-properties you'll need), up to a maximum of, say, eight layers. Actually, I was thinking of adding and removing layers dynamically as needed. I extended the props interface so it can create nodes with values of any type. Removal is a bit of a problem though. In the current situation properties are created for life. We could just leave unused nodes, or I could add a delChild() method, or I could add it to the destructor. What do you think? Before too long, FGEnvironment will be able to modify these properties dynamically during the flight, but to start, we'll just have to set the properties manually in the property browser. Indeed. That's the general idea. - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Fri, Feb 22, 2002 at 05:46:11PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/23 20:48:54 fb987c4aba33a35a7765901a555eedf5 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx38i0ACgkQN880WP6HRItobQCZAVI72FD1OW6sF7jKCUw7zY2E NiEAoK3ytkHtCAQHoeecDQOiYQzuwKcT =+Kuy -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Odd character bug in property manager.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 23, 2002 at 10:00:35AM +0100, Melchior FRANZ wrote: Exceptions are simply broken in gcc around version 2.95.2, they don't work across modules. Oh. Cute. Does gcc 3 support this feature as well? Of course, one could work around that gcc bug for now, but I think it's better to write code for working compilers, Yup. Couldn't agree more. On the other hand, these crashes never locked my voodoo card, so you are possibly talking of another problem. (?) Well, you probably don't have a voodoo2 or less. The card simply doesn't get deinitialized properly. Apparently fgfs raises a signal that isn't caught by the driver's handler. Not a big problem as blindly restarting fgfs gives me back my screen. - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Re: Odd character bug in property manager. In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Sat, Feb 23, 2002 at 10:00:35AM +0100 X-S-Issue: [EMAIL PROTECTED] 2002/02/23 18:28:45 180a5618f364e6381b10f68e6c583b5c -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx30VUACgkQN880WP6HRIuE9QCgtTXyEc08PitivHOVCSRrBeIP znYAn2QVnVqDYRvZh/5D+rPxOjbDyNqp =4l3m -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
Jon wrote: There is one in the works for JSBSim, at least Ah - excellent news! Jon Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Re: Odd character bug in property manager.
* Martin van Beilen -- Saturday 23 February 2002 18:30: On Sat, Feb 23, 2002 at 10:00:35AM +0100, Melchior FRANZ wrote: Exceptions are simply broken in gcc around version 2.95.2, they don't work across modules. Oh. Cute. Does gcc 3 support this feature as well? I don't know, but I'm confident that it's fixed now. The bug was already reported in the 2.95.2 times, so it should even be fixed in 2.95.3. The versions prior to gcc3.* are generally poor w.r.t. c++ code generation. They are said to produce huge but slow code, compared to, for example, the Intel compiler. When they were written, not many people used c++ at all. Especially with KDE that has changed and the gcc people are now focusing more on c++. There are rumors, that a brand new version supporting precompiled headers (PCH) compiles KDE 12 times(!) faster than before. Then there is that objprelink stuff, that makes loading shared objects a lot faster. OK, both improvements are pretty irrelevant for fgfs, but still. The most important thing, though, is the generated code that should be perceivably faster. I'm looking forward to gcc3.0.4++ ... :-) On the other hand, these crashes never locked my voodoo card, so you are possibly talking of another problem. (?) Well, you probably don't have a voodoo2 or less. [...] No, a voodoo3, which works reasonably well. OK, it hangs sometimes (not reproducable), but a SysRq-e solves that problem, albeit not quite sensible. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: FG/Opengc Interface
#define SERV_HOST_ADDR your_NIC_address for the machine running fgfs. As I see it, I've to hard code the NIC at build time, right? This might be a pity for people like me sitting on a (home) network with dynamically assigned addresses (DHCP). The address of your loopback interface should always be the same - I think you might use that one, 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
Re: [Flightgear-devel] OpenGL/Plib rotation
David Megginson writes: I'm having a mental block right now, and would appreciate help on a simple question. How do I rotate an object (in raw OpenGL or preferable, plib/ssg) around a point other than the origin? Do I have to transform the object to the origin, rotate it, then transform back again? It's been a while, but as I recall you probably want translate the object to the origin (or have it start out there) do whatever combination of rotations to orient it properly, and then translate it to it's final location. 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] Post 0.7.9 priorities
On Thu, Jan 31, 2002 at 09:51:31PM -0500, David Megginson wrote: Yes, I agree that bug-swatting is also important. We should aim to have 0.8 build clean with -Wall (under G++), and run clean with all Is someone working on the warning cleanups? If not, I'll have a try at it. Petru ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
Martin van Beilen writes: Removal is a bit of a problem though. In the current situation properties are created for life. We could just leave unused nodes, or I could add a delChild() method, or I could add it to the destructor. What do you think? Properties exist for life because any number of different modules might be holding pointers to them. We'll have to figure out some kind of management scheme if we want node removal. 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] OpenGL/Plib rotation
Curtis L. Olson writes: It's been a while, but as I recall you probably want translate the object to the origin (or have it start out there) do whatever combination of rotations to orient it properly, and then translate it to it's final location. Yes, that's what I ended up doing. It seems counter-intuitive, but that's low-level coding for you. 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] Tower view
There seems to be a vestigial reference to TOWER_VIEW in
0.7.9, but as Michael says, the code section that was in
0.7.8 is no longer there. This would be a useful feature
for simulating r/c flight.
Mark
-Original Message-
From: Michael Selig [mailto:[EMAIL PROTECTED]]
Sent: Saturday, February 23, 2002 12:30 PM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel] Tower view
At 2/23/02, you wrote:
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.02.22 18:40]:
Is there no longer a tower view option? 0.7.8 could toggle from
pilot to chase to tower view, I believe. 0.7.9 does not seem to
have this feature.
I think you're mistaken. FlightGear has never had a tower view.
In my 0.7.8 main.cxx I have this snippet of code:
// Tower View
FGViewerLookAt *tower_view =
(FGViewerLookAt *)globals-get_viewmgr()-get_view( 2 );
tower_view-set_view_forward( pilot_view-get_view_pos() );
if (!tower_view_initialized) {
tower_view-set_geod_view_pos(
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Lat_geocentric(),
(cur_fdm_state-get_Altitude()+200)*
SG_FEET_TO_METER );
tower_view-set_sea_level_radius( cur_fdm_state-
get_Sea_level_radius()*
SG_FEET_TO_METER );
tower_view-set_pilot_offset( npo[0], npo[1], npo[2] );
tower_view-set_view_up( wup );
tower_view_initialized = true;
}
... and I can toggle the 'v' key to go from cockpit, to
external rear view,
to a tower view (when flying at the default airport) ---
works great. Is
this not part of the standard fgfs? I mentioned to Mark that
we have this
working in our fgfs 0.7.8. I don't see this same piece of
code in 0.7.9,
however.
--
Cameron Moore
[ Why is a boxing ring square? ]
___
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
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New subsystem: FGEnvironment
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Feb 23, 2002 at 06:16:19PM -0500, David Megginson wrote: Properties exist for life because any number of different modules might be holding pointers to them. We'll have to figure out some kind of management scheme if we want node removal. Well, that's the easy part. We can add a DELETE flag and set it on all dynamic properties. I'm more worried about multithreading. It may be necessary to implement a locking scheme to prevent simultaneous access and deletion of a property. (Only if DELETE is set, of course.) - -- Regards, I RADIS, do you? =Martin=http://www.iradis.org/ PGP: FE87448B DDF8 677C 9244 D119 4FE0 AE3A 37CF 3458 FE87 448B From: Martin van Beilen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] New subsystem: FGEnvironment In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Sat, Feb 23, 2002 at 06:16:19PM -0500 X-S-Issue: [EMAIL PROTECTED] 2002/02/24 01:02:26 8746db0a0cea416c4497d06a7120862e -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) iEYEARECAAYFAjx4LZkACgkQN880WP6HRIuZhgCdFIFCkbgntF27zIl7nWTBQTlB ssEAnR4M9aB11Dgjyl7tnyjvEJAphsEi =YemD -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] FGEnvironment [not] vs. WeatherCM
On Sat, 23 Feb 2002, David Megginson wrote: Christian -- I'm developing my own weather DB in a separate stream (--with-new-environment) partly to give you and others a chance to integrate your code. If you can tie it in to the rest of FlightGear (including the FDMs), I'll happily stop my own work and write off the couple of hours I've spent on it. Here are a couple of suggestions: I think I might be missing something here, so please let me know if I am. Instead of taking what seems a lot like some kind of passive aggressive approach, wouldn't have been a little easier to simply propose a new interface for the environment subsystem? Also, wouldn't it be the FDM author's responsibility to integrate their FDM into FG's other components? Also, if only the three things listed needed to be altered for the existing code to be acceptable, wouldn't it have been easier to make the changes yourself? Like I said, if I'm missing something, I'd really appreciate it if someone would fill me in. Is there a mailing list or website that discusses or describes what components need to be developed or improved and how those components should fit together? I think I'm subbed to all the FG lists and I've read the docs at FlightGear.org, but these don't have what I'm looking for. To someone looking into this project from the outside, changes to the existing code and changes to accommodate external projects seem to be made in an almost arbitrary manner. If there is something that could help define a context in which these changes should be viewed, it might make it easier to attract contributors. Thad ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower view
* [EMAIL PROTECTED] (Michael Selig) [2002.02.23 13:32]:
At 2/23/02, you wrote:
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.02.22 18:40]:
Is there no longer a tower view option? 0.7.8 could toggle from
pilot to chase to tower view, I believe. 0.7.9 does not seem to
have this feature.
I think you're mistaken. FlightGear has never had a tower view.
In my 0.7.8 main.cxx I have this snippet of code:
// Tower View
FGViewerLookAt *tower_view =
(FGViewerLookAt *)globals-get_viewmgr()-get_view( 2 );
tower_view-set_view_forward( pilot_view-get_view_pos() );
if (!tower_view_initialized) {
tower_view-set_geod_view_pos( cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Lat_geocentric(),
(cur_fdm_state-get_Altitude()+200)*
SG_FEET_TO_METER );
tower_view-set_sea_level_radius( cur_fdm_state-
get_Sea_level_radius()*
SG_FEET_TO_METER );
tower_view-set_pilot_offset( npo[0], npo[1], npo[2] );
tower_view-set_view_up( wup );
tower_view_initialized = true;
}
... and I can toggle the 'v' key to go from cockpit, to external rear view,
to a tower view (when flying at the default airport) --- works great. Is
this not part of the standard fgfs? I mentioned to Mark that we have this
working in our fgfs 0.7.8. I don't see this same piece of code in 0.7.9,
however.
Michael,
You had to have put that there yourself because that was never committed
to CVS (I know...I wrote it). It works, but it's a major hack and
shouldn't be in the official FG source (IMHO).
Someone needs to rewrite the viewer code to allow viewpoints to be added
at runtime; then, we can define a tower position for specific airports
and allow you to switch to the nearest tower. And as usual, I don't
have the time (much less the programming prowess) to take on such a
task.
--
Cameron Moore
[ Would a fly without wings be called a walk? ]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Tower view
Boslough, Mark B writes: There seems to be a vestigial reference to TOWER_VIEW in 0.7.9, but as Michael says, the code section that was in 0.7.8 is no longer there. This would be a useful feature for simulating r/c flight. There was never any code to support it; Curt just added it to the enum as a bit of wishful thinking. 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] New subsystem: FGEnvironment
Martin van Beilen writes: Well, that's the easy part. We can add a DELETE flag and set it on all dynamic properties. I'm more worried about multithreading. It may be necessary to implement a locking scheme to prevent simultaneous access and deletion of a property. (Only if DELETE is set, of course.) From my experience with Java, I think the trick with threading is to do all write access from a single thread; otherwise, things get amazingly ugly (personally, I'd prefer doing all read access from that thread as well). 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] Tower view
There seems to be a vestigial reference to TOWER_VIEW in 0.7.9, but as Michael says, the code section that was in 0.7.8 is no longer there. This would be a useful feature for simulating r/c flight. There was never any code to support it; Curt just added it to the enum as a bit of wishful thinking. Perhaps we're approaching this the wrong way. The multiplayer capability provides a multitude of 'actors' in the virtual world, all of which have an FDM and one of which is running on this computer. Why don't we just make the GL rendering occur with respect to an arbitrary 'actor' ... both in terms of FDM and position viewpoint ? That would support tower view, instructor look-over-shoulder and a bunch of other uses. It may also integrate the multiple-monitor code and multiple-player code into a more consistent feature set. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Tower view
At 2/23/02, you wrote:
* [EMAIL PROTECTED] (Michael Selig) [2002.02.23 13:32]:
At 2/23/02, you wrote:
* [EMAIL PROTECTED] (Boslough, Mark B) [2002.02.22 18:40]:
Is there no longer a tower view option? 0.7.8 could toggle from
pilot to chase to tower view, I believe. 0.7.9 does not seem to
have this feature.
I think you're mistaken. FlightGear has never had a tower view.
In my 0.7.8 main.cxx I have this snippet of code:
// Tower View
FGViewerLookAt *tower_view =
(FGViewerLookAt *)globals-get_viewmgr()-get_view( 2 );
tower_view-set_view_forward( pilot_view-get_view_pos() );
if (!tower_view_initialized) {
tower_view-set_geod_view_pos( cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Lat_geocentric(),
(cur_fdm_state-get_Altitude()+200)*
SG_FEET_TO_METER );
tower_view-set_sea_level_radius( cur_fdm_state-
get_Sea_level_radius()*
SG_FEET_TO_METER );
tower_view-set_pilot_offset( npo[0], npo[1], npo[2] );
tower_view-set_view_up( wup );
tower_view_initialized = true;
}
... and I can toggle the 'v' key to go from cockpit, to external rear
view,
to a tower view (when flying at the default airport) --- works great. Is
this not part of the standard fgfs? I mentioned to Mark that we have this
working in our fgfs 0.7.8. I don't see this same piece of code in 0.7.9,
however.
Michael,
You had to have put that there yourself because that was never committed
to CVS (I know...I wrote it). It works, but it's a major hack and
shouldn't be in the official FG source (IMHO).
Someone needs to rewrite the viewer code to allow viewpoints to be added
at runtime; then, we can define a tower position for specific airports
and allow you to switch to the nearest tower. And as usual, I don't
have the time (much less the programming prowess) to take on such a
task.
Hu ... That's interesting. I was under the impression that it was
part of the fgfs CVS. Its apparently a case of the right hand not knowing
what the left hand was doing, i.e. I don't know how we got it.
I don't like hacks, but I will tell you I sure like flying from the tower
view. As you know it works w/ the 'v' key toggling from cockpit, to
external view, to tower view. When I get to the tower I can zoom in w/ 'x'
to get a better view of the aircraft.
Though I am a glider pilot, I also fly R/C models and the tower view suits
me best. A few of the UIUC (Roskam) aircraft models have bad yaw damping
and/or a dutch roll, and with those I get sick flying from the cockpit.
I sure hope something like this tower view gets to be permanent.
--
Cameron Moore
[ Would a fly without wings be called a walk? ]
___
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] Tower view
* [EMAIL PROTECTED] (Michael Selig) [2002.02.23 20:08]: At 2/23/02, you wrote: Michael, You had to have put that there yourself because that was never committed to CVS (I know...I wrote it). It works, but it's a major hack and shouldn't be in the official FG source (IMHO). Someone needs to rewrite the viewer code to allow viewpoints to be added at runtime; then, we can define a tower position for specific airports and allow you to switch to the nearest tower. And as usual, I don't have the time (much less the programming prowess) to take on such a task. Hu ... That's interesting. I was under the impression that it was part of the fgfs CVS. Its apparently a case of the right hand not knowing what the left hand was doing, i.e. I don't know how we got it. I don't like hacks, but I will tell you I sure like flying from the tower view. As you know it works w/ the 'v' key toggling from cockpit, to external view, to tower view. When I get to the tower I can zoom in w/ 'x' to get a better view of the aircraft. There were a couple[1] reasons[2] why I didn't finish this, but I had planned on adding an auto-zoom feature. Manual zooming is annoying. Though I am a glider pilot, I also fly R/C models and the tower view suits me best. A few of the UIUC (Roskam) aircraft models have bad yaw damping and/or a dutch roll, and with those I get sick flying from the cockpit. R/C'ing is the reason I added it in the first place. Now that I have an R/C joystick again (see footnote #1), I may try to work on this viewpoint stuff again if I ever get enough time. I sure hope something like this tower view gets to be permanent. Once someone actually impliments it intelligently, it should be permanent. :-) [1] I had to give back the the transmitter/joystick that comes with the RealFlight R/C simulator that I was borrowing from a family member. I got it back again this weekend. ;-) [2] I accidently deleted my development directory and lost a lot of the code I had written. I wasn't in the mood to do rewrite after that. :-/ -- Cameron Moore [ Curiosity killed the cat, but for a while I was a suspect. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
John Wojnaroski wrote: On the 747 YASim model, have not been able to slow to a resonable approach speed 150kts and maintain altitude, run out of elevator authority around 184 kts and flap settings seem to have no effect. The numbers I have in my 747 flight manual don't match up with what I'm seeing in the sim. For example, for 450k lbs, landing speed at full flap/slat setting is 128kts. It won't fly at that speed! Certainly not, when it's gross weight is 800k lbs. :) The weight you quote is close to the zero-fuel weight, which is typical for landing. By default, YASim will top your tanks off at startup. The plane in this condition will indeed have a very high approach speed. Try setting the /sim/fuel-fraction property to something like 0.2 for a reasonable approach configuration. Your problems with the lack of elevator authority seem real, though. You could try tuning the effectiveness property of the hstab definition, like so: hstab ... effectiveness=2 !-- Give it 2x as much force per surface area -- I'm not sure what the AoA produced by max back-yoke in a 747 is. It looks like the YASim model tops out at around 16 degrees, which is probably not enough. Or any of the reference landing speeds for that matter. Realize the model is not intended to be *right-on*, but closer would be nice. (Using the 0.7.9 official release) Undeniably. Unfortunately, the only way to get it closer is to have people work on and provide feedback for the models. I'll freely admit that I don't spend much time in the 747 model, because big jets don't push my buttons. 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] FG/Opengc Interface
Andy Ross writes: Undeniably. Unfortunately, the only way to get it closer is to have people work on and provide feedback for the models. I'll freely admit that I don't spend much time in the 747 model, because big jets don't push my buttons. Jim Brennan, could probably rattle off 747 performance numbers all day long for you if you want (or at least know where / how to look them up.) I'm sure hey wouldn't mind seeing the 747 model improved. 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] FG/Opengc Interface
On Saturday 23 February 2002 10:24 pm, you wrote: Andy Ross writes: Undeniably. Unfortunately, the only way to get it closer is to have people work on and provide feedback for the models. I'll freely admit that I don't spend much time in the 747 model, because big jets don't push my buttons. Jim Brennan, could probably rattle off 747 performance numbers all day long for you if you want (or at least know where / how to look them up.) I'm sure hey wouldn't mind seeing the 747 model improved. Regards, Curt. There may be stuff already up on ftp.kingmont ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG/Opengc Interface
Andy Ross writes: Undeniably. Unfortunately, the only way to get it closer is to have people work on and provide feedback for the models. I'll freely admit that I don't spend much time in the 747 model, because big jets don't push my buttons. Jim Brennan, could probably rattle off 747 performance numbers all day long for you if you want (or at least know where / how to look them up.) I'm sure hey wouldn't mind seeing the 747 model improved. Jim ran off some performance data for me which I posted a while back , but I did not try to mess with the code hoping the authors would do a much better job of tweaking the params. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
