• 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.

MSFS20 msfs 2020 runway approach lights

It's good to see you are comprehending the SDK methods to a level of higher confidence. :)


But... Hah, 10:1 odds says you will be humbled by XML coding like the rest of us (at some point). :rotfl:

Your ENKH pre-release formatted XML source code is 18,682 lines long. :yikes:

I'm wagering your future project(s) will exceed 50,00 lines of formatted XML code each. :duck:

Oh, and that is not including your custom glTF 3D models (...with LODs for MSFS 2024).


NOTE: All the above assertions are a good thing, as I like the attention to detail I see in your projects.


BTW: Time permitting, I'll share feedback on a few things you previously asked about with your ENKH project, later today or tomorrow.

Other than the intended feedback focused on your prior inquiries, your project detail, size, and appearance in MSFS is quite exceptional.

GaryGB
 
Last edited:
GaryGB said:
It's good to see your are comprehending the SDK methods to a level of higher confidence. :)


But... Hah, 10:1 odds says you will be humbled by XML coding like the rest of us (at some point). :rotfl:

Your ENKH pre-release formatted XML source code is 18,682 lines long. :yikes:

I'm wagering your future project(s) will exceed 50.00 lines of formatted XML code. :duck:


BTW: Time permitting, I'll share some feedback on a few things you previously asked about with your ENKH project, today or tomorrow.

GaryGB
Click to expand...
Well. I'm already overwhelmed. I have no idea what that means, and why or how I should do anything about the xml code! :yikes:
 
One might be able to do all one needs with creation / editing via the MSFS SDK DevMode GUI, but some things are easier to do via XML.

It would also be good to have graphical editors such as ADE and SBuilderX (enhanced for 2020 / 2024 ?) brought out of retirement as tools.

Tomt478's recent very large FSX project really required use of multiple applications to implement and troubleshoot features.

I would expect MSFS projects combining larger scenery areas surrounding Helipads (especially using Lights and other features that can only be used within a assigned Test Radius of probably "multiple" invisible airport ARPs), will require use of multiple applications to prevent burnout.

The good news is, the MSFS XML code we use now is more logical / easier to make sense of than FS2Kx, even if we still RTFM the SDK Docs.

GaryGB
 
Last edited:
GaryGB said:
One might be able to do all one needs with creation / editing via the MSFS SDK DevMode GUI, but some things are easier to do via XML.

It would also be good to have graphical editors such as ADE and SBuilderX (enhanced for 2020 / 2024 ?) brought out of retirement as tools.

Tomt478's recent very large FSX project really required use of multiple applications to implement and troubleshoot features.

I would expect MSFS projects combining larger scenery areas surrounding Helipads (especially using Lights and other features that can only be used within a assigned Test Radius of probably "multiple" invisible airport ARPs), will require use of multiple applications to prevent burnout.

The good news is MSFS XML code we use now is more logical and easier to make sense of than FS2Kx, even if we still RTFM the SDK Docs.

GaryGB
Click to expand...
But why do one need to consider the number of coding lines?
 
Nightstalkernor said:
But why does one need to consider the number of coding lines?
Click to expand...

First, my Jovial reference to the number of lines of code in a XML editor was an indirect reference to the amount of details you included in your project; it was not intended as a critique, but rather as a compliment. :)

The number of lines of code in a XML editor will likely always correlate with the amount of details one includes in a project.

Generally speaking, more details = more complexity = more lines of code required to implement it.


For MSFS, one is not required- and typically may never need- to work with the XML code in an editor, and can instead just use a GUI.

In some ADE or MCX dialogs, we have the option to work with selected parameters in a "Table" format, called the "Raw" view by ADE


You can open one of the XML files in your PackageSources folder chain of your project using NotePad++ (for example ENKH.xml).

https://notepad-plus-plus.org/downloads/


Then navigate in NotePad++:

NotePad++ Menu > Plugins > XMLTools > PrettyPrint - Indent Attributes ...to view XML code in a 'formatted' layout.


The XML code works either in the horizontal 'single line-oriented' format or vertically-expanded 'multiple line-oriented' format.

The vertically-expanded 'multiple line-oriented' format makes it quicker / easier to view / inspect for missing markup characters.

The trade-off is, it requires more lines to display the formatted XML code / characters, so it ends up with more line numbers.


The sub-sections within the XML are referred to as "XML Elements".


This is a way to see how simple- and familiar- XML code can be, when one takes a look "under-the-hood" at what compiles to BGLs. :pushpin:

GaryGB
 
Last edited:
GaryGB said:
First, my Jovial reference to the number of lines of code in a XML editor was an indirect reference to the amount of details you included in your project; it was not intended as a critique, but rather as a compliment. :)
Click to expand...
Ah! :) Thanks for the clarification, and the compliment. I appreciate any feedback, so I was curious about how the xml plays a role inn scenery creation and if I need to have it in mind.😁
GaryGB said:
The number of lines of code in a XML editor will likely always correlate with the amount of details one includes in a project.

Generally speaking, more details = more complexity = more lines of code required to implement it.


For MSFS, one is not required- and typically may never need- to work with the XML code in an editor, and can instead just use a GUI.

In some ADE or MCX dialogs, we have the option to work with selected parameters in a "Table" format, called the "Raw" view by ADE


You can open one of the XML files in your PackageSources folder chain of your project using NotePad++ (for example ENKH.xml).

https://notepad-plus-plus.org/downloads/


Then navigate in NotePad++:

NotePad++ Menu > Plugins > XMLTools > PrettyPrint - Indent Attributes ...to view XML code in a 'formatted' layout.


The XML code works either in the horizontal 'single line-oriented' format or vertically-expanded 'multiple line-oriented' format.

The vertically-expanded 'multiple line-oriented' format makes it quicker / easier to view / inspect for missing markup characters.

The trade-off is, it requires more lines to display the formatted XML code / characters, so it ends up with more line numbers.


The sub-sections within the XML are referred to as "XML Elements".


This is a way to see how simple- and familiar- XML code can be, when one takes a look "under-the-hood" at what compiles to BGLs. :pushpin:

GaryGB
Click to expand...
Thanks for the tip! :)
 
GaryGB said:
BTW: Time permitting, I'll share feedback on a few things you previously asked about with your ENKH project, later today or tomorrow.
Click to expand...

Some MSFS 2024 mandatory updates were pushed by Asobo, and my MSFS 2020 SDK was not up to date yet, so, I may post this weekend.

When I do so, it will likely be in your original ENKH main thread. ;)

GaryGB
 
Quoted from Arno's post on Page-1 of this same thread:

https://www.fsdeveloper.com/forum/threads/msfs-2020-runway-approach-lights.459915/post-933215

arno

MSFS20 Post in thread 'msfs 2020 runway approach lights'

GaryGB said:
Arno: Assuming MCX is actually able to properly read MSFS 2020 and 2024 Scenery Library Object BGLs...

* Are there MSFS Effects "Attached" to glTF 3D models that are not shown in MCX dialogs (yet) ?
Click to expand...
MCX can read MSFS BGL files correctly. But attached effects are stored in the model XML file and MCX does not support all options there yet. So it is likely that you can miss certain attached effects. If anybody has more pointers in common types that are used I can try to add support for them as well.
GaryGB said:
In other words, can MSFS Effect attachment be done via placement BGLs and...
Click to expand...
  • Like


Also quoted from Arno's post on Page-1 of this same thread:

https://www.fsdeveloper.com/forum/threads/msfs-2020-runway-approach-lights.459915/post-933266

arno said:
Hi Gary,

That warning is about an animation, so that has nothing to do with the attached objects that are shown. It means that MCX does not have a definition for the animation that is used and that can give issues if you export the model again. In the animation editor you will see this animation highlighted in pink.

I need to double check, but I don't think MCX can read all information from the model XML yet. I still need to implement a good mapping for that.
Click to expand...

Hi Arno:

I would like to look further into how the MSFS default VHHX sequential Approach Lights that use a number of features ...actually work.


How might we best derive info regarding the way those specific lights are coded ? :oops:


I see via MCX Attached Objects Editor that MSFS SDK Visual Effect "Lights" appear to be used.


I also see via MCX Animation Editor that Animation is used as well.

IIUC, you inferred that the Animation may not be the mechanism which controls the VHHX sequenced Approach Light itself.


I am not certain where else one may look to see how those VHHX lights are controlled for sequencing, and triggering (if any).


As to: "MCX does not have a definition for the animation that is used and that can give issues if you export the model again.":

I would not propose re-exporting or re-packaging the MSFS default VHHX Approach Light Animation and compiling it.


My goal is to see how the MSFS default VHHX Approach Lights are coded / implemented so we can all make such Light arrays.


I anticipate that MCX would have a way to derive the code from the scenery library and other contents of the scenery package.

Why does MCX restrict Animation Export of a MSFS default scenery object that sequences Visual Effect Lights via a Animated glTF ?:banghead:


The object in question is not an aircraft or other object containing even remotely proprietary code by a subcontractor with 'secrets to keep'.

AFAIK, most of the FS Development Community attaches Effects via 3D ModelParts rather than via scenery placement code (which I happen to prefer).


If MCX is not allowed to "go there" to derive code for Visual Effect Lights sequenced via a Animated glTF, IMHO MCX is unnecessarily limited. :duck:


IIRC, MS / Asobo pledged to maintain code in an accessible format for default objects, so all can learn how to develop for MSFS equitably.

We need to access this code so we can develop for MSFS and work around the current limitations of MSFS SDK Lightrow / LightSupport methods.


It is apparent this specific MSFS VHHX "meta-object" is by necessity 'custom', and thus not a prepared / fixed Approach Light / Lead-In Strobe Array.

And, it does not, IIUC, utilize the MSFS SDK Lightrow / LightSupport methods, which reportedly would be too 'feature limited'.



FYI: MCX Attached Object Editor reports use of a Visual Effect *.Fx format object:

General Name: light00

AutoGeneratedFileName: fx_lightFFFFFF_0.2

Use AutoGeneratedName: True


Did MCX correctly identify this Effect Light ?

I can not find a path from which the Visual Effect "Lights" object is sourced, as MSFS shows no listing for that object name in a Search with the "Everything" utility.

https://www.voidtools.com/


Is it possible the object is an "aliased" Visual Effect used by MSFS to implement the MSFS default VHHX Approach Lights ?


Does MSFS source Visual Effect objects from a DLL and allow use of 'Friendly Names' as an "alias" for coding purposes ?


AutoGeneratedFileName (for P3D ?) and CustomFileName are not documented in MSFS SDK Docs, or MCX' PDF Manual as of June 09, 2025.

IIRC, the MSFS SDK uses a GUID for Visual Effects; does MCX derive that from the project source (ex: ModelLib object), or would we manually enter the GUID into the above cited CustomFileName field in MCX ?


Studying this MSFS default VHHX_ApproachLight meta-object, I can confirm its source, as seen at the bottom of this image:

MSFS_2020_Default_VHHX_Dev_Camera_ApproachLights-1.jpg


I can also confirm the Light is a Visual Effect attached to the scenery library object "ApproachBlink" as seen in this image:

MSFS_2020_Default_VHHX_ApproachBlink_MCX-1.jpg


...as well as in the images posted earlier above on Page-1 in this same thread:

https://www.fsdeveloper.com/forum/threads/msfs-2020-runway-approach-lights.459915/post-933263



I am not yet certain how we would access code that provides the "effectParams" MSFS equivalent to trigger / control Visual Effect files by glTF.

I see no way in June 09, 2025 MCX to extract code to provide the "effectParams" MSFS equivalent to trigger / control Visual Effect files by glTF.


As you may have noted in this directly related thread (elsewhere):

https://www.fsdeveloper.com/forum/t...-and-day-night-activation.460036/#post-934084

...there are limits to what can be achieved using MSFS default Approach Lights via LightRow / LightSupport methods.


IIUC, if one wishes to have a local light flash reflecting off nearby object surfaces, one can instead use a sequenced Visual Effect.


Must we do some further de-compilation of code in glTF and/or other files, to see how MSFS coded these VHHX lights ?

Can we make sufficient headway with this inquiry by using the current build of MCX and/or other MSFS file de-compilers? :scratchch


Thanks in advance for clarifying how we might gain better understanding of methods used at VHHX, that 'we' can also use to achieve our own goals. :)

GaryGB
 
Last edited:
You must log in or register to reply here.
Back
Top