-
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.
FSX There are no 3d objects when creating approach lights.
The airport .bgl you sent is a FSX airport. I'm not surprised things don't work for FS9. SInce USDB does not appear to be a stock airport in either FS9 or FSX, I'm unable to diagnose any further.
That being said, AFLT on my system generates the .mdl files for post and head for FS9 in AFLT_USDB_Bases_9.xml. (AFLT "doesn't care" for which version of Flightsim the airport .bgl applies.) Since FSX uses FS9 base models, the fsx and FS9 .xml should be identical.
That being said, AFLT on my system generates the .mdl files for post and head for FS9 in AFLT_USDB_Bases_9.xml. (AFLT "doesn't care" for which version of Flightsim the airport .bgl applies.) Since FSX uses FS9 base models, the fsx and FS9 .xml should be identical.
Started over... I cleared all the project lights, created approach lights using the CALVERT template.
Posts and heads are missing. In addition, there are problems with BGL lights - they disappear against the background of the aircraft. However, this happens with all transparent FS9 objects if they are used in FSX...I decided to find out what is the reason for the absence of objects - the objects themselves or the object to which they are attached. I created a small 5x5 square with a transparent texture in GMAX. Edited XML, replacing objects with attachment points with this square.
In MCX, I generated a new GUID's and renamed 2 new objects. Then I created new attachment points and compiled them with a compiler for FSX.
All objects are visible and are in their place.
Although it seems that the lights are behind the lanterns - this is not the case... These are the problems of the material of the lights.
Added standard effects to MCX.
It looks like FSX ignores all attached objects if compiled for FS9. Therefore, no effects appear when compiling from AFLT with the "standard effects" option.
Posts and heads are missing. In addition, there are problems with BGL lights - they disappear against the background of the aircraft. However, this happens with all transparent FS9 objects if they are used in FSX...I decided to find out what is the reason for the absence of objects - the objects themselves or the object to which they are attached. I created a small 5x5 square with a transparent texture in GMAX. Edited XML, replacing objects with attachment points with this square.
In MCX, I generated a new GUID's and renamed 2 new objects. Then I created new attachment points and compiled them with a compiler for FSX.
All objects are visible and are in their place.
Although it seems that the lights are behind the lanterns - this is not the case... These are the problems of the material of the lights.
Added standard effects to MCX.
It looks like FSX ignores all attached objects if compiled for FS9. Therefore, no effects appear when compiling from AFLT with the "standard effects" option.
Last edited:
tgibson
Resource contributor
- Messages
- 11,453
- Country
Hi,
If there is ANY exclude file covering that area, the attached objects (the legs and the heads) will not appear, even if the exclude file is present in a scenery folder with a lower priority than the AFLT BGL files. ANY exclude file. Try removing all exclude files that cover that airport (temporarily) and see if they appear then.
If there is ANY exclude file covering that area, the attached objects (the legs and the heads) will not appear, even if the exclude file is present in a scenery folder with a lower priority than the AFLT BGL files. ANY exclude file. Try removing all exclude files that cover that airport (temporarily) and see if they appear then.
Andrew, it's not clear what you are trying to accomplish. In the absence of you stating it explicitly, it is clear from my first couple of responses that I assumed you were using FS9. At no point have you taken issue with that assumption. Now it seems you are using FSX.
I have confirmed - and so have you in the AFLT .xml excerpt above - that AFLT does generate the .mdl files for the post and heads. I have further confirmed that all these 3D models display at your airport in FSX on my system - though I had to add a flatten since the default terrain elevation is nearly 300' (90 m) whereas the airport ARP elevation is just over 7m. (Even without the flatten, all the models display at default elevation.)
But, I would note one thing. Presumably, you are using the Russian version of Windows. A while ago, one of your countrymen had difficulty with another of my applications (TS Pro) using Russian Windows. The crux of the matter was that, under certain, as-yet-undefined circumstances, Russian Windows and/or NET Framework seems to handle Guids differently from their English/US counterpart. It seems significant now that when you replaced the guids, all was well.
This seems more than a coincidence. Consequently, I will take another look at the situation and report back.
I have confirmed - and so have you in the AFLT .xml excerpt above - that AFLT does generate the .mdl files for the post and heads. I have further confirmed that all these 3D models display at your airport in FSX on my system - though I had to add a flatten since the default terrain elevation is nearly 300' (90 m) whereas the airport ARP elevation is just over 7m. (Even without the flatten, all the models display at default elevation.)
But, I would note one thing. Presumably, you are using the Russian version of Windows. A while ago, one of your countrymen had difficulty with another of my applications (TS Pro) using Russian Windows. The crux of the matter was that, under certain, as-yet-undefined circumstances, Russian Windows and/or NET Framework seems to handle Guids differently from their English/US counterpart. It seems significant now that when you replaced the guids, all was well.
This seems more than a coincidence. Consequently, I will take another look at the situation and report back.
Is the English version of Windows for development or FSX? Which version of FSX did you use for the tests? In early versions (without service packs), there were almost no problems with scenerys FS9. With the advent of SP1, the simulator has become completely different. I have FSX SP2.
Just re-reading your series of posts, in your initial post you said:
Approach_T_1_x_0.00_White.mdl and Approach_T_4_x_1.00_White.mdl (which I have confirmed are present in the material you sent in Post #5 above), so separate placement data is not required.
I appreciate this does not solve your issue (which I remain convinced is a guid-related problem in the Russian version of Windows 10 for which I have yet to find a solution). But, this may aid in your understanding of what's going on "inside" AFLT.
I This is normal. The post and heads are not called separately. The required number of each are called via attachpoints in the .mdl files for
Approach_T_1_x_0.00_White.mdl and Approach_T_4_x_1.00_White.mdl (which I have confirmed are present in the material you sent in Post #5 above), so separate placement data is not required.
I appreciate this does not solve your issue (which I remain convinced is a guid-related problem in the Russian version of Windows 10 for which I have yet to find a solution). But, this may aid in your understanding of what's going on "inside" AFLT.