RALF9636

I don't have an idea for a solution, but I can report that I also use AAO for the controls and always load the ATR via the EFB using the simbrief integration and never had this issue with the AP disconnecting.

Have you tried a reinstall? Try if it works with the default settings. Maybe something got messed up when you changed the values. I never had the issues you describe. I made dozens of flights with this app and it always worked as expected.

That would be nice indeed. So far there is only the satellite map of your touchdown so you can assess that yourself.

The range for the best job chances is 70 - 100 %, so there is still a large margin even with that 2 % pause penalty.

It gives you feedback on your flying skills. APL provides an extensive evaluation of a multitude of items. "Pause" is just one of the many - you can just ignore that one and still enjoy the rest of APL.

I never understood why people are so bothered by this pause penalty. It is just a 2 percent penalty so your rating is 98 % not 100 %. These are just numbers. You know the reason is that you paused the flight, so you know it was a perfect rating for you. What is the issue? As far as I know there isn't even a community leaderboard depending on the ratings. So just consider 98% your goal. Problem solved.

That happens automatically in the sim - without this tool - because the higher you are the farer away you are from objects on the ground so less of them will be displayed. Eventually that is what LODs are for. Indeed. Because of the OLOD more small objects on the ground will be displayed when you are on or close to the ground. So with a high OLOD setting a lot of these objects will be displayed even at a further distance which will affect performance. At least on my system the OLOD setting does not really affect the overall FPS but is more about the smoothness. A lower OLOD setting prevents stutters when you get close to the ground and a lot of small ground objects are getting rendered. So for example with an OLOD setting of 80 for ground / low altitudes, the clutter around the terminal of a large third party airport will only be rendered when you are taxiing towards the apron, creating only - if at all - a small stutter at a time when it does not really matter. But with an OLOD setting of 200 all these objects would be rendered when you are on short final, potentially creating a significant stutter at the worst moment.

I concur with what most others have said. I was sceptical at first, but this is a must-have. Turbulence feels so much more plausible than the exaggerated and repetitive default bumps. I see the best results with the MSFS turbulence setting to low. And it also works fine together with the FSRealistic general turbulence effect.

I do feel your pain, but I guess for most simmers that is very good news. It was a strange business decision to prioritize the P3D release in the first place. It would be great to see FSLabs coming to MSFS.

So we have to decide and manually set if we want the TLOD/OLOD or the cloud quality to be decreased when the target FPS is not maintained, do I understand correctly? Is there any way for this tool to automatically detect if we are in a CPU- or GPU limited situation, maybe by reading some of the parameters available in developer mode? Then the tool could automatically either decrease TLOD/OLOD (for CPU-limited situations) or cloud quality (for GPU-limited situations).

Unfortunately that would be way over my head... 😉

That is a great idea. In CPU-limited situations the TLOD setting is the one with the biggest FPS-impact. In GPU-limited situations the Volumetric Cloud setting has a very high FPS-impact. So to include this setting in this tool would be a great addition. The setting with the most FPS-impact in GPU-limited situations though is the Render Scaling setting. Do you think that can also be changed on the fly? Apart from that maybe the visual difference would be too noticeable.

After a while I took the ATR again for some flights with the latest MCE (3.0.6.4). I noticed some issues: 1. When going through the checklists the items are proceeded on the MFD but the ATR seems not to recognize that the checklist is done afterwards. The completed checklist reappears under "Pending". Not sure if MCE can do anything about that. If not, it might be better to not automatically proceed the items on the MFD but leave that for the user. 2. There seems to be no command for "Oxygen main supply ON" (on the upper right overhead panel). This is an item that should be turned on during the cockpit preparation flow as it is off by default in the cold and dark state of the ATR. Can you add that? 3. "Window heat ON" also turns on the Side Windows Anti Icing. As far as I have seen on some Youtube tutorials (by Magnar) this is normally not always turned on together with the windshield heating. So maybe it would be better to exclude that from the "window heat ON" command and have a separate command for the Side windows Anti Icing. 4. The "Strobe ON" / "Strobe OFF" commands are recognized but do not actually change the setting of the strobe lights switch. 5. The "Hydraulic Ground Aux Pump Push" command that is included in the "start engine two in hotel mode"-flow has no effect (I know this is hit and miss anyway because of a bug in the ATR, but even when pressing the button - the one on the pedestal below the parking brake - with the mouse works fine, the MCE command does nothing.). Since the whole prop brake procedure seems to be bugged in the ATR, maybe leave this for later. Have a happy new year!

Yes. Only if the airport developer has properly assigned the gates for specific airlines. So for most airports: No. You mean like an AI pilot for your aircaft? No. PSXT with RealTraffic is the best option for that.

The developer also recommends a reasonable step-size of 25-75. Which is a kind of a dilemma. The more steps you have the more chances for stutters you get. But the larger the step-size is the bigger the chance for a more noticeable stutter is as well. So I guess key is to not go to extremes like a step every few hundred feet or step-sizes of 100 or more. I use these steps for Airliners: tlodPairs0" value="0:80|500:100|1000:110|2000:120|3000:130|5000:140|8000:160|12000:180|16000:200|20000:250|24000:300 and these for GA:: tlodPairs1" value="0:100|300:120|600:140|1000:150|1500:160|2000:170|3000:180|4000:200|5000:250|6000:300|8000:350 These settings don't cause issues with stuttering for me. Of course you can always get a stutter when some demanding scenery is just at the edge of an LOD area, but that will happen without this tool as well.

Have you tried setting the weather in the main menu before starting the flight? That is what should be saved for your next session. What you set from the toolbar during flight is not saved.

You need to manually edit your exe.xml.

That is the understatement of the year - so far 😉. Of course for those who are happy with their system's performance under all circumstances and who are not able to see any difference in visual quality between TLOD 100 and 400 under any circumstances with their setup, this app is obsolete. For everybody else - this app is a game changer.

While this is true for some regions, it is just plain wrong in this generality. This. Or to give another example think of a high desert climate where you can expect freezing temperatures at night and heat at noon. This sums it up nicely. When you don't feel the need for historical weather because you want to just cope with the weather as is regardless if it is plausible or not, then you don't need live weather either. Just some random weather would do. In the end there is no antagonism between live weather and historical weather. Both are snapshots of the real worldwide weather at some specific point in time. Live weather is just a special case of historical weather: the corresponding time is now and not some time in the past.

The FSLTL settings are irrelevant if you use it with FSHud. Only the FSHud settings are relevant. Start with the default settings. With your PC it shouldn't be a problem to go even higher. But since the airborne traffic separation of FSHud is still work in progress higher settings of active aircraft might lead to problems like go-arounds.

Which settings do you mean?

@Ray Proudfootjust give it up. We have been explaining it to them for three years now. They will never understand.

Same here.

I'm afraid we are really beating a dead horse here. This thread as well as all the threads about it in the past show that many simmers either don't care for plausible weather according to the time of day and season set in the sim, misunderstand the term historical weather or don't even have an idea of the concept at all. The relatively small number of votes this wish has got over the years shows that we who consider historical weather a must-have for a serious flightsimulator are a minority. So there is no reason for MS/Asobo to implement something like this. Even more so as the devs themselves seem to not understand to concept of historical weather. Whenever it was mentioned in their Q&As they showed a total lack of comprehension. I don't expect historical weather will ever come to any version of MSFS. The only hope is that some third party dev someday finds a way to somehow "hack" the weather system of MSFS to provide this sorely missing feature.

You need to use one of the available third party addons for ATC. All of them come with their own issues but are a lot better than the default ATC. I use FSHud at the moment. It not only provides ATC but controls the AI traffic as well. So you don't have to deal with all the quirks of the default AI engine as well if you use FSHud. FSHud is not a finished product yet but still in (public) beta status. It is actively developed with a new version every few days/weeks. It has made significant progress over the recent weeks and in its current state for me it is the best option for ATC and AI traffic available for MSFS right now.