FSXA [Solved] Nesting XML macros?

[Kekelekou]

Hello there!

Following the release of my Damage Mod for the Flight1 BN-2 Islander, I am working on the interface with FSCaptain. I want to fail "my" systems if the corresponding failure code is triggered by FSC, and the other way around too.
There are a lot of failure codes (circa 75) and systems (25) to work with, so I have splitted the gauge into several macros, basically as follows :
@CodeFromSystem : input : Damage mod system name, output : Corresponding FSC failure code
@SystemFromCode : input : FSC failure code, output : Corresponding Damage mod system name
@FailThisCode : input : FSC failure code, output : sets corresponding DM system wear index to max
@FailThisSystem : input DM system name : output : sets corresponding FSC failure code

I would then nest the macros as @FailThisCode( @CodeFromSystem(...)) and @FailThisSystem(@SystemFromCode(...)) to get the expected result in a much shorter and clerarer code.

BUT

FSX crashes everytime I test the gauge with nested macros, or (to be accurate) when one of the arguments is a macro callback. Each macro works fine when tested with an hard-coded argument.

Is this a well-known limitation?
Is there a work-around?

Any help appreciated!

 

[Heretic]

If I remember correctly, you can call a macro from other macros, so maybe try that.

 

[n4gix]

Keep in mind that a @Macro is nothing more than literal replacement for regular XML scripting.

 

[taguilo]

Is this a well-known limitation?

Yes. Is your <Update> or <Element> script greater than ~ 50 Kb? . That is the limit for a single one.
If there is no macro call in it, sim will parse all the characters until reaching the limit and then stops. FS will load normally but the gauge won't work as expected.
Now, if there is a macro call embedded, FS will crash while loading the aircraft.

Is there a work-around?

Yes. Split you big script in two or more sections, ie, use <Update> and as many <Element> as needed.

Tom

 

[Kekelekou]

Hello guys!

Thank you for your help.
The whole gauge file is less than 50kB, with 3 Element sections and one single Update line at the top (to set the Update frequency).
Since a macro simply replaces code as n4gix puts it, does the gauge stall if there are too many macro callbacks that make the flattened, « unmacroed » code pass beyond the 50kB limit?

Anyway, I have adjusted the gauge as suggested by Heretic so that no macros are used as macro arguments. Testing imminent.

Thanks again

 

[taguilo]

Since a macro simply replaces code as n4gix puts it, does the gauge stall if there are too many macro callbacks that make the flattened, « unmacroed » code pass beyond the 50kB limit?

Sure it will crash, as what counts is total script size after macro replacement.
If, for example, you have a 30 kb macro that is called 4 times in a simple script, that counts for 120 Kb total size, and FS will crash while replacing the second macro call.

Anyway, I have adjusted the gauge as suggested by Heretic so that no macros are used as macro arguments. Testing imminent.

There's nothing wrong with using macros as macro arguments. In fact that is a very powerful option in some circumstances. If you have many of those, try putting each master calling macro in a separate <Element> script.

Tom

 

[n4gix]

As an ultimate example of "nesting macros" take a really close look at the default GPS script(s). Trying to trace all of the @macros will drive you insane!

 

[COBS]

As an ultimate example of "nesting macros" take a really close look at the default GPS script(s). Trying to trace all of the @macros will drive you insane!

Amen to that one Fr Bill .
I spent about a week or so trying to track the GPS 500 macro's , eventually I managed , I was after a constantly updating scrollable Flight Plan listing .
Got it to work and it now resides within my radar instrument , it was well worth the effort , but as you said , it will drive you insane , or close to it .

Cheers
Karol

 

[Kekelekou]

Sure it will crash, as what counts is total script size after macro replacement.

Oh boy! So I really did a mess of it. Each of my section was called about a dozen times, no wonder I got kicked out!

I have just measured each of the nested callbacks, so that I can stay below the limit. A simple section breakdown will do the trick.
Thank you all again for you much valuable inputs!

 

[Heretic]

Convert the gauge to FS9 syntax. No size limit there.

 

[rpmc]

I recall Tom Aguilo making reference to the 50kb limit as it pertains to FS9 schema.

 

[Heretic]

I recall Tom Aguilo making reference to the 50kb limit as it pertains to FS9 schema.

For update sections yes, but there's no limit for Element-Select-Value constructs.

 

[taguilo]

For update sections yes, but there's no limit for Element-Select-Value constructs.

Limit applies to any script, either in <Update>, <Value>, etc.

Tom

 

[Heretic]

Let's make this crystal clear then:

FSX syntax: The sum of the code size contained in the "update" element, no matter how many there are, may not surpass 50 KB -> 50 KB size limitation for background gauges.
FS9 syntax: The code contained in the single available "update", or any "value", element may not surpass 50 KB -> No effective size limitation for background gauges.

 

[rpmc]

Building on Bjoern's summary, is this correct as per FS9 schema?

The ~50kb size limit applies to blocks of script that support script evaluation. For example,

<Update>, <Value>, <Visible>, <Click>, <Script>, <On>

There is a ~50kb limit for each one of these that are included in the gauge.

Comments are removed from the script before anything else, so they don't count towards the size. But tabs, spaces, CR and LF do count, and affects the final length that is copied to memory.

When the XML parser finds a script section, it first assigns a block of memory the size of the script or ~50kb, whichever is smaller, and then copies only the portion of the script that fits into the assigned memory block. If it fits entirely then all right, otherwise the portion of the script exceeding the memory block size is discarded. In this case, the gauge will load and the script will execute but the result will probably not be as expected. A tough debug indeed!

When a macro is included within a script, the parser will expand the memory block to ~50kb and insert the code that replaces the macro call. If the expanded script exceeds the ~50kb limit, a runtime error occurs and FSX will crash to desktop.

There appears to be no size limit to the overall gauge (i.e., between <Gauge> and </Gauge>), nor numbers of variables included in the gauge.

Bob

 

[taguilo]

FSX syntax:

The sum of the code size contained in the "update" element, no matter how many there are, may not surpass 50 KB

Correct. And same for <Value>, <Visible>, <Click>, <Script>, <On> , etc.

50 KB size limitation for background gauges.

No. There is no size limit for gauge structure (<Gauge>....</Gauge>). Same as FS9.

FS9 syntax:

The code contained in the single available "update", or any "value", element may not surpass 50 KB -> No effective size limitation for background gauges.

Correct.

Building on Bjoern's summary, is this correct as per FS9 schema?

Yes Bob; I recall to have written that long ago, just too lazy to search it back and put the link here. Thanks!

Tom

 

[PhantomTweak]

just too lazy to search it back and put the link here

Please, Tom!
You're not "lazy", you are just "energy frugal". Very, very frugal!

Have fun all!
Pat☺

 

[Heretic]

No. There is no size limit for gauge structure (<Gauge>....</Gauge>). Same as FS9.

I was referring to background gauges, i.e. gauges not containing any artwork, only evaluation sections.

 

[taguilo]

I was referring to background gauges, i.e. gauges not containing any artwork, only evaluation sections.

It's the same.
Simply put for bot FS9/FSX gauges:
~50 Kb limit per each script section included in the gauge. No practical <Gauge>...</Gauge> file size limit (.xml).

Tom

 

[Kekelekou]

Thank you all for the technical insight!
I have splitted the gauge into many Element sections. No FSX crashes so far, so I guess I am done thanks to you.