Having used Roman's script as a base, I discovered the "danger" of using (G:Var)'s instead of (L:Custom,unit) variables...In my G1000 PFD I already had a bunch of (G:Var)'s in use which of course conflicted with the one's he'd used in his script... :( In any case, here is my version of an Airspeed Trend Indicator that's more in tune with a light GA a/c...

<!-- ======================= AIRSPEED TREND INDICATOR ======================= --><Element>	<Select>		<Value>			(P:Local Time, seconds) 0.2 % 10 * int 0 == 			if{ (A:Airspeed select indicated or true, knots) (>L:SpeedPrevious,knot) }		</Value>	</Select></Element><Element>	<Select>		<Value>			(P:Local Time, seconds) 0.2 % 10 * int 1 == 			if{ (A:Airspeed select indicated or true, knots) s1 (L:SpeedPrevious,knot) - 0.1 / 10 * l1 + (>L:SpeedTrend,knot) }		</Value>	</Select></Element><Element>	<Position X="275" Y="145"/>	<Visible>		(L:SpeedTrend,knot) (A:Airspeed select indicated or true, knots) >	</Visible>	<MaskImage Name="G1000_SpeedTrend_Mask.bmp" Bright="Yes">		<Axis X="0" Y="64"/>	</MaskImage>	<Image Name="G1000_SpeedTrend.bmp" Bright="Yes">		<Nonlinearity>			<Item Value="2" X="0" Y="0"/>			<Item Value="40" X="0" Y="64"/>		</Nonlinearity>	</Image>	<Shift>		<Value Minimum="2" Maximum="40">			(A:Airspeed select indicated or true, knots) 45 < 			if{ 0 } 			els{ (L:SpeedTrend,knot) (A:Airspeed select indicated or true, knots) - }		</Value>		<Delay PixelsPerSecond="10"/>	</Shift></Element><Element>	<Position X="275" Y="209"/>	<Visible>		(L:SpeedTrend,knot) (A:Airspeed select indicated or true, knots) <	</Visible>	<MaskImage Name="G1000_SpeedTrend_Mask.bmp" Bright="Yes">		<Axis X="0" Y="0"/>	</MaskImage>	<Image Name="G1000_SpeedTrend.bmp" Bright="Yes">		<Nonlinearity>			<Item Value="-2" X="0" Y="64"/>			<Item Value="-40" X="0" Y="0"/>		</Nonlinearity>	</Image>	<Shift>		<Value Minimum="-40" Maximum="-2">			(A:Airspeed select indicated or true, knots) 45 < 			if{ 0 } 			els{ (L:SpeedTrend,knot) (A:Airspeed select indicated or true, knots) - }		</Value>		<Delay PixelsPerSecond="10"/>	</Shift></Element>

Hi. For a speed trend indicator, has anyone besides me had better luck with the ACCELERATION BODY or ACCELERATION WORLD variables? As far as I can see, change in speed over change in time is the same thing whether taken directly from a variable, or computed manually, as here. I've personally found that directly using the acceleration variables eliminates spiking and jitteriness. I don't remember if those variables are available for FS9 though, and I no longer have that SDK installed.

Having used Roman's script as a base, I discovered the "danger" of using (G:Var)'s instead of (L:Custom,unit) variables...In my G1000 PFD I already had a bunch of (G:Var)'s in use which of course conflicted with the one's he'd used in his script... :( In any case, here is my version of an Airspeed Trend Indicator that's more in tune with a light GA a/c...<snip code>

Those variables are not available from the XML tokens in FS9, which is precisely why I have to compute it myself. Everything I code/script for must run in both FS9 and FSX/SP2... :)The next goal is to compute "rate of turn" for a turn trend indicator above the EHSI compass... :(

Bill, WOW! Thanx for bringing that 'ol code back. Ahh, memories of FS02 & G:Vars LOL! Anyhow now I'd throw the "math" into a <update> tag with comments now ( Still on 9 BTW ).. Glad it worked for you. SPRINTZ, Using, ACCELERATION BODY or ACCELERATION WORLD may work. ( Bill, BTW they do work in FS9 ) But the whole deal is what's interpreted by the "end" user, IE pilot. AND dependant on aircraft systems. Yes, in real life they are pulled by the IRS's and AirNav comps. Where indeed Acc vars are the perfect deal, except, the vars that I know of are all on single axis' X,Y,Z (Exactly how IRS, AirNav comps etc.. work) . The end result is also on a reference to indicated airspeed on the gauge. So to use Acc X,Y, or Z vars with all the other outside stuff will make a code base of the "trend" alot larger, by a factor of 10 for sure.. All of that is taking into consideration by a simple sampling deal of the "known" indicated airspeed. My junk 'puter has never had a problem with this sampling, smooth as Victoria Secret. To do it the other way, in my opinion, is overkill. Code on! Dont forget the closing tags!RomanP.S. Bill- Did you try to use the same sampling? Throw the turn rate instead of airspeed into the mix? Cannot see math wise any diff. Go Horizontal vs Vertical.

P.S. Bill- Did you try to use the same sampling? Throw the turn rate instead of airspeed into the mix? Cannot see math wise any diff. Go Horizontal vs Vertical.

Actually, as it happens there are TWO (A:var,unit)'s precisely for this purpose already computed... :( This is what I wound up doing...

			<!-- ======================= TURN TREND INDICATORS =========================== -->			<Element>				<Position X="404" Y="361"/>				<MaskImage Name="G1000_TurnTrendRight_Mask.bmp" Bright="Yes">					<Axis X="40" Y="115"/>				</MaskImage>				<Image Name="G1000_TurnTrendRight.bmp" Bright="Yes">					<Axis X="40" Y="115"/>				</Image>				<Rotate>					<Value>(A:DELTA HEADING RATE,Radians per second) 10 *</Value>				</Rotate>			</Element>			<Element>				<Position X="404" Y="361"/>				<MaskImage Name="G1000_TurnTrendLeft_Mask.bmp" Bright="Yes">					<Axis X="40" Y="115"/>				</MaskImage>				<Image Name="G1000_TurnTrendLeft.bmp" Bright="Yes">					<Axis X="40" Y="115"/>				</Image>				<Rotate>					<Value>(A:DELTA HEADING RATE,Radians per second) 10 *</Value>				</Rotate>			</Element>

My next step will be to replace the bitmaps with vector arc segments, but for prototyping purposes used some temporary bitmaps... :(

Bill. Know notta of FSX & new vars etcc,.. NEVER MIND! Wow.. a new "9" that has never been played with! Nice...Just like TV,,, 3000 channels & nothing on,, til you find it.RomanQuick edit.. what was your 2nd find? All i got was A:PROP SYNC DELTA LEVER# in a search of my database for "Delta"

Bill. Know notta of FSX & new vars etcc,.. NEVER MIND! Wow.. a new "9" that has never been played with! Nice...Just like TV,,, 3000 channels & nothing on,, til you find it.RomanQuick edit.. what was your 2nd find? All i got was A:PROP SYNC DELTA LEVER# in a search of my database for "Delta"

Okay, I forgot to list the two variables:TURN INDICATOR RATE Turn indicator reading Radians per second // only available in FSXDELTA HEADING RATE Rate of turn of heading indicator Radians per second // availabe in BOTH FS9 and FSXFor obvious reasons, I chose to use the latter since it's "sim agnostic" and I see no reason to complicate matters... :(

For obvious reasons, I chose to use the latter since it's "sim agnostic" and I see no reason to complicate matters... :(

True.... Thanx..

Roman:Combos of Acceleration World or Body or Velocity World or Body variables work just fine. That they are each in one spatial dimension only is no problem. A little trig gets you where you need to be. I've compared both methods ( sampling delta IAS over delta time, vs. the "pure" variable ), and the only difference is a lack of spiking and twitching with the "real" variables... a significant advantage. You can make the math more and more complex to get the speed trend value more and more precise, but it is not ever off by a factor of 10. (Am I reading you correctly????) In fact, using only ACCELERATION BODY Z and VELOCITY BODY Z (I think it's Z, IIRC) gets you very, very close 99% of the time. And the remaining 1% is a non-issue for civil aviation, unless something very bad is already happening. ;-)Thanks for your comments,Scott

Bill, WOW! Thanx for bringing that 'ol code back. Ahh, memories of FS02 & G:Vars LOL! Anyhow now I'd throw the "math" into a <update> tag with comments now ( Still on 9 BTW ).. Glad it worked for you. SPRINTZ, Using, ACCELERATION BODY or ACCELERATION WORLD may work. ( Bill, BTW they do work in FS9 ) But the whole deal is what's interpreted by the "end" user, IE pilot. AND dependant on aircraft systems. Yes, in real life they are pulled by the IRS's and AirNav comps. Where indeed Acc vars are the perfect deal, except, the vars that I know of are all on single axis' X,Y,Z (Exactly how IRS, AirNav comps etc.. work) . The end result is also on a reference to indicated airspeed on the gauge. So to use Acc X,Y, or Z vars with all the other outside stuff will make a code base of the "trend" alot larger, by a factor of 10 for sure.. All of that is taking into consideration by a simple sampling deal of the "known" indicated airspeed. My junk 'puter has never had a problem with this sampling, smooth as Victoria Secret. To do it the other way, in my opinion, is overkill. Code on! Dont forget the closing tags!RomanP.S. Bill- Did you try to use the same sampling? Throw the turn rate instead of airspeed into the mix? Cannot see math wise any diff. Go Horizontal vs Vertical.