[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_00:52:30 (sydadams) /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/cropgrass1.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/cropgrass2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/cropgrass3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/deciduous1.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/deciduous2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/deciduous4.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/drycrop1.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/drycrop2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/drycrop3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/drycrop4.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/forest1a.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/forest1b.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/forest1c.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/herbtundra.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/herbtundra2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/herbtundra3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/irrcrop1.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/irrcrop2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/irrcrop3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/mixedcrop1.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/mixedcrop3.rgb Adding missing winter textures ...more to come =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_00:52:31 (sydadams) /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/mixedcrop4.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/mixedforest2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/mixedforest3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/shrub2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/shrub3.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/tundra2.rgb /var/cvs/FlightGear-0.9/data/Textures/Terrain.winter/tundra3.rgb Adding missing winter textures ...more to come =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_12:34:19 (vmmeazza) /var/cvs/FlightGear-0.9/data/gui/dialogs/formation-select.xml Experimental formation menu =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_12:38:45 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_1.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_2.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_3.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_4.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_5.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Models/Liveries/Attic/formation_6.xml Experimental formation menu stuff =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_16:13:02 (vmmeazza) /var/cvs/FlightGear-0.9/data/AI/wingman2_demo.xml /var/cvs/FlightGear-0.9/data/AI/wingman_demo.xml Experimental formation menu stuff =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_17:27:01 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_1.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_2.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_3.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_4.xml Correct folder contents =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_17:27:02 (vmmeazza) /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_5.xml /var/cvs/FlightGear-0.9/data/Aircraft/Buccaneer/Formations/formation_6.xml Correct folder contents =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_20:56:29 (tat) /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/ki-84-sound.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/adf.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/alt.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/boost.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/cyltemp.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/egt.xml /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/gauges.rgb /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/gauges.xcf /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Instruments/vsi.xml Updated Ki-84 for 1.0.0 and OSG/CVS: Added: ki-84 specific Nasal file and jwarbirds Modified: alt, cyltemp, vsi for accuracy Modified: electrical.nas that applied the "var" to show variable's scope. Removed: unused Nasal file =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-11_20:56:30 (tat) /var/cvs/FlightGear-0.9/data/Aircraft/Ki-84/Nasal/Attic/a6m2.nas /var/cvs/FlightGear-0.9/data/Air
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-15_00:44:05 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/model/particles.cxx /var/cvs/SimGear-0.3/source/simgear/scene/model/particles.hxx particles from Tiago_G =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-15_00:44:24 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/model/particles.cxx /var/cvs/SimGear-0.3/source/simgear/scene/model/particles.hxx Cleanup of particles contribution Put particles classes inside simgear namespace Refactored some redundant code Reworked local frame math to use OSG math classes as much as possible =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-02-16_11:01:01 (mfranz) /var/cvs/SimGear-0.3/source/simgear/scene/model/SGMaterialAnimation.cxx remove getRootNode(), as this resets the model root 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] New Eye-Candy
On Sat, Feb 16, 2008 at 7:15 PM, Csaba Halász wrote: > Vivian, thanks for the fun feature ;) > Here are some "appetizer" screenshots: > http://picasaweb.google.com/Csaba.Halasz/BuccaneerFormationFlying > I don't want to spoil anyone's easter egg Vivian, but nice touch with the wingman pilot figure! I had to do a double take to see if I really saw what I just thought I saw! :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] New Eye-Candy
Vivian, thanks for the fun feature ;) Here are some "appetizer" screenshots: http://picasaweb.google.com/Csaba.Halasz/BuccaneerFormationFlying -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Looking for someone to interview
Hello, I am Steven Sayers, I co-host a new and, at least I'd consider it up and coming podcast called "The Teen Linux Lounge". I am personally a huge fan of what the community and developers have done to fgfs. I come to ask any of you; who have a microphone and a gizmo client installed; would you like to appear on "The Teen Linux Lounge" and discuss some of the neat features you've added, going to add, and topics of that sort. It'd be great to get a teen fgfs developer however I am fine with any age really. You can view our site at http://teenlinuxlounge.com and can contact me at [EMAIL PROTECTED] . Thank you for reading. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] season patch
Here's a patch to remove the ".winter" that is appended to the Terrain texture path... I will upload a new materials.xml.test file with the required changes ... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> mat.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Blackout/Redout
--- Stuart Buchanan wrote: > I've just committed a generic, configurable version which means that all > aircraft > now have G-force blackout, and the aircraft-specific versions can now be > retired. > As G-force affects all pilots, it seems appropriate to have a single solution > for > everyone as part of the core simulator, rather than only specific aircraft. I've committed some changes to this, based on feedback from Melchior. The only change in function is that the property names have changed to the following: /sim/rendering/redout/parameters/blackout-onset-g /sim/rendering/redout/parameters/blackout-complete-g /sim/rendering/redout/parameters/redout-onset-g /sim/rendering/redout/parameters/redout-complete-g The other changes make it more efficient (by using listeners instead of reading properties every iteration) and smoother (by updating the blackout level every frame). -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] b1900d asi suggestion
On Sat, 16 Feb 2008 10:28:24 +0100 "K. Hoercher" <[EMAIL PROTECTED]> wrote: > Hi! > > According to > http://www.pprune.org/forums/archive/index.php/t-166572.html > http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/4bd70d173cbc5f4586256fb80048f054/$FILE/A24CE.pdf > and others at google's discretion the b1900d is restricted to a > Vmo=248KIAS and a Mmo of 0.48 at an, allegedly, pressure altitude of > 13200ft or above. That restriction is "somehow" displayed by the barber > pole in the airspeed indicator. Short of knowing (despite some search) > how the asi works to that effect I suggest something like the patch > attached. > > The change in the asi300gauge.ac would reset the barber pole to start > from a position where its lower edge meets the upper one of the airspeed > needle. That allows for it to be driven through the illinear scaling of > the modelled asi mimicking the airspeed needle animation. > > I have cutoff its movement at an arbitrary 178(KIAS), as that would be > way beyond any specified operating limits. > > The calculation itself is a bit messy. I think the changeover point is > a made up reference to essentially construe a meaning of > limit=min(Vmo,Mmo). Apparently the equality would be at that pressure > altitude in ISA standard day conditions, but could shift somewhat as the > speed of sound isn't dependent on the pressure itself alone. I decided > to stick to that published pressure alt restriction until I know > positively otherwise. > > As the indicated-speed-kt property is calculated from the density of > the air (thus including temperature), side-slip, pressure etc. which I > think would also define the mach number to compare against, I avoided the > real calculation steps and just took it as a reference to "somehow" > arrive at a value for representing the Mach 0.48 in the KIAS scale. Any > noise at low speeds/altitudes can be written off following the sticking > to the mentioned changeover criterium. That should also minimize the > computing effort needed every frame. > > The same is perhaps true for not overwriting the property with the Vmo > every frame. Yeah I know, don't speculatively optimize without > profiling. I plead guilty on infringing that one; please change as you > see fit. > > HTH > K. Hoercher > I,ve added your improvements , it's now in cvs .Thanks . Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG seasons
On Sat, 16 Feb 2008 19:40:21 +0100 Georg Vollnhals <[EMAIL PROTECTED]> wrote: > Syd&Sandy schrieb: > > Hi everyone , > > Since I've been working on trees and seasonal textures , I'd like to > > propose some ideas > > 1: Could we have Jester's materials.xml condition patch put in CVS ? > > 2: Remove the .winter that is appended to the texture path in the source > > code? > > 3: Add /sim/startup/season = summer as default to the preferences.xml , > > since it doesn't exist unless you use the command line option ? > > 4: Have a Textures.high/Trees with 128 pixel high images for the systems > > that can handle it ? (which I've already created ) > > 5: I better stop there ;) > > > > Cheers > > > > > Hi Syd, > > this is just a feedback as I reported some problems with lacking ground > textures in the winter-season. I found out what the problem was - as > always very simple but time-consuming to get there: > > 1. > I identified 2 problems where the materials.xml has set the texture-path > to Terrain.winter/.. > When you change it to just Terrain/.. the WINTER groundtextures are > displayed in FG. > > SAMPLES: > > EvergreenBroadCover > ... > > Terrain/forest1.rgb > > > DeciduousBroadCover > ... > > Terrain/forest1c.rgb > > There are 3 further pathes set in the material.xml to Terrain.winter. > Should I change them to just Terrain either? > > 2. Lacking City-textures > I just placed city1.rgb .. city3.rgb summer-textures into > /Textures.high/Terrain.winter and they are now displayed. Better > summer-textures than no textures at all :-). I think this is easy to > change and if there is no GIMP specialist who can do this very fast I > will have a look at GIMP how to convert green to white. This should do > for the first until we get some better city textures. > > Georg EDDW > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Yes I thought I mentioned changing the "Terrain.winter" to "Terrain"... We still need to remove the appended ".winter" in the source code , but I can't do that ... Then the materials.xml can pick its own textures from whichever folderit desires and not be forced into the Terrain.winter folder... Cheers -- Syd&Sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG seasons
Syd&Sandy schrieb: > Hi everyone , > Since I've been working on trees and seasonal textures , I'd like to propose > some ideas > 1: Could we have Jester's materials.xml condition patch put in CVS ? > 2: Remove the .winter that is appended to the texture path in the source code? > 3: Add /sim/startup/season = summer as default to the preferences.xml , since > it doesn't exist unless you use the command line option ? > 4: Have a Textures.high/Trees with 128 pixel high images for the systems that > can handle it ? (which I've already created ) > 5: I better stop there ;) > > Cheers > > Hi Syd, this is just a feedback as I reported some problems with lacking ground textures in the winter-season. I found out what the problem was - as always very simple but time-consuming to get there: 1. I identified 2 problems where the materials.xml has set the texture-path to Terrain.winter/.. When you change it to just Terrain/.. the WINTER groundtextures are displayed in FG. SAMPLES: EvergreenBroadCover ... Terrain/forest1.rgb DeciduousBroadCover ... Terrain/forest1c.rgb There are 3 further pathes set in the material.xml to Terrain.winter. Should I change them to just Terrain either? 2. Lacking City-textures I just placed city1.rgb .. city3.rgb summer-textures into /Textures.high/Terrain.winter and they are now displayed. Better summer-textures than no textures at all :-). I think this is easy to change and if there is no GIMP specialist who can do this very fast I will have a look at GIMP how to convert green to white. This should do for the first until we get some better city textures. Georg EDDW - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bizarre dynamic scenery
* jean pellotier -- Monday 21 January 2008: > the bo105 has this problem, specialy the doors witch are invisible when > it's an mp aircraft. (and the livery change is global) This was a bug in the SGMaterialAnimation class. Should be fixed now. m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tomcat beta and some RFC
On Feb 16, 2008 6:32 PM, flying.toaster <[EMAIL PROTECTED]> wrote: > > If CVS maintainers think it is worthy, I will provide a link to a compressed > TAR file I am not a cvs maintainer, but by all means, do provide a tarball for testing! Surely a lot of people are interested in the Tomcat. -- Csaba/Jester - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Tomcat beta and some RFC
Hi everybody, Still working on the flight dynamics of the tomcat and it is coming along nicely. I have ran into a few limitations lately and I would like to know if people have been working on fixes for those limitations or if other people than me feel frustrated about those limitations and I should try to start changing the source code for addition into the CVS (rather than hacking around in Nasal). Here are the few limitations I have ran into (not that bad, I am definitely NOT in a FG bashing spirit :) ) : * The HUD tapes have the option to provide moving pointer display. This is a nice feature since it was implemented this way on the F-14A/B tomcats (rather than moving scale on modern aircrafts)... The thing is, it does not work on FG 1.0 : the pointer is replaced by a single line all the way to the top of the screen. I have looked in the source code and found no visible error. Beats me. If somebody else is stuck with this problem and it has not been fixed I can give it a closer look. * It seems that pitch rates and yaw rate properties are given in an earth trihedral rather than a airframe trihedral. While this is very nice for instruments, it is hardly usable for, say, the implementation of a Stability Augmentation System which relies on aircraft trihedral angular rates for stabilization. Can (are ?) those values be exposed in the property tree and if so, why are they not exposed ? The F-14 is much more flyable now than it used to be. Some textures are still incomplete, the 2D cockpit is still to be made, and there is no documentation at all, but I think it may be worth uploading to CVS as an alpha version for people to start providing inputs on how it flies on different versions of flightgear and different hardware setups (I am afraid it is a little bit of a bloatware :( ). If CVS maintainers think it is worthy, I will provide a link to a compressed TAR file Regards Enrique - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] b1900d asi suggestion
Hi!
According to
http://www.pprune.org/forums/archive/index.php/t-166572.html
http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/4bd70d173cbc5f4586256fb80048f054/$FILE/A24CE.pdf
and others at google's discretion the b1900d is restricted to a
Vmo=248KIAS and a Mmo of 0.48 at an, allegedly, pressure altitude of
13200ft or above. That restriction is "somehow" displayed by the barber
pole in the airspeed indicator. Short of knowing (despite some search)
how the asi works to that effect I suggest something like the patch
attached.
The change in the asi300gauge.ac would reset the barber pole to start
from a position where its lower edge meets the upper one of the airspeed
needle. That allows for it to be driven through the illinear scaling of
the modelled asi mimicking the airspeed needle animation.
I have cutoff its movement at an arbitrary 178(KIAS), as that would be
way beyond any specified operating limits.
The calculation itself is a bit messy. I think the changeover point is
a made up reference to essentially construe a meaning of
limit=min(Vmo,Mmo). Apparently the equality would be at that pressure
altitude in ISA standard day conditions, but could shift somewhat as the
speed of sound isn't dependent on the pressure itself alone. I decided
to stick to that published pressure alt restriction until I know
positively otherwise.
As the indicated-speed-kt property is calculated from the density of
the air (thus including temperature), side-slip, pressure etc. which I
think would also define the mach number to compare against, I avoided the
real calculation steps and just took it as a reference to "somehow"
arrive at a value for representing the Mach 0.48 in the KIAS scale. Any
noise at low speeds/altitudes can be written off following the sticking
to the mentioned changeover criterium. That should also minimize the
computing effort needed every frame.
The same is perhaps true for not overwriting the property with the Vmo
every frame. Yeah I know, don't speculatively optimize without
profiling. I plead guilty on infringing that one; please change as you
see fit.
HTH
K. Hoercher
diff --git a/Instruments/asi300.xml b/Instruments/asi300.xml
index d848d8d..546aa9f 100644
--- a/Instruments/asi300.xml
+++ b/Instruments/asi300.xml
@@ -31,6 +31,23 @@
rotate
+ASI.needle.001
+
/instrumentation/airspeed-indicator/limit-indicated-speed-kt
+
+ 0.0178.0
+170.0178.0
+240.0268.0
+300.0333.0
+
+
+-1.0
+0.0
+0.0
+
+
+
+
+rotate
ASI.needle
/instrumentation/airspeed-indicator/indicated-speed-kt
diff --git a/Instruments/asi300gauge.ac b/Instruments/asi300gauge.ac
index 3cdca1b..af1287c 100644
--- a/Instruments/asi300gauge.ac
+++ b/Instruments/asi300gauge.ac
@@ -9,18 +9,18 @@ texture "asi300.rgb"
texrep 1 1
crease 30
numvert 12
-0.002238 0.001557 0.003006
-0.002238 0.003459 0.000672
-0.002238 0.002921 -0.001971
-0.002238 0.000672 -0.003459
-0.002238 -0.001971 -0.002921
-0.002238 -0.003459 -0.000672
-0.002238 -0.002921 0.001971
-0.002238 -0.000258 0.003375
-0.002238 -0.000271 -0.011011
-0.002238 -0.004056 -0.010241
-0.002238 0.005449 0.022667
-0.002238 0.005061 0.028952
+0.002238 0.003188 -0.001138
+0.002238 0.001132 -0.003337
+0.002238 -0.001559 -0.00316
+0.002238 -0.003337 -0.001132
+0.002238 -0.00316 0.001559
+0.002238 -0.001132 0.003337
+0.002238 0.001559 0.00316
+0.002238 0.003309 0.00071
+0.002238 -0.010947 -0.001215
+0.002238 -0.010694 0.002639
+0.002238 0.023194 -0.002345
+0.002238 0.02937 -0.001114
numsurf 5
SURF 0x10
mat 0
diff --git a/Nasal/systems.nas b/Nasal/systems.nas
index 6534752..a11ec6b 100644
--- a/Nasal/systems.nas
+++ b/Nasal/systems.nas
@@ -22,6 +22,27 @@ var MB =
props.globals.getNode("/instrumentation/altimeter/millibars",1);
var FHmeter = aircraft.timer.new("/instrumentation/clock/flight-meter-sec",
10);
FHmeter.stop();
+#http://www.pprune.org/forums/archive/index.php/t-166572.html
+#http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/4bd70d173cbc5f4586256fb80048f054/$FILE/A24CE.pdf
+var LIMIT_VIAS=248.0;
+var LIMIT_MACH=0.48;
+var LIMIT_CHANGE=13200.0;
+var CURR_HP_NODEP="instrumentation/altimeter/pressure-alt-ft";
+var CURR_KIAS_NODEP="instrumentation/airspeed-indicator/indicated-speed-kt";
+var CURR_MACH_NODEP="velocities/mach";
+var
CURR_LIMIT_NODEP="instrumentation/airspeed-indicator/limit-indicated-speed-kt";
+props.globals.getNode(CURR_LIMIT_NODEP,1).setValue(LIMIT_VIAS);
+
+var set_barber_pole = func {
+ if (getprop(CURR_HP_NODEP)>LIMIT_CHANGE) {
+
setprop(CURR_LIMIT_NODEP,getprop(CURR_KIAS_NODEP)/getprop(CURR_MACH_NODEP)*LIMIT_MACH);
+ } else {
+if (!(getprop(CURR_LIMIT_NODEP)==LIMIT_VIAS))
+ setprop(CURR_LIMIT_NODEP,LIMIT_VIAS);
+ }
+ settimer(set_barber_pole,0);
+}
+
setlistener("/sim/signals/fdm-initialized", func {
[Flightgear-devel] Generic Blackout/Redout
Hi All, We currently have a number of aircraft which feature blackout and redout due to the G-force on the pilot. Blackout occurs when the pilot is subject to high positive G-loading, as the blood is drained from the head. Red-out occurs when the pilot is subject to high negative G-loading, as extra blood pools in the head. The effects can be mitigated by tensing the muscles of the legs (for blackout) or wearing a G-suit. I've just committed a generic, configurable version which means that all aircraft now have G-force blackout, and the aircraft-specific versions can now be retired. As G-force affects all pilots, it seems appropriate to have a single solution for everyone as part of the core simulator, rather than only specific aircraft. Notes: 1) There is a G-force Options dialog under the View menu, which allows the user to enabled/disable blackout and set the G-force at which blackout and red-out occur, and are "complete" (i.e. the screen is completely black/red). 2) Whether or not blackout is enabled is controlled by /sim/rendering/redout/enabled. This is a userarchive property. The intention is that the user will configure this. 3) The points at which blackout/redout start and are complete are configured by the following properties: /sim/rendering/redout/blackout-onset /sim/rendering/redout/blackout-complete /sim/rendering/redout/redout-onset /sim/rendering/redout/redout-complete These are not userarchive. The intention is that aircraft designers can configure these appropriately to take into account the resilience of the pilot. For example, the default values are probably appropriate for a civilian pilot, while a military pilot in a G-suit will have a much higher tolerance. 4) The blackout/redout only occur within in-cockpit views (the view/internal property), so have no effect on chase or tower views. 5) The properties and dialogs are under "redout" as this is the name .cxx file and that implements the blackout/redout, and also the property which is used to control the current blackout/redout itself. Yes, we could change it to "blackout". 6) This is OSG only, so isn't applicable to the plib data branch. Comments are, as always, very welcome. -Stuart __ Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
