Modeldef.xml Code Help Needed

[n4gix 4,947]

Believe it or not, now I'm in need of some XML assistance for an FSX model...I have need of two bits of code to control whether gauge polys use the "lighted material" or the "non-lighted material" depending on the following conditions*: vc_lighted 1) master battery ON and 2) panel lights ON and 3) battery voltage > 22vdc vc_nonlighted 1) master battery OFF - or - 2) panel lights OFF - or - 3) battery voltage <= 22vdc Since there's no example of an OR condition in modeldef.xml I have no prototype to follow, but it occurred to me that I might be able to pass the calculated value from the "vc_lighted" codition to the "vc_unlited" conditional. vc_lighted100 (A:LIGHT PANEL,bool) (A:ELECTRICAL MASTER BATTERY,bool) (A:ELECTRICAL MAIN BUS VOLTAGE, volts) 22 > &&& if{ 1 d (>L:LightsOff,bool) } els{ 0 d (>L:LightsOff,bool) } vc_unlighted100 (L:LightsOff,bool) 0 == if{ 1 } els{ 0 } Is there perhaps a more elegant way that WILL work properly, or what would be the corrected syntax?

[Guest HartmannH]

Bill,are you sure that this works?(A:LIGHT PANEL,bool)(A:ELECTRICAL MASTER BATTERY,bool)(A:ELECTRICAL MAIN BUS VOLTAGE, volts) 22 >&&&In my opinion it should be:(A:LIGHT PANEL,bool)(A:ELECTRICAL MASTER BATTERY,bool) &&(A:ELECTRICAL MAIN BUS VOLTAGE, volts) 22 > &&If you want to use ORs, just use || instead of &&:(A:LIGHT PANEL,bool) !(A:ELECTRICAL MASTER BATTERY,bool) ! ||(A:ELECTRICAL MAIN BUS VOLTAGE, volts) 22 <= ||Same as in C/C++ ;-)

[n4gix 4,947]

No, I'm not at all sure that it would work... I hadn't tried it yet! ;)I suck at XML RPN... *:-* Thanks, I'll give your code a try! :-beerchug

[Guest HartmannH]

I just wrote it down (for fun. It's 11:30pm - too late to work and I'm bored). That should explain how this works.(A:LIGHT PANEL,bool) !(A:ELECTRICAL MASTER BATTERY,bool) ! ||(A:ELECTRICAL MAIN BUS VOLTAGE, volts) 22 <= ||-----------------------------Step 1:(A:LIGHT PANEL, bool) is pushed on the stack. Let's say it's TRUE. Stack after this step:TRUE-----------------------------Step 2: ! (= not) is an unary operator which means that it technically pops the current topmost element from the stack, negates it and pushes it on the stack again. The bottom line is that it simply negates the topmost element ;).Stack after this step:FALSE-----------------------------Step 3:(A:ELECTRICAL MASTER BATTERY, bool) is pushed on the stack. Let it be FALSE for this example.Stack after this step:FALSEFALSE-----------------------------Step 4:! negates the topmost element of the stackStack after this step:TRUEFALSE-----------------------------Step 5:|| (binary OR) ORs the two topmost stack elements and pushes the result back onto the stackStack after this step:TRUE-----------------------------Step 6:(A:ELECTRICAL MAIN BUS VOLTAGE, volts) is pushed on the stack. For example 24 voltsStack after this step:24TRUE-----------------------------Step 7:22 is pushed on the stackStack after this step:2224TRUE-----------------------------Step 8: <= is a binary operator. It pops the two topmost elements from the stack, compares them and pushes the result back on the stack. 24 is greater than 22 so the result is false.Stack after this step:FALSETRUE-----------------------------Step 9:|| again ORs the two topmost elements and pushes the result back on top of the stack.Stack after this step:TRUEand this last TRUE is what goes into your if-clause.BTW: I suck when I have to use words like "on", "onto", "in", "at" and so on. I always seem to use the wrong one ;-)

[n4gix 4,947]

Thanks again, Hans.In case you're wondering why this is important, here is the reason...As you know, in FSX VC gauge backlighting is now limited to strictly pure, bright white or nothing. Also, the backlighting is tied to the panel lights switch.While this isn't a major problem in and of itself, what is important is that the "nightime alternate bitmaps" are tied to both panel lights switch AND battery voltage!This means that if you sit long enough for the battery to drain below 22vdc, the gauge's bitmaps will suddenly switch back to "daytime" set, and the gauge polys remain lighted...This is a very, very UGLY thing to have happen......so, rather that futz around in each gauge's code, the simpler solution is to switch the gauge poly sets between "lighted" and "unlighted" Materials... ;)

[Guest HartmannH]

Yep. A VC lighting has become a true pain in the a.. err.. neck

[Guest EnGauged]

1) Hans' advice looks good to me.2) I don't think you need all of this: (L:LightsOff,bool) 0 == if{ 1 } els{ 0 }Try just using '(L:LightsOff, bool)'Theoretically, if there were a tool for converting "normal notation" (AKA "infix") to RPN... and vice versa... would you be interested? How much would that help?And if there was some error checking so that an alert of some sort were thrown up if you used invalid syntax (e.g. '&&&'), how useful would that be? Just trying to figure out if it might be worth investing time in such tools.-Susan

[n4gix 4,947]

>1) Hans' advice looks good to me.>2) I don't think you need all of this:> (L:LightsOff,bool) 0 ==> if{ 1 } > els{ 0 }>Try just using '(L:LightsOff, bool)'Oh for sure, it's simply a template pattern I've been using since it will work for nearly any expression I can dream up... :)But, note that I'm wanting the inverse of simply (L:LightsOff,bool), so I'd have to use ! (L:LightsOff,bool)... IOW, if (expression) is zero, give me a one...Actually, if || (or) works as expected, then the above isn't needed at all.>Theoretically, if there were a tool for converting "normal>notation" (AKA "infix") to RPN... and vice versa... would you>be interested? How much would that help?>>And if there was some error checking so that an alert of some>sort were thrown up if you used invalid syntax (e.g. '&&&'),>how useful would that be? >>Just trying to figure out if it might be worth investing time>in such tools.Susan, I think that would be a splendid tool. I suspect that you'd likely receive a lot of marriage proposals after release too! Ok, maybe not that, but for sure a lot of Bravo Zulu's!!! :-lol It's curious, but the DTD schema for modeldef.xml is just slightly different than that used with gauge XML...

[n4gix 4,947]

Just a brief note to advise that Han's suggested code works perfectly!Thanks Hans! ;)

[Guest ziporama]

Bill,I was thinking that using a C tag may be even simpler than try to figure out RPN in XML (:)). It seems to me that having a single dll providing all these unique properties and computations is more flexible in the long run for specialty functionality not "in the box". True, the initial framework is arguably more complex than the code above, but adding a new C value is a piece of cake once the base template is in place. Adapting the cabin comfort example doesn't appear that daunting, although I haven't reached that far yet...Etienne

[n4gix 4,947]

Keep in mind that this discussion involves XML code embedded in the .mdl file, not an XML gauge.Granted that a simpler solution would have been to use a custom L:var in the .mdl's XML code, and write the controller code in C++ in one of the gauges in the multi-gauge cluster (such as the electrical panel), but from the stand point of sheer efficiency, I prefer to limit the number of such memory allocations for L:vars to a minimum... ;)