Assigning Variables for Use Later

[Guest depot_haldol]

I'd like to assign an (L:Var, bool) at the beginning of a gauge that I can call later in several subsections (hence the utility of assigning a variable).I tried beginning the gauge with this element: (L:Var1, enum) (L:Var2, enum) 2 * + (>L:Storage, enum) I know I'm a beginner, so this must be a stupid mistake. When I try it like this, the gauge fails to display. When I comment this section out completely, the gauge works, so I know there's an error with this snippet. When I add a statement with an tag in the middle, like this: (L:Var1, enum) (L:Var2, enum) 2 * + (>L:Storage, enum) Then the gauge surprisingly works again. I can even check with Doug's helpful xml_id utility that L:Storage gets assigned the correct value, so the first snippet looks like it should be good. The problem is that it only runs when I add that that and part.I'm smart enough to look for an FS9 dtd, and I read the lame dtd that came with the MSFS SDK, but I haven't found anything that explains to me why a Value tag should need Case and Image in order to work.Can anyone help? I'd just like to calculate a few variables at the beginning of the gauge that I can call later on...BTW I got this running with macros, but I really don't need the calculations performed multiple times within the gauge. Just once calculation per running of the gauge is enough. Thanks.---Will

[Guest rkruijer]

Hi Will,>Then the gauge surprisingly works again. I can even check>with Doug's helpful xml_id utility that L:Storage gets>assigned the correct value, Not necessarily. All Vars have the value of ZERO as soon as you introduce them! So the part may be wrong and it will still work.What are the values of (L:Var1, enum) (L:Var2, enum) btw?Try to use number i.s.o. enumDo you know where I can get this Doug's helpful xml_id utility? I would be very pleased if you could point me to it.Roelof

[rcbarend 37]

Hi Will,That's correct.The first section of the gauge code should always contain a bit map assignment, if it is a visisble gauge.So you either start the gauge with an element section, that selects a bitmap based on some condition, or you just start the code withbefore the first element section.With means, that if you do you bitmap selection in e.g. the last element of the code (so all other elements have been processed first), your gauge should start with the above line.And of course it can be "replaced" by the bitmap (if any) assigned in the selection element. Cheers, ROb Barendregt

[taguilo 33]

Will,Actually, when there is no default bitmap in a gauge, or its first element(s) is/are code only, must be placed after in order to the gauge's visible elements to be displayed. Notice that its code is in fact executed (the gauge is "active"), but not visible because it lacks a "container" space where to show the output(s).So the solution goes for either using or assigning a defaul as Rob stated.Tom

[Guest depot_haldol]

Thanks for the useful perspectives. Let me go a little more in depth. My gauge does in fact display seevral bitmaps. Basically, I have a default bitmap that acts as a background, and it has two states: normal if the lights are off and a Bright="Yes" argument if the lights are on.Then there are four buttons, each of which has two bitmaps, based on whether it is receiving electrical power. Finally, there is the section with statements embedded so that pressing the buttons only activates their function if the aircraft has power. Sounds simple, right?The format of the whole gauge looks like this in pseudo-XML: (By the way, this whole part is actually working fine.)First Element:Are the lights turned on?Case Value=1, default bitmap.Case Value=2, default bitmap + Bright="Yes"Second Element: (Display buttion 1)Do the buttons have electrical power and are they pressed?Case Value="0" appropriate bitmap for button 1.etcetcetcThird Element: (Display button 2)Does button Number 2 have electrical power and is it pressed?Case Value="0" appropriate bitmap for button 2.etcetcetcFinally, Mouse Section:If the buttons are powered, make them do their thing.Adjust the tags so that the buttons display properly the next time around.Again, this part works.And as you can see, there are plenty of bitmaps in my gauge. But I am doing the caclulation "Do the buttons have electrical power?" several times and I thought I could make things more elegant if I just did that calculation once at the beginning of the gauge and stored the result as an L:Var for use in subsequent elements. That is where the snippet in my original post came from. The problem is that the INITIAL snippet seems to want a bitmap associated with it. Should I try placing my variable assignment within the first part of the code that has a bitmap? Thanks.---Will

[Guest Vorlin]

Disclaimer: What I'm about to say is not considered to be the right way to do things as far as I know.... but, for some goofy reason, it's the only way I can get some things to work.I was printing a string and was having trouble with it. I was assigning the variable at the top of the file and using it in the string later, as we all know is intelligent way to do it. But it was failing...Until I moved the assignment element *below* the element that used that variable.It makes no sense at all... but it worked. I was having another issue with the same file that was tracked down to the size tag, as someone described above.Will: I think you may have misunderstood them above. It's not a matter of using bitmaps in your file, it's a matter of assigning a single background bitmap that will be used to set the gauge's size or expressly setting a gauge size tag.Try the size tag first... if all else fails, try moving the assignment to the bottom just to see what happens. But I swear, if all other things are correct, the assignment placed above the rest of the script, but below the size or background image tag, should be just fine.Scott / Vorlin

[Guest depot_haldol]

Scott, moving the assignment section to AFTER the variable has been called fixed the problem. Are these gauges read from end to beginning?---Will

[Guest Vorlin]

I don't know. This is one that perplexed me for some time and many of the best here were trying to help me for days. If you didn't already try the size tag, put one in and save the file. Then Cut & paste the assignment code back up top, save it and leave the editor open while you try that.If it works, keep it. If it fails, hit undo a couple times and resave... but I'd keep the size tag if you don't have a main background bmp, it's a good practice that shouldn't be skipped.Sott / Vorlin

[taguilo 33]

Will,This kind of coding should work: (* you may put above the size of the biggest bmp in the gauge *)""I could make things more elegant if I just did that calculation once at the beginning of the gauge"" goes here...rest of the code""Finally, there is the section with statements embedded "" How come? I'd like to know a bit more on how are you using this.:-)Tom

[Guest depot_haldol]

Remember when I said I did have several bitmaps? I just moved the elements that calculate my variables to the spot AFTER the first bitmap and now everything is working. It goes like this:Element1: Draw the first bitmap. If the variable L:Electricity=1, make bright.Element2: Calculate L:Electricity.Element3: Calculate other things.Element4: Calculate still more things.Element5: Calculate even more.Element6: Based on those calculations, choose some bitmaps.Element7: Same as #6 but using different bitmaps....ditto for about 4 more bitmaps ...Element12: Mouse section to allow clicking.So in Elements 2, 3, and 4 I calculate and assign L:vars based on the state of various things in the simulator.Elements 7, 8, 9, 10, and 11 use those L:vars to draw buttons and switches and lights that depend on those variables. If I couldn't calculate and assign all those variables, I would have to repeat the calculations within each of those Elements. Assigning the variables meand I only have to do it once per gauge cycle.Then comes the mouse part, which also uses the variables.So this is up and running and it works fine. I moved the first variable calculation, the one that sets L:Electricity, to the second spot so that the initial element draws a bitmap. The initial Element looks at the state of L:Electricity and is dependent upon it, but the gauge works fine in the order you see above. When the part assigning L:Electricity came BEFORE the first bitmap, the gauge wouldn't work.What I've done is made some buttons that open and close doors on my aircraft. But I wanted the buttons to work only under certain conditions: left main DC bus powered, hydraulics working, engines off, etc. (No engineer would put a pushbutton in the cockpit that would allow you to open a door in flight...) So all that calculation in Elements 2, 3, and 4 is basically the way to define the state of the buttons. Instead of repeating the code for each of the door buttons in the gauge, I asigned the L:Vars and got rid of the need to do the calculations nultiple times.Having these calculations separate also helped, because I keep changing my mind about the proper state for the buttons to work... the result of the calculation part ends up setting a L:bool flagging whether the buttons are "armed" or not. That way, I can change my mind freely about how these buttons are "wired" without mucking in the depths of the gauge at all. So that's what I'm up to.---Will

[taguilo 33]

Will,That's a good approach to a/c system's logic programming. However, I was talking of what you described as structures within section, because AFAIT, they are not supported there but only inside a , which is an substructure . Tom

[Guest depot_haldol]

You're quite right. I started out trying a whole bunch of things that didn't work, likeMouseArea1SelectValue/ValueCase/Case/SelectArea2SelectValue/ValueCase/Case/Select/MouseBut in reality, I ended up using if{ statements for the conditionals, which worked.---WillP.S. Steep XML learning curve, but progressing nicely...