FS2004 Incrementing var values

[vololiberista]

I'm fast coming to the conclusion that it can't be done :-((
I'm surprised that this issue has never come up before. Even the single example in the wiki is for mouse clicks. I have to say it's a serious omission on the part of xml.
vololiberista

 

[vololiberista]

I think you are still missing the point I made in Post #15. XML code is handled differently to VB or C. It's run in a loop by FS and the XML gauges are updated (that is called and executed) at regular intervals. By default this rate is 16Hz although it can be changed by including <Update Frequency=n/>

If you included code like if a=true then add y to x until x=z then the first time the gauge is called the loop would run to completion and set x=z immediately.

Yes, but it doesn't do that!!! It increments once only. in effect it is simply adding two values together and stopping.

(A:FUEL TANK CENTER2 QUANTITY, gallons) 3.4231 * (>L:FUEL TANK CENTER2 QUANTITY, number) sets the minimum value of the tank i.e. 56.19 kilos.
(L:FLD_Rate,number) (L:FLD_Conv,number) * near 60 / 18 / (>L:C2_uplift rate,number) sets the uplift rate taking 18 times a second into account. Resulting in 1.48.

Every incremental permutation I have tried including those of the hallowed gurus here result in a single addition only, equalling 57.67. Which is 56.19+1.48 then stop. In other words its adding and not incrementing!
If I do " * ++ " It's effectively doing the increment 18 times giving a result of 87 ish I cannot get beyond this. I cannot see where or why it stops dead. It shouldn't. As long as the switch (flag) is set it should run and run. As you say it loops so each time it revisits the gauge it should add a bit more etc. It doesn't. If XML can't do [if a=true then add y to x until x=z or a=not true] then I can't see a solution to my problem.
vololiberista

 

[taguilo]

I think you are still missing the point I made in Post #15. XML code is handled differently to VB or C. It's run in a loop by FS and the XML gauges are updated (that is called and executed) at regular intervals. By default this rate is 16Hz although it can be changed by including <Update Frequency=n/>

Actually not much different. An <Update> script is in fact a C++ gauge_callback equivalent, an <Element> script is like a C++ macro function and so on. Bear in mind XML code as we write it does not exists at runtime, it has been parsed and translated into FS memory to C++ equivalent "macros", classes and functions. Efficience won't be the same as in compiled C++ code, obviously, but for most of the projects will be more that satisfactory.

If you included code like if a=true then add y to x until x=z then the first time the gauge is called the loop would run to completion and set x=z immediately.

A loop in XML is not normally coded as in C++ (except for the goLabel :label operators), but instead using control variables:

a=true and x<>z
if{ x = x + y }

Tom

 

[taguilo]

Yes, but it doesn't do that!!! It increments once only. in effect it is simply adding two values together and stopping.

That's what you believe it is doing.
I notice that you still miss some XML important concepts...

(A:FUEL TANK CENTER2 QUANTITY, gallons) 3.4231 * (>L:FUEL TANK CENTER2 QUANTITY, number) sets the minimum value of the tank i.e. 56.19 kilos.

Yes, and it sets that value on every gauge cycle.

Every incremental permutation I have tried including those of the hallowed gurus here result in a single addition only, equalling 57.67. Which is 56.19+1.48 then stop

Of course, because you are setting the minimum value of the tank i.e. 56.19 kilos. at the beggining of every cycle!

It's quite evident it is not an XML flaw but a misconcept on how it works

Tom

 

[vololiberista]

Tom,
I was suspicious as to why (L:ct2_min,bool) 0 == didn't reset to 1 after defining the minimum tank quantity so I rewrote that bit as

<Value>(L:ct2_min,bool) 0 == if{ (A:FUEL TANK CENTER2 QUANTITY, gallons) 3.4231 * (>L:FUEL TANK CENTER2 QUANTITY, number) (A:FUEL TANK CENTER2 CAPACITY,gallon) 3.4231 * (>L:FUEL TANK CENTER2 CAPACITY, number) 1 (>L:ct2_min,bool) }</Value>

Now it resets to 1 therefore as you suggested (L:FUEL TANK CENTER2 QUANTITY, number) doesn't now reset itself each pass. I also played with the other element which now appears to work!!!!

<Value>(L:FLD_Control,bool) 1 == if{ (L:FUEL TANK CENTER2 QUANTITY, number) (L:C2_uplift rate,number) + (>L:FUEL TANK CENTER2 QUANTITY, number) ++ }</Value>

So now I can put in the other control variables for the other functions.
Talk about not seeing the wood for the trees!!
vololiberista

 

[mgh]

Actually not much different. An <Update> script is in fact a C++ gauge_callback equivalent, an <Element> script is like a C++ macro function and so on. Bear in mind XML code as we write it does not exists at runtime, it has been parsed and translated into FS memory to C++ equivalent "macros", classes and functions. Efficience won't be the same as in compiled C++ code, obviously, but for most of the projects will be more that satisfactory.

The difference is that XML code is run in an FSX loop and is not free-standing. An analogy would to regard the XML code as a C function which FSX call every gauge cycle. All the XML code is repetitively executed every cycle. That's at 16Hz by default or about every 62 millisec. Also, I don't believe XML is converted into C. There's no reason for in because XML is more readily converted to machine code than C so it would be a retrograde step.

A loop in XML is not normally coded as in C++ (except for the goLabel :label operators), but instead using control variables:

a=true and x<>z
if{ x = x + y }

But that doesn't loop when it's it's called. If the conditions are met it will execute x = x + y once each gauge cycle and is equivalent to my pseudo-code in Post #15 and will result in x becoming equal to z over several cvcles

 

[n4gix]

I'm fast coming to the conclusion that it can't be done :-((
I'm surprised that this issue has never come up before. Even the single example in the wiki is for mouse clicks. I have to say it's a serious omission on the part of xml.
vololiberista

The Wiki example was intended to be used in a mouse routine.

A very simple example of a counter outside of a mouse routine would be:

<Update Hidden="Yes">
     (L:MyCounter,enum) 100 &lt;
     if{ 
          (L:MyCounter,enum) ++ (>L:MyCounter,enum)
       }
</Update>

 

[taguilo]

Talk about not seeing the wood for the trees!!

Yep, and hope you now understand me when I asked you to show here the wood -or at least a part of it-, especially when the trees affect important concepts in the way the code works.
And btw, the red part has no meaning in the sentence, you should remove it to avoid more confusions:

<Value>(L:FLD_Control,bool) 1 == if{ (L:FUEL TANK CENTER2 QUANTITY, number) (L:C2_uplift rate,number) + (>L:FUEL TANK CENTER2 QUANTITY, number) ++ }</Value>

Tom

 

[taguilo]

The difference is that XML code is run in an FSX loop and is not free-standing. An analogy would to regard the XML code as a C function which FSX call every gauge cycle. All the XML code is repetitively executed every cycle. That's at 16Hz by default or about every 62 millisec. Also, I don't believe XML is converted into C. There's no reason for in because XML is more readily converted to machine code than C so it would be a retrograde step.

The complete panelset runs in a loop; gauges are processed sequentially with no discern of being C++ or XML coded (with some few exceptions and zorder defines). And your analogy is not quite exact, it is not like a single C function.
But I guess discussing the details here will be outside of the thread's subject, so let's leave it for a proper moment.

But that doesn't loop when it's it's called. If the conditions are met it will execute x = x + y once each gauge cycle and is equivalent to my pseudo-code in Post #15 and will result in x becoming equal to z over several cvcles

Yes, of course. I only pointed that out to reinforce the concept.

Tom

 

[rpmc]

Bob,
Unfortunately your updates do exactly the same as Tom's suggestion above in that they increment the var only once!

So it would appear that XML cannot increment continously unless you use

<Click Repeat="Yes"> which is incorrect in this instance and quite impracticable.

vololiberista

Tom and mgh have already discussed it in more length, but the XML in post#11 does increment continuously. This isn't a shortcoming of xml.

You'll get it to work, I'm sure.

Cheers,

Bob

 

[vololiberista]

Yep, and hope you now understand me when I asked you to show here the wood -or at least a part of it-, especially when the trees affect important concepts in the way the code works.
And btw, the red part has no meaning in the sentence, you should remove it to avoid more confusions:

<Value>(L:FLD_Control,bool) 1 == if{ (L:FUEL TANK CENTER2 QUANTITY, number) (L:C2_uplift rate,number) + (>L:FUEL TANK CENTER2 QUANTITY, number) ++ }</Value>

Tom

Tom,
You see, this is what is confusing about XML!! A single "+" means add and a double "++" means increment. Without the double ++ I can't get that to increment. It works correctly as written so is it wrong??? Maybe it is is but it works!! So it's sort of right!!! If I remove it as you suggest then I'm removing the increment instruction.
One bows to the experts of course but there are times when xml logic is worse than a nightmare especially when it comes to modelling fuel flow and transfer. What is a simple physical operation in real life becomes a pain to model mathematically! In this case there is the bowser feed and in flight there are four valves plus pumps, plus level indicators which make the fuel go in one direction or another. Not only that the centre2 tank is only fuelled when the centre tank is over 60%. and, you cannot land with nore than 50kgs in it! It's easier to build the real thing!!!
vololiberista

 

[mgh]

I can't get that to increment...

Do you really want to increment? Increment increases the value by 1 by definition. That's not a peculiarity of XML, it's the same in other languages.

EDIT

A question for the experts

...(>L:FUEL TANK CENTER2 QUANTITY, number) ++

first assigns the value on the top of the stack to (L:FUEL TANK CENTER2 QUANTITY, number). What does ++ do - increment the top of the stack or (L:FUEL TANK CENTER2 QUANTITY, number) ?

 

[taguilo]

A question for the experts

...(>L:FUEL TANK CENTER2 QUANTITY, number) ++

first assigns the value on the top of the stack to (L:FUEL TANK CENTER2 QUANTITY, number). What does ++ do - increment the top of the stack or (L:FUEL TANK CENTER2 QUANTITY, number) ?

It does like the first case.

A bit of ellaboration:

... (>L:FUEL TANK CENTER2 QUANTITY, number) extracts the stack's topmost value and then assigns that to L:FUEL TANK CENTER2 QUANTITY variable. After this operation, and following vololiberista's code, the stack is empty so the increment ++ operator applies over a 0 value then the result will be always 1.

Tom

 

[taguilo]

Tom,
You see, this is what is confusing about XML!! A single "+" means add and a double "++" means increment. Without the double ++ I can't get that to increment. It works correctly as written so is it wrong??? Maybe it is is but it works!! So it's sort of right!!! If I remove it as you suggest then I'm removing the increment instruction.

The ++ in your code has nothing to do with the increment of your variable.
What makes L:FUEL TANK CENTER2 QUANTITY increment is this sentence:

(L:FUEL TANK CENTER2 QUANTITY, number) (L:C2_uplift rate,number) + (>L:FUEL TANK CENTER2 QUANTITY, number)

Leaving or removing the ending ++ does not make any practical difference -see my reply to mgh in the post above- but leaving it may lead to confusions -as it happened to you.

See, FS's XML scripts logic is very simple and works perfect BUT, as uses to happen with computer code, you need a plenty understanding on the way it works to avoid transforming a development pleasure into a nightmare

Tom

 

[teson1]

hi, I haven't followed this thread, and don't know whether it's relevant or has already been mentioned, but I think "FUEL TANK CENTER2 QUANTITY" is an A: variable.
Does creating an L: variable with the same name cause issues ?

 

[vololiberista]

hi, I haven't followed this thread, and don't know whether it's relevant or has already been mentioned, but I think "FUEL TANK CENTER2 QUANTITY" is an A: variable.
Does creating an L: variable with the same name cause issues ?

Yes it is an A:var but my problem has been /is that for some reason I can't get (A:FUEL TANK CENTER2 QUANTITY, number) to actually work with Doug's fuel gauge. If I could life would be much simpler!
Instead therefore I'm having to simulate by creating an L:var. It's important that any A:var value is transferred only once.

<Value>(L:ct2_min,bool) 0 == if{ (A:FUEL TANK CENTER2 QUANTITY, number) (>L:FUEL TANK CENTER2 QUANTITY, number) 1 (>L:ct2_min,bool) }</Value>

In this case there is a residual quantity of fuel in the A:var (about 50kgs). This is transferred into the L:var and thereafter I can play with the L:vars much as I like.

The Super VC10 has a fin tank from which fuel can be transferred to and from the main centre tank in flight and and the ground. It also can be loaded from the bowser whilst on the ground. The fin tank fuel is used both as reserve fuel and trim fuel.

Both gauges have an additional needle pointer which is manually set, the valves are opened and the fuel transfers automatically one way or the other.

Coding the inflight/ground fuel transfers is the next nightmare!!!
vololiberista

 

[teson1]

hi, I haven't followed this thread, and don't know whether it's relevant or has already been mentioned, but I think "FUEL TANK CENTER2 QUANTITY" is an A: variable.
Does creating an L: variable with the same name cause issues ?

On rewiewing the thread I've realised this has already been brought up by Naruto-Kun and answered by Tom).
Sorry for the noise.