Variable assignment and initialization

[ahuimanu 50]

Hello,In doing a search I found the following topic very helpful:http://forums.avsim.net/dcboard.php?az=sho...ing_type=searchHowever, the .xdr and .dtd that comes with the FS2004 SDK does not allow this. Is there some conforming way to initialize variables?The Pike tutorial at FS2X.com is fairly instructive, but doesn't really go far enough. Arne Bartel's 2002 XML gauge document is useful, but mainly focuses on RPN (God I wish MS would use infix) and not on how to make and use L Vars.Thanks,J-

[taguilo 33]

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

[ahuimanu 50]

Hi 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.Some have suggested this sort of approach: 52(>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.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.J-

[taguilo 33]

>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

[nickpike 0]

Hi Tom, could you explain a little further please? Is it just a shorter form of code to assign fresh values to the variables?cheers,nick

[phjvh 0]

Nick,I use codeInstead of codeJan"Beatus ille qui procul negotiis..."

[n4gix 4,947]

AFAIK, it seems to be MORE that simply a place to set up the various variable's initial values, because it's clear from the G500 code example that the section is read each cycle.There's "dynamic code" in the section of the G500.

[taguilo 33]

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

[Varmint007 2]

Tom,Thanks for that explaination. I'm curious about ; Does that determine how other Element's tags are interpreted? For example, it's known that the condition controls the DISPLAY of data, but doesn't prevent calculations from taking place despite the being hidden. Does prevent that?Thanks,--Jon

[Guest Ron Freimuth]

>Tom,>>Thanks for that explaination. I'm curious about >; I had tried around blocks and found I could only have one block.>Does that determine how other Element's tags are>interpreted? For example, it's known that the >condition controls the DISPLAY of data, but doesn't prevent>calculations from taking place despite the being>hidden. Does prevent that?>--Jon I think I know how to see how much CPU is used by gauges. C or XML. I noted that if I Pause FS9 and minimize the window, the Windows Task Monitor may still show a high load for FS9. The gauges continue to run even with FS Paused. At least, if 'Pause' isn't used in some way to stop execution. "(A:Sim Disabled,bool)" didn't appear to be equivalent to "Pause". It would certainly be useful if currently invisible displays didn't take all that CPU power. I expect the visual parts don't load the CPU when not seen, but the other coding does. Ron

[Varmint007 2]

> I had tried around >blocks and found I could only have one >block.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.> I think I know how to see how much CPU is used by gauges. >C or XML. I noted that if I Pause FS9 and minimize the>window, the Windows Task Monitor may still show a high load>for FS9. The gauges continue to run even with FS Paused. At>least, if 'Pause' isn't used in some way to stop execution.>> "(A:Sim Disabled,bool)" didn't appear to be equivalent to>"Pause". Pausing the sim does have an effect on frame rates - they go up, but not nearly as much as they should, considering the sim is PAUSED!> It would certainly be useful if currently invisible>displays didn't take all that CPU power. I expect the visual>parts don't load the CPU when not seen, but the other coding>does. Indeed, and that's why I'm interested in what is doing. Right now I store the condition in a register which I check later in the structure to prevent calculations from taking place: For example:(L:Condition, bool) (L:Condition2, bool) and s0l0 if{ a bunch of trig }Since there is generally a lot of trig in many of my elements, I find it prudent to check the condition of prior to making the calculations. This wouldn't be necessary if simply worked correctly in the first place. I could be wrong, but I can't come up with any reason why it would be beneficial to execute calculations in an invisible block!The down side of doing all those checks, is they too use CPU. If you've got several hundred blocks, they add up. --Jon

[Varmint007 2]

OK just to answer my own question, I've confirmed that Update Hidden="No" does in fact prevent calculations from being carried out behind tags! Good news! I am seeing large improvements in performance, and it will go up even more once I remove all my visibility check cludges.EX:1 With (or omitted), Test Var gets set to 1 despite being set to 0.0pseudo...%(1 (>L:Test Var, enum)Test Var = 1EX:2 With , and Test Var set to 5 Test Var remains 1 with still set to 0.0pseudo...%(5 (>L:Test Var, enum)Test Var = 1EX:3 With set back to "Yes", Test Var gets set to 5, proving that 0pseudo...%(5 (>L:Test Var, enum)Test Var = 5--Jon

[taguilo 33]

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

[taguilo 33]

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

[taguilo 33]

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