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

Airfield Lights ToolBox is Ready

G

gadgets

Resource contributor
Messages
9,388
Country
ca-britishcolumbia
Shortly before Christmas, I announced in this forum I had developed a utility called Airfield Lights Toolbox (AFLT for short). At the time, I was soliciting beta testers.

As the name suggests, AFLT is a utility to create 3D airfield lights and light arrays for FlightSim airports - including:

* omni-directional runway, taxiway and obstruction lights,
* split runway-end lights,
* strobe lights for use in REIL, ODALS and other "running-rabbit" applications,
* approach lights on supports in a variety of configurations,
* PAPIs, several configuration of VASIs and wig-wags, and
* aeronautical obstruction beacons.

But the real magic in not in the creation of individual lights. Rather, it is in AFLT's ability to generate complete runway end and approach lighting configurations based on a simple text array-definition file. As well, pilot-controlled lighting (PCL) is fully implemented. AFLT includes 3D models for a variety of airfield light fixtures and approach lighting configurations from which you should be able to create just about any usual airfield light arrangement.

The beta trial is finished and Airfield Lights Toolbox (AFLT) is available for use. Go to http://stuff4fs.com, navigate to User Applications Airfield Lights Toolbox and download the Development Release.

Development Release? Unfortunately, yes. AFLT uses BGL_LIGHTs and SEPARATION_PLANEs - FS8/FS9 technology which, at the moment are not supported in P3Dv2 and for which currently there is no available alternative. While effects could be used in some airfield lights, it is not currently possible to create sequenced strobes ("running-rabbit"), PAPI/VASIs and wigwags with effects. I understand P3Dv2.1 will support these features. But, until 2.1 is released, I won't know for sure. So, I'm waiting until I know the situation with P3Dv2.1 before releasing AFLT generally - since further changes may be necessary.

In the meantime, if you are running FS9, FSX or P3Dv1.4, feel free to try AFLT. 3D lighting is a great way to improve airport realism.

To avoid cluttering this forum, please report any issues or make your comments in the ADE_GP sub-forum (which at the moment is seldom used) or directly to me by e-mail.

Enjoy,
Don
 
Sorry folks, there is a problem with the archive I posted last night. I have disabled downloading until I figure out what is causing it.

Don
 
We're back in business, folks. Turned out the error message was inconsequential and could have been ignored. New version posted. Or, just delete the last (blank) line in the types.txt file.

Don
 
is it compatible with p3d2 then please?
Click to expand...
As more fully explained on the first page of the user manual, not at the moment. Perhaps P3Dv2.1 - depending on whether or not LM add FS9-compatibility.

Don
 
P3Dv2.1 is out,
Click to expand...
Then I guess I've got some work to do. If P3Dv2.1 "Knows" how to handle BGL_LIGHTs and SEPARATION_PLANEs, then AFLT should be compatible.

I'll do some testing later today.

Don
 
I've just installed the 2.1 update and it appears LM have not fixed BGL_LIGHTs and SEPARATION_PLANEs. Don't know what it is they did fix in that area and haven't had time to review the detailed documentation - if any. The statement
BackCompat Issue - night apron/taxiway/runway approach lighting issues
Click to expand...
doen't really tell me much.

I'll spend some time later seeing what if anything else I can do. But, I'm not hopeful.

Don
 
Dumb question, but where do you install airfield lights? And where is the library? The Manual is not too specific.
 
AFLT is not a library of lights. It is a utility that helps you create a library of lights. If you read the manual in that "light", perhaps it will be more meaningful.
 
Hi Don,

Speaking of your utility, is there a reason you need to create the omnidirectional lights for each airport? Could those be placed into a single "permanent" library? I know you need to create the unidirectional lights each time to get the correct heading.

Thanks,
 
A VERY timely question, Tom. I've just spent the full past two days investigating a problem with a PAPI that turned out to be due to nothing more than me having used the same Guid as a PAPI at another airport. Now, I know your question dealt only with omni-directional lights. But, that experience demonstrates the effect of an error should you accidentally include a directional light in the mix.

The simple answer to your question is "Yes", you could maintain a separate library of Omni-directional lights. But, why bother? Typically, you're only going to have at most, two variations of runway lights (high and medium intensity), three taxiway lights (red, blue and amber) and one obstruction light - for a total of six. Creation of a complete set of omni-lights for each airport involves only a few mouse clicks. The model size for a unidirectional light is only 6kb (including PCL) and for the attached light, another 1 kb. So, that's a savings of, at most 42kb per airport. My CYBL, a single runway airport - albeit with very detailed, realistic models for every building - comes in at nearly 100mb (including textures). On the down-side, the same texture used by the omnis is also used by other models. You need three copies (day, night and "day-glo") each consuming 85kb. Creating and maintaining a separate library hardly seems worthwhile.

Many users have trouble handling one library file. Why invite more trouble by giving them two and the need/ability to make a decision? Unless I've missed the point of your question, it's not something I'd be eager to add to AFLT. That being said, since the user controls the contents of each library file, you could always create a separate file for your omnis and exclude the omnis from the airport-unique library. (Reluctantly, I could add a pair of checkboxes - Omni/non-Omni - on the Library Dialog to make that task easier. Normally, both would be checked. Both files would end up in the /scenery folder of the airport being worked on. It would be up to the user to manage what stayed there and what didn't.)

As well, since I've "got the floor", I want to make users aware of an idiosyncrasy with SEPARATION_PLANEs I encountered during the conversion of one of my airports (replacing hand-tweaked ASM lights with AFLT) AFLT uses SEPARATION_PLANEs in combination to limit the directional visibility of the BGL_LIGHTs. This sometimes involves 3 or more planes. In this particular case, the runway heading was exactly 135. The horizontal spread of the lights was set at 90 degrees. The approach light models were rendered in the proper position but the lights were not illuminated when the user aircraft was on approach path. Instead, each light came on when the aircraft entered the 90 degree sector to its right.

After some investigation, I determined that the cause was the angle between the SEPARATION_PLANEs. I changed the spread of the lights and they operated normally. In fact, they work fine at spreads of 89 and 91 degrees. But, at 90, they shine to the right. I suspect the mid-quadrant runway heading is at the root of the problem, since 90 degrees is OK at another of my airports and this issue was not reported during the beta.

I'll continue to investigate as I convert my other airports. In the meantime, if you should encounter such a problem, I suggest you adjust the horizontal spread of the problem-light.

Don
 
Dale_Reitz said:
Dumb question, but where do you install airfield lights? And where is the library? The Manual is not too specific.
Click to expand...

Dale,

The AFLT assumes a certain level of kowledge about FS/FSX design "principles". At first glance, it may seem a bit esoteric. However, the knowledge required isn't all that much and once you get to a certain point, things sort of "click" so you see what guys like Don are getting at.

I don't know your level of experience/expertise, but I'm going to assume you need a baseline answer here and risk telling you things you already know.

If you look at any stock airport, you will see that runway lights, taxi lights and apron lights are all little starry things floating a few feet over the ground. Well, many of us would rather see something that looks like an actual runway light, with a structure and maybe even a bulb. It's one of those things that makes for a nice touch. Then there is the notion of putting the approach lights (the ones that flash in front of the runway), which now requires some way to make lights flash. It gets icky in a hurry.

A long standing solution has been to use what is called a BGL light and attach it to a structure. Until now, you had to create a model (using gmax or some other modelling progrom), write some ASM code and do jumping jacks while carrying a cup of coffee - without spilling any.

Don has taken all that work and put it into a package so we don't have to. (!) AFLT is a package of structure models for runway lights, taxi lights, apron lights and approach lights. The program is designed so that you can easily place these lights at your airport. The main thing is that his program does all the coding and compiling to attach those nifty BGL lights to the structures. You can do in 10 minutes what used to take 10 days. (or 10 hours for the gurus around here.)

I don't know if any of that helps or just makes things worse. Let me know. Trust me, I know what it's like to see and not understand. My signature is a statement of fact, I assure you.

-MJL
 
Dale_Reitz said:
Dumb question, but where do you install airfield lights? And where is the library? The Manual is not too specific.
Click to expand...

And the direct answer to your questions:

1. You install the BGL files created by AFLT into your individual airport scenery/SCENERY folder, and any textures needed into the adjoining TEXTURE folder. AFLT might do this for you, but I haven't tried it yet. If you don't use a separate folder for this airport, you place them where any other BGL files for this airport have been placed. If you are only adding lights to a default airport, then I guess they could go into any active scenery folder (Addon Scenery/scenery might be logical).

2. The AFLT program creates the library BGL files which are installed in #1 above. Those are the only BGL files it will create for you (AFAIK). Then you need to use ADE or another program (like Instant Scenery) to place these library objects where you need them at your airport (just like placing any other library object). That placement information will end up in a separate BGL file (i.e. your ADE file, or a special file that IS creates).
 
AFLT might do this for you, but I haven't tried it yet.
Click to expand...
Tom, Dale just so we don't prompt people to look for a hard way to do things, AFLT won't create an object library until you tell it into which scenery folder you want the library file placed. When the object library is creates (and copied), any required textures are copied to the companion \texture subfolder for you.

Then you need to use ADE or another program (like Instant Scenery) to place these library objects
Click to expand...
That's true for things like taxiway and runway edge lights, wigwags and PAPIs. However, AFLT creates entire approach light arrays and runway end-light arrays and places these directly. You simply tell AFLT where is the center if the threshold of the applicable runway and define the light configuration in a text file; AFLT does everything else for you - including creating the .bgl file, copying it to the designated destination folder and also copying any required textures. Several sample array definitions are provided which can be used directly after adding the applicable runway specification. You can create an entire ASLF-2 approach lighting system, complete with strobes in little more than the time it takes to specify the position of the runway threshold (obtained graphically from ADE or another airport CAD development program) and the runway heading and elevation (also available from the airport development program.).

Don
 
A short clarification on my clarification.

Yesterday, I confirmed that you could create a separate library for "Omni" lights but that there was minimal benefit from doing so.

While that remains true, I need to point out that at airports where you program airport operating hours (as part of AFLT's PCL capability), even the omnis become unique to that airports. So, you would not want to include them in your "Omni" library or use your "Omni" library with that airport.

Don
 
You must log in or register to reply here.
Back
Top