FS2004 Maximum Number of Updater codes in one XML gauge

[lionheart]

Hey all,

Is there a limit to how many updates one can put in an <Update> section of an XML gauge?

For instance, I have several gauges that are only for Updating, hidden gauges. Can one put all of this code into one single Updater gauge, like have 20 different sections of Updates (in one <Update> section) and have it all work? Or am I save with having 5 Update hidden gauges? Does system memory increase/decrease with 'many' Updaters? (I would think it would remain the same, as you have the exact same amount of 'system's being monitored, so quantity of hidden gauge Updaters wouldn't matter, but I could be wrong).

 

[ddawson]

I think the number of lines of code will be far more important than the number of gauges they are contained in.
Probably easier to debug the code if it is broken up into smaller blocks, in separate gauges.

 

[taguilo]

Bill,

FS9 XML schema supports only one <Update> property per gauge. If more than one is defined, only the latest in sequential order is loaded and parsed. Within <Update> you can put as much as around 50 Kb of code, which is a considerable amount and more than enough for a simple to mid-complex gauge.

FSX XML schema supports more than a single <Update>; this upgrade probably had the intention to overcome the 50 Kb limit. However, all the defined <Update> share a single memory block, which means all of their scripts are linked sequentially to form a single parsing section. As a result, some care must be taken when writing to multiple <Update> sections.

Regarding the one to multiple "hidden" gauges, technically speaking less gauges means less resources consumed, but in most cases the difference would be insignificant. I for one prefer to use only one "hidden" gauge with a big chunk of code and multiple <!-- comments --> for each section being handled.

Tom

 

[rpmc]

Hi Tom,

I wonder if you wouldn't mind expanding a little on your comments regarding ~50kb limit.

1. Which blocks of code does this limit apply to? For example, <Update></Update>, <Element></Element>, <Mouse></Mouse> (what about <Area></Area>?), <Keys></Keys>? Seems that it could not apply to <Gauge></Gauge>. Do all types of blocks have the same size limit?

2. Does the size limit apply to 'machine code' (or 'parsed code' or whatever the proper term is after the XML script is loaded), and not to the file size of the XML script? I presume it must be the 'machine code'. Apologies for using the wrong term here.

3. Use of macros in the XML script will increase the size of code in the block. So, the ~50kb limit must apply to the block size after the gauge is loaded and the macros have been substituted into the script, is that correct? I suspect that I may have run up against this in an <Keys> section last year when I made very heavy use of Robbie's String Storage macros which expand to create a lot of lines of code and a significant number of new L:Vars.

4. Will the number of variables, like L:Vars in the script, affect the size, or is it just amount of code?

5. Finally, do you have any examples, even anecdotally, of how many, or about how many, lines of XML script would consume a 50kb block of code? I understand when you say it is considerable, but is it possible to say how much that might be in terms of 'typical', 'normal', or 'usual' styles of XML gauges? Like ... usually at least 1000 lines per 'block' of code? 2000 lines? More? Is there any way to determine the size of a certain block of code other than, "Maybe it's too big because the gauge doesn't work"? Just curious.

Will be interested to hear what people say. Thanks in advance.

Bob

 

[n4gix]

While working on the B737-200 last year, I first "hit the limit" when some simple "stuff" inserted at the bottom of my <Update> section would not work at all, but when moved to the top would work perfectly...

...and eventually noticed that the previously working "stuff" at the bottom of the section no longer worked. "Ah ha!" I thought to myself, "I've reached a limit here."

Thus, I then split my "stuff" in the <Update> section into a two additional "server" type gauges, namely the SP77 autopilot "logic" and the SP177 autopilot "logic." I honestly do not remember what the file size was, not the precise number of lines, but I think it was somewhere around 4,000+ lines all together.

 

[rpmc]

While working on the B737-200 last year, I first "hit the limit" when some simple "stuff" inserted at the bottom of my <Update> section would not work at all, but when moved to the top would work perfectly...

...and eventually noticed that the previously working "stuff" at the bottom of the section no longer worked. "Ah ha!" I thought to myself, "I've reached a limit here."

Thus, I then split my "stuff" in the <Update> section into a two additional "server" type gauges, namely the SP77 autopilot "logic" and the SP177 autopilot "logic." I honestly do not remember what the file size was, not the precise number of lines, but I think it was somewhere around 4,000+ lines all together.

Thanks Bill. Interesting. 4000 lines in an Update section ought to satisfy the mere mortals.

I had a problem in a <Keys> section. I didn't know it at first, but I think my huge macros did me in.

As well, I have hit another type limit - the 55ms update cycle period. My uneducated guess is that it might be less common to hit this limit rather than the ~50kb block size limit, but who knows.

My case was in testing the LOGGER module - which is probably a bit of a unique application because it was writing variables to HDD and as I increased the number of variables, it eventually missed writing some before the next update cycle began (though it was fine up to about 750 L:Vars to HDD each Update cycle).

Thanks for the response.

Bob

 

[taguilo]

Hi Tom,

I wonder if you wouldn't mind expanding a little on your comments regarding ~50kb limit.

Hi Bob, sure!

1. Which blocks of code does this limit apply to? For example, <Update></Update>, <Element></Element>, <Mouse></Mouse> (what about <Area></Area>?), <Keys></Keys>? Seems that it could not apply to <Gauge></Gauge>. Do all types of blocks have the same size limit?

It applies to properties that support script evaluation: <Update>;<Visible>,<Value>;<Click>, etc. The size of a gauge doesn't seem to have a specific limit.

2. Does the size limit apply to 'machine code' (or 'parsed code' or whatever the proper term is after the XML script is loaded), and not to the file size of the XML script? I presume it must be the 'machine code'. Apologies for using the wrong term here.

You presume right. The limit affects the script portion only.

3. Use of macros in the XML script will increase the size of code in the block. So, the ~50kb limit must apply to the block size after the gauge is loaded and the macros have been substituted into the script, is that correct? I suspect that I may have run up against this in an <Keys> section last year when I made very heavy use of Robbie's String Storage macros which expand to create a lot of lines of code and a significant number of new L:Vars.

AFAIT, when the XML parser finds a script section, it first assigns a block of memory the size of the script OR the ~50kb limit, whichever meets the condition. Then copies only the portion of the script that fits into the assigned memory block; if it fits entirely then allright, otherwise the portion of the script exceeding the memory block size is discarded. In this case, the gauge will load fine and the script will execute but the result might not be as expected. A tough debug indeed!
When a macro is included within a script, the parser will expand the memory block and insert the code that replaces the macro call. If the expansion exceedes the ~50kb a runtime error occurs and FSX will crash to desktop. Nice uh?

4. Will the number of variables, like L:Vars in the script, affect the size, or is it just amount of code?

No, it's just amount of code.

5. Finally, do you have any examples, even anecdotally, of how many, or about how many, lines of XML script would consume a 50kb block of code? I understand when you say it is considerable, but is it possible to say how much that might be in terms of 'typical', 'normal', or 'usual' styles of XML gauges? Like ... usually at least 1000 lines per 'block' of code? 2000 lines? More? Is there any way to determine the size of a certain block of code other than, "Maybe it's too big because the gauge doesn't work"? Just curious.

Actually we can't speak of lines but rather bytes of code. Number of lines would depend exclusively on the number of bytes used on each one, including spaces and control chars (CR,LF,etc).
To determine the size of a certain code, just select it entirely then see how much space it takes. If you use an editor like Ultraedit, it shows the number of bytes selected at the bottom of the window. If you don't have this facility in yours, just open a .txt and paste the code there, then save the file and notice how much space it takes, and you'll have a figure.

Tom

 

[rpmc]

Actually we can't speak of lines but rather bytes of code. Number of lines would depend exclusively on the number of bytes used on each one, including spaces and control chars (CR,LF,etc).
To determine the size of a certain code, just select it entirely then see how much space it takes. If you use an editor like Ultraedit, it shows the number of bytes selected at the bottom of the window. If you don't have this facility in yours, just open a .txt and paste the code there, then save the file and notice how much space it takes, and you'll have a figure.

Thanks, Tom,

I see, so it is the length, or size, of the XML text that matters (now I am a little confused by my question #2).

A test gauge I'm working on has an <Update> section consisting of 300 lines which is 17kb in size. That would infer a limit of about 900 lines of XML in my <Update> section, everything else being about the same. That's actually much less than I expected. Bill got 4000 lines in an <Update>; apparently, I cram a lot onto each line.

BTW, I use Notepad++, and it too shows length (size) in bytes and number of lines at the bottom of the window. Never paid attention before.

Bob

 

[spokes2112]

Just to comment - I too have had the dreaded "Too much XML". It always resulted in a hard FSX crash with a "BEX" ( stack overflow, ~600 full lines of code ) error.
Your advisment to "split" it up did the trick

And here is the big question. Does ( or can? ) overly formatted (tabbed to look nice) w/ comments all over the place contribute to this?

 

[taguilo]

I see, so it is the length, or size, of the XML text that matters (now I am a little confused by my question #2).

A test gauge I'm working on has an <Update> section consisting of 300 lines which is 17kb in size. That would infer a limit of about 900 lines of XML in my <Update> section, everything else being about the same. That's actually much less than I expected. Bill got 4000 lines in an <Update>; apparently, I cram a lot onto each line.

I understand your confusion, but scripts are parsed as is, like a big chain of bytes. There ain't no "machine code" conversion; their texts have the same lenght in memory as in the XML files they are written (less comments-see below)

Regarding the number of lines, I believe Bill uses much of indentation to improve readability, so the reason of such a difference with your own limit.

And here is the big question. Does ( or can? ) overly formatted (tabbed to look nice) w/ comments all over the place contribute to this?

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 lenght that is copied to memory.


Tom

 

[lionheart]

Interesting......