• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FSXA Confusing: modulo in XML

Vitus

Resource contributor
Messages
1,480
Country
newzealand
Hi there,

I just noticed that the modulo operator % is a little bit weird in XML coding. Usually the modulo operator needs two arguments: the number that is divided and the coefficient. The result should be the remaining of the division. But the SDK reads:
Operator Operation Arguments Example Result
% taking modulo 1 5.3 % 5

what's that? In my understanding, a usual modulo operation is something like:
42 % 12 = 6

I hope you can help me!

Regards
Vitus
 
I noticed that too vitus

like %( (A:ACCELERATION BODY Z, feet per second squared) )%!4.5f!

I think it is a way to identify the value to be displayed in gauge strings.
 
Hi there,

I just noticed that the modulo operator % is a little bit weird in XML coding. Usually the modulo operator needs two arguments: the number that is divided and the coefficient. The result should be the remaining of the division. But the SDK reads:
Operator Operation Arguments Example Result
% taking modulo 1 5.3 % 5

what's that? In my understanding, a usual modulo operation is something like:
42 % 12 = 6

For the sake of convenience, I'm going to (re)post a reply to a similar question someone once asked at AVSIM. The following is a rather technical reply, but I hope it will serve to illustrate and explain the rather special case of the XML parser's use of the modulus operator:

Hi all,

I understand modulus to a degree, like

123 10 % strips out the 3 and places it on the stack.

what does, say, 2 % do?

The "result" is only obvious whenever you use 10 as a divisor, because it effectively bitshifts the decimal, and the remainder is simply the decimal portion! ;)

With other numbers as a divisor however, the operation is more opaque... :scratchch

The modulus, or remainder, operator divides number1 by number2 and returns only the remainder as result. The sign of result is the same as the sign of number1. The value of result is between 0 and the absolute value of number2.

For example, in the following expression, A (which is result) equals 5.6.

A = 19 6.7 %

This is equivalent to:

19 / 6.7 = 2.8358208

We throw away the fraction leaving 2 as the result

Now we have:

A = 19 - (6.7 * 2)

Therefore A = 5.6

The above is an example where the result is certainly not obvious! :eek:

The "%" (or "mod") operator in computer languages is simply the remainder. For
example,

17 3 % = 2

because

17 / 3 = 5 rem 2

which in turn means

17 = 3 * 5 + 2

There are some tricky issues when negative numbers are used, but that
shouldn't ordinarily be necessary.

In math (number theory), the term is used a little differently. The
"modulus" is actually not the remainder, but the number you are
dividing by; and "mod" is not an operator, but a label telling "in
what sense two quantities are considered congruent, or equal." For
example, we would say

17 = 11 (mod 3)

(read as "17 is congruent to 11, modulo 3"), meaning that 17 and 11
both leave the SAME remainder when divided by 3. You probably won't
see this usage if you are only reading about programming, but it's
worth being aware of if you look deeper into the math behind it.

The expression a = b (% n) means that n is a divisor of a - b. This
sentence is read, "a is congruent to b modulo n." It is something
like a remainder, because if you subtract a remainder from the
dividend, the divisor will go into the result evenly.

Examples: 100 = 86 (% 7), because 100 - 86 = 14 has 7 as a divisor.
On the other hand, if you divide 100 by 7, the quotient is 14 and
remainder is 2, and 100 = 2 (% 7), too.

Now, back to your original question, what would 123 2 % be?

A = 123 2 %

123 / 2 = 61.5, therefore:

A = 123 - (61 * 2)

A = 1

I hope that this is helpful! It's probably a lot more than you wanted to know... ;)
 
I noticed that too vitus

like %( (A:ACCELERATION BODY Z, feet per second squared) )%!4.5f!

I think it is a way to identify the value to be displayed in gauge strings.

Here is an excellent example of "inconsistent use of symbology" within the XML parsing engine of FS...

When used within a <String> or <FormattedString> expression, the rules are changed quite a bit! In this case the "%" symbol is not a modulo or modulus operator. Instead it is -as you noted- meant to convey something entirely different.

In this special case, the "%" is a command to "evaluate what follows this symbol." In the example you cited above, it means "evaluate the result of (A:Acceleration Body Z, feet per second squared) and display it in this (evaluated) format."

Another example of this inconsistency is the case of the if/else syntax. In normal use, the prototype for if/else in XML syntax is:

Code:
(A:Condition,unit) [I]result[/I] if{ [I]do this[/I] } els{ [I]do that[/I] }

However, within a <String> or <FormattedString> statement, the syntax is completely different!

Code:
%((A:Condition, unit) [I]result[/I] )%{if}[I]do this[/I]%{else}[I]do that[/I]%{end}

The position of the curly-braces is different:
if{ } versus {if}
els{ } versus {else}
and the addition of {end} for <String> or <FormattedString> syntax... :D
 
The genius known as Bill strikes again!

Thanks for that very informative post. Inconsistent symbology is one of my pet peeves.

Thanks for the explanation.
 
Hi Bill,

I am still confused, because all the given examples have TWO arguments (which makes sense), but the SDK states that the % operator needs ONE (which doesn't make sense at all).

Thanks for your time! Much appreciated!
Vitus
 
Hi Bill,

I am still confused, because all the given examples have TWO arguments (which makes sense), but the SDK states that the % operator needs ONE (which doesn't make sense at all).

Thanks for your time! Much appreciated!
Vitus

The example from the SDK does have two arguments, although the (b) argument is assumed to be 10 unless otherwise stated. The SDK definitely does not make this clear at all:

5.3 (10) % 5

a (b) % result

I wrote:
The "result" is only obvious whenever you use 10 as a divisor, because it effectively bitshifts the decimal, and the remainder is simply the decimal portion!
 
:banghead: I did some experiments with the %-operator. It seems like
a % always results in 0!!
therefore a second argument is mandatory!
 
Last edited:
I've never not used two arguments... :rotfl:

I've found that the more explicit one is with XML, the less problems one has.

For example, the expression (A:Something,bool) if{ do something } els{ do something else } in theory will always be execute do something only if (A:Something,bool) is TRUE. However, it doesn't always work.

On the other hand, (A:Something,bool) 1 == ... will almost always work...

...but, if you really, really, REALLY MUST be certain, then this construct will ALWAYS work...

(A:Something,bool) 0 != if{ do something els{ do something else } :stirthepo
 
Last edited:
Not sure why the first version doesn't work, but for the second and third version, the third version is the correct one, since the definition of a BOOL is either 0 (FALSE) or !0 (TRUE), there's no guarantee that a TRUE will be 1 just that it will be non-zero :->
 
Back
Top