Well, of course, it moves in steps. It is a discontinuous simulation of a continous variable. Well, actually, according to quantum mechanics everything is discontinuous! =)Anyway, the code I gave you works, and I'm not sure what you are thinking is wrong. Perhaps you have a problem in your non-linearity table. =)Good luck.

Just a small note... regarding the last value in the MAKE_NEEDLE macro... it should not always be a value other than 0. Here's why, it's definition:"Determines the refresh rate for the macro. Gauges are refreshed 18 times per second, so a value of 0 means update every cycle; a value of 6 means update every third of a second. You trade off gauge display quality versus frame rate

Great in theory, but in fact, it works perfectly fine and the needle moves smoothly and accurately. There is no need to update stuff at 18 Hz. In fact, you will get better performance from a panel that has maintained control of how fast things update vs. trying to let them all update at 18 Hz. :DOne always has to rememeber the difference between statistical and clinical effectiveness. :D

>As stated above, MODULE_VAR_NONE should only be used when>there is no FS var for what you are after, or you really want>to ignore it. In your case it should be AIRSPEED. Also, you>don't need the BIT7, and the final 0 could really be like 6,>but zero is fine.Patrick, do you even know what the "BIT7 IMAGE_FLAG" is used for?If you don't I won't be surprised since it's not documented in the SDK...However, from Dai's excellent tutorial:"In addition there is one undocumented flag and another use for one of the documented ones. Each of them are in the gauges.h file but neither has an explanation anywhere."BIT7: Using this flag anti-aliases needles and sprites i.e it smooths the edges of the bitmaps.The #define is for IMAGE_BILINEAR_COLOR which provides a clue......the new flag name replaces the old one, IMAGE_ANTI_ALIAS which is certainly more descriptive! ;)Here is a comparison showing what happens when BIT7 image flag is omitted:http://forums.avsim.net/user_files/184586.jpgBTW, the other "undocumented image flag" is BIT15, but you can read Dia's tutorial if you want further details on when/how it may be used to good advantage... ;)

>Great in theory, but in fact, it works perfectly fine and the>needle moves smoothly and accurately. There is no need to>update stuff at 18 Hz. In fact, you will get better>performance from a panel that has maintained control of how>fast things update vs. trying to let them all update at 18 Hz.> :D>>One always has to rememeber the difference between statistical>and clinical effectiveness. :D>>>Well, I don't want my ILS needles updating 1 or 2 times per second. The granularity of such a display would make tracking the ILS at jet speeds extremely difficult.Like I said... primary instrument needles need to be updated as often as it can be done.

Yes, but if you start with good artwork, then you don't need to make the computer do extra work. :)I guess if you have a really kick-a** computer, but then I like using every available frame for flight.

I agree with you Ed but... when I look at the actual number of times for instance the AIRSPEED value is updated in FSX then you don't get anywhere near 18x/second. But rather close to 4-5 imes per second at best. My LLZ and GS needles don't move smooth at all but rather in steps which makes them very unrealistic.Then there is another problem apparently, I get the impression that needles, sliders and in fact all MACRO elements seem to have a rather crude resolution. What I'm mean is that a needle will only turn once a minimum delta angle is reached. For a GA aircraft that flies at low speed and where the whole dial may only cover 160 knots this will not be that visible (although it is visible once you start looking at it). But for jet aircraft with their non-linear speed dials for instance, once you fly at say 280-290 knots the needle will only move every extra 1 knot in speed change or even in larger steps.It tried something very simple, in stead of sending the AIRSPEED to my ASI needle, I just send a float value that is increasing by 0.2 every tick. When you look at the needle though you will notice a complete lack of smoothness ! In stead of elegantly moving over the ASI dial the needle will still move in discreet and visible steps !Maybe you guys don't have this problem and if so, then I would be really intersted to know why that is, but I see it in all but a few panels. So somebody must have figured out how to avoid this, I certainly haven't...Bj

I thought about this more, and I think I'm not seeing it for a couple reasons. a) I fly low and slow, esp. in helos. :( I only get 15 fps anyway c) I use the smoothing provided by the degrees per sec parameter.As far as I know, the ultra smooth gauges you see are indeed not done with the macros, but I just have never run into that limitation and have always stayed within the SDK whenever possible.I have also done GDI+, but found that it was overkill in most cases. Was useful for a CDU, and things like that, but for standard instruments I use the macros.If you aren't getting the higher resolution of data from FS, having an ultra accurate gauge won't help, which is why it is easier to use the MS approach and "fake" it. =)Yes, for an ILS I'd go for 18 Hz too. =)Just my two cents.Patrick

Patrick,What do you mean by the "degrees per second parameter" ?Bj

>Patrick,>>What do you mean by the "degrees per second parameter" ?>>Bj

I use GDI+ instead of the SDK-Makros (for glass-cockpit displays) but i'm also still in trouble with the IAS-Value from FSX. At higher Airspeeds (maybe > 280kt) the Value begins to "stutter". Also, if i set Thrust to Idle and IAS decreases it seems FSX "rounds" the IAS every second. Especially for GDI+ this is inacceptable.But the most famous thing i think is: if you use TAS instead of IAS from FSX the Values from FSX are very smooth, absolutely no stutters on the Gauge. Also, you can try any Unit for IAS, the stutters remain.Found an formula to calculate IAS by myself on this site:http://williams.best.vwh.net/avform.htm#Intro. I've tried it but no chance, the stutters will remain. Is eventually the "MACH" Value from FSX the Problem?For Information i post my Code here. Try it if you want and you will see that only "AIRSPPED TRUE" works very well.Btw.: using "lookup_var" instead of "execute_calculator_code" alsohas absolutely no effect.Is there any Formula out there to calculate IAS from TAS given? Maybe this will be a positive Solution.FLOAT64 Adiru::Airspeed() const{ //x=(1-6.8755856e-6*PA)^5.2558797 //ias=661.4786*(5*((1 + x*((1 + M^2/5)^3.5 - 1))^(2/7.) - 1))^0.5 FLOAT64 M; execute_calculator_code("(A:AIRSPEED MACH, Mach)",&M,NULL,NULL); FLOAT64 PA = 0; execute_calculator_code("(A:PRESSURE ALTITUDE, feet)",&PA,NULL,NULL); FLOAT64 x = pow(1-6.8755856e-6*PA,5.2558797); FLOAT64 ias = 661.4786*pow(5*(pow(1 + x*(pow(1 + M*M/5.0,3.5) - 1),2/7.0)-1),0.5); return ias; //FLOAT64 val; //{ // execute_calculator_code("(A:AIRSPEED INDICATED, knots)",&val,NULL,NULL); // execute_calculator_code("(A:AIRSPEED TRUE, knots)",&val,NULL,NULL); //} //return val;}Kind Regards

Hi,Those "stutters" for IAS values are perfectly normal. IAS is a direct reading of airspeed through static ports' system of an aircraft, hence it is affected by macro/micro pressure changes. Both CAS/TAS are of course more stable because they are calculated values from IAS that include aircraft's specific calibration and correction formulas. Real analog airpseed gauges have a delay in their needles' movement that smooth their reading to avoid abrupt changes, especially when dealing with turbulent conditions. However, on those who have rolling numbers for IAS, it is noticeable how much they stutter at high altitudes even on level flight.I guess that you could put a tiny delay in your GDI+ needle if you don't like the stuttering effect.TomPS: I would prefer to use lookup instead of execute_calculator for reading AVar values in standard C gauges (.gau), because of the extra process that means going through the script parsing system.

That's exactly what I was saying on this same thread a few moons ago ! I did notice however that when you put the IAS value into a string element, the updating goes much faster ! Very strange indeed.You could try to add a string element that reads the IAS value, put that value into a variable that you then use in your GDI+ gauge. Maybe that works better ? I also used MACH value because it was suggested I think by Lefteris, but the same thing happens. Bj

Tom,>Both CAS/TAS are of course more stable because they are calculated >values from IAS that include aircraft's specific calibration and >correction formulas.If CAS/TAS are calculated IAS giben, how can they be more stable if IAS is changing in so big Steps?Bjoern,i've tried your idea, but it takes no effect:FLOAT64 FSAPI airspeed_value_cb( PELEMENT_STRING pelement ){ FLOAT64 val; val = pelement->source_var[0].var_value.n; iasValue = val; return val;}MAKE_STRING(ias_value, (PPELEMENT_HEADER)&pfd_list2, NULL, IMAGE_USE_ERASE | IMAGE_USE_BRIGHT | IMAGE_USE_TRANSPARENCY, 0, 7, 8, 185, 38, 8, //ELEVATOR_TRIM, AIRSPEED, MODULE_VAR_NONE, MODULE_VAR_NONE, RGB(189, 9, 18), RGB(0, 0, 0), RGB(189, 30, 50), "Arial", FW_NORMAL, DEFAULT_CHARSET, 0, DT_RIGHT | DT_VCENTER | DT_SINGLELINE, 0, airspeed_value_cb )PELEMENT_HEADER pfd_list1[] ={ &ias_value.header, NULL};"iasValue" is used as a function-call parameter for the GDI+ code:FLOAT64 iasValue;myPfdDisplay.DrawASI(graphics_asi, iasValue);the GDI+ Transformation Code:double aspeed = 30; if(iasValue > 30) { aspeed = iasValue; // /aspeed = adiru.Airspeed(); } long int spd = (long int)aspeed; double ias = aspeed; graphics.TranslateTransform(0.0f,(ias-(int)ias)*20.0);Today i've made a liitle Video to show you what's the Problem. If you want you can Download it here: http://www.megaupload.com/de/?d=KS50MX46Look at the ASI and you will see whati mean with "stutter".To compare i've done that also with "AIRSPEED TRUE" instead of "AIRSPEED INDICATED". You will see tthat there are much less "stutters".http://www.megaupload.com/de/?d=G0CWSYJ6Both Videos are captured at 30fps, after encoding it to *.wmv it will play with 25fps. You can see in FS-Window, fps still stays at 30fps.Kind Regards

Sven,I was not able to solve this problem either I'm afraid. Apparently some people have (I've seen demos) but they are not willing to share their knowledge so...Now looking at the video it looks like the indicator is moving pretty smoothly to me, except that tick every second or so. Note that this tick always happens at almost exactly the same interval so I'm wondering if there may be something in your code that causes this to happen ? This hanging every second or so is visible almost right from the start. Focus on the external view on you'll see the outside image has the same thing happening.The airspeed "switching" back frequently is something I have not seen in the past so I may be worth while checking your code to see if you don't do something really demanding to the CPU every 18 ticks.Bj