• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About afterburner

  • Rank
    Advanced Member
  • Birthday 04/17/1983

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    South Carolina
  1. Hi, This is a very old topic, but I wanted to give you an insight on what might be the cause of this behavior. I too experienced a situation where some airplanes (in particular Boeing 737-800) approached the runway too high and declared a missed approach following a go-around (while other airplanes didn't have this problem). I checked the aircraft configuration file of the MyTraffic 737-800 AI-airplane and found the Oswald efficiency factor to be 7.50. In the Prepar3D documentation, I read that a value of 1 represents a perfect wing, so a value higher than one should produce an unrealistic flight behavior. And indeed, after I changed the Oswald efficiency factor of the 737-800 from 7.50 to 0.75, the AI-plane approached the airport on a correct glideslope and no longer did a go-around. I presume that having a value of 7.5 made the airplane's aerodynamics "too good to be true", so it had difficulty gliding down the glideslope without gaining too much speed. So if you experience this issue, try changing the Oswald efficiency factor in the configuration file of the respective airplane.
  2. Burkhard, could I ask you to look at my question #19? I thought to bring this up, since I was concerned that my post could become lost of focus after so many new posts. Thank you!
  3. Hi Burkhard, I have two questions about MyTraffic6: Is it true that the user can no longer use the "simplified" models as in MT5.4 to save FPS? In another thread, you stated that the new version only includes the wide screen format of the models. Does that mean that if you still use a 5:4 or 4:3 format screen, you should expect visual distortions of the models?
  4. Hi, I wanted to bring to attention an issue that has been apparent at the default KORD airport with MyTrafficX 5.4b (I use the "b" version instead of "c", because the latter resulted in unpredictable ntdll crashes). Even if I set airline traffic at only 25% in FSX, all gates are filled with airplanes at that airport. I have attached a "satellite picture" to show that. You can see that literally all parking positions are populated with airliners. As you can imagine, this drags down on the performance and creates unnecessary congestion at the airport. Other airports show much less traffic relative to their available parking spots. Certainly, the ground traffic at KORD can be reduced by tuning down the traffic sliders to let's say 15%, but then there is going to be too few traffic at other airports, while Chicago will still have plenty of it. The imbalance still remains. Do you have the same traffic density at your Chicago airport as well with the same traffic settings? If yes, is there anything that can be done to reduce it without reducing the traffic sliders? (Should I try a different AFCAD file?)
  5. Please also note that the professional version allows you to select between low- and high resolution AI textures, and also to activate or deactivate jetway contact points on AI airplanes. Especially the latter can be an extreme FPS killer if you have your airliner traffic slider high and you start at a huge international airport. A huge chunk of CPU power will be dedicated to processing jetway dockings on airplanes and baggage loading.
  6. Okay, so I did another experiment in KGSP, and this time I have measured the fps in both running and paused modes. The airplane is the same, and the display settings are changed only insofar as I have deactivated ALL ground traffic (service vehicles, cars, boats, ships) in order to avoid confounding of the effects on FPS in running vs. paused mode between ground traffic and air traffic. I am just going to post the FPS range that I have measured for each slider combination without screenshots (since they are a little time consuming) (If required, I can include them later) KGSP (Greenville/Spartanburg), Cockpit view Stock Aircraft Included 0% IFR, 100% GA Run 44-48 fps Paused 70-76 fps 100% IFR, 0% GA Run 59-63 fps Paused 92-100 fps 100% IFR, 100% GA Run 32-34 fps Paused 56-61 fps Stock Aircraft removed 0% IFR, 100% GA Run 84-88 fps Paused 117-125 fps 100% IFR, 0% GA Run 59-63 fps Paused 92-100 fps 100% IFR, 100% GA Run 47-50 fps Paused 86-90 fps 100% IFR, 0% GA, Hi Texture, Jetways active Run 53-55 fps Paused 86-91 fps Conclusion: We can see that pausing the sim does raise the FPS indeed considerably. However, for a mysterious reason, even when FSX is paused, the FPS at 0% IFR and 100% GA are significantly lower (70-76 fps) when stock planes are included, compared to 117-125 fps in the case of stock aircraft being removed. Remember that in both cases, almost no GA planes are visible on the airport. If it is true that most CPU power is allocated to tracking GA traffic, should the frame rates not be the same for stock planes included vs. excluded when the simulator is paused? And I still would like to know which tool you need to use to remove stock airplanes from MTX AI flight plans. If that happens (either one way or another): Will there be less GA traffic activity in general, or will the planes that were used by stock planes be replaced by MTX own GA planes, resulting in only little change in traffic volume?
  7. Now I am on to remove stock airplanes from the FSX airplanes folder, as I did before. I restart FSX, set GA traffic to 100% (and airliner traffic to zero) and load the same scenario: Well, that's a different story! Average FPS is here 78.6 versus 44.7 with stock aircraft - that's an increase by factor 1.75! In the menu, we still see lots of GA traffic, but none from stock airplanes: And the final question now: What are the frames with 100% both GA and airliner traffic, without stock planes in use? 46.3 - I think it's good - in fact, it is a little HIGHER than having GA traffic only with stock planes included (remember, avg. fps was 44.7 in that scenario)! Now to my conclusive questions: Can you reconstruct these scenarios and check whether stock airplanes also impact your computer that much? That would answer the question whether it happens on other systems, too. From the results, I suspect that it must be stock planes that cause such a fps plunge. Even though I realize that with GA stock planes removed, there is less GA traffic in operation. But still: The fact that the combination of 100% GA and IFR traffic without stock planes produces a little higher frame rate than 100% GA only with stock planes is telling and indicates to me that the stock airplanes are the culprit. And the next question: How can I eliminate stock aircraft from all MXT plans without having to remove the aircraft from the airplanes folder inside fsx SimObjects? I assume it must be possible, but I haven't worked with the tools yet. I would like others to test out these scenarios, too, in order to find out whether GA traffic takes a toll on their performance, too. If that's the case, maybe it would be a good idea for the developer to replace the stock airplanes with MTX' own framerate-friendly versions...
  8. In the next scenario, I want to position the airplane at an airport that is not so detailed and FPS intensive as JFK. I'm using the same airplane, but I select the Greenville/Spartanburg Intl. airport in South Carolina (KGSP). The default runway is 04. The weather is the same as before, as well as all display settings except of air traffic. This time I measure the average fps from the cockpit view of a very simple airplane. In the first case, I have deactivated all air traffic: 100 fps on average looks like a lot, but it should be no surprise, as there is no complex scenery around and the aircraft has a cockpit as simple as can be. Now I have moved all stock airplanes to their original folder, so that MyTraffic can use them. I set the GA traffic slider to 100%. Let's see: The average frame rate is more than playable, but it has taken a very huge hit by a whopping factor of 2.43! And it comes at no reward for the visual quality or realism: The airport is still empty, as the next picture shows: A look at the traffic menu reveals that there are lots of Barons and Bravos in operation (stock aircraft) Now I am interested in the frame rate at 0% GA and 100% airliner traffic. Here we go: Well, here is the irony: Despite being visible, "bigger" and filling all gates at the airport, the frame rate with 100% airliner traffic and 0% GA is higher than vice versa (even though the airport is empty then). The top-down view shows that the relatively small airport is indeed busy with traffic:
  9. Out of curiosity, I have set both sliders to 100%: Here, two massive FPS eaters join forces and push the frame rate down to 13.5. That's obviously so low that the sim is on the verge of stuttering. Now back to the 0% airliner and 100% GA traffic scenario: For the fact that there is no GA traffic in proximity, 28 fps is actually a bad deal. I have been wondering why, not only since GA airplanes are much simpler than big airliners (therefore require less CPU power), but also because there are almost no airplanes to display (only processing those that are farther away out of visibility). The MyTraffic manual documents that the package uses some stock airplanes, such as Beechcraft, Cessna, Mooney Bravo, Learjet and others. And it has been known in the FSX comminity for long that stock (default) airplanes are a very huge resource hog. Could the bad performance be related to stock airplanes being used as AI traffic? Upon clicking on "View Mode -> Air Traffic" in the menu, I realized that there were lots of Barons, Skyhawk's, Beechcrafts and Bravo's rendered - most of them stock planes. I have asked myself: What if I get rid of them and leave only those GA planes that came along with the MTX package? Some of the tools included in the MTX 5.4b package allow the user to disable specific aircraft from being used as AI traffic, but to be honest, I have not experimented with these tools yet. Instead, I have applied a simpler method: I have removed all aircraft (except of Airbus and the Troka that I have been using) from the Airplanes subfolder inside the SimObjects-folder into a temporary outside folder. That way MyTraffic would not find stock airplanes first place. What happens if I set the GA traffic slider to maximum now, employing the same airport szenario? Here I get 36.1 fps on average. That's a jump from 28 fps (stock airplanes used) by factor 1.29, which I think is very considerable! Is all GA traffic gone now? There are almost none available on this airport, but a click on the menu shows that the FSX processes some distant GA traffic - however, none of it comes from the stock airplanes. At last, I was interested in what happens when I set both traffic sliders to 100%. Here is the result: Around 20 fps average frame rate. I would say it's playable. Remember, the same slider combination produced 13.5 fps when stock GA traffic was rendered. Disabling the latter makes the frame rate soar by a factor of 1.48! I think this is immense. The top down view shows that pretty much all gates on the airport are populated with airliner traffic: Before moving on to the next part, I think it can be concluded at this point that stock GA airplanes, when used as AI traffic, are serious FPS killers that interfere with the framerate-friendly MTX airplanes.
  10. Hello Burkhard Renk and other MyTraffic-users, I have recently purchased the latest edition of MyTrafficX Professional 5.4b for FSX, and I am quite happy with it! However, I have noticed that GA traffic takes a giant toll on the framerate. Let me document it: Let's start with the display settings of my system, which I have tweaked according to some known sources (Jesus, Kosta, etc.): For the beginning, we are going to set air traffic completely to zero (and only leave some ground traffic): Now I set the skies to "clear" and the visibility to 10 miles (this is why weather settings are irrelevant in that scenario). The airport that I'm going to select is default KJFK on runway 31L. I use the spot view and direct the camera at the airport buildings and terminals, where most airplanes are normally parked. Without air traffic, the average frame rate is 41.4, which is not bad at all for the given scenery settings. Now I increase the airline traffic slider to 100%. I know this value is extreme and unrealistic, but I do it for experimental purposes. As a side information, I will be using reduced AI airplane textures, and I have deactivated exit data for jetways and extended lights, because my PC is not that powerful. Let's see what happens: The average frame rate is now 21.9. The performance has taken a huge toll, but it's still good in my opinion, since there are over 100 airplanes (!) present on this airport alone (you can count them using top-down view). By the way, if I use high-quality textures, I get around 13 fps. If I also activate jetways and ground services, the frame rate drops to dramatic 7 fps initially (I have tested it, but not documented with pictures). So sticking to low-quality textures and dispensing with jetways definitely helps a lot in terms of fps. Now I set the airliner traffic slider to zero and GA traffic to 100%: What has happened? The average frame rate is now 28. You would think that this is not too bad for such a large airport, but the problem is that there is no GA traffic visible (and there are only very few on this airport stationed). To show that, I am attaching a picture of the top-down view, on which you see no airplanes: (next part following in the second post, since I have reached my maximum screenshot limit)
  11. Hello Pete Dowson, as I´ve noticed, you´ve already implemented a lowest visibility limitation for both global and local FS weather in your new FSUIPC version 3.51. I´ve read your last post within this thread after I installed the new version. This implementation is great and I want to thank you for your fantastic support. You wrote: That doesn´t matter in my mind, the same did and does apply to maximum visibility, however. I´m happy with how it works now. 8) You also wrote: Earlier, when I didn´t use FSUIPC or FSInterrogate, the fact that one got blue sky not until a visibility of 20 miles, set at the low-resolution visibility slider inside FS´own weather has bugged me much, because that was unrealistic. Later, when I found out that the real grey sky limit was at 10,1 miles, I felt better. At least I could correct the 10 miles value, set in weather menu, manually by FSInterrogate. Now that it does automatically, thanks to FSUIPC and your lowest visibility limit implementation. I agree that the FS2004´ grey sky limit of 10 miles is a lot worse than the 4 miles in the previous version. In exchange for that, if a visibility of, let´s say, 5 miles is reported together with overcast skies at the weather station, in FS2002 you saw a "blue" fog and could hardly see the grey sky color that should be caused by overcast sky condition. In FS2004, weather in such cases is displayed much better in my mind. And in FS2002 you couldn´t see the fog layer from upper altutides, which was also very unrealistic. I think both FS2002 and 2004 have their pro´s and contras, but a satisfactorily creation of misty conditions is not developed perfectly at both. (Another brutal solution might be placing a stratus cloud layer at the ground in FS2004 for creating misty conditions)... Again, thank you for implementing lower visit limitation applying to FS´own local weather! 8) Reagards Konstantin
  12. OK, since you´ve said the visibility limiter works for external weather programs, it´s all clear now. Earlier, I´ve thought this way: "Allow changes to FS own weather" button on -> make no visibility corrections on FS by FSUIPC. What has been set in FS weather menu, it does apply "Allow changes to FS own weather" button off -> enable the FSUIPC visibility limiter to work, FSUIPC has the priority over FS own weather...
  13. Hello Pete Dowson and other FSUIPC-users, the "Stop visibility going below (1/100th mile)" - button should do what it is called, not to let visibility going below the entered value. But at my FS, it does only work if I enable the checkbox "Allow changes to FS own weather" in the technical section. I thought this should be the other way around (when this checkbox is disabled)... When I disable this checkbox, I can set visibilities that are lower than I´ve entered in the FS weather menu, and FSUIPC won´t make any corrections... Is such a behaviour purposed, is it a failure of my system or of FSUIPC itself? Furthermore I would like to ask following: The lowest visibility limitation does apply only to global weather. Is it technically impossible to apply this function to local weather (it would surprise me as long as the maximum visibility limitation works for all weather), or isn´t there a need of this function for local weather? The sense of this would be preventing some unrealistic weather conditions with clear skies, but a low visibility below 5 miles with the grey sky I got sometimes before... Just a question... Thank you for replies! Afterburner
  14. Hello! Now I´m able to change values at offsets in FSInterrogate. I have experimented with changing the offset "Visibility" (not "Visibility around aircraft" at 2DF0, I get only zeros there...), and in fact, an almost stepless change in visibility is possible. My motivation of changing visibility values was checking out the visibility value below which the sky turns to grey. I have found out that a visibility of 10.05 miles is the lowest visibility where they still have blue sky at clear cloud conditions. And I´m pleased to have found this out because the grey sky at 10 miles (visibility I´ve set in weather menu) has made me angry. Now I know that FS´weather engine itself enables to get clear blue sky at a visibility of 10 miles (exact: 10,05 miles). Thank you for your help, Pete and scuffyduck! I will write more when I´m back at home (now I´m visiting my relatives). Regards Konstantin
  15. Hello Pete! Thank you for your very quick reply! I would like to try it by myself, but the problem is, I don´t know how to write a value in an offset. I´ve tried FSInterrogate, I could only read values by clicking "read buffer", but not write. Do I need FSInterrogate to write values? Maybe I haven´t fully understood this program. Next question - do I need a registered version of FSUIPC to be able to write values in an offset (i.e. the offset 2DF0)?