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

FS2004 Can't Get Started

Hi,

Using a freshly downloaded 41.11 now. I deleted my entire AFLT folder and started over fresh with a new Project.

Re: the Texture folder path. I entered three different things into the Scenery Folder Path box and tested where the textures ended up.

1. CalClassic Core - textures placed into the CalClassic Core/texture folder
2. CalClassic Core\scenery - textures placed into the CalClassic Core\texture folder
3. CalClassic Core/scenery (the one I used the first time) - textures placed into a CalClassic Core\scenery\texture folder.

So it was because I used a forward slash instead of a reverse slash. I'll have to be more careful, but I would bet others might make that mistake?
 
I'll check the validity of the scenery folder entry. That, at least, will raise an alarm.

Hopefully there's an equally simple explanation for the approach tower legs.

Don
 
I still have the bars with no legs on the approach lights. Project file attached. This project uses the KSAN BGL file I posted, not the XML file.

EDIT: The bars are there day and night, but just the bars.
 

Attachments

Last edited:
Here is an example of some of the duplicated lights in the KSAN project. I have dragged the duplicates away from the other light(s) and placed a red circle around them. There are cases where there are more than two lights on top of each other.

aflt_ksan_dupes.jpg


I guess I confused you about the color "problem". The lights appeared to be different colors because there was more than one light shining at one spot. There is no color problem.
 
BTW, the pattern of lights is not the same as in the ADE file (or in FS).

Here is the same area in ADE:

aflt_ksan_dupes_ADE.jpg


and the same area in FS2004 using the ADE lighting:

aflt_ksan_dupes_FS.jpg


If you can make them out, there are taxiway lights only on one side of this taxiway, and there are no lights inside the taxiways themselves.

Here is the AFLT lighting in FS:

aflt_ksan_dupes_FS_AFLT.jpg


As you can see, there are lights on both sides of the taxiway instead of only on the upper side. Where the lights are duplicated the lights are brighter (where the lights are very bright there are 3 or 4 lights there). The dimmest lights are the single lights at a given spot, the rest are duplicated. You can also see the lights on the taxiway surface, which are not in the ADE lighting.

I understand that you probably cannot match the location of these taxiway lights exactly since their final location is determined by FS, not by the XML file (as I remember). But I just thought I would make you aware of the situation.

Hope this helps,
 
Last edited:
PS. One thing that might minimize the Scenery Path problem is if there was a ... button next to the box and you could browse to the folder?

But for most people the best advice is probably to just use the main folder name and leave off the \scenery part altogether, as long as the folder is inside the Addon Scenery folder.
 
Last edited:
I took the same project (didn't even quit and restart AFLT after the result above of only having bars again) and compiled to FSX instead. The result:

aflt_approach_fsx.jpg


So the problem only exists with FS2004 compilations, not when you compile to FSX, using the same project.

When I copied the FS9 AFLT BGL files into FSX (after removing the FSX BGL files), FSX displayed only bars. So it's not a sim-specific display problem, the FS2004 BGL just does not display those objects. ModelConverterX shows that the FS2004 BGL file contains those objects, but they are not displayed.
 
Last edited:
I decompiled the FS9 AFLT_ksan_Bases_9.bgl into an XML file. I then loaded that BGL file into ModelConverterX and found out that the GUID for the approach light head is a8ae12cd4c7c88973cb9c3bdbf503e82. Then I looked for that GUID in the XML file. While it is present as a ModelData line at the top of the file, it is not used in the placement information below that. Thus the light heads are never placed, it appears.

Hope this helps,
 
It appears you are using a technique in the FSX Bases file that none of my decompilers can figure out, so I don't know how the approach stands are built in that file. But they do display. Not in the FS2004 version.
 
My, my. You have been busy!!!

Re the scenery folder specification, I have now included proper validation. I didn't include a button because the folder specification is meant to apply to all installed versions of FS, not just the one you are compiling in the expectation that, like me, those who produce airports for application across the FS spectrum will use the same scenery folder setup in all FS versions. But, I will revisit that approach.

Re the "approach leg" issue, I can't reproduce the problem even in FS9. I tried only yesterday using your KSAN files. That's why I suspected a corrupted file issue. Both the legs and the lights are attached to the bar using attachpoints and guids generated on the fly (which is why you didn't find a match). Can you think of anything that you might have added to your FS9 system that would suppress the rendering of those attachpoints?

From a quick observation, I suspect the duplicate taxiway lights problem is related to undesignated taxiways, which are handled differently. If the problem also exists on designated runways, please advise. In the meantime, I will investigate.

Otherwise, it looks like I have a busy day ahead.

Don
 
Further to my earlier post, I have examined the .mdl code of the approach structures in the KSAN project folder you sent (Approach_T_White_5_x_0.75.mdl and Approach_T_White_5_x_1.03.mdl) with my "home-grown" .mdl decompiler and all the necessary attachpoints are there. The guid for the posts is "240b ....." and for the light head is "7ee8 …". Both those guids are included in AFLT_ksan_Bases_9.xml .

I also decompiled the file AFLT_ksan_Bases_9.bgl with BGL2XML and confirmed that the .bgl file does include all the requisite models.

And, finally, I loaded your .bgl files into my FS9. The approach towers displayed normally.

As I said before, I don't experience the issue when the lights are compiled on my system. So, it appears that something in your FS9 system is suppressing the display of the posts and light heads on the support bars. One thing that will do this is if a guid is defined more than once, which could happen if the .bgl file exists in more than one place within the purview of FS9. But, if that were the case, I would expect other 3d models to also be suppressed. Do you see other 3d models?

Approach bars are the only 3D structures that have other .mdls attached. Do you have any FS9 addons that could somehow suppress the display of attached objects?

On another front, I have confirmed that the duplicate taxiway lights only exist on undesignated taxiways. So, it would seem AFLT is getting "confused" when importing undesignated taxiways. Look for another release in the near future.

Don
 
Last edited:
Hi,

When you asked about suppressing the display of attached objects, that rang a bell. In FS2004, we have found that exclude files (even in the same folder as these AFLT BGLs) can suppress effects, depending on the order they load. I wondered - "would this include attached objects?" Well, it does. I removed all of my San Diego exclude files from the CalClassic Core/scenery folder, and the full approach stands appeared. So now I know - it is due to exclude files. I'll play around and see if I can make them show up by changing the (alphabetical?) order of the files.
 
Hi again,

No, the only way I can get the approach stands to display is to make sure that there is no exclude file covering that area that includes exluding library objects. While it doesn't exclude the actual library objects so the bars show up (it shouldn't since it's in the same folder as the library object BGL) it does apparently exclude the attached objects. I can't even put the AFLT files into a higher priority scenery layer, they still don't show up. Once I re-created the exclude bgl file to avoid that area they displayed fine.

One more thing I noticed - the VASI stands are not being placed directly on the ground. You can see that the runway light is indeed on the ground.

aflt_vasi_aloft.jpg


Hope this helps,
 
I'm REALLY glad you have discovered the cause. Thanks for sticking with me on this one. I gather just naming your exclude files "0_ …" doesn't help. This sound like something I should address in the user manual.

There seems little I can do to eliminate attached objects. The base approach structure is a simple bar 0.5 m long. AFLT lengthens the bar as required and attaches however many legs and light heads of the appropriate color as are required - all on the fly. The alternative is a myriad of models - and given the variations needed for both FAA and Calvert systems, there would always be one or more missing.

Re the duplicate taxiway lights. The current method of handling taxiways depend on some extent on consistent naming, i.e. all links in a physical taxiway bearing the same designator. In your case, you have a lot of undesignated links scattered between designated links. While this (presumably) doesn't matter to Flightsim, it's "doing a job" on AFLT. Fixing the duplicate links should be relatively easy. But, coming up with a more reliable algorithm will be somewhat more difficult. But, I do have an idea. It will take me a couple days to flesh it out.

Please let me know of anything else you discover.

BTW, the new release I just made was to address a couple of issues found by Martin Gossmann, one of which relates to P3D, the other to parallel runways, so shouldn't affect you.

Don
 
Tom, if you dowloaded 4.1.12 before receiving this post, please download again.

Don
 
Hi,

I'm glad I figured that out as well. I will download 4.1.12 soon.

Yes, I did try to rename them as _0 and as zzz_ to see if either end would work and neither did. And even when I put the AFLT files into a scenery layer *higher than the exclude files* they STILL excluded the attached parts. Since I only use standard MALSR and Calvert approach lights I will create library objects with the complete structures and when this happens just plop them in using Instant Scenery (much easier than trying to rework all the existing exclude files).

Yes, I really should be better about naming taxiways. But taxiways were not typically named in the era I model, so I don't usually bother. Since my airports have no taxi signs there is no way to use taxi designations to navigate to the runway anyway. As you said, it's not that difficult to delete the duplicates, no problem. The Use Stock Lights is so much easier than starting from scratch so it's worth the work.
 
Since I only use standard MALSR and Calvert approach lights I will create library objects with the complete structures and when this happens just plop them in using Instant Scenery (much easier than trying to rework all the existing exclude files).
Click to expand...
Whatever works best for you. Once I get some "breathing room", I'll explore the issue further to see if there's something I can do in the .mdl file to help.

From the work I've done in the past hour or so, it seems I took a shortcut with undesignated taxiways that is responsible for the duplicates. That will be fixed.

Don
 
I appear to be wrong about the VASI boxes - they do sit on the ground but the legs do not create shadows and thus they appear to be floating.

I'll put aside the approach structure/exclude problem for now, since we know what's causing it.

Other outstanding issues I see so far:

1. Use Stock Lights creates duplicate lights on undesignated taxiways.
2. Use Stock Lights creates lights on the taxiway surface at the junction of designated and undesignated taxiways, as well as the junction between undesignated taxiways.
3. Use Stock Lights with a MALSR approach with no strobes in the ADE file ends up with 5 strobes in AFLT.
4. Use Stock Lights on undesignated taxiways with only one side of the taxiway lighted ends up with lights on both sides. I don't know about designated taxiways.
5. The taxiway and runway lights are pulsing, but only when facing 270 (at KSAN), not when facing 090. It is easier to see during the day for the runway lights, but they both do it. It is not the lights that are pulsing, it's the 3D objects. You must be sitting right in front of the light to see it clearly.

Hope this helps,
 
6. Use Stock Lights with green runway end lights is placed at an angle to the runway:

aflt_ksan_end_AFLT.jpg


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