• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

FS2004 Creating Array and killing shadow

#1
Sorry again but I'm facing with some differences with this new version and something is confusing me.

I have two .def files for two different arrays I prepared. I put them into the array folder of the Library Folder. Then I clic on the Make Array button and in the following window I indicate the .def file from which I want to obtain the array bgl, I also select FS9 under "Save for". At the end of the routine AFLT asks me to indicate bglcomp.exe versions for P3d and for FSX (both of them not installed) answering with a compiling error when I clic on abort. Then I indicate bglcomp.exe for fs9 version. Why AFLT ask me for those .exe if I selected fs9? And how to stop it from asking me again every time I use "make library" option?

The .ini files generated from the .def file (those with "%" in the file name) are now visible from the main AFLT window (Element section) but even if there is the possibility to select Kill Shadow, the Create/Save Element button remains deactivated so it is no possible to modify the option from there instead of making it directly into the .ini file by hand.

Thanks
 

gadgets

Resource contributor
#2
I'll check why the request for the FSX and P3D compilers. Obviously, that shouldn't happen.

As regards the Create/Save Element button being disabled, AFLT is waiting for further input. Please refer to the section in the user manual entitled
UPGRADING FROM AFLT VERSION 1 .

Don
 
#3
Ok I'll check better... thanks

EDIT: I found that the problem was related to the name of the colours used in the previous version.
 
Last edited:

gadgets

Resource contributor
#4
I have found and fixed the error where the path to the FSX and P3D compilers was requested when you compiled arrays for FS9. Please download and install Development Release 2.0.10 from http://stuff4fs.com.

Don
 
#5
Sorry Don, thanks a lot for your efforts but at the moment I have the following problems (v. 2.0.10):

1. The application does not accept anymore the network path to the folder in the other pc (the one in which I installed FS9). I tried to add it manually in the Library.ini file using both the complete path or only the folder as I made till v.2.0.09 but the application does not retrieves the scenery folder.

2. (this was also in v.2.0.09) activating the kill shadow option for an object defined in %.ini file (generated during array construction) in which is defined 2 bulbs, if I do not confirm again 2 bulbs (I have to write again 2 in No. Lights field), when I save the element the application changes the n. of bulbs to 1.

3. (v2.0.09 and also v2.0.10) After I used the Make Array, the Guid of all the objects into the BGL are different from those into the related xml file so the objects are not visible into the scenery.
 

Attachments

gadgets

Resource contributor
#6
1. If you want to force AFLT to look for FS9 on a network drive, try setting the full path in AFLT.ini, not Library.ini. (Flightsim path is common to all libraries.) If you open AFLT.ini, the path entry for FS9 (it must be the fully-qualified path to the folder holding FS9.exe) is the very first item.

2. I've tried a number of scenarios and they all work for me. Please give me step-by-step instruction to force iot to happen.

3. AFLT builds the .xml. It's the compiler that takes it from there. If the guids in the xml file are correct, AFLT has done its job. Are you sure it not just that the guid in the XML is in FS9 format and whatever you are using to decompile the .bgl shows the same guid but in FSX format?

Don
 
#7
1. If you want to force AFLT to look for FS9 on a network drive, try setting the full path in AFLT.ini, not Library.ini. (Flightsim path is common to all libraries.) If you open AFLT.ini, the path entry for FS9 (it must be the fully-qualified path to the folder holding FS9.exe) is the very first item.
OK I think I solved. It was related to the fact that now it seems that the path to be indicated for the "scenery folder path" is to be complete and not only the folder inside the Addon Scenery. Absolute Path and not Relative Path. In this way it works. But I think that the indication "may be relative to Addon Scenery" could be misleading.

2. I've tried a number of scenarios and they all work for me. Please give me step-by-step instruction to force iot to happen.
I open AFLT, from the Element drop down menu I select one of the items, I activate "kill shadow", the number of lights is "2". I leave it unchanged. I simply clic on Create/Save Element without modify anything else. After that it apparently seems to be all ok. But if I select another element and then the last element (the one for which I only activated the kill shadow option) [or simply if I open the related ini file just to check] the number of bulbs was back to 1. If when I activate "kill shadow" I also insert (confirm it because apparently it is 2) "2" in the No. Lights, it remain 2 after saving. There is also some other differences between the .ini file generated from .def using make array and the one saved after simply adding "kill shadow" from the window. I attach an example

Before applying Kill Shadow [the following is the .ini generated by Make Array function using the .def file]

Type=Approach
Guid to Call=4fff6c964d68c71a8d5291ae8fe21c44
Guid to Attach=38a7f2c44456a97c9979ae82d45b1df5
Light Only=False
All in One=False
Use Effect=
No. Bulbs=2
Strobe Firing Sequence=-1
Total Strobe Flashes=0
Strobe Seed=1
Color_Front=App-White
Color_Back=Rwy-Hi [I do not understand why there is this line that is not indicated in the .def file]
Heading (deg.)=104.84
Slope (deg.)=0
Horizontal Spread (deg.)=120
Vertical Spread (deg.)=1
Base Model Name=Approach
Kill Shadow=False

After applying Kill Shadow from the window

Type=Approach
Guid to Call=4fff6c964d68c71a8d5291ae8fe21c44
Guid to Attach=2cc701f64867a3a25a7041ad247bf0d3
Light Only=False
All in One=False
Use Effect=
No. Bulbs=1 [The numer is changed]
Strobe Firing Sequence=1 [This line is changed]
Total Strobe Flashes=16 [This line is changed]
Strobe Seed=1
Color_Front=App-White
Heading (deg.)=104.84
Slope (deg.)=0
Horizontal Spread (deg.)=120
Vertical Spread (deg.)=1
Base Model Name=Approach
Kill Shadow=True

EDIT: the number of bulbs changes to 1 in any case also simply selecting an element with more than one bulb and saving it without changing anything

3. AFLT builds the .xml. It's the compiler that takes it from there. If the guids in the xml file are correct, AFLT has done its job. Are you sure it not just that the guid in the XML is in FS9 format and whatever you are using to decompile the .bgl shows the same guid but in FSX format?
No it is not a problem of FSX/FS9 GUID
-------
I noticed the following: I start from zero AFLT_2010, I indicate the new Library Folder and AFLT create inside the 3 subfolders "Array", "INI", "Ligths". Then I copy inside the Array folder my .def file.
Then I clic on Make Array button, I select the .def file, complexity remain "normal", activate FS9 in the Save for field then I clic on Make Array button. The application start to work and at the end appears the following error

Error.jpg

I clic on OK and in the array folder appears the xml file, but not the related bgl. If I make the same operation again leaving the old xml file the operation goes ok. but (maintaining copy of the preceding xml file) I noticed that the guids indicated in the xml produced now are different from those of the preceding .xml. Moreover using bglanalyzer9.exe with the bgl produced, I can see that it contains the guids of the old xml. So creating the library, in it there are guids not linked to those contained in the BGL.
The attachment I made in my last post has the complete library with .def, .ini, .xml, .bgl made last night.
------

If after the above error, I take the first created .xml file and I bring it on the bglcomp.exe, it generates a bgl that using bglanalyzer9.exe this time has the same guids as the xml.
 
Last edited:
#8
1. If you want to force AFLT to look for FS9 on a network drive, try setting the full path in AFLT.ini, not Library.ini. (Flightsim path is common to all libraries.) If you open AFLT.ini, the path entry for FS9 (it must be the fully-qualified path to the folder holding FS9.exe) is the very first item.
OK I think I solved. It was related to the fact that now it seems that the path to be indicated for the "scenery folder path" is to be complete and not only the folder inside the Addon Scenery. Absolute Path and not Relative Path. In this way it works. But I think that the indication "may be relative to Addon Scenery" could be misleading.
Forget it. Unfortunately, I did not make a complete test to evaluate if the workaround was ok.
This is the error I receive.
Error2.jpg
Notice that in the error there is a strange quotation mark sign before the path. Could it be the problem?
The following is the AFLT.ini file
Code:
Path to FS9=D:\Microsoft Games\Flight Simulator 9
Path to FS9.cfg=C:\Users\Administrator\AppData\Roaming\Microsoft\FS9\FS9.cfg
Path to FS9 Compiler=C:\Program Files (x86)\AFLT_Airfield Lights Toolbox_2010\FS9 Compilers\bglcomp.exe
Previously Selected Libraries=C:\Users\Administrator\Desktop\LIME Project\LIME_AFLT 2010
Dialog Width=825
Light Model=%Approach-3x5F_App-Red_als28_LO
No Check For Update=False
where D is one of the two Hard Drive in my test PC
Just to be complete, I'm using Win 7 64bit with Administrator rights, AFLT is in
C:\Program Files (x86)\AFLT_Airfield Lights Toolbox_2010
 

gadgets

Resource contributor
#9
I found 2 error in 2.0.10. The first only affected FS9-only systems and was responsible for the reports of non-existent files/folders. The other is the one resetting the number of bulbs to 1 - which I haven't yet fixed but will shortly.

I expect to make Development Release 2.0.11 shortly.

Don
 

gadgets

Resource contributor
#10
I have just posted Development Release 2.0.11 to http://stuff4fs.com. It fixes the issues noted. I think you'll find it better behaved.

You'll note a new advisory message when you edit an array element using the Main Panel to the effect that, for changes to be permanent, the .def file must also be edited. This is because the Main Panel updates the .ini file, not the .def file - and the reason you couldn't edit array elements from the Main Panel until you pointed out that there was no facility in the .def file to Kill Shadow. Frankly, I've never had a need to kill shadows in a .def file. Base models such as the approach lighting towers, strobe towers, etc for which you wouldn't want or need shadows, have the shadow suppressed in the .mdl file. If you have created custom models, I suggest you do the same.

Nonetheless, I will investigate adding a Kill Shadow capability to .def files since that's the only capability of Main Panel editing that's not available in .def files.

Don
 

gadgets

Resource contributor
#11
Development release 2.0.11(a), just posted to http://stuff4fs.com, adds a Kill Shadow capability to .def files. To use it. simply preface the "supplementary data" field in each .def file entry to which it is applicable with "K/", or just "K" if there is no other data.

While implementing the Kill Shadow capability for .def files, I encountered another potential bug that may have prevented the Make Array button on the make Array panel from becoming enabled.

Don
 
#12
I have just posted Development Release 2.0.11 to http://stuff4fs.com. It fixes the issues noted. I think you'll find it better behaved.

If you have created custom models, I suggest you do the same.

Don
Hi Don, thanks for this, I confirm I'm using your models (I'm not able to create custom models unfortunately). Particularly I'm using "approach" model (the one single lamp without tower). It has a circular grey base but I noticed that if I use the shadow, on the ground appears a black square surrounding the grey circle. This square is the shadow of the texture that should be transparent. I don't know how to solve it so I decided to kill the shadow to avoid it.
 
#13
Development release 2.0.11(a), just posted to http://stuff4fs.com, adds a Kill Shadow capability to .def files. To use it. simply preface the "supplementary data" field in each .def file entry to which it is applicable with "K/", or just "K" if there is no other data.

While implementing the Kill Shadow capability for .def files, I encountered another potential bug that may have prevented the Make Array button on the make Array panel from becoming enabled.

Don
Thanks a lot, I'm going to try it as soon as possible.

What about the compile error I reported few post above?

Have a good Sunday
 

gadgets

Resource contributor
#14
What about the compile error I reported few post above?
You received an error message before the compile, one that should not be repeated.

Give the new version a try. If you still get that compile error, we'll talk about it.

Dopn
 
#15
Hi Don, Just tried to make the array starting from Array folder with only two .def file inside and after starting the make array routine I receive the Error C2002 again.
But after the error (as explained before) the xml file is correctly generated but not the bgl one. So I start again the make array with the same .def file selected, now it generates again the same xml (I check that both would be exactly equal) and then the bgl correctly

EDIT: I made this test: Inside the Array folder I created an empty .xml file with the same name as the related .def file. Inside the xml file I put the following

Code:
<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0"
   xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
   xsi:noNamespaceSchemaLocation="bglcomp.xsd">
</FSData>
This time the make array function worked ok without errors but the bgl created seems to be empty.
 
Last edited:
#16
Don, sorry if my last posts are a little bit confusing but also for me the situation is not stable.
At the moment the situation is that I cannot generate array bgl and corresponding library correctly linked each other.
I receive the error C2002 as reported above, then after a second attempt (leaving the .xml file, generated after the error, in the array folder) it is generated a bgl compiled but the xml does not correspond at all in GUID (I used BglAnalyzer9.exe just to check) so when I prepare the library, this is not linked to the bgl and the objects are not displayed on the scenery. Tell me (when you are able obviously ;)) if I can help you with other details if you need it.

I'm a little bit frustrated because it is about 6 months that I'm fighting with a G3D.dll crash that I think is due to the approach light system but for which till now I was not able to find the responsible...
 

gadgets

Resource contributor
#17
I do not recognize "error C2002". You haven't mentioned it before. Is that a (Microsoft) compiler error? If so, perhaps you can tell me the nature of the error. (I suspect that is the cause of the guid mismatches. Since you got a compiler error, no .bgl would have been generated. So, you were probably comparing the new .xml with an old .bgl.)

EDIT: I made this test: Inside the Array folder I created an empty .xml file with the same name as the related .def file. Inside the xml file I put the following

Code:
<?xml version="1.0" encoding="ISO-8859-1"?><FSData version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
</FSData>
I have run both Make Arrays and Make Library on the data you sent, without difficulty - both with and without the <xml> statement you added. Nonetheless, I have permanently added that <xml.> statement, just in case some compilers are expecting it, and will be e-mailing you an updated version shortly.

This time the make array function worked ok without errors but the bgl created seems to be empty.
I'm not surprised. That's an "empty" .xml file, which should generate an "empty" .bgl.

EDIT: I just Googled Error C2002. It seems to relate to a special character in the .xml file. Microsoft compilers don't "like" commas (",") as decimal separators or periods (".") where commas are expected. If you are using a non-English version of Windows, perhaps Windows is doing a substitution somewhere.

Don
 
#19
I do not recognize "error C2002". You haven't mentioned it before. Is that a (Microsoft) compiler error? If so, perhaps you can tell me the nature of the error. (I suspect that is the cause of the guid mismatches. Since you got a compiler error, no .bgl would have been generated. So, you were probably comparing the new .xml with an old .bgl.)
I mentioned it in msg n.7 of this thread.


EDIT: I just Googled Error C2002. It seems to relate to a special character in the .xml file. Microsoft compilers don't "like" commas (",") as decimal separators or periods (".") where commas are expected. If you are using a non-English version of Windows, perhaps Windows is doing a substitution somewhere.

Don
Damn, the problem is that ModelConvertX (as it seems) needs to have period as decimal separator so, even if I have my windows in Italian version, I momentarily change the European configuration and that maybe the problem. I'm going to check it.
Thanks for the advice.