taguilo

Ok then it seems to be a bug in FS's direct conversion from gallons to liters. The simplest way would be to do the conversion by yoursef:(A:ENG1 FUEL FLOW GPH, gallons per hour) (A:ENG2 FUEL FLOW GPH, gallons per hour) + 3.7854 * (>L:TOTAL_FUEL_FLOW, liters per hour)Tom

The baron 58 fuel pph gauge is expresed in gallons/hour. (its tooltip info being wrongly indicated as liter/hour). If you remained sit on the tarmac with the engines running at a fuel flow mark of "4", you were actually consuming a total of near 32 liters/hour. If 8 liters were first loaded, I think that gives you a rough approach to your out of fuel value.Tom

Hi,Did you actually do the flight and run out of fuel after 12 min, or that is the value you measured in (L:TIME,hour) ?Tom

Jordan,I've never had problems like those you report. I've been playing with XML almost for two years, from a start point of not knowing what the heck RPN meaned up to now having a collection of very complex gauges of my own. One of them is a "test gauge" that I've been using to experiment with syntax code, stack's composition and macro's behavior among other things. I use the reload_panels command and the only times I hung the sim were because of events constantly fired, bad handling of stack's loops and improper macro coding.However, I've heard of other people having problems with components, bitmaps positioned wrong inside a gauge, and a bunch more of this type, more related to be graphic issues.Honestly, I find XML gauges to be very stable, much more than some C ones. In fact I own a couple of the most prestigious airliner's addons, and have suffered the "blue screen" drama more than once.Tom

>>A powerful XML gauge emulator would also be a huge boon to>those of us who get tired of restarting the sim 8,000 times to>develop a complex gauge (luckily, simple gauges only take 500>restarts of the sim, lol).In FS2004 you can test and debug an XML gauge while the sim is running. Nothing more easy. No need to restart ever, as CTD and hungs are RARE events to happen because of the way the code is handlend, ie syntax and math errors (like div by 0) are literally ignored and produce no crash effects on the sim.Tom

>XML is a mess, it's useless for procedural and especially OO>use.I cannot disagree more. In fact, I think XML is the future in FS gauge development (though C++ would not be abandoned for obvious reasons). >Almost everyone who tries to turn it into a programming>language has second thoughts after a while.>Precisely its strenght lies on not being like a classic (structured) programming language, and its stack-oriented-assembler-like flow makes it run fast, faster than some people may think.>While for simple things it might do, when you get into the>complicated, advanced stuff, it either becomes incredibly>messy and impossible to maintain.Well, I'd dare to say, for example, that nothing could be a better choice than XML to program an airliner's complex overhead (freeware of course). And I know what I'm talking about.>And even with C++ (which is a very nice language) it's not>just a "privileged few" that would be able to do it.>Anyone with a decently developped brain can learn it>reasonably wellProbably, but, why bother to learn C++ if XML:- It's easier to code - It's easier to test and debug- It's fast- It's very stable (no PC crashes and/or hungs)Unless someone's going to develope a payware project, needs to code vector graphics, sound or file IO, I strongly believe XML is the option.If FS team manages to address some of these weakness, they would make a lot of people very happy for sure! And, if ever they (or someone else) finally find a way to protect XML cabs, most payware groups would begin to smile as well...Just my thoughts.Tom

Bill,As as humble suggestion, why don't you use a "case" operator to simplify the code and get rid of all those "if{" structures?Man, I hate nested "if{"s (though that is MY problem and not anyone's else :-) )TomEDIT: Deep looking through your code, it seems could be even more simple: (VarValue) ++ 3 min (>VarValue) for up and (Varvalue) -- 0 max (>VarValue) for down...

Hi,>What I call copilot gauge is actually a bunch of xml gauges>that triggers proper >"comments" (maybe I'll also add actions thru K: events) as per>SOP's for a certain type of aircraft thru various A:vars. Use your own L:Vars to trigger the "comments" instead of FS A:Vars.For example, if you want the copilot say "parking brake set" when you actually set it via a keyboard/mouse/joystick command, use something like this:(L:Parking Brake set, bool) if{ *SOUND CALL* }Then, to update the Lvar value, inside something like:(A:Brake parking position, percent) 50 < (>L:Parking Brake set, bool)Hope this helpsTomEDIT: even would be better to make the call directly inside the event, like (A:Brake parking position, percent) 50 < if{ *SOUND CALL* }, avoiding the first and the need of a second var to prevent continuous calls.

>Just for the record, the problem was this:> (L:L:Wiper,enum)... True, (L:L:Wiper,enum) won't work, as (L:Wiper,enum ) won't either.BUT, (L:Wiper, enum) or ( L:Wiper,enum) or ( L:Wiper, enum) will.Amazing XML by the FS team... Tom

Well, you might try: (L:SetHeading, radians)( discarded)If this doesn't work, you should review the code for a "hidden" typo, a bad def, or anything else I can't spot on at first sight.Tom

Hi,"deg" is not a valid unit; should be "degrees". Something like: (L:SetHeading, degrees) 1 - dnor (>L:SetHeading, degrees) (L:SetHeading, degrees) 1 + dnor (>L:SetHeading, degrees) and (L:SetHeading, degrees) etc..Tom

Glenn,At first sight and assuming (L:LightA, number) initializes with 0, on the first click, MemA takes the value of SetValue; therefore SetValue has to be defined elsewhere in the code BEFORE, so in that part SetValue will take its value every cycle, overwriting the value transfered from MemA inside the ...Just a guess.Tom

Well, a bit of expanded information would be great, however:-If crashes are occasional, it is possible that they happen for a given conditon. Maybe a corrupted bmp is called then, so replacing all "conditional" bmps with a known-good bmp could help to find the problem.-Are nested macros used? Could be that in some case they are called recursively, starving resources. Other thing to consider is whether "goto" operator (g0,g1,etc) is used, it is done properly.-Is there any call to a C gauge inside your gauge? (like DDawson's Sound Gauge).I've never got a blue screen or fatal crash of FS with my gauges, though I did get hungs because of bad macro coding. Hope this helps.Tom

>I'd love to, but it's finding time at the moment. I'm working>on 3 panels at the moment for a certain development group. We>could do with a good tutorial regarding the use of macros,>modulus and an understanding of stack manipulation and how it>works, and the use of operators like 'd', 'r', etc. Do you>fancy putting pen to paper? Be nice to have a tutorial on>formatted text as well, but that's another story.>cheers,>nickI can't promise anything so far, though I'll try to sketch something.Tom

>Thank you Tom, you have been most helpful in this entire>matter, and I've learnt a great deal.>cheers for now,>nickWas my pleasure Nick. Have you thought of making another wonderful tutorial like those you made before, from all this gathered info? Tom

>Yes. Happy to report it worked.>Good news!>>l3 10 % s4 8 >= l4 8 - 2 / * l3 10 / flr +>and l3 coming from a previous line,> (A:Airspeed select indicated or true, knots) s3 10 %>>This looks more lean to me.>Even better news. There's always something more to pull from the bag when you put your creativity to work.:-)>Before,> (A:Airspeed select indicated or true,>knots) 10 / flr 10 * > >%(@E1IAS 30 +)%!3d!n%(@E1IAS 20 +)%!3d!n%(@E1IAS 10 +> )%!3d!n%(@E1IAS)%!3d!n%(@E1IAS 10 - 0 max)%!3d!n%(@E1IAS 20>- 0 max)%!3d!>>Now,>%((A:Airspeed select indicated or true, knots) d 10 / flr 10 *>s0)%( l0 30 + )%!3d!n%( l0 20 + )%!3d!n%( l0 10 + )%!3d!n%(>l0 )%!3d!n%( l0 10 - 0 max )%!3d!n%( l0 20 - 0 max )%!3d!>>and I use l0 in subsequent lines.>Are macros handled in a different way to plain code which give>advantages?The second option is for sure more efficient. In the first, the compiler is pasting the macro code into the stack each time it is referenced.Macros should tend to be used: 1-As fine constants, (see GPSNN.XML) easier to reference than the original var.2-Whenever there is a repetitive code in a gauge, in different elements, and it is a complex source. (Ie when handling polinomies, extracting data from tables, etc)Using macros gives no advantage in performance than not using them, its only a code saving aid to the programmer, and sometimes an easier path to undertand what the code means. >>BTW, with l3 10 % s4 8 >= l4 8 - 2 / * l3 10 / flr>+>Is there a way to rid of s4 and l4. The stack would have a 1> (or zero) after >= and the required value for 8 - before >=,>that is,>x >= 1(0)>Therefore 1(0) is on top of the stack and x the next value>down. I have tried reversing, duplicating/reversing but to no>avail.>Duplicating/reversing should work:l3 10 % d 8 >= r 8 - 2 / * l3 10 / flr +Tom

>Hi Tom, now that is VERY interesting,>many thanks,>nickYou can save a lot of "if{ els{" by using bool maths. The * factor gives 0/1 which is stored on the stack like any other value, maybe a float64 (as of Ron's tests); Any bool Lvar or bool value is placed with the same float structure, so there is no difference of using bools or * factor values. BUT, if{ els{ are stack's jumps, which have to consume extra cycles. Even there seems to be a limit of nested if{ as Jon did find in his test. The cost of using bool maths? less readability for sure. But, hey, maybe I'm going too far here..:-)Tom

>Hi Tom, something else that's interesting,>> @E1IASDigit(x,x) s3 8 >= is saying, when @E1IASDigit(x,x) is>equal to or greater than 8, do l3 8 - 2 / *. How does this>manage to do away with any 'if{ }' statements?>cheers,>nickI am using "bool maths" here. You know that any time "s3" is < 8 a 0 is placed on the stack, else is placed a 1. So, what I do is multiply the result of "l3 8 - 2 /" by that "stack factor" of 0/1 and add it to the macro's return. When s3 < 8 I add nothing (0).A way to do with if{ structure would be@E1IASDigit(x,x) s3 8 >= if{ l3 8 - 2 / } els{ 0 } Tom

Nick,How about @E1IASDigit(1,1) l9 d int % + s3 8 >= l3 8 - 2 / * @E1IASDigit(1,2) + Note: l9 is coming from s9 used in the macro. Test it and let me know :-)CheersTom

Nick,I'll let you solve this by yourself :-)BUT, with a little hint:@E1IASDigit(1,1) s3 8 >= l3 8 - 2 / * @E1IASDigit(1,2)@E1IASDigit(1,1) reaches 8 and then?..goes to 9 directly and then to 0 again..No "fractionals" to help the rolling.When @E1IASDigit(1,1) is 8, @E1IASDigit(1,2) returns, say, 5 Then @E1IASDigit(1,1) goes to 9 so "s3 8 >= l3 8 - 2 / *" gives 0.5and @E1IASDigit(1,2) returns 5.5 ...etcGood luck! Tom

>I take it S0 remains in the register until overwritten. What>is the significance of 'popping' the value. Why do this, and>if 'popped' off the stack how would , say, l0 get the value of>sp0?>"sp0" first saves the value to register 0 then removes ("pops") it from the stack so it would not interfere with any further operation.But it can still be recalled with "l0".As an example, just take a look at my "rolling numbers" macro:(A:Indicated Altitude, feet) sp0 l0 int 10 @2 pow % 10 @2 1 - @1 1 - - 0 max pow / intI use this to call the macro: @AltDigit(4,4) s1 9980 >=l1 100 % 80 - 20 / * @AltDigit(1,5) +Now, if ever I use (A:Indicated Altitude, feet) s0 instead of (A:Indicated Altitude, feet) sp0 The result will be quite different! CheersTom

>>Also, just a quick comment on macros, and something that Tom>has said before on another subject; macros won't necessarily>make your code more efficient in terms of processing power.>They'll make it much easier to manage and read, but everything>within a macro is being iterated over as if its contents were>expanded. You have to keep in mind that a macro is not like>storing something in a variable or a register, it's going to>be executed over and over again.This is absolutely right.>>But if you take (A:RELATIVE WIND VELOCITY BODY X, m/s)>(A:RELATIVE WIND VELOCITY BODY Z, m/s) atg2 s0>>You can use l0 to reference that again and again throughout>your subsequent code without the actual (expensive)>calculation being carried out multiple times every pass.>>>--JonThis is right as well. The code that I posted on that thread was just an example, indeed not the most efficient.Using registers (s0..etc) like Jon does here is the best recommended.However, managing registers' values across the entire gauge needs to be done carefully. For example, as registers are a component of the stack, clearing the stack with a "c" operator also resets all registers to 0. Just a word of caution :-)Tom

Nick,The 50 registers (s0-s49) are valid for the ENTIRE gauge. You can save a value (ie s0) in any part of a gauge -in , ,,, etc- and retrieve it in another (as l0).Any time you save to "s0" you're actually overwriting its content, so two things to consider here:1-It does no harm to use the same register as may times as you wish2-As a consequence of this, you have to be carefull when using the same register in multiple single/nested macros, because you may end up losing data "unawarely".TomNote: remember "s" doesn't remove the saved value from the stack. You must use "sp" instead, and this is also especially important when dealing with complex macros.

>Tom,>>Thanks. Maybe I'm stupid, but I don't see any if else structure in >that code - neither do I see the ? operator>>>Click> (L:OffOnReset,enum) ++ d 3 != * d> (>L:OffOnReset,enum) 1 == if{ (P:Absolute time, seconds)> (>L:Off1, enum) }I used "if/elseif" as pseudo code to make things more understandable. Here bool maths ("3 != *") are replacing "if{" structures.A more "standard" XML phrase would be: (L:OffOnReset,enum) 1 + s0 3 < if{ l0 } els{ 0 } (>L:OffOnReset,enum) (L:OffOnReset,enum) 1 == if{ (P:Absolute time, seconds) (>L:Off1, enum) }TomEdit: In the section I used "case" operator, that searchs for a "passed" value among three stack values. Something likeSelect case a case a = 0 case a = 1 case a = 2End selectAgain, the "if/elseif" was mere pseudo code

Jon,>Interesting. I wonder if Update Hidden has a different effect in >the absence if an block. "Hidden" is a flag. I've found no different effect when usingor code>For example I plot lots of symbology in HSI and radar pages, and >even if there was a slowdown it would certainly be noticeable > (particularly if it was 90%!). I still get smooth rotations and >displayed variables are updating just as they had before.Maybe I've done a different test. You could try this:-In a gauge that is placed on a subpanel which can be displayed/hidden (Like the GPS), add an structure. -Then, add an (L:VarTest,enum) ++ (>L:VarTest,enum)-In a gauge placed on the main fs panel (always visible), add a test string like %(L:VarTest,enum)%!5.3f!-Then toggle the subpanel display and see how it affects the update's rate of the Lvar.-Change in the subpanel's gauge with (L:VarTest,enum) ++ (>L:VarTest,enum)-Then remove the that refered to (L:VarTest,enum) previously.-Then toggle the subpanel display and see the difference.>I guess the next step is to place a filter in a block and see what >the frequency is.I'd be glad to know the result of your tests :-)Tom