Re: [Flightgear-devel] Aerial images
Paul Surgeon wrote: When I fired up FlightGear a week ago I noticed that the textures looked very dry and brown to me. I thought San Francisco would be a lot greener and reckoned it was just the guys who created the textures. Neh, I'm not brown. Tonight I was thinking of making some greener looking grass textures for the airports however when I did some searching around USA on Terraserver looking at colour photos (not BW) I saw that USA looks dry everywhere including places like Georgia, Washington DC and Chicago. I've yet to find a nice green photo. Do the aerial photo, surveyor guys pick the dry seasons to do all their work in or is USA really as dry as it appears on Terraserver? It's actually quite understandable. Grass is green in spring. In the other seasons grass is mostly brown or yellow. Only in places like The UK and The Netherlands where there can be quite some rain even during the summer grass _might_ stay green a little longer. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aerial images
Paul Surgeon wrote: When I fired up FlightGear a week ago I noticed that the textures looked very dry and brown to me. I thought San Francisco would be a lot greener and reckoned it was just the guys who created the textures. Tonight I was thinking of making some greener looking grass textures for the airports however when I did some searching around USA on Terraserver looking at colour photos (not BW) I saw that USA looks dry everywhere including places like Georgia, Washington DC and Chicago. I've yet to find a nice green photo. Do the aerial photo, surveyor guys pick the dry seasons to do all their work in or is USA really as dry as it appears on Terraserver? Seems a little odd to me and I'm curious. :) Is it that important at all ? I mean, it's like Erik said: usually the green areas aren't even green most of the time ... so, essentially green imagery wouldn't be suitable for other seasons anymore ... Unless of course one intends to apply some basic color-based filtering: Of course, having colorful imagery in the first place would theoretically enable you to try to approximate the color-changes per season based on the simulator settings, and possibly also country-/region specific profiles - maybe even based on contributing factors such as the relative position of rivers/lakes in the proximity ;-) One would then need to tell FlightGear in what season an image has been created, so that it can generalize spring, summer, fall and winter settings by deriving corresponding changes in color strength, and -density ... sounds a bit like rocket-science, doesn't it ? ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trim quotes
Date: Fri, 22 Oct 2004 22:13:56 +0100 From: Lee Elliott On Thursday 21 October 2004 22:47, Jon S Berndt wrote: Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... Jon It's not grumpy:) Generally, I _do_ tend to [snip..]... but it also depends on what else I might be thinking about, something that happened at work today, what I'm planning to do tomorrow, who was it who said..., I wonder why?..., now what did i just forget to do?... not to mention intoxication states... Serendipitously, I just wrote on this to the User list. If you get the Digest, there is no threading, and you are trying to follow multiple conversations at once. For me, snipping, and reading replies that are interspersed within the message, are a Good Thing (tm). But, hey, I'm only a lurker here; far be it for me to set the terms. Nick ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
David Luff wrote: On 10/22/04 at 5:11 PM Frederic Bouvier wrote: Speaking about feature requests, do you considered using libcurl instead of wget to fetch images ? That would remove those ugly console popup on windows. It's on my TODO list, since wget isn't widely installed on Windows. Patches would of course be accepted :-) I see it's not yet possible to add tower and windsock positions? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
I'm not big on XML (done HTML before) but this: maturityalpha/maturity doesn't seem right. I would expect something more like: modeltag maturity=alpha /modeltag Where modeltag would encompase the whole model definition. Again, I'm not really familiar with just how bloated XML is supposed to be but if this is how you define a property of something it seems more wasteful than I ever thought. An even more complex thing would be to allow: modeltag bunch of stuff... maturity = alpha less developed part of model /maturity /modeltag Again, I'm no authority and I don't even know if this second thing makes sense in this context. Thanks, Paul Boris Koenig wrote: Ampere K. Hardraade wrote: whereas level can be anything between pre-alpha,alpha,pre-beta,beta and done Of course running something like fgfs --min-maturity=alpha --show-aircraft should not return any aircraft right now, as none of the current aircraft definition files in your base-package is using the required maturity/maturity tag - but you can easily give it a try by adding something like maturityalpha/maturity to abitrary aircraft ($FG_ROOT/data/Aircraft/.../*-set.xml) files. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aerial images
Actually, my grass is green all summer, and so are most of my neighbors and most businesses. I'm in Michigan and we have no shortage of water so people like to keep things green. I sometimes tell my wife not to water so much and that it's OK to let it brown a little, but it's still green. Look at the blue marble images from NASA and you'll see that the midwest is much greener than other parts of the US. There are really maybe 2 months when the wild grassy areas really turn brown at all around here. -Paul Erik Hofman wrote: It's actually quite understandable. Grass is green in spring. In the other seasons grass is mostly brown or yellow. Only in places like The UK and The Netherlands where there can be quite some rain even during the summer grass _might_ stay green a little longer. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] [PATCH] classifying development status of aircraft extending fgrun
Paul Kahler wrote: I'm not big on XML (done HTML before) but this: maturityalpha/maturity doesn't seem right. I would expect something more like: modeltag maturity=alpha /modeltag You are right - and wrong, actually it doesn't matter at all, logically you are of course somehat right, personally I would also often use parameters where FlightGear uses separate tags, but on the other hand it's definitely easier the way it is done now, taking into account that an XML file is parsed recursively to be put into FG's global property tree. You'll notice that only very few of FlightGear's XML files really use parameters ... Where modeltag would encompase the whole model definition. Again, I'm not really familiar with just how bloated XML is supposed to be it's not XML's fault - it's just a matter of the exact implementation, look into any of the aircraft XML files, you'll see a lot of stuff that you'd normally expect to be a parameter of a tag rather than a separate tag, personally I did also consider this somewhat confusing in the beginning. but if this is how you define a property of something it seems more wasteful than I ever thought. you can do it either way, XML itself doesn't care whether you store data separately or as a parameter. An even more complex thing would be to allow: modeltag bunch of stuff... maturity = alpha less developed part of model /maturity /modeltag Again, I'm no authority and I don't even know if this second thing makes sense in this context. it's a matter of convenience - and also of habits, I'd say: FG offers the functionality to easily obtain a particular node, because that's exactly what FG is doing all the time, while doing it the other way would seem to make more sense, it would not be conventional in FG terms ;-) But again: this was just meant as a suggestion - in case that it should be accepted to become a temporary solution for FG, I'd recommend to let me refine it anyway - e.g. I was already told that the maturity levels wouldn't be adequate ;-) -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Martin Spott wrote: Jon Stockill wrote: Possibly, although there are a number on that list that definitely aren't closed (yet). I'll cross check some of the info when I get home to see how accurate it is. I appreciate your effort, Hmmm, typical, by the time I get around to looking at this the server has vanished (a traceroute stops at mlra.ucar.edu). Does anyone have a copy of the list? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Jon Stockill wrote: Hmmm, typical, by the time I get around to looking at this the server has vanished (a traceroute stops at mlra.ucar.edu). Does anyone have a copy of the list? ftp://ftp.uni-duisburg.de/FlightGear/Devel/Pre_1973_stations.txt 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Martin Spott wrote: Jon Stockill wrote: Hmmm, typical, by the time I get around to looking at this the server has vanished (a traceroute stops at mlra.ucar.edu). Does anyone have a copy of the list? ftp://ftp.uni-duisburg.de/FlightGear/Devel/Pre_1973_stations.txt Thanks. I've looked these up in a reasonably current (Jan 04) and an older (June 92) En Route Supplement. In the list below Accurate means the lat/lon are within 1 minute of the reference. Unlisted means they don't appear in either edition. Unchecked means the position isn't listed, but the facility contact details are, so it's still active. PRESTWICK SCOTLAND APT Current - Accurate WADDINGTON ENGLAND RAF Current - Accurate CONNINGSBY RAF UK Current - Accurate HOLBEACH ENGLAND GUNNERY RANGE Current - Unchecked MARHAM ENGLAND RAF Current - Accurate WYTON ENGLAND RAF Current - Accurate BASSINGBOURN ENGLAND Unlisted STANTON ENG/SHEPHERDS GROVE RAFUnlisted METFIELD ENGLAND Unlisted HIGHWYCOMBE UK Unlisted WETHERSFIELD ENGLAND RAF STN Tacan only in 1992 LONDON (HEATHROW APT) ENGLAND Current - Accurate WEST MALLING ENGLAND/FARSONUnlisted -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Trim quotes
On Sat, 23 Oct 2004 18:46:38 +1000, Nick wrote in message [EMAIL PROTECTED]: Date: Fri, 22 Oct 2004 22:13:56 +0100 From: Lee Elliott On Thursday 21 October 2004 22:47, Jon S Berndt wrote: Would it be grumpy of me to suggest that we try a little harder to trim quotes when replying with quotes? I've noticed that there are several emails today with 100 to 200 lines of quoted material, followed by anywhere from a few lines to ten or so. Over time, this stuff builds up... Jon It's not grumpy:) Generally, I _do_ tend to [snip..]... but it also depends on what else I might be thinking about, something that happened at work today, what I'm planning to do tomorrow, who was it who said..., I wonder why?..., now what did i just forget to do?... not to mention intoxication states... Serendipitously, I just wrote on this to the User list. If you get the Digest, there is no threading, and you are trying to follow multiple conversations at once. For me, snipping, and reading replies that are interspersed within the message, are a Good Thing (tm). ..and is properly done if you for each of the multiple discussions in the digest, trim off the excess fat contained in the other conversations and add in your response to this one, and send that off and repeat for the next discussion. Here, I see no need to snip, as this message can serve as a summary. ;-) -- ..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 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Submodels
I wrote some time ago: ... snip ... I've gone back to cvs update as of 15 Oct: all the aircraft work correctly. I conclude that this problem is caused by your new code. Unless you can confirm that the instruments work in all models in your location, or tell me exactly what I have to do to correct the situation, I strongly suggest that whatever has been done, be undone. I understand that you are frustrated, but IMHO the ability to configure instrumentation and systems is an improvement. I also think that going back to them being hardcoded is a step in the wrong direction. I agree, it's definitely the right way forward, I'll keep on trying. It's only frustrating because I have been looking at the problem at the individual aircraft level, and I don't think that the problem lies there. It must be a more general problem. And it's going to be a duh!! when I get there. I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. However, it was before I updated. Checking, I find that /sim/systems/path contains 'Aircraft/Generic/generic-systems.xml' (unspecified). Correct, but should this be a string type? A quick cout check in systems_mgr.cxx shows that path_n = 0, so there's the problem. Possibly a problem in simgear/misc/sg_path.hxx? Unlikely, that hasn't been changed in months. So, it's not a duh yet :-). Any advice on what to check next? Can any other Cygwin user confirm my findings, or tell me what they have done differently? Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Can someone give me some debugging tips?
I don't want to be a pain in the @ss but this is getting very frustrating and I need to get this issue resolved. FlightGear still crashes on the joystick code even after I updated my system to a new distro and kernel. If I remove the joystick drivers FG loads without any problems. My Sidewinder joystick used to work with FG so I think something is broken in plib. I get this : ... Initializing button 4 Reading all bindings Reading binding property-assign Reading all bindings Reading binding property-assign terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Aborted I know everyone is busy so can someone tell me how to fix this myself? How do I go about tracking down the offending code? The only debugging I've ever done was with friendly Borland tools. Thanks Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New airport data available
Martin Spott wrote: Now, here comes the next feature request I have a tiny image which represents my favourite airport. I can make JPEG out of it and load it into TaxiDraw. I even can see it in TaxiDraw - but I don't have any clue about the scale of this image. Sorry, no need anymore: After about three years of searching I finally found a satellite image which apparently has exactly on pixel per 5 meter. Man, am I happy !!! Martin. P.S.: French authorities told me severeal times, that photos and maps even of disused military airfields are not available to the public -- 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 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Submodels
On Saturday 23 October 2004 21:14, Vivian Meazza wrote: I've finally found time to revisit this problem. The FGFS is working fine with updates up to 15th Oct. Paths, etc. are good. I've updated and recompiled Simgear and Flightgear. Nothing else has been changed. Should work, right? Wrong: I get the following errors using the default aircraft: Object PanelInstruments not found Object ControlsGroup not found I also get these now and then. No instrumentation model specified for this model! I also get this: General Initialization === == FG_ROOT = /FlightGear-cvs/data Which is correct. The menu bar has also disappeared, so it would seem likely that the correct path is not being found. However, it was before I updated. Checking, I find that /sim/systems/path contains 'Aircraft/Generic/generic-systems.xml' (unspecified). Correct, but should this be a string type? You could try to explicitly specify it as a string type: path type=stringAircraft/Generic/generic-systems.xml/path in preferences.xml. Are you absolutely 100% sure that '/Flightgear-cvs/data/Aircraft/Generic/generic-systems.xml' exists? A quick cout check in systems_mgr.cxx shows that path_n = 0, so there's the problem. Possibly a problem in simgear/misc/sg_path.hxx? Unlikely, that hasn't been changed in months. The autopilot uses the exact same coding technique (that's where I copied and pasted from). And the autopilot does not explicitly set the type to string, so I have little hopes for my tip :-( So, it's not a duh yet :-). Any advice on what to check next? Can any other Cygwin user confirm my findings, or tell me what they have done differently? You could try to insert a cout in xmlauto.cxx, in the init method of FGXMLAutopilot, at least to confirm that path_n != 0 there. Maybe '/sim/systems/path' does not exist in the property tree when instr_mgr is trying to read it. You could try to set this property in the command line, I forget how to, but I'm sure you'll figure it out. Try to step through the code with a debugger. IIRC 'insight' should be available on Cygwin. -- Roy Vegard Ovesen ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New airport data available
Martin Spott wrote: Now, here comes the next feature request I have a tiny image which represents my favourite airport. I can make JPEG out of it and load it into TaxiDraw. I even can see it in TaxiDraw - but I don't have any clue about the scale of this image. Here is a reasonably good reprojection utility that I often use http://www.remotesensing.org/gdal/gdal_utilities.html#gdalwarp google( reprojection ) will yield many others Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aerial images
In the wild, nobody keeps the grass, so you will see more brown rather than green. Ampere On October 23, 2004 01:04 pm, Paul Kahler wrote: Actually, my grass is green all summer, and so are most of my neighbors and most businesses. I'm in Michigan and we have no shortage of water so people like to keep things green. I sometimes tell my wife not to water so much and that it's OK to let it brown a little, but it's still green. Look at the blue marble images from NASA and you'll see that the midwest is much greener than other parts of the US. There are really maybe 2 months when the wild grassy areas really turn brown at all around here. -Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Default airport
What is the elevation of the default runway in FlightGear? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Defaults
In addition, what is the temperature and atmospheric conditions at the default runway? I'd like to run a test with known conditions - i.e. I'd like to use our JSBSim internal atmosphere. I suspect that the atmospheric conditions are getting passed in by default, true? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Default airport
Jon Berndt writes: What is the elevation of the default runway in FlightGear? Depends on the height of the tide :-) following from Airports / basic.dat.gz A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Default airport
OK ... so: essentially sea level. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Norman Vine Sent: Saturday, October 23, 2004 6:08 PM To: FlightGear developers discussions Subject: RE: [Flightgear-devel] Default airport Jon Berndt writes: What is the elevation of the default runway in FlightGear? Depends on the height of the tide :-) following from Airports / basic.dat.gz A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Defaults
Jon Berndt writes:
In addition, what is the temperature and atmospheric conditions at the default
runway? I'd
like to run a test with known conditions - i.e. I'd like to use our JSBSim internal
atmosphere. I suspect that the atmospheric conditions are getting passed in by
default,
true?
FGEnvironment::FGEnvironment()
: elevation_ft(0),
visibility_m(32000),
temperature_sea_level_degc(15),
temperature_degc(15),
dewpoint_sea_level_degc(5), // guess
dewpoint_degc(5),
pressure_sea_level_inhg(29.92),
pressure_inhg(29.92),
turbulence_magnitude_norm(0),
turbulence_rate_hz(1),
wind_from_heading_deg(0),
wind_speed_kt(0),
wind_from_north_fps(0),
wind_from_east_fps(0),
wind_from_down_fps(0)
{
_setup_tables();
_recalc_density();
}
but you should really just use the property browser
as these are exposed under the environment
void
FGEnvironment::read (const SGPropertyNode * node)
{
maybe_copy_value(this, node, visibility-m,
FGEnvironment::set_visibility_m);
if (!maybe_copy_value(this, node, temperature-sea-level-degc,
FGEnvironment::set_temperature_sea_level_degc))
maybe_copy_value(this, node, temperature-degc,
FGEnvironment::set_temperature_degc);
if (!maybe_copy_value(this, node, dewpoint-sea-level-degc,
FGEnvironment::set_dewpoint_sea_level_degc))
maybe_copy_value(this, node, dewpoint-degc,
FGEnvironment::set_dewpoint_degc);
if (!maybe_copy_value(this, node, pressure-sea-level-inhg,
FGEnvironment::set_pressure_sea_level_inhg))
maybe_copy_value(this, node, pressure-inhg,
FGEnvironment::set_pressure_inhg);
maybe_copy_value(this, node, wind-from-heading-deg,
FGEnvironment::set_wind_from_heading_deg);
maybe_copy_value(this, node, wind-speed-kt,
FGEnvironment::set_wind_speed_kt);
maybe_copy_value(this, node, elevation-ft,
FGEnvironment::set_elevation_ft);
maybe_copy_value(this, node, turbulence/magnitude-norm,
FGEnvironment::set_turbulence_magnitude_norm);
maybe_copy_value(this, node, turbulence/rate-hz,
FGEnvironment::set_turbulence_rate_hz);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Defaults
I'm trying to find a way to force the JSBSim atmosphere to be used. I'm still not quite
sure how to do that (is a property set somewhere in a -set file?).
Jon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Norman Vine
Sent: Saturday, October 23, 2004 6:29 PM
To: FlightGear developers discussions
Subject: RE: [Flightgear-devel] Defaults
Jon Berndt writes:
In addition, what is the temperature and atmospheric conditions at the
default runway? I'd
like to run a test with known conditions - i.e. I'd like to use our JSBSim internal
atmosphere. I suspect that the atmospheric conditions are getting passed in
by default,
true?
FGEnvironment::FGEnvironment()
: elevation_ft(0),
visibility_m(32000),
temperature_sea_level_degc(15),
temperature_degc(15),
dewpoint_sea_level_degc(5), // guess
dewpoint_degc(5),
pressure_sea_level_inhg(29.92),
pressure_inhg(29.92),
turbulence_magnitude_norm(0),
turbulence_rate_hz(1),
wind_from_heading_deg(0),
wind_speed_kt(0),
wind_from_north_fps(0),
wind_from_east_fps(0),
wind_from_down_fps(0)
{
_setup_tables();
_recalc_density();
}
but you should really just use the property browser
as these are exposed under the environment
void
FGEnvironment::read (const SGPropertyNode * node)
{
maybe_copy_value(this, node, visibility-m,
FGEnvironment::set_visibility_m);
if (!maybe_copy_value(this, node, temperature-sea-level-degc,
FGEnvironment::set_temperature_sea_level_degc))
maybe_copy_value(this, node, temperature-degc,
FGEnvironment::set_temperature_degc);
if (!maybe_copy_value(this, node, dewpoint-sea-level-degc,
FGEnvironment::set_dewpoint_sea_level_degc))
maybe_copy_value(this, node, dewpoint-degc,
FGEnvironment::set_dewpoint_degc);
if (!maybe_copy_value(this, node, pressure-sea-level-inhg,
FGEnvironment::set_pressure_sea_level_inhg))
maybe_copy_value(this, node, pressure-inhg,
FGEnvironment::set_pressure_inhg);
maybe_copy_value(this, node, wind-from-heading-deg,
FGEnvironment::set_wind_from_heading_deg);
maybe_copy_value(this, node, wind-speed-kt,
FGEnvironment::set_wind_speed_kt);
maybe_copy_value(this, node, elevation-ft,
FGEnvironment::set_elevation_ft);
maybe_copy_value(this, node, turbulence/magnitude-norm,
FGEnvironment::set_turbulence_magnitude_norm);
maybe_copy_value(this, node, turbulence/rate-hz,
FGEnvironment::set_turbulence_rate_hz);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
