taguilo

J-,Pseudo code would be like> (L:OffOnReset,enum) ++ d 3 != * d> (>L:OffOnReset,enum) 1 == if{ (P:Absolute time, seconds)> (>L:Off1, enum) }"If (L:OffOnReset,enum) is lower than 3, add one to (L:OffOnReset,enum) else assing 0 to (L:OffOnReset,enum)""If (L:OffOnReset,enum) is 1, save (P:Absolute time, seconds) value to (L:Off1, enum)" %ET %((L:ETVar, Seconds) (L:Off1, enum) (P:Absolute>time, seconds) - abs 0 3 (L:OffOnReset,enum) case (>L:ETVar,>seconds) (L:ETVar, hours) int)%!02d!%:%((L:ETVar,minutes) 60 %>int)%!02d!"If (L:OffOnReset,enum) is 0, assign 0 to (L:ETVar, Seconds)""Elseif (L:OffOnReset,enum) is 1, assign the difference between (L:Off1, enum) and (P:Absolute time, seconds) in absolute value (to get rid of minus sign) to (L:ETVar,seconds)""Elseif (L:OffOnReset,enum) is 2, assign (L:ETVar, Seconds) the same value it had on the previous cycle""Make FS automatically convert (L:ETVar, Seconds) to (L:ETVar, Hours) and remove the decimals to prevent roundings." "Make FS automatically convert (L:ETVar, Seconds) to (L:ETVar, minutes) ;obtain the remainder of hours' multiplo and remove the decimals to prevent roundings". "Express all this stuff as ET HH:MM, with leading zeros"This was the best I could do :-)Tom

>So, what's that (A:Sim Disabled,bool) related to?I don't know. I always read it as 0, even when using the PAUSE_TOGGLE event.>I guess one could look at the FS time, and if it isn't>changing, the sim is paused. One could then jump around some>or all code blocks with an if{ block.Yes, I agree with this option. FS time stops when Paused. Interesting is, the WHOLE sim execution stops when a menu is selected.>Since I Strobe my XML calculation blocks, I could change>the Strobe rate dynamically if I wanted to. But, other than>stopping the Strobes when Paused, I don't see much reason to>do that. OTOH, if one is calculating a lot of navigation>trig stuff, then there are probably times the rate can be>decreased. I also use strobes rather than FS time and found the problem that strobes still run when sim is paused. Still didn't make code to handle pauses. That would be one of my next tasks.>And, if XML gauges tend to slow down the FPS or add>pauses, I don't think this applies to XML gauges only but also C/C++ ones. What really eats CPU time and FPS is OUTPUT , everything that is shown on the screen. On a maximixed FS window, CPU percent use nears or is 100 %. When the sim is paused, there is no percetible decrease of CPU usage (maybe 1 % or less) but the memory usange in bytes remains unchanged . This last one seems logic, as there is no sim vars actualization.But, when FS is minimized (no output to screen), CPU usage drops to a 15-17 %, for my 757 with 130 XML custom gauges, to 1 % for the Piper Cub and 45 % for LevelD 767. I think the difference is pure data and structural code actualization, which indeed happens because Lvars still update at their set frequencies .Tom

Jon,Unfortunately, I didin't get the same results as you got regarding the "Hidden" flag.My Lvars still update even with Hidden="No" and 0 ; placed wherever, inside ,,, etc, Actually what I found is:Hidden="No" REDUCES the update frequency of the structures to near a 10 % of its original frequency, when THE GAUGE is not visible (the panel that contains it is hidden)But the code inside the is still executed at its original frequency.For example, for the default frequency of 18 cycles/sec, it seems that it is reduced to a little more than 1 cycle/sec.For a frequency=6 it seems to go down to 0.5 cycle/sec.I did those test some time ago. I think they deserve a new round :-)Tom

Jon,>Right, as Tom said. Also, and this is the killer for me,>there is a definite limit to the number of 'if's one can>perform within an element. I know my code>breaks when I try combining all my> code into a single> block. It will quite literally crash FS9 if>there are too many.>Even though there are only perhaps 10 top-level>"if" structures, the subordinate "if"s>are also somehow contributing to the limit."if{" operators are jumps whithin the stack. It seems reasonable that there should be a limit of its memory pointers, just considering there is only 30 value holders in each FS stack. However, I think much of these "if" jumps could be avoided using boolean math. I try to use as less "if/els" as possible, though have to be honest and say sometimes I can hardly understand my own code!! :-)Tom

Ron,>The gauges continue to run even with FS Paused. At>least, if 'Pause' isn't used in some way to stop execution.Actually nothing stops running when sim is paused EXCEPT that sim vars (A/E/P) are NOT updated. But (L/G) vars indeed are.Every piece of code is still executed, so there is not really a big save in CPU cycles. Tom

Nick, is a tag, like ,, etc. Basically it is a stack holder; it means any kind of operation that uses the stack can be done here. As Jan stated, it brings the same functionality as within an , though the stack is handled slightly different (more details below) It can be placed anywhere in the structureFor example:-At the top of the gauge file after -Between two structures-After a structure-etc.A can contain only one . If more than one is found, only the last one will be considered by FS.It has its own flags: "Frequency"; "Hidden" is well known. is a flag that controls whether data will be updated when the gauge is hidden. operates on its own stack, not shared by Elements and other gauge's structures. It can be a good replacement of data-only elements.Hope this was clear enough. Tom

"b" examples:2 4 5 b = stack is 2 4 5 4 2 4 5 + b = stack is 2 9 5 2 4 + 5 b = stack is 6 5 6 Tom

It is not documented that I know. And BTW I find it rather confusing. I prefer to use other operators like "r" (though not the same meaning), registers (s,l) etc. Tom

>I understand Lvars and their use. What I am looking for is a>syntax which allows me to declare and initialize my LVar>variables upfront.There is no need to declare LVars in XML; they all default to 0 when referenced for first time. >>Some have suggested this sort of approach:>> > > 52(&-gt-;L:Test, number)> > >>This works, but the DTD/XDR that comes with the SDK (which I>am using to validate the gauge and to enable Intellisense when>using VS 2005's XML editor) doesn't like that.Maybe using ">" instead of "&-gt-;" gives the solution.(Note:"&-gt-;" typo ex-profeso for this message) >>Often, a programmer wishes to declare variables at the top of>a source file and I am trying to mimick that. I see many>examples where this works well "in line" but I want to be able>to declare several variables up front.>If you want to do so, at the top of the gauge you may use: 0 (>LVar1,unit) nn (>LVar2,unit) etc etcTom

Hi,What else would you like to know about LVars appart from that described in Nick's tutorials and other posts in this forum?Regards,Tom

"b" is a backspace operator.It jumps the last stack entry and pop the beforelast, but WITHOUT poping (removing) the last. Examples:2 4 5 b = gives 4 and jumps 5 stack 2 4 5 + b = gives 5 and jumps + operator2 4 + 5 b = gives 6 jumps 53 5 b b = gives 5 and jumps the b operator 3 5 b b b = gives 3 and jumps the 54 5 7 b (>LVar1) (>LVar2) now LVar1 equals 5 and LVar2 equals 7 Tom

Hi, Not exactly your code, but this should work (or almost :-))%ET %((L:MyVar, seconds) (G:Var1) (P:ABSOLUTE TIME, seconds) - abs 0 3 (L:OnOffReset,enum) case (>L:MyVar, seconds) (L:MyVar,hours) int)%!02d!%:%((L:MyVar,minutes) 60 % int)%!02d! (L:OnOffReset,enum) ++ d 3 != * d (>L:OnOffReset,enum) 1 == if{ (P:ABSOLUTE TIME, seconds) (>G:Var1) } Starts in reset mode (L:OnOffReset,enum) = 0Then to On mode, begin to sumThen to Off mode, freezes valueThen to reset, back to 00:00TomNote: Beware GVars reset to 0 whenever ALT_ENTER or Panel ReloadsI'd recommend to use a LVar instead

That post was not intended to be a "help to the helper" but instead an observation of the way the compiler treats the source code, and a simple example on how to make FS take benefit of it.:-)Tom

Hi,This use of "case" structure is very efficient when dealing with complex code.Now, just some hints that would help the compiler to optimize the resultant code, and is a hand-coding saver as well:Instead of repeating (L:cchannel,enum) you may save it to a register at the top of the snippet, "(L:cchannel,enum) s0" and the use "l0 1 == ; l0 2 ==" etc to make the comparison. In this case you'll save a lot of typing and make FS access the value a bit faster (registers are accesed faster than var memory areas). The same applies for (L:ctype,enum)Instead of placing @fixradio on each "case" line, you may save the "case" result to a register (ie "case s1 } and then at the end of the snippet call the macro like: ...0 (>L:change,enum) l1 @fixradio } Or use a goto operator, which will avoid to process each line of comparison until the end of the snippet.The point here is, each time the macro is called, the compiler will replace the @macro reference with the code included in the structure, then if you call it 20 times, at run time there will be a lot of code inserted which, in complex projects, may have incidence in the gauge's performance. Tom

>I am dealing with the fact that each line has to be printed on a >different position. X and Y are changing al the time.>Look at it as a list of names that are to be printed on a background>but not on top of each other.If you need 60 XY positions which involves 60 , why not use a single bitmap with the 60 phrases printed on a transparent background? This would be far more efficient, because you're using a single element...Tom

>My first question is: Can these 2 lines be printed using one>element. From what I see in gauges, XML seems to be very>inefficient!>As Jan stated you can use with "Tabs=" flag.I think this thread is more understandable than gps.xml :http://forums.avsim.net/dcboard.php?az=sho...ing_type=search>Second question: These 2 lines would be printed every time,>depending on the update frequency, that could be many times>using resources unnecessarily!Don't worry about resources, it wold be very rare to fall short of them when coding standard gauges. Bear in mind that in fact each line of code is executed every time (depending on freq as you stated).>From what you told me (G:Var1,bool) >would print them only once providing G:Var1,bool would be>False to begin with and made True when printing is done. This> (G:Var1,bool) could be inserted in every>Element and that's it, In my case 60 extra lines!>No, the idea is to use an that would be the "container" and its condition will extend to the nested elements preventing the need to add a flag to each one.For examplexx 1>If is not visible, neither will be Elements 2 and 3>Does this thing followed by >solve that problem? >Not but I just "named" the element to have a better reference of its meaning inside the gauge. I use to name almost all of my elements, because it becomes easier to debug when there are too much of them.>I found this code searching for . Can you tell me >please what does or is supposed to do? is a related flag, the same as . will refresh only those elements defined in the gauge that are positioned within its XY boundary. Maybe a carry from FS2002, not useful that I find it for FS9.In your example code, both Container and Update are placed within an Element; they shoudn't work as expected because as stated above, they are not but flags.Tom

Roelof, tells FS to refresh the code once a second.So, the "container" element and hence its "childs" elements have to be visible as long as (LVAR1) is 0. On the first pass, (LVar1) is 0 so the elements are visible. But at the end of the element you turn (LVAR1) to 1, so in the next cycle will be 0 then the elements will hide. Now, as the refresh freq is one cycle per second, you will see the elements during this time, and in the next cycle, after a second, they will hide.If you remove UpFreq line, you'll see the elements flash and dissapear almost inmediately because the default refresh rate is 18 cycles/second. To keep showing the elements, either do not use the (LVar)/Visible code or update (LVAR) according to other condition.Tom

Roelof,I'm not sure to fully understand the question, but if you need to "print" all those elements in one step, maybe this works: (L:Var1,bool) ! ...601 (>L:Var1,bool)Tom

>The SDK says there are stack operators s0...s49, l0...l49, and>sp0...sp49.These are not stack operators but registers where stack values can be saved. Saving a value to a register (s0,s1...) doesn't remove it from the stack unless you use the "p" operator (sp0,sp1...)>That suggests to me that there are stack would hold 50>values.No, the limit is 30 stack values regardless of the operators.>An expression would have to be very complicated to push 50>values on the stack without popping any. Having said that, I>wait for someone to provide one! Not too complicated, just long!ie: a "case" operator with 27 values (very useful for reading tables)Tom

Sorry I forgot to answer this:> Except from not showing does>it still execute the code or does it skip the code all>together? only affects outputs to FS, ie Image, String, CustomDraws, Polys, etc.If the last stack entry before the is EXACTLY 0, those won't show; ANY other value and those will be visible.The rest of the code in the , ie inside , etc, will be executed no matter its condition; including var and/or events assignments; etc.Tom

>One shouldn't use non bool variables when doing Bool>Logic.I agree, but as he refered to "the 2 last stack entries", I though it was useful to clarify a bit. Values put on the stack are treated as bytes until an operation is made with them, so they initialy "don't understand" of bool, number, etc.>"0" is almost always False, but what value(s) is>recognized as True depends on the convention of the language. Here, any value >= 1 or <= -1 is treated as True, otherwise is treated as False>Using Bool Logic on general variables may give defined>results, but is dangerous. Much better to use only real>Bools for the variables. Agree also. However, as code errors are not easy to debug in XML, sometimes an unpredicted result may appear. That's the reason I think it's worth to know how the stack is interpreted.Tom

>The operator && will check if the 2 last stack>entries are both 1. In FS XML, not exactly :-)&& (or "and") will check that BOTH 2 last stack entries are >= 1 OR <= -1, giving 1 OR 0 otherwise. If you are testing two bool vars, of course the only posibilities are 1 or 0. BUT, what happens when those values are not boolean?ie:2.5 1.1 && gives 10.66 1.34 && gives 0-1.45 3.55 && gives 1-0.45 0.99 && gives 0etc..Is there an operator that will check if both are 0 (zero) ?Not a direct one that I know.The classic would be "Value1 0 == Value2 0 == and"|| ! (OR NOT) as proposed by Ron will work only for boolean values, but it won't if both values are between 1 and -1 Tom

>Tom,>>I wonder if having the Yaw Damper on could have been the>reason? I have it on from pushback to parking. I'm happy with>the way things are now thanks to Ron.>>Cheers,Ray, I think YD must be off on the ground and only enabled when (A:SimOnGround) is 0. It should improve the steering for sure.Tom

>I never set over 35 deg, even though one can't turn tightly, real >Jet Transports only steer by +/- 5 deg or so though the rudder >pedals.It seems weird to me that Ray cannot steer the a/c at t/o roll with NG contact points' turn section of 70. Shouldn't be the other way, the nose to swing abruptly as sharp rudder pedal is applied?In my 757 I use 65 (max nose steer angle), but I programmed a steer tiller that commands the nose that wide, and limit rudder action to +/- 6 deg. At low speeds, I can do tight turns using the tiller (like in the real a/c) but at speeds of more than 50-60 KIAS, I have good rudder control (like the real a/c also) Tom

>Tom, I was wondering if there