Sign in to follow this  
Guest Ron Freimuth

Variable assignment and initialization

Recommended Posts

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-

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

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

Share this post


Link to post
Share on other sites

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-

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

>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

Share this post


Link to post
Share on other sites

> 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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this