• 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 Custom 3D aircraft lights

Messages
665
Country
us-illinois
I know that a lot of payware (and maybe a few freeware) aircraft don't use generic .FX light effects like the default ones do. For example, the PMDG 737's exterior lights consist of just X, Y and Z planes with the light texture on them. It's quite simple and I already know how to do that, but how does one go about coding that light to flash on and off, or be triggered by a switch? Is the XML entered into the object's Custom Properties in Max?

It must involve some kind of sorcery...:wizard:
 
I think you have to attach a visibility condition to the light object. I would give "general light" a try.
 
Thanks Capt_X, I will try the General Light condition tomorrow. I'm just wondering if there is an option for a flashing light...Well, I'll find out tomorrow! :p
 
My new Bell 222 has 3D lights built in. I will send you examples via email. Since I am busy this weekend, I can do it Monday early or in the evening.
 
I use two bits of XML to control flashing lights. First is the 'control code' that cycles an L:variable on/off. Second is the <Visibility> script for the actual 'light object."

First, the control script. This is nested conditions that will create a "double flash." This bit of script is in my main "logic gauge" in the <Update> section.
Code:
    <!-- STROBE LIGHT FLASHER -->
    (A:LIGHT STROBE,bool)
    (A:ELECTRICAL MASTER BATTERY,bool)
    and
    if{
       (P:Absolute time,seconds) 2 % 0.4 > !
       if{
          (P:Absolute time,seconds) 0.2 % 0.1 > !
          if{ 1 (>L:B737_Strobe,bool) }
          els{ 0 (>L:B737_Strobe,bool) }
         }
    }
Here is the modeldef.xml entry for the strobe light visibility:
Code:
  <PartInfo>
    <Name>B737_light_strobe_vis</Name>
    <Visibility>
      <Parameter>
        <Code>
          (L:B737_Strobe,bool)
          (A:LIGHT STROBE,bool)
          and
          (A:ELECTRICAL MASTER BATTERY,bool)
          and
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>
 
You will need lights for parts that move, like rudders, flexing wings, etc.

The bad side is you need nice ones, as the stock FS lights are horrible. I need to figure out how to do this as some on mine are horrible. (Giant fluffy looking light balls instead of cool little lights).

The standard way of doing this is to create a little Polygon (rectangle or triangle) and place it outside of polygons (like on a surface of a lamp). Create a material that is a color (no bitmaps or graphics), and name it appropriately, like LIGHT_NAV. (The names can be found in the SDK, and I have totally forgotten where in the SDK, my humble apologies). Create a color for each 'color' part, such as green, red, white. Attach to these Polygons, map them as well, quick add of a UVW Map is all. Then attach the Effect to it (like nav white), then attach the Visibility to it, (again, light_nav, light_strobe, etc), and Voila, done. Export test model and test in FS.
 
I use two bits of XML to control flashing lights. First is the 'control code' that cycles an L:variable on/off. Second is the <Visibility> script for the actual 'light object."

First, the control script. This is nested conditions that will create a "double flash." This bit of script is in my main "logic gauge" in the <Update> section.
Code:
    <!-- STROBE LIGHT FLASHER -->
    (A:LIGHT STROBE,bool)
    (A:ELECTRICAL MASTER BATTERY,bool)
    and
    if{
       (P:Absolute time,seconds) 2 % 0.4 > !
       if{
          (P:Absolute time,seconds) 0.2 % 0.1 > !
          if{ 1 (>L:B737_Strobe,bool) }
          els{ 0 (>L:B737_Strobe,bool) }
         }
    }
Here is the modeldef.xml entry for the strobe light visibility:
Code:
  <PartInfo>
    <Name>B737_light_strobe_vis</Name>
    <Visibility>
      <Parameter>
        <Code>
          (L:B737_Strobe,bool)
          (A:LIGHT STROBE,bool)
          and
          (A:ELECTRICAL MASTER BATTERY,bool)
          and
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

Bill #1, is the first block of code that you posted for the switch to operate the light? Or does it go in modeldef.xml somewhere? I'm not exactly sure what you mean by the <Update> section, but then again, I'm still a newbie. :o
 
Bill #1, is the first block of code that you posted for the switch to operate the light? Or does it go in modeldef.xml somewhere? I'm not exactly sure what you mean by the <Update> section, but then again, I'm still a newbie. :o

Oy vey! Now that is a loaded question... :)

First of all, no that is not a switch. It is simply the logic that will create a trigger to flash twice. Sort of a "blink-blink - pause - blink-blink - pause" sequence.

Second of all, it can be used within an <Update> section within an XML "gauge" or in the modeldef.xml file when attached to a simple hidden polygon in the model.

In an XML "gauge" you can create a separate section named <Update>. Scripts placed in this section will be evaluated every gauge cycle, or if desired can be slowed down. You are only allowed one <Update> section per gauge.

If you create a tiny object in your model, you can use the Attach tool to assign this "Visibility" script to that object. Whatever is put between the <Code> and </Code> tags will be evaluated constantly.

Code:
  <PartInfo>
    <Name>Logic</Name>
    <Visibility>
      <Parameter>
        <Code>
             <!-- PLACE ALL 'LOGIC' SCRIPTS HERE -->
        </Code>
      </Parameter>
    </Visibility>
  </PartInfo>

All XML scripts may be easily accessed and modified by anyone. The major advantage of using the second (hidden polygon/script attached) technique is that it makes it very difficult (not quite impossible) for anyone to access and modify your script(s).
 
Last edited:
Alright, thanks, I think I'm starting to understand it now. So both of those codes go into modeldef for the light object, or just the visibility script? (I apologize for my programming ignorance. :eek:)
 
If you need practical examples for the implementation of custom code into a model, check my Do-328. It's, handily enough, in .max format.


Basically, custom code goes into the modeldef and has to be assigned to the part by the animation manager or attachpoint tool.
 
In practice this will require THREE separate entries in your modeldef.xml file:
  1. Switch to turn on/off the light
  2. Script to control the <Visibility> of the light
  3. Script to provide the "logic" for the light's operation
 
Basically, custom code goes into the modeldef and has to be assigned to the part by the animation manager or attachpoint tool.

I can grasp THAT part, but the weird thing is, new entries for animations are not showing up in my anim manager. I've even created a new category of animations, and that will not show either. Also, will a new visibility tag show up in AttachPoint if only the <PartInfo> entry is made? I'm not seeing any other corresponding entries in that file for visibilities (like how animation tags have their GUIDs and other info towards the top.)
 
:confused: I'm reinstalling the P3D SDK because Max is not recognizing any changes I make to modeldef.XML...Even moving it to another location yields a still-working Animation Manager, and all of the ACES Tools are working as if the file was still there. :confused: I know that I have the right one!! :mad:

Max Plugins path: "C:\Prepar3D SDK\Environment Kit\Modeling SDK\3DSM2012_x64\Plugins"

ModelDef path: "C:\Prepar3D SDK\Environment Kit\Modeling SDK\bin\modeldef.xml"

:confused::confused::confused: Unless I'm missing something, those paths should be correct. Yep...I'll be downloading an reinstalling the SDK to see if that helps. :rolleyes:
 
Eureka! Well, sort of. :rolleyes: Re-installing the SDK did in fact solve the issue. I still have no idea why my new entries weren't showing up in the ACES Toolset, but at least they are now. :D Time to start learning some code! :wizard:
 
Back
Top