You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(1) 
_{May}
(612) 
_{Jun}
(916) 
_{Jul}
(1079) 
_{Aug}
(536) 
_{Sep}
(476) 
_{Oct}
(354) 
_{Nov}

_{Dec}


2005 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}
(143) 
2006 
_{Jan}
(828) 
_{Feb}
(774) 
_{Mar}
(1114) 
_{Apr}
(795) 
_{May}
(566) 
_{Jun}
(857) 
_{Jul}
(336) 
_{Aug}
(412) 
_{Sep}
(213) 
_{Oct}
(385) 
_{Nov}
(1065) 
_{Dec}
(514) 
2007 
_{Jan}
(864) 
_{Feb}
(501) 
_{Mar}
(346) 
_{Apr}
(357) 
_{May}
(720) 
_{Jun}
(598) 
_{Jul}
(714) 
_{Aug}
(275) 
_{Sep}
(366) 
_{Oct}
(428) 
_{Nov}
(674) 
_{Dec}
(1197) 
2008 
_{Jan}
(582) 
_{Feb}
(357) 
_{Mar}
(456) 
_{Apr}
(314) 
_{May}
(150) 
_{Jun}
(188) 
_{Jul}
(205) 
_{Aug}
(440) 
_{Sep}
(349) 
_{Oct}
(705) 
_{Nov}
(643) 
_{Dec}
(781) 
2009 
_{Jan}
(684) 
_{Feb}
(456) 
_{Mar}
(450) 
_{Apr}
(371) 
_{May}
(294) 
_{Jun}
(319) 
_{Jul}
(199) 
_{Aug}
(349) 
_{Sep}
(570) 
_{Oct}
(720) 
_{Nov}
(547) 
_{Dec}
(481) 
2010 
_{Jan}
(535) 
_{Feb}
(680) 
_{Mar}
(666) 
_{Apr}
(345) 
_{May}
(269) 
_{Jun}
(216) 
_{Jul}
(241) 
_{Aug}
(195) 
_{Sep}
(240) 
_{Oct}
(350) 
_{Nov}
(498) 
_{Dec}
(452) 
2011 
_{Jan}
(550) 
_{Feb}
(577) 
_{Mar}
(439) 
_{Apr}
(495) 
_{May}
(343) 
_{Jun}
(473) 
_{Jul}
(287) 
_{Aug}
(337) 
_{Sep}
(481) 
_{Oct}
(495) 
_{Nov}
(409) 
_{Dec}
(500) 
2012 
_{Jan}
(335) 
_{Feb}
(490) 
_{Mar}
(382) 
_{Apr}
(464) 
_{May}
(234) 
_{Jun}
(255) 
_{Jul}
(226) 
_{Aug}
(266) 
_{Sep}
(213) 
_{Oct}
(201) 
_{Nov}
(268) 
_{Dec}
(186) 
2013 
_{Jan}
(196) 
_{Feb}
(363) 
_{Mar}
(164) 
_{Apr}
(222) 
_{May}
(146) 
_{Jun}
(256) 
_{Jul}
(126) 
_{Aug}
(150) 
_{Sep}
(196) 
_{Oct}
(201) 
_{Nov}
(270) 
_{Dec}
(196) 
2014 
_{Jan}
(232) 
_{Feb}
(282) 
_{Mar}
(234) 
_{Apr}
(189) 
_{May}
(262) 
_{Jun}
(132) 
_{Jul}
(44) 
_{Aug}
(157) 
_{Sep}
(192) 
_{Oct}
(164) 
_{Nov}
(252) 
_{Dec}
(71) 
2015 
_{Jan}
(147) 
_{Feb}
(369) 
_{Mar}
(641) 
_{Apr}
(443) 
_{May}
(210) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 




1
(6) 
2
(3) 
3
(2) 
4
(2) 
5
(40) 
6
(17) 
7
(5) 
8
(4) 
9
(8) 
10

11
(5) 
12
(15) 
13
(20) 
14
(10) 
15
(5) 
16
(5) 
17
(8) 
18
(11) 
19
(22) 
20
(4) 
21
(3) 
22
(13) 
23
(6) 
24
(1) 
25
(8) 
26
(3) 
27
(11) 
28
(2) 
29
(1) 
30



From: Jon S. Berndt <jonsberndt@co...>  20100905 04:17:28

> On Sat, 4 Sep 2010, Jon S. Berndt wrote: > > > Which directory should one be under when they execute the git > command? > > Hi, > > You should be in the directory where you want to have the fgdata > directory, i.e. git creates fgdata in the current directory. > Cloning will download about 2.5GB of data so it will take a good while. > If gitorious is slow you can also clone from > http://mapserver.flightgear.org/git/fgdata > > > Is there anything that needs to be done afterwards when the data is > all > > downloaded, or is FlightGear ready to run at that point? > > FlightGear should be ready to run at that point. Use the > fgroot=/path/to/fgdata > argument to point FlightGear to the fgdata directory  it probably > won't > find it otherwise. > > Cheers, > > Anders Here's how I ran FlightGear, but it did not like the command: $ FlightGear/projects/VC90/Win32/Release/fgfs fgroot=/home/jon/flightgear/fgdata/ Base package check failed ... Found version [none] at: /home/jon/flightgear/fgdata/ Please upgrade to version: 2.0.0 Hit a key to continue... I just downloaded the base package today as directed via git. What am I doing wrong? Jon 
From: Jon S. Berndt <jonsberndt@co...>  20100905 04:11:55

> Hi, > > You should be in the directory where you want to have the fgdata > directory, i.e. git creates fgdata in the current directory. > Cloning will download about 2.5GB of data so it will take a good while. Yeah, I got it and it certainly did take a good long time! Jon 
From: Anders Gidenstam <anderswww@gi...>  20100904 20:38:39

On Sat, 4 Sep 2010, Jon S. Berndt wrote: > Which directory should one be under when they execute the git command? Hi, You should be in the directory where you want to have the fgdata directory, i.e. git creates fgdata in the current directory. Cloning will download about 2.5GB of data so it will take a good while. If gitorious is slow you can also clone from http://mapserver.flightgear.org/git/fgdata > Is there anything that needs to be done afterwards when the data is all > downloaded, or is FlightGear ready to run at that point? FlightGear should be ready to run at that point. Use the fgroot=/path/to/fgdata argument to point FlightGear to the fgdata directory  it probably won't find it otherwise. Cheers, Anders   Anders Gidenstam WWW: http://www.gidenstam.org/FlightGear/ 
From: Jon S. Berndt <jonsberndt@co...>  20100904 19:42:28

> From: Frederic Bouvier > > I forgot : > 13. Get the data from Gitorious too : git clone > git://gitorious.org/fg/fgdata.git fgdata Which directory should one be under when they execute the git command? Is there anything that needs to be done afterwards when the data is all downloaded, or is FlightGear ready to run at that point? Jon 
From: <thorsten.renk@jy...>  20100903 08:49:57

> Don't we need to keep R, the universal gas constant, to make the equation > work? > > v ~ sqrt(TR/M) ? Not when you write it like this, because it's just a constant, so you can pull it out and the result is still proportional to the rest if you drop it, like v ~ sqrt(R) * sqrt(T/M) ~ sqrt(T/M) (you have to put it back in when you want v_E = xxx instead of v_E ~ xxx in the end  but you can gather all numerical constants into a single number in the end, and I guess that's precisely what you'd want to do anyway, see below). > It was my thinking that an increase in RPM would cause a pressure > increase > because: >  The pressure from the exhaust valve falls off over time and having the > valves open more often would increase the average pressure. (untested > hypothosis) >  The piston ejecting the burnt air from the cylinder moves faster as RPM > increases, causing the air to be ejected faster and leading to an > increase > in total pressure. (another untested hypothosis) Air pressure adjusts to changing conditions with the speed of sound (any deviation from equilibrium propagates with the speed of sound). Unless the piston moves supersonically, its movement cannot cause the air to be ejected faster than it would naturally do given its thermodynamics. If it moves supersonically, things become complicated, because then you're into shockwave propagation and then the precise geometry of the engine matters  thermodynamics is then insufficient to provide an answer, you'd need to run fluid dynamics. > Would p_E be the ambient air pressure? And p would not be the intake > manifold > pressure, which we have, it is the exhaust manifold pressure which we do > not > have. [1] I also assumed that a falloff of ambient pressure would be > accompanied by a falloff in mass flow. *shrugs* Your proposal was to replace the term by a constant. Mine was to use manifold pressure and ambient pressure as proxies for the real conditions (which we do not have). Of course that's not exact  but in all likelihood captures qualitatively what is going on and is better than a constant. In the end, there are hundreds of things you don't know  friction in the exhaust tube for example... its geometrical shape (exhaust velocity isn't actually a constant  there's some spatial profile to the velocity field)... turbulence when the exhaust airstream enters ambient air... and so on. So, you want to write down an equation which gives you the right qualitative behaviour, and have an adjustable constant in front of it which gives you the number right which is supposed to take care of all the things you don't know or have neglected with the hope that enginespecific constant and qualitative equations are a good enough model for the physics that goes into the problem. If the air mass flow drops with ambient pressure or not is a question of having a turbocharger for the engine or not I guess. Plus, there is of course the dynamic ram pressure due to the aircraft motion which increases air density in the engine. I would guess as long as manifold pressure does not change, the air mass flow does not change, because that measures at the intake. Cheers, * Thorsten 
From: Ron Jensen <wino@je...>  20100903 05:46:40

On Thursday 02 September 2010 01:39:52 thorsten.i.renk@... wrote: > A few comments to your math: > > I haven't done anything (yet) with Hal's exhaust thrust function. I was > > waiting for someone else to work out the math... > > > > The exhaust thrust function should return a force. Newton tells us: > > > > F=ma > > Indeed, but not very helpful here... force as a timederivative of the > momentum is what you need, i.e. > > F = dp/dt = dm/dt v_E + m * d v_E/dt = dm/dt * v_E > > using > > p = m * v_E > > and > > v_E = const. > > (as you also use yourself below). I was just introducing the concept of dimension analysis with that formula. > > Hal had said something like > > > > F=m*v^2 > > That would be the kinetic energy  as you point out correctly, it has the > wrong dimensions. > > > m_dot = m_dot_air + m_dot_fuel for our model. > > I am prepared to bet that for an aircraft engine (unlike a rocket) > dm_air/dt >> dm_fuel/dt is always true, i.e. you can forget about the fuel > content. Yes, m_dot_air : m_dot_fuel is 12:1 or higher > Yes, this says that the thermal velocity is proportional to the root of > the temperature. That is so because temperature (in suitable units) is a > measure of the mean kinetic energy of gas molecules, so if you write > > T ~ E_kin = M v^2 > > you can solve it for v and get > > v ~ sqrt(T/M) > > which is what the formula says. The rest gathers the physics of expansion > and pressure gradient. Note that units matter here! The temperature must > be given in Kelvin [K] in order to agree with the interpretation as unit > of energy measure. I doubt that the egt property is in K  so you need to > convert to proper units before inserting into the formula. True. JSBSim tends to be in US units, I believe its in Fahrenheit so T_Rankine = (T_Fahrenheit+459.67) T_Kelvin = (5/9)(T_Rankine) Don't we need to keep R, the universal gas constant, to make the equation work? v ~ sqrt(TR/M) ? > > The third term > > > > [1  (P_e/P)^((k1)/K)] > > > > Can be thought of as an efficiency factor, It should always be greater > > than or > > equal to zero and less than or equal to 1. Its value probably increases > > with > > pressure altitude as I believe that will lower P_e (pressure at the exit > > end > > of the exhaust manifold); P (pressure from the cylinders when the exhaust > > valves open) is probably related to manifold pressure and RPM. > > I guess that's a good starting point  the lower pressure would be outside > pressure, the higher pressure manifold pressure. I don't see how RPM come > in though. It was my thinking that an increase in RPM would cause a pressure increase because:  The pressure from the exhaust valve falls off over time and having the valves open more often would increase the average pressure. (untested hypothosis)  The piston ejecting the burnt air from the cylinder moves faster as RPM increases, causing the air to be ejected faster and leading to an increase in total pressure. (another untested hypothosis) > > It may be > > appropriate to think of this as a constant, too. > > Why  you have outside pressure and manifold pressure, so you can compute > it dynamically. It's not going to be a big effect though... p_E/p is > usually a small number. > > Cheers, > > * Thorsten Would p_E be the ambient air pressure? And p would not be the intake manifold pressure, which we have, it is the exhaust manifold pressure which we do not have. [1] I also assumed that a falloff of ambient pressure would be accompanied by a falloff in mass flow [1] http://web.mit.edu/16.unified/www/FALL/thermodynamics/notes/fig5OttoReal_web.jpg from http://web.mit.edu/16.unified/www/FALL/thermodynamics/notes/node26.html 
From: Stuart Buchanan <stuart13@gm...>  20100902 18:39:56

On Sat, Aug 28, 2010 at 9:09 PM, HBGRAL wrote: > Hi all > > I sent a small merge request to fgdata repo > http://gitorious.org/fg/fgdata/merge_requests/38 > > I was looking to the c172p directories and found some unused files and > some wrong paths coming from last commit (?). > >  effects in models had wrong paths, (re?)created a folder Effects >  removed unused graphic files in top models directory >  changed some .rgbgraphic files to .png (50 % data) > > I did not change any of the graphics or any other code. It is just a > small clean up and I checked the log well after this changes. > > Feel free to merge in, or not. This has now been merged. Thanks very much for the cleanup! Stuart 
From: <thorsten.renk@jy...>  20100902 07:40:07

A few comments to your math: > I haven't done anything (yet) with Hal's exhaust thrust function. I was > waiting for someone else to work out the math... > > The exhaust thrust function should return a force. Newton tells us: > > F=ma Indeed, but not very helpful here... force as a timederivative of the momentum is what you need, i.e. F = dp/dt = dm/dt v_E + m * d v_E/dt = dm/dt * v_E using p = m * v_E and v_E = const. (as you also use yourself below). > Hal had said something like > > F=m*v^2 That would be the kinetic energy  as you point out correctly, it has the wrong dimensions. > m_dot = m_dot_air + m_dot_fuel for our model. I am prepared to bet that for an aircraft engine (unlike a rocket) dm_air/dt >> dm_fuel/dt is always true, i.e. you can forget about the fuel content. > m_dot_air could also be > estimated as a function of RPM, engine displacement, and manifold air > density. Something like: > > m_dot_air = > (1/2)(RPM/60)(rho_manifold)(displacement)(volumetric_efficiency) Sounds very reasonable to me. > [2] gives us a formula for v_e: > v_e = sqrt( (T*R/M) (2k/(k1)) [1  (P_e/P)^((k1)/K)]) > > See the wikipedia article for a full explanation of the formula. Yes, this says that the thermal velocity is proportional to the root of the temperature. That is so because temperature (in suitable units) is a measure of the mean kinetic energy of gas molecules, so if you write T ~ E_kin = M v^2 you can solve it for v and get v ~ sqrt(T/M) which is what the formula says. The rest gathers the physics of expansion and pressure gradient. Note that units matter here! The temperature must be given in Kelvin [K] in order to agree with the interpretation as unit of energy measure. I doubt that the egt property is in K  so you need to convert to proper units before inserting into the formula. > k~= 1.4 > > for exhaust temperatures up to 1000 degrees C. > so the second term becomes: > > (2k/(k1)) ~= 7.0 > > The third term > > [1  (P_e/P)^((k1)/K)] > > Can be thought of as an efficiency factor, It should always be greater > than or > equal to zero and less than or equal to 1. Its value probably increases > with > pressure altitude as I believe that will lower P_e (pressure at the exit > end > of the exhaust manifold); P (pressure from the cylinders when the exhaust > valves open) is probably related to manifold pressure and RPM. I guess that's a good starting point  the lower pressure would be outside pressure, the higher pressure manifold pressure. I don't see how RPM come in though. > It may be > appropriate to think of this as a constant, too. Why  you have outside pressure and manifold pressure, so you can compute it dynamically. It's not going to be a big effect though... p_E/p is usually a small number. Cheers, * Thorsten 
From: Ron Jensen <wino@je...>  20100902 02:14:27

On Tuesday 31 August 2010 21:08:32 Jon S. Berndt wrote: > Ron, Hal, > > Just a reminder that this feature (arbitrary functions in engine > definitions)  I believe  works and is now in JSBSim CVS. Maybe it should > be moved to FlightGear? > > Jon I tend to keep my FlightGear uptodate with the latest JSBSim. I keep a git clone of this at http://gitorious.org/fg/jentronsflightgear. I don't have write access to the master repository. I haven't done anything (yet) with Hal's exhaust thrust function. I was waiting for someone else to work out the math... The exhaust thrust function should return a force. Newton tells us: F=ma or Newtons=kg*m/s^2 (SI) lbf=slugs * ft/s^2 (US pound as force) poundals = lb * ft/s^2 (US pound as mass) For the rest of this discusion I'm going to use the US pound as a force system. Hal had said something like F=m*v^2 but that yields slugs*ft^2/s^2. Not the correct units. F=m_dot * v_e [1] where m_dot is total mass flow per second and v_e is the velocity of the exhaust stream. lbf = (slugs/2)*(f/s) = slugs* ft/s^2 m_dot = m_dot_air + m_dot_fuel for our model. FGPiston currently calculates m_dot_air internally, but does not expose it as a property. m_dot_fuel is a property, and we could potentially use it, along with the mixture setting, to estimate m_dot_air. The problem with this approach is m_dot_fuel can be zero while m_dot_air still has a nonzero value. m_dot_air could also be estimated as a function of RPM, engine displacement, and manifold air density. Something like: m_dot_air = (1/2)(RPM/60)(rho_manifold)(displacement)(volumetric_efficiency) [2] gives us a formula for v_e: v_e = sqrt( (T*R/M) (2k/(k1)) [1  (P_e/P)^((k1)/K)]) See the wikipedia article for a full explanation of the formula. k~= 1.4 for exhaust temperatures up to 1000 degrees C. so the second term becomes: (2k/(k1)) ~= 7.0 The third term [1  (P_e/P)^((k1)/K)] Can be thought of as an efficiency factor, It should always be greater than or equal to zero and less than or equal to 1. Its value probably increases with pressure altitude as I believe that will lower P_e (pressure at the exit end of the exhaust manifold); P (pressure from the cylinders when the exhaust valves open) is probably related to manifold pressure and RPM. It may be appropriate to think of this as a constant, too. A first guess would be ~0,4. The first term: (T*R/M) contains two constants, R and M, so this value is completely controlled by T, our exhaust gas temperature, Exhaust gas temperature is available as a property in FlightGear but not JSBSim standalone. In short, I propose the following formula for v_e: v_e = sqrt( egt * k) where k = R/M * 7 * 0.4 Thanks, Ron  [1] http://en.wikipedia.org/wiki/Rocket_engine_nozzle#Specific_Impulse [2] http://en.wikipedia.org/wiki/Rocket_engine_nozzle#1D_Analysis_of_gas_flow_in_rocket_engine_nozzles 
From: J. Holden <stattosoftware@ya...>  20100901 20:45:58

Hi All, I have failed yet again to get TerraGear running on two computers. I recently tried a technique for the first time to determine land cover from satellite images. I am glad to say I succeeded, but there are still a number of problems with the scenery, from null values to cloud cover. This is 45Mb worth of shapefiles, beta land cover for northern Switzerland (Zurich, Bern, Neuchatel, Luzern, Interlaken), eastern France (Mulhouse) and southwestern Germany (Konstanz, Friedrichshafen). I would like to have compiled before I submit it to the land cover database so the community has a chance to fly over the area and note any special problems. My hope is this landcover will ultimately be a highinterest area for FlightGear users. Please reply here or email me off the list if you are able to download and compile this area  I think it is 3x2 degrees. Thanks John 
From: J. Holden <stattosoftware@ya...>  20100901 20:37:53

Hi All, Recently, I have been working on Switzerland scenery for FlightGear. Hopefully beta landcover will be released soon. At the moment, I've been making use of as many materials as I can find to accurately model the control tower at LSZB  Bern/Belp, and through some pictures I've noticed the arrows in the displaced threshold are different than the FlightGear textures. I would very much like to represent this if I can as it adds a level of localized realism. I also thought of another previous mailing list discussion about aiming point textures in Great Britain, and of yellow runway markings in northern Japan. This leads me to my question: Is there an easy way to replace the default textures on an airportbyairport basis? Currently there is one texture set for every airport. I am thinking of possibly indexed airport folders, such as Airport_1. If the airport is somehow classified as taking the textures from Airport_1, then load the textures (with the same file names) from that airport folder, and then fall back to the main texture folder if the texture is not found. For instance, Heathrow uses different aiming point marks than most airports. If you had a folder: Runway/EGLL_Textures with only the file pc_aim.png, and then you somehow had a file telling the program to look for textures in /Runway/EGLL_Textures BEFORE it looks in /Runway JUST for Heathrow, you could load the different pc_aim.png just for Heathrow. My gut thinks this is impossible, but my gut is also very hungry. Thanks John 
From: Gijs de Rooy <gijsrooy@ho...>  20100901 20:29:55

> Jon wrote: > Nice! How does one begin writing for the next issue? Is there a particular format to follow? Order of stories? Nice to see you're interested Jon! I've written a little guide a while ago, which is available at the forum: http://www.flightgear.org/forums/viewtopic.php?f=28&t=7794 It is not a big deal to contribute. You just need a wikiaccount (free to register); you don't even need an idea on what to write about, as checking other people's texts for typos or adding screenshots is also welcome! I can imagine that you would like to write something about JSBSimupdates? That is exactly the kind of thing I would like to see more often in the news letter! A list of updated aircraft is nice of course, but it does not make this into a newsletter... Feel free to ask if things are unclear. However, to freequote the IRCtopic: "Don't ask to add, just add!" :) Looking forward to your contribution! Gijs 
From: HBGRAL <flightgear@sa...>  20100901 13:35:59

Am 28.08.10 12:34, schrieb HBGRAL: > Am 28.08.10 01:16, schrieb Tim Moore: >> There needs to be some coordinate for the fog. You could try using >> gl_FogFragCoord instead. >> >> Tim > > Thanks for your answer Tim. And what should happen when I change > gl_BackColor.a from 0.0 to 1.0 in default.vert? I see here that this > makes the terrain shaders (or the light) running at least for some older > ATI cards (and .z/.w is def. not the problem). > > What do I loose with this change? What do I have to check? And could > this work for terrain also for other cards with gl_BackColor.a = 1.0? > > Thanks, Yves Ok, I can keep all the new code now with my older ATI. For my card I only had to add 'if (gl_BackColor == 0.0) { n = n; }' again in default.frag and that seems finally to work with recent changes. Maybe this makes not a lot of sense, but I do not care anymore ;) Yves 
From: Jon S. Berndt <jonsberndt@co...>  20100901 03:12:05

Nice! How does one begin writing for the next issue? Is there a particular format to follow? Order of stories? Jon 
From: Jon S. Berndt <jonsberndt@co...>  20100901 03:08:30

> Yes, arbitrary functions would be very, very handy. Especially if > there were > a macro to get the engine number so a multi engine aircraft wouldn't > need > multiple copies of the same system file... > > Thanks, > Ron Ron, Hal, Just a reminder that this feature (arbitrary functions in engine definitions)  I believe  works and is now in JSBSim CVS. Maybe it should be moved to FlightGear? Jon 