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

Can't find the .bgl

J

John Young

Messages
158
Country
unitedkingdom
I'm really impressed with this program and thanks for developing it. I've managed to place all my taxi and runway lights and want now to add some approach light arrays.

I know how to edit the Def file and I can generate the array .bgl file. However, I understand that I still need to make a library file for the array. I can fill out the library screen and when I click "create library" the program produces a series of small black windows as it works through the process. However it then terminates with a message that the process can't find the .bgl I just generated because it's in use by another program. There are no other programs open.

Could you possibly suggest what's happening and how to correct it please?

John
 
That is a Windows message being "parroted" by AFLT. Either you have the folder in which that file resides open on your desktop or, for whatever reason, the file is locked (not released by the last application to open it.) If the latter, a restart my help.
 
It must be a single minded parrot. No matter what I do, I always get the "can't find the .bgl" message when generating the library. However, now that I know what I am looking for, I can see that all the files have been compiled anyway and I can see the array in the sim, so all is fine. Thanks for your help.

John
 
Please send me your library folder and state the exact contents of the error message.

Don
 
Don, just before I do that could I just check with you on how to create a lights only array. I can see the array in FS9 when it is compiled with the bases. I've tried 3 things to compile without the bases:

Checking "light only" before I click "Make Array"
Clearing and not clearing "All in One override" when making the library
Adding a "_LO" suffix to the light name in the .def file.

However, when I do any of these things nothing shows.

John
 
Adding _LO to the type in the .def file generates light only in an array. The first method has no effect on array generation and the second would make no difference since a Light-only element is an all-in-one element.

Did you make an object library of the array elements after creating the array and copy (or have the system copy) the library to an active scenery folder?

Don
 
I've just re-tried adding _LO as a suffix to each light type in the def file. After making the array, creating the library and copying the two .bgl files to FS9, the array shows but with the bases present.

My library folder is attached. That includes the def file with the _LO suffixes and a screen shot of the error message after making the library.

Note that the def file is purely experimental at this stage but contains some of the elements I will use when I come to create the array proper.

John
 

Attachments

John. I don't see anything wrong and the libraries compile fine for me.

What I'd like to see is a screenshot of the Make Library dialog just before you click Create/Save Library

The only thing I can thing of is that you are attempting to save the library into your Library folder (which is in use) rather than to a scenery folder active in your scenery library.

Don
 
Thanks Don, that is indeed the explanation. I've just done a fresh compile of the array and the library, but this time saving directly to the scenery folder in both cases. There was no error message this time. Also unchecking the "All in One" override in the make library screen has enabled a lights only array in the sim.

That's great. I've now learned how to make taxiway lights, runway lights, PAPIs (very much easier compared to hand coding separation planes) and approach light arrays with and without the supplied bases. Now to do the approach light design proper and work out how to associate it with my own Gmax model for the bases.

John
 
The approach array, now properly specified in the def file is working very well with my own bases. Just two questions please Don:

1. Can I change the spread of the approach lights in the def file? I think they are set at 90 degrees, ie 45 degrees either side of the centre line by default, I'd like them a bit wider than that if it's possible, but how do I do it please?

2. If I want an array with brighter lights, I can duplicate the def file entries and that certainly works. Is that the best way of doing it please?

John
 
1. Can I change the spread of the approach lights in the def file?
Click to expand...
You can set it to anything you like up to 180. (Not sure what will happen if you set it > 180 - probably 180 - x.

2. If I want an array with brighter lights,
Click to expand...
Just increase the number of bulbs for the lights you want brighter.

Don
 
Don, I seem to have a heading dilemma with my approach light arrays.

I’ve created a simplified Calvert approach light array, typical of RAF airfields in the 1980s. The foreground runway end in the screen shot is 23 and the far end is 05. I built 23 first as it’s longer and has more bars. It displayed fine.

I then copied and pasted part of the 23 array def file for the 05 end, changed the heading by 180 degrees and saved it as a separate file that I also compiled separately with different file names. That worked fine in isolation because I had temporarily removed the 23 files while I built and tested the 05 array. However when I put the 23 files back into the scenery folder, they immediately caused the 05 lights to reverse their direction – hence the green threshold lights at the far end and the white lights at that end on the wrong side.



I could put the 05 lights in the same def file as the 23 ones and take the measurements either side of the ARP, but how do I reverse the direction of the 05 set of lights, whether I do it like that or whether I have two separate files please?

If I change the heading of the 05 array by 180 degrees, that also reverses the 23 end too, even though the files are separate. I also tried making the spread of the approach light in the “types.txt” file -180 for the 05 compile just in case that might be the answer. Alas it did nothing.

What do I need to do please?

John
 
When you copied the 23 data and reversed the heading, did you also change the reference position and tags?

You don't need two separate files, you only need data specific to each end, properly referenced and "tagged" differently so that the correct library items are generated.

If theses questions don't prompt you in the right direction, please send me you Library folder so that I can see exactly what you have done..

Don
 
Don, the reference position in each file is the position of the green threshold markers for the respective runway end. I'm not clear how the tagging information needs to be entered/differentiated for the two runways. At the moment it consists only of the light colour, just like the sample def files. I have attached the 05 and 23 files so you can perhaps tell me what needs to be added/changed please.

John
 

Attachments

Please read the fifth paragraph of Appendix "C" of the user manual. You have used the character string "tag" as the tag in both cases. Consequently, not all required library objects are being generated.

The tags must be unique for each array. Either define unique tags or delete the string "tag" in which case AFLT will use the default.

Don
 
Thanks Don.

I wasn't expecting a reversal of one heading in the sim when the two independent files were used together - the file names were different, the lat/long positions in the headers were different as were the headings. I didn't appreciate the significance of the word "tag" because I just copied the header line from one of the def file examples as my starting point and assumed it should remain like that.

However, I have now substituted "05" and "23" for the word "Tag" in the header line of the respective def files and that has solved the problem and put both arrays in the right direction.

For next time, if I put both arrays in a common def file, sharing the same reference position and heading in the header, I presume that a supplementary string needs to be added to each element line to put each light in the right direction? I'm not clear how that is specified, is it just "| 230" for example, or does the block of lights for the reciprocal end have it's own header?

An example in the pack of a def file with two arrays might be useful.

John
 
I wasn't expecting a reversal of one heading in the sim when the two independent files were used together - the file names were different, the lat/long positions in the headers were different as were the headings
Click to expand...
.Yes, that's all true. But everything is put into a single library file - or two (one for lights and one for bases) if you omit the "_LO" suffix. Please check the third paragraph from the bottom of page 17 of the User Manual. You'll see that the tag is an essential element of library object naming. When you compiled the first .def file you created an object oriented in one direction. When you compiled the second file, you created an object oriented in the opposite direction but, since the element name and the tag were the same, the first filename was duplicated and the first-generated file was overwritten and used for both arrays. If you open the Make Library dialog for your current data, you'll see that there are now two sets of objects, one set suffixed with _05", the other with "_23". Before, you would have had only one set - all suffixed with "_tag".

I didn't appreciate the significance of the word "tag" because I just copied the header line from one of the def file examples as my starting point and assumed it should remain like that.
Click to expand...
But you did substitute actual values for everything else in the header line. Why would you assume "tag" should be treated differently - especially in light of the contents of Appendix "C". As well, I'm surprised you didn't find every library object name being suffixed with "_tag" a little suspicious.

For next time, if I put both arrays in a common def file, sharing the same reference position and heading in the header, I presume that a supplementary string needs to be added to each element line to put each light in the right direction?
Click to expand...
You can put as many arrays as you like in a single file. Each must have its own header line defining position and orientation and a unique tag - which, as stared in the manual can be any character string you choose. The only firm requirement for the tag is that it be unique for the reason discussed above. Please note also that it's the heading entry in the header line that controls object heading, not the tag or some supplementary data. Indeed, there is no heading entry in any supplementary data. Therefore if you want to have arrays for both ends of the runway in a single .def file, each end must have its own header line.

Given your focus on complex arrays and the issues you've encountered so far, might I suggest a thorough review of Appendix C is in order. I think you'll find everything you need to know is there. And, once you "know" it, you should be able to generate any array you can imagine. Feel free to ask questions if you don't understand something. But please, spend a little time with Appendix "C" first.

Don
 
Sorry Don, I just didn't grasp that part of light-making. I spent the best part of 40 hours making the arrays. I must have read the manual 10 times and Appendix C a few times more than that. Because the first def file I made (for 23) worked fine with "Tag" still in the header, I assumed it had a default function. 05 worked in isolation too so that rather confirmed that all was OK. I found Appendix C a little vague on how to create an array at each end and an example to show me would have helped. However, we got there between us and I'm grateful for your help.

The program is a "must" for any scenery that uses Gmax ground polygons that cover the AFCAD layer which then hides the default lights. I found making taxi and runway lights very easy and PAPIs were just simplicity itself compared to hand coding separation planes. It was only the combined arrays that threw me. Here's a few screen shots of the finished lights:









Thanks again for adding a new tool to my armoury. I'll do much better with the arrays next time.

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