-
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 Crash
- Thread starter Foxi
- Start date
As I reported earlier, when I use the files originally posted by Foxi, I now get the crash on approach to ENTL as you do
To be sure it was not a problem with the files themselves, I regenerated them using the latest version of AFLT and the Library files also posted by Foxi some time ago. Those crash as well. But, surprisingly, there was no problem with a test flight to one of my own airports which uses every type of light generated by AFLT. And, as I've said on other occasions, no one else is reporting such a problem with their airports.
So, while it certainly appears that the problem lies within AFLT, it would seem to be localized and of limited effect. (That's not an excuse; it would seem to be a fact.)
I will continue to look for the cause of this issue. But, given that:
Don
To be sure it was not a problem with the files themselves, I regenerated them using the latest version of AFLT and the Library files also posted by Foxi some time ago. Those crash as well. But, surprisingly, there was no problem with a test flight to one of my own airports which uses every type of light generated by AFLT. And, as I've said on other occasions, no one else is reporting such a problem with their airports.
So, while it certainly appears that the problem lies within AFLT, it would seem to be localized and of limited effect. (That's not an excuse; it would seem to be a fact.)
I will continue to look for the cause of this issue. But, given that:
- there is absolutely no diagnostic information given when the crash occurs,
- we're dealing with effects (one of the least-investigated aspects of Flightsim) and
- AFLT does some very unusual things in order to get synchronized blinking and directionality with effects - neither of which is possible with stock capability,
Don
I have good news, sort of. After a day and a half of repeatedly flying from ETNU to ETNL, I have isolated the cause of the crash as a strobe in very close proximity to another. In both .def files, there is a cluster of 3 strobes at a distance of 3000' - one 62.5' on either side of the centerline and a third 65' to the left - less than 1m from one of the other two.
As far as AFLT is concerned, this is a valid arrangement. However, it appears FS9 doesn't like it. If you leave the third strobe out of the arrangement, there is no crash. But, it's not the strobe itself that's creating the problem since, if you leave in the third and delete the other two, there still is no crash.
There a similar arrangement at 1500' but, in that case, the third strobe is 5' from its neighbour - which is not causing an issue.
Curiously, if the aircraft is at ETNL, FS9 copes with these arrangements very well. So, whatever the underlying issue, it seems to relate to initializing the display of a models in close proximity when approaching from a distance. That being the case, in the absence of any diagnostic information at the time of the crash, all I can do is put a note in the manual to that effect.
Don
As far as AFLT is concerned, this is a valid arrangement. However, it appears FS9 doesn't like it. If you leave the third strobe out of the arrangement, there is no crash. But, it's not the strobe itself that's creating the problem since, if you leave in the third and delete the other two, there still is no crash.
There a similar arrangement at 1500' but, in that case, the third strobe is 5' from its neighbour - which is not causing an issue.
Curiously, if the aircraft is at ETNL, FS9 copes with these arrangements very well. So, whatever the underlying issue, it seems to relate to initializing the display of a models in close proximity when approaching from a distance. That being the case, in the absence of any diagnostic information at the time of the crash, all I can do is put a note in the manual to that effect.
Don
Both. Despite the similarity to effects type 25 vs 19, it seems to have nothing to do with the specific light source. Increase the separation between those two lights and the problem should go away.
Don
EDIT: After further investigation, it seems that while the cause seems common for both effects and BGL_LIGHTs (i.e., proximity of models), there appear to be different limits. With BGL_LIGHTs, FS9 tolerates the 5' separation of the elements at 1500' (but not the 2.5' separation at 3000'), suggesting a limit of about 3-4'/1m. However, when substituting effects for BGL_LIGHTs, one of the elements with 5' separation at 1500' must also be removed. Fortunately, the problem appears to affect only strobes.
Last edited:
After many flights between ETNL and ETNU (Both arrays) is something I noticed.
1. With your base models I still crashes after a while (ETNL-ETNU-ETNL-ETNU-crash) With or without strobes. All Lamps min. 10ft apart.
2. Have I then look at your base models looked at MCX
For all 2 Attachpoints can be seen with the same name.
3. I then even gave me a lamp built with Gmax and her only a Attachpoint. As long as I mdl in MCX not new export them so work the approach lights.
4. The MCX set Attachpoints not work. (Visible light in the wrong place and at the wrong angle)
5. strobes with my lights and effects, I have a Strobearray addition to the actual, but only the lights. See Image.
6. BGL_light With Strobes I continued irregular crash with my Lamps.
7. When you make a PCL = True in the types.txt my approach lamps are lit the day on.
8. By my lights, there are also no longer crash when Type = 19 effects
Question: Is there in the creation of lamps to note anything?
1. With your base models I still crashes after a while (ETNL-ETNU-ETNL-ETNU-crash) With or without strobes. All Lamps min. 10ft apart.
2. Have I then look at your base models looked at MCX
For all 2 Attachpoints can be seen with the same name.
3. I then even gave me a lamp built with Gmax and her only a Attachpoint. As long as I mdl in MCX not new export them so work the approach lights.
4. The MCX set Attachpoints not work. (Visible light in the wrong place and at the wrong angle)
5. strobes with my lights and effects, I have a Strobearray addition to the actual, but only the lights. See Image.
6. BGL_light With Strobes I continued irregular crash with my Lamps.
7. When you make a PCL = True in the types.txt my approach lamps are lit the day on.
8. By my lights, there are also no longer crash when Type = 19 effects
Question: Is there in the creation of lamps to note anything?
Attachments
Last edited:
There meets a MCX error an AFLT problem:
http://www.fsdeveloper.com/forum/th...ect-when-converting-dae-to-fs2004-mdl.432144/
http://www.fsdeveloper.com/forum/th...ect-when-converting-dae-to-fs2004-mdl.432144/
Foxi, the underlying problem is with the way FS9 initializes the display of those models, not the models themselves. For example, the problem with model spacing discovered last week. Whether the strobe models are close together or far apart, they are the same model from the same file in the library.bgl. Perhaps 10' isn't far enough. Perhaps the minimum distance is 12', or 15'. I don't know, and I have no way of finding out other than by experimentation. And in the end, nothing in AFLT is likely to change because the problem doesn't appear to have anything to do with AFLT itself. You can conduct the same experimentation yourself.
It would now seem that the problem is not isolated to strobes. And that's not surprising. Last week, you had two strobes in very close proximity and that's what was triggering the issue then. (I did not attempt to determine whether the problem was the two strobes in close proximity or simply two models in close proximity) It now appears that the problem is triggered by two copies of the same model (of whatever type) in close proximity. Since you now have to fly the route several time for the problem now to recur, it would seem there's something else involved - perhaps angle of approach to the airport - which, at the position of the aircraft (18-24 nm away), could affect the visual distance between two closely-placed models.
I realize you are trying to be helpful. But, the underlying issue still seems to be in FS9's initialization of closely spaced models. AFLT doesn't control model spacing; it puts models where you tell it to. I don't see anything that can be addressed by a change in AFLT. Could I suggest you do some experimentation with the minimum spacing of models to see what works for you. If you find something that can be fixed by AFLT, I'll be happy to consider it.
While I was typing this, you made another post to the effect that MCX is mishandling attachpoints. That explains some of the things you mentioned above. However, even after Arno fixes that issue, you will still not be able to substitute MCX-generated light modes in place of AFLT-generated models (unless Arno also implements some of the functionality in AFLT).
Don
It would now seem that the problem is not isolated to strobes. And that's not surprising. Last week, you had two strobes in very close proximity and that's what was triggering the issue then. (I did not attempt to determine whether the problem was the two strobes in close proximity or simply two models in close proximity) It now appears that the problem is triggered by two copies of the same model (of whatever type) in close proximity. Since you now have to fly the route several time for the problem now to recur, it would seem there's something else involved - perhaps angle of approach to the airport - which, at the position of the aircraft (18-24 nm away), could affect the visual distance between two closely-placed models.
I realize you are trying to be helpful. But, the underlying issue still seems to be in FS9's initialization of closely spaced models. AFLT doesn't control model spacing; it puts models where you tell it to. I don't see anything that can be addressed by a change in AFLT. Could I suggest you do some experimentation with the minimum spacing of models to see what works for you. If you find something that can be fixed by AFLT, I'll be happy to consider it.
. PCL is normally set to "True" for approach lights. Have you programmed PCL to be active at your airport?
Then it would seem the effect type was not contributing to the problem and you can continue to use them if you wish.
.Without seeing your AFLT Library folder, I can't comment.
That seems unusual. Which particular model were you displaying.
Id be surprised if they did work! AFLT does far more than simply add attachpoints.
While I was typing this, you made another post to the effect that MCX is mishandling attachpoints. That explains some of the things you mentioned above. However, even after Arno fixes that issue, you will still not be able to substitute MCX-generated light modes in place of AFLT-generated models (unless Arno also implements some of the functionality in AFLT).
Don
Foxi, there's no point in sending me just pictures. If you want me to investigate something like this, I also need the files of concern.
I can assure you, my base models have but a single attachpoint. Once processed by AFLT, that single point may be expanded into several more - depending on the purpose of the model - but they all have different name suffixes.
In any case, if this were a problem due to the number of attachpoints, wouldn't you think it would have some affect close-up?
Don
I can assure you, my base models have but a single attachpoint. Once processed by AFLT, that single point may be expanded into several more - depending on the purpose of the model - but they all have different name suffixes.
In any case, if this were a problem due to the number of attachpoints, wouldn't you think it would have some affect close-up?
Don
Foxi, for whatever reason, you have chosen to keep your .def files outside the ALFT Library folder. There's nothing essentially wrong with doing that but, if you want me to investigate your arrays, I need to see their definitions.
Loading the .bgl files you sent, I see two approach arrays for ENTL 28. The first is a series of strobes aligned with the runway. These are not flashing in the daytime. There is also another lighted array offset about 500' to the right of the runway centerline which seems like a rather unusual place for it. But, I can't tell anything more without the .def files.
Don
Loading the .bgl files you sent, I see two approach arrays for ENTL 28. The first is a series of strobes aligned with the runway. These are not flashing in the daytime. There is also another lighted array offset about 500' to the right of the runway centerline which seems like a rather unusual place for it. But, I can't tell anything more without the .def files.
Don
Foxi, the def files refer to what appear to be light models of your own making. But, you didn't include their .mdl files or the types.txt and colors.txt support files, so I can't even compile them. (I know, I didn't ask specifically for those latter files - but, if the problem relates to custom models, I shouldn't have to.)
This is becoming far too complex. If you have a problem with AFLT as I provide it - using it in accordance with the user manual, I'm happy to investigate. I think I have amply demonstrated that. The user manual specifies the base requirements for custom models. If your models meet those requirements and the support files are edited correctly, I'm confident they will work. I simply don't have time to diagnose your custom work.
I'm going to be away from my development system for the next couple of weeks so, I'm afraid you are "on your own" for a while.
Don
This is becoming far too complex. If you have a problem with AFLT as I provide it - using it in accordance with the user manual, I'm happy to investigate. I think I have amply demonstrated that. The user manual specifies the base requirements for custom models. If your models meet those requirements and the support files are edited correctly, I'm confident they will work. I simply don't have time to diagnose your custom work.
I'm going to be away from my development system for the next couple of weeks so, I'm afraid you are "on your own" for a while.
Don