boez

I reported this in the official forums. Doesn’t appear to be universal (couple of posters said it didn’t happen to them) which has surprised me as no other changes were made to my system except the update. https://forums.flightsimulator.com/t/1-37-8-0-regression-custom-window-size-being-reset-every-time-app-is-started-also-fullscreen-mode-reverting-to-windowed-mode/633921/14

@Reset XPDR there is an (indirect) dependency which your app does not check for but caused issues when I tested your app on my (very) fresh windows 11 installation. I found that simconnect.dll needs to have “Microsoft Visual C++ 2015 - 2022 Redistributable” installed otherwise it refuses to load and the simconnect indicator in your app remains red. Your log file contained the error “Could not load file or assembly ‘Microsoft.FlightSimulator.SimConnect.dll’ or one of its dependencies”. Of course both of these are in your distribution and so I was confused, however a Google search later and once I installed the vc++ library, all was well. I think most users PCs will have already had this library installed at sometime by other software and so this won’t be a common issue but thought I’d share my learning with you.

From the projects GitHub page… 0.60: The nag prompt at startup has been removed. Added a log file ("dlssg_to_fsr3.log") in the game directory. Added support for developer options and debug overlay ("dlssg_to_fsr3.ini"). Miscellaneous stability tweaks.

No - there are two types of update. One applies to the binary and the other the content. The binary update is done from the Xbox or ms store app. This will probably break the mod. The other update of the content is done within the msfs app. This will not break the mod. Note that sometimes both types of update are made simultaneously’. In fact a binary update e.g. SU14 is almost certainty followed by a content update. But a content update can be made independently. The update at the time of this post is content only so no issues with mod. *actually to be pedantic there are 2 types of content update. Mandatory where some core content is updated for all users and optional which only applies if you have downloaded that optional content.

Double click does exactly the same as merge. You should have seen a pop up box asking you “are you sure you want to continue?”. If you clicked yes then the reg file has been “merged”…

Haha that’s me! Even though I have a 4090 I gave it a try out of curiosity and I’ve got to say as a free mod it’s effective. There are the limitations described in this thread but overall it works. I’ve no comment on whether it’s better than nvidia’s FG as, since it stopped working with true vsync earlier this year, I stopped using it and so I’ve little experience to use in a meaningful comparison. That limitation (of true vsync) also applies to this mod BTW.

Yes this is exactly what the hack is doing. From the GitHub page… About Adds AMD FSR3 Frame Generation to games by replacing Nvidia DLSS-G Frame Generation (nvngx_dlssg). …it uses the local known-name DLL trick (nvngx.dll in this case) to redirect part of the graphics pipeline through the custom FSR DLL. They called that “dlssg_to_fsr3_amd_is_better.dll”!

When in drone view there is a keypress that allows you to toggle between allowing full control of the aircraft as if you were in the cockpit or moving the drone. I think that this is assigned by default to a key but I remapped mine so long ago I can’t remember what that original key was! I quite often toggle between the 2 modes so I can move the drone and then return to controlling the aircraft without leaving drone view.

The very specific issue which the network connection workaround helps with is whenever MSFS is loading terrain tiles from the server (and no other type of CTD such as 3rd party addons, drivers, etc.). That occurs in 5 places: loading simulator world map loading flight (blue bar at around 80%) flying, and, as added by another poster, while looking for scenery in the marketplace. edit: the most ‘stressful’ time, i.e. when the most terrain tiles per second are being loaded, is during map zooming and flight loading. This is the likely reason that most CTDs caused by this (apparent) speed issue occurs at those times. Background: So around mid October posters on the official forum thread were seeing CTDs in some or all of these places with no apparent common connection. Personally for me CTDs on the map were rare but loading flight was common. After I asked for hardware specs one common feature of all the posters were that they were on high speed network connections hence my workaround to slow it down. I must repeat that this was just a hunch on my part and asobo did not confirm the cause. However the workaround is still good a month later. It is also not the solution nor is it intended to be. That needs to be fixed by asobo and/or Microsoft (at the server). I was on the su13 beta for 2 months and never saw the issue. A few days after the public release of su13 I, along with others, started seeing the CTDs. BUT no code changes were made to the beta version once it went public. So why didn’t I see the CTDs during the beta if it was in the code? Again my hunch is a configuration change on the server but I guess only Asobo will know for certain. edit: for perspective I had more CTDs in 3 days before the workaround than I’d had in 3 years of using the sim. I’m guessing with that uptick in frequency that I’d have seen a CTD during the 2 month beta if it were in the code.

No but I never said it was. You posted your thread reply during a phase of discussion where the network workaround was being indicated as working for a couple of (more) posters and you said it doesn’t work for everyone. I just wanted to ascertain if that was indeed true only because if it was then that’s the first time I’d see someone post that. I’m only pressing for more information as I (or other contributors) may be able to help the subset of folk for whom the workaround doesn’t help. It’s not an attack on your point of view and/or situation. It’s very important when debugging software to know under what conditions a fix does not work even if that makes the fix less solid as it gets you closer to the real cause.

My network connection is 100% rock solid. I only need to apply the workaround when in MSFS - I remove it when I’ve exited the sim. edit. I apply the workaround *before* starting MSFS.

This is a genuine question and not a challenge to your statement but can you show me where the ‘many others’ have posted their results? Except for you (and I think I may be talking to you on the other thread) I’ve not seen any. Again I’m only talking about terrain loading over a wired high speed fibre connection and not the plethora of other CTDs.

I never claimed it would - I’ve always been very careful to warn that my workaround is only for a specific cause of CTDs. Frustratingly this warning often goes unheeded. But of the many posters who contributed to the thread on the official forum it made the sim playable. I personally have not had a CTD since I formulated the workaround. In summary if someone has a generally CTD prone system as well as this (unproven) network speed CTD then applying the workaround won’t remove all CTDs. It can’t. But that doesn’t mean it hasn’t worked.

You can find that out both in this thread and the one on the official forum 😉 p.s. the 100mbps ‘half’ duplex suggestion was made over a month after my original workaround was first posted and I still feel the original 100mbps ‘full’ duplex is sufficient for most folk. Of course it is system dependent and the poster who moved to half duplex found it better for him but that setting now seems to have ‘stuck’ unnecessarily as a recommendation. It does no harm of course. I narrowed the CTD down to those who were on high speed fibre connections (and using a LAN cable connection) quite early on after the issue arose by asking folk seeing the issue on the official forum to share their hardware specs. It was just a hunch that the high speed was causing the issue but that looks to be true. I guess a relatively few simmers are in this category of having a high speed connection… p.s. I was on SU13 beta for 2 months with no CTDs at world map. No update was made to the sim for beta testers on release but a couple of days later the issue started (including for me of course). For this reason I don’t think it’s SU13 itself that is the cause. Again that’s just my hunch.

Where have I ever claimed anything other than this? Hence me calling my ‘cure’ a workaround. Workaround: something that fixes an issue temporarily. Once asobo fix the issue the workaround is no longer needed and I’ll stop using it. You could do with reading the (rather long) thread on the official forum. You’ll see I’ve based my workaround on facts and feedback from multiple posters who were having the exact same issue and not just a throw away opinion with no basis. Many posters on that thread are successfully using my workaround and have done for weeks. edit: I’m actually agreeing with you just to be clear. I personally don’t think the issue is in the MSFS code but to do with the server connection or configuration at the Azure terrain server.