Most Tedious and Boring Tasks

n4gix

Resource contributor
#1
I don't know about the rest of you, but getting 50 annunciator lights to light up and extinguish has to be among the most tedious and boring tasks in sim development!
 

Ronald

Resource contributor
#6
When I get creative and start modeling, I try to get in a state-of-flow whereby I practice to postpone any kind of (mental) judgment.
This keeps my attention and energy focused to the challenges at hand (feet? anywhere?) and gets the job done in any way I can.

Questions:
Nice panel by the way Bill. To which aircraft does it belong?
- Are you only referring to the changing textures in this case?
- Does this panel/gauge use with backlight-ing that dynamically in/decreases in light-intensity when turned on/off?
- Is it possible to automate these boring tasks in any way, with macro's of some sort?
 
Last edited:
#7
Mirroring an airliner wing... it's reason enough to stick to GA!

Getting mechanical parts to work is often both interesting and annoying - the new 737 models will require me to construct the original 727 thrust reverser unit, and it's a convoluted piece of garbage (hence why they got rid of it).
 

n4gix

Resource contributor
#9
Questions:
Nice panel by the way Bill. To which aircraft does it belong?
- Are you only referring to the changing textures in this case?
- Does this panel/gauge use with backlight-ing that dynamically in/decreases in light-intensity when turned on/off?
- Is it possible to automate these boring tasks in any way, with macro's of some sort?
This is the annunciator sub-panel for the Avanti P180.
Each "light" requires two polygons; one for the unlighted text, the other for the lighted text (Additive mode, Self-Illumination)
They are controlled by <Visibility> conditions, so 50 of them require 100 unique entries in the modeldef.xml file.
Since the only difference between them is the custom L:variable used for <Visibility> control, and the <PartInfo> name, it is indeed possible to copy/paste each set and simply change the names of the <PartInfo> and (L:var)...

...which while relatively fast, is still boring and tedious! :confused:

This panel has a "Systems Test" knob that selects the specific system to test, and requires a knob "pull" to make the selector active, which is why the extra test conditions in the <Code> section.
Code:
  <!-- ANNUNCIATOR LIGHTS VISIBILITY -->

  <PartInfo>
    <Name>Avt_L_FIRE_LIGHT_OFF</Name>
    <Visibility>
      <Parameter>
        <Code>
          (L:Avt_SysTest_SEL,enum) 0 !=
          (L:Avt_SysTest_PULL, bool) ! or
          (L:Avt_L_FIRE_LIGHT,bool) ! and
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

  <PartInfo>
    <Name>Avt_L_FIRE_LIGHT_ON</Name>
    <Visibility>
      <Parameter>
        <Code>
          (L:Avt_SysTest_SEL,enum) 0 ==
          (L:Avt_SysTest_PULL, bool) and
          (L:Avt_L_FIRE_LIGHT,bool) or
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>
 
Last edited:

Paul Domingue

Resource contributor
#10
Try sipping on some 12 year old single malt while while doing it. It won't be quite so boring but it might get lisppier, is that a word? :p
 

Ronald

Resource contributor
#11
Thanks Bill for your explanation and the panel's XML code fragment that shows how it works. Very educative!
 
#12
You can always try mentally reciting the Rosary - as a cradle Catholic, when have tedious things to do, I sometimes do that to contemplate on weightier matters…although I can never remember the new mysteries that JPII added. In this case… an "Our Father" for each column of Warning Lights and a "Hail Marry" for each Caution Light in a column, actually works - albeit only four decades…just say'n. :)
 

Heretic

Resource contributor
#13
Speaking of tedious and boring, I find recreating the materials, animations, visibilities and hierarchy of objects imported from .obj into 3ds Max incredibly boring especially since it's hours and hours of work to get to the point of something that was already there.
There needs to be an ISO norm for a universal 3D model format.
 
#15
Bill, great work on that annunciator. Keep going, it will be worth it!
Speaking of a lack of motivation, below are some shots of the OH and the annunciators of the Saab 340 - 134 lamps only there.



Each "light" requires two polygons; one for the unlighted text, the other for the lighted text (Additive mode, Self-Illumination)
They are controlled by <Visibility> conditions, so 50 of them require 100 unique entries in the modeldef.xml file.
Might I suggest another approach: My unlighted lamps are part of the OH texture - there are no seperate polygons for them, they are always there. The lighted polygons "hover" directly above the unlighted. Therefore only the lighted polygons require a "Visibility" entry in the modeldef.xml. Saves you 50% of workload and you can't tell a difference visually.;)
 

n4gix

Resource contributor
#16
Steven, I've tried that technique before and was frustrated by some zbias flashing issues that showed up on some customer's systems.
 
#17
Steven, I've tried that technique before and was frustrated by some zbias flashing issues that showed up on some customer's systems.
Valid argument, I didn't think about. Let's see, if the beta phase will raise some of these complaints.
Thanks for the warning then:duck:
 
Top