I am wanting to make my electric gyro instruments only come alive after their gyro power is switched on by a separate switch.So, I created my own attitude indicator, and the switch of course.the MAKE_SPRITE uses ATTITUDE_INDICATOR_PITCH_DEGREES ATTITUDE_INDICATOR_BANK_DEGREESwhich automatically "spool" down and up, but with battery power.So, in the SPRITE callback, if I use the power switch to just not connect them to the gauge, it would just sit in the zero position (which I could adjust) but then would snap to the spooled up values.So, it would seem that I will have to create functions that spool up to the current values, when they are switched on, and spool down to an off position when switched off to be independent of those MODULE_VARS.I am not missing anything am I?Patrick

No, you have it figured out...Use any of the following to achive your goal:Create a loop function to increment your custom variable at whatever rate you wish until it is equal to the current sim var's value.Create another loop function to decrement... :)

Patrick,You might search for Arne Bartel's Exponential Averaging formula in this forum, and suit it to your needs. Smooth transitions of any kind can be obtained by its use. Further more, I think it is the most useful piece of code ever posted in the entire forum...Thanks Arne!TomPS: my engine control code makes use of this gem 32 times...(yes, 32 times!)...SO FAR :-)

Thanks Tom, I'll check it out if I can find it.Patrick

Your assignment then is to translate it to C++... ;)

Yes, I have the discovered the fabled formula: yn1 = yn * D + (1.0 - D) * xn1where ledgend has it: yn1 - "Your new" var now yn - "Your new" var before D - Dampening constant ( 0 < D < 1 ) xn1 - "ex-var (you formerly were dependent on) nowForthwith I shall create a function (or possibly an object or two or three) that shall encapsulate this fabled formula.:-rotor

Patrick,This XML macro is one example that you could use as a reference when translating the formula into C++: @1 sp0 (@3,number) @2 * 1.0 @2 - l0 * + d (>@3,number) and then:new value = @Damped(target final value, D factor ,reference variable without unit)What I really use is an expanded macro that takes account of FS paused state and Simulator Rate.Tom

Tom,Totally new stuff for me, must have missed something!Can you give an example:Say you use next formula for the velocity vector in a HUD how would you dampen it?It is jumping!..............(A:Velocity body X, m/s) (A:Velocity body Z, m/s) atg2 rddg (A:Velocity body Y, m/s) (A:Velocity body Z, m/s) atg2 rddg Jan"Beatus ille qui procul negotiis..."

Jan,I can think of something like this:Intermediate vars: (L:VBodyRefXZ,number) and (L:VBodyRefYZ,number)Reference vars: (L:VBodyXZ,degrees) and (L:VBodyYZ,degrees)Damping factor to start with: 0.990. This is kinda subjective and you must change it until obtain the result desired. Usual values range from 0.800 to 0.999 In the section, for XZ :(A:Velocity body X, m/s) (A:Velocity body Z, m/s) atg2 rddg sp0@Damped(l0,0.990,L:VBodyRefXZ) (>L:VBodyXZ,degrees)for the YZ (A:Velocity body Y, m/s) (A:Velocity body Z, m/s) atg2 rddg sp0@Damped(l0,0.990,L:VBodyRefYZ) (>L:VBodyYZ,degrees)Then in each (L:VBodyXZ,degrees) etc..Good luck!Tom

Not to change the subject here, but that vector jumping might just be because of the nature of those Velocity Body variables you're using. (Though theoretically, it seems like they SHOULD work perfectly, I know! ....) I do remember using them myself at one point and running into your same problem. So...I did a TON of experimentation with making a truly accurate velocity vector several months ago, and I got by far the best results using Velocity World X and Velocity World Z for track angle, and then Velocity World Y and Ground Velocity for climb angle. With those variables, there is no *unrealisitc* jumping in the vector, even with severe turbulence. So it should not need to be dampened. Yes, you'll have to patch up the area around heading 000 (when aircraft heading is on one side of 000 and actual track on the other), but that can be done pretty easily. The attached screen shot will give you an idea of my little analysis. I had 6 or 7 differently coded (and colored) velocity vectors on the screen at once (each based on some combination of the Velocity Worlds, Velocity Bodies, Ground Velocity, alpha, beta, etc.). I then used my own test gauges and AFSD (not shown, obviously) to determine which method gave the most accurate vector in each of several different kinds of flight situations (for example, inverted, or with a hard bank and then pull, or during slow flight, and on and on....) The results were pretty unambiguous: use the Velocity World variables I just mentioned. Avoid the Velocity Body variables if possible (I still do not know WHY), and avoid (like the plague) using incidence alpha and incidence beta for a velocity vector. Hopefully this post will not step on anyone's toes (I know a few in here have in the past touted the simplicity of the incidence alpha / beta approach), but the above is what I found. Hope it might help.Scott

Makes me want to run off and make myself a cool HUD, haha.Patrick