<Update> Section Limit...

[n4gix 4,961]

While eating dinner and watching a bit of TV to relax a bit, I got to thinking about the problem with only having a single <Update> section allowed in any given XML script......and it occurred to me that by setting up several sections of "timers," one could have as many update frequencies as one could possibly want!Since the <Update> has no "Frequency" specified, it will run at 18/Hz rate, but the timers will only execute the contents of the if{...} condition per the time modulo set...

<Update Hidden="Yes">  <!-- 1.0 SECOND UPDATE -->  (P:Absolute time,seconds) 2 % 1 > !  if{    <!-- PLACE XML HERE-->  }  <!-- 0.5 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.5 > !  if{  <!-- PLACE XML HERE-->  }  <!-- 0.25 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.25 > !  if{  <!-- PLACE XML HERE-->  }  <!-- 0.7 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.7 > !  if{  <!-- PLACE XML HERE-->  }</Update>

[rcbarend 37]

While eating dinner and watching a bit of TV to relax a bit, I got to thinking about the problem with only having a single <Update> section allowed in any given XML script......and it occurred to me that by setting up several sections of "timers," one could have as many update frequencies as one could possibly want!Since the <Update> has no "Frequency" specified, it will run at 18/Hz rate, but the timers will only execute the contents of the if{...} condition per the time modulo set...

<Update Hidden="Yes">  <!-- 1.0 SECOND UPDATE -->  (P:Absolute time,seconds) 2 % 1 > !  if{    <!-- PLACE XML HERE-->  }  <!-- 0.5 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.5 > !  if{  <!-- PLACE XML HERE-->  }  <!-- 0.25 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.25 > !  if{  <!-- PLACE XML HERE-->  }  <!-- 0.7 SECOND UPDATE -->  (P:Absolute time,seconds) 1 % 0.7 > !  if{  <!-- PLACE XML HERE-->  }</Update>

Hi Bill,I understand the above, but I've never been able to figure out what the Update object really does, or why one would need to use it.Can you shed some light ?Thanks, Rob

[n4gix 4,961]

Hi Bill,I understand the above, but I've never been able to figure out what the Update object really does, or why one would need to use it.Can you shed some light ?Thanks, Rob

Rob, it's a very handy section in which to place script that you wish to be continuously evaluated, or at least evaluated semi-continuously to keep from hammering the system with repeated commands ever cycle, and also has the advantage of collecting all one's "logic" into a single location."Traditionally," folks have put such stuff in a bunch of <Element><Select><Value> constructions, such as this:

   <Element>      <Select>         <Value>               <!-- RESET FLAP LEVER TO NEUTRAL -->               (L:Flap_reset) (P:local time, seconds) >               if{ }               els{ 0 (>L:FlapToggle,enum) }         </Value>      </Select>   </Element>

Well, that's not really a "Good Idea" since when any of the conditions is TRUE, the L:vars will be updated at 18Hz rate......not to mention it scatters what is essentially "logic script" throughout all of the sub-gauges, making finding/fixing the logic a real PITA!A better approach is to use the <Update> section method:

   <Update>      <!-- 0.25 SECOND UPDATE -->      (P:Absolute time,seconds) 1 % 0.25 > !      if{          <!-- RESET FLAP LEVER TO NEUTRAL -->          (L:Flap_reset) (P:local time, seconds) >          if{ }          els{ 0 (>L:FlapToggle,enum) }        }      <!-- END OF TIMER LOOP -->   </Update>

For those who're doing 3d modeling and embedding their XML in the model file, a similar construct is to use a single, tiny polygon in the model on which to hang a <Visibility> script:

  <PartInfo>    <Name>T38_Valid</Name>    <Visibility>      <Parameter>        <Code>          <!-- INITIALIZATION ROUTINE(S) -->          (L:T38_Init,bool) 0 ==          if{             <!-- PLACE ANYTHING ONLY TO BE DONE ONCE HERE -->             1 (>L:T38_Init,bool)          }          <!-- END INITIALIZATION ROUTINE(S) -->          <!-- 0.25 SECOND UPDATE -->          (P:Absolute time,seconds) 1 % 0.25 > !          if{              <!-- SET FUEL CUTOFF(S) TO SHUT DOWN ENGINE(S) -->              (L:T38_FuelCutoff_Left,bool) 1 ==              if{ (>K:MIXTURE1_RICH) }              els{ (>K:MIXTURE1_LEAN) }              (L:T38_FuelCutoff_Right,bool) 1 ==              if{ (>K:MIXTURE2_RICH) }              els{ (>K:MIXTURE2_LEAN) }              }          }  <!-- END OF TIMER LOOP -->        </Code>      </Parameter>    </Visibility>  </PartInfo>

Typically, while writing the script and rigging the 3d model, I'll use an "XML Logic" gauge with one huge <Update> section only, then once everything is throughly debugged, copy/paste the entire huge hunk of script into the modeldef.xml <Visibility> "Logic" section and compile it into the interior model.

[rcbarend 37]

Rob, it's a very handy section in which to place script that you wish to be continuously evaluated, or at least evaluated semi-continuously to keep from hammering the system with repeated commands ever cycle, and also has the advantage of collecting all one's "logic" into a single location."Traditionally," folks have put such stuff in a bunch of <Element><Select><Value> constructions, such as this:

   <Element>      <Select>         <Value>               <!-- RESET FLAP LEVER TO NEUTRAL -->               (L:Flap_reset) (P:local time, seconds) >               if{ }               els{ 0 (>L:FlapToggle,enum) }         </Value>      </Select>   </Element>

Well, that's not really a "Good Idea" since when any of the conditions is TRUE, the L:vars will be updated at 18Hz rate......not to mention it scatters what is essentially "logic script" throughout all of the sub-gauges, making finding/fixing the logic a real PITA!A better approach is to use the <Update> section method:

   <Update>      <!-- 0.25 SECOND UPDATE -->      (P:Absolute time,seconds) 1 % 0.25 > !      if{          <!-- RESET FLAP LEVER TO NEUTRAL -->          (L:Flap_reset) (P:local time, seconds) >          if{ }          els{ 0 (>L:FlapToggle,enum) }        }      <!-- END OF TIMER LOOP -->   </Update>

For those who're doing 3d modeling and embedding their XML in the model file, a similar construct is to use a single, tiny polygon in the model on which to hang a <Visibility> script:

  <PartInfo>    <Name>T38_Valid</Name>    <Visibility>      <Parameter>        <Code>          <!-- INITIALIZATION ROUTINE(S) -->          (L:T38_Init,bool) 0 ==          if{             <!-- PLACE ANYTHING ONLY TO BE DONE ONCE HERE -->             1 (>L:T38_Init,bool)          }          <!-- END INITIALIZATION ROUTINE(S) -->          <!-- 0.25 SECOND UPDATE -->          (P:Absolute time,seconds) 1 % 0.25 > !          if{              <!-- SET FUEL CUTOFF(S) TO SHUT DOWN ENGINE(S) -->              (L:T38_FuelCutoff_Left,bool) 1 ==              if{ (>K:MIXTURE1_RICH) }              els{ (>K:MIXTURE1_LEAN) }              (L:T38_FuelCutoff_Right,bool) 1 ==              if{ (>K:MIXTURE2_RICH) }              els{ (>K:MIXTURE2_LEAN) }              }          }  <!-- END OF TIMER LOOP -->        </Code>      </Parameter>    </Visibility>  </PartInfo>

Typically, while writing the script and rigging the 3d model, I'll use an "XML Logic" gauge with one huge <Update> section only, then once everything is throughly debugged, copy/paste the entire huge hunk of script into the modeldef.xml <Visibility> "Logic" section and compile it into the interior model.

Hi Bill,I don't have a clue about using XML code in the .mdl (.mdl's are out of my leage :( ), but if I rephrase my question to code for XML gauges:I DO understand your original post about adding a time condition in the Update object. I've used that same trick myself (not in relation to the Update object), to prevent a piece of XML code in an XML gauge being executed everytime the gauge is scheduled (either at 18HZ, or specified by the Update_Frequency).My question was more basic (and I still don't understand that):What's the fundamental difference (in an XML gauge) between placing a piece of XML code in an Update object or placing it in an Element-Select-Value structure (performance-wise) ??Hope you understand what I mean ...Thanks, Rob

[n4gix 4,961]

My question was more basic (and I still don't understand that):What's the fundamental difference (in an XML gauge) between placing a piece of XML code in an Update object or placing it in an Element-Select-Value structure (performance-wise) ??

In terms of "performance," nothing at all that I can tell. What it does offer IMHO is a rather HUGE benefit of putting all of one's logic in one central place.In that respect at least it makes it much, much easier to follow the logic chain, and absolutely guarantee that any evaluations that MUST preceed subsequent evaluations do so.For relatively simple projects with a scant handful of gauges, switches, knobs, and assorted doo-dads, it probably would be less useful, but when dealing with more advanced "systems" type projects, it's a huge boon.

[rcbarend 37]

In terms of "performance," nothing at all that I can tell. What it does offer IMHO is a rather HUGE benefit of putting all of one's logic in one central place.In that respect at least it makes it much, much easier to follow the logic chain, and absolutely guarantee that any evaluations that MUST preceed subsequent evaluations do so.For relatively simple projects with a scant handful of gauges, switches, knobs, and assorted doo-dads, it probably would be less useful, but when dealing with more advanced "systems" type projects, it's a huge boon.

Thanks; I think I grasped the meaning of it now.Best, Rob