smoothchat

The profiles are stored in "Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\SystemAppData\wgs\000901FDF6A0322A_00000000000000000000000069F80140" (last folder name may be different) ---- re:recovery of lost profiles When I moved from the alpha to the release, I was able to transfer all my controllers over by doing the following.... The same process can apply to lost (or accidentally deleted) profiles. 1. In FS2020, create a new empty profile for the particular controller and exit the sim. 2. Go to the profile folder (as above) and search through the sub folders until you find the file just created that relates to your controller 3. Using a text editor like notepad++, copy the contents of the old profile (from a backup) into the newly created profile file, replacing what was there. You may want to update the "Friendly name" text. 4. Run FS2020. The newly altered profile will be uploaded to the cloud. Assuming you have a backup, you can recover a profile that was deleted this way. Note: Every time a profile is created or altered, a new GUID based folder is created, so you cant just copy an old profile into the profiles folder. You have to create / cut and paste (at least that's how it was the last time I did it) Of course, the better ongoing solution is to have your OS on a small partition so you can backup regularly, and ensure that the FS2020 data folders (eg: Community and Official folder) are on a non OS drive, so if you lose the configs, you can just rollback your OS partition which will restore the FS2020 main runtime and profiles to the last backup state. Missing profiles will be re-synced to the cloud.

I think we should all report it to zendesk. The more reports the better. I have found that reducing the size of the game window helps, as does the ASW30 solution (for rift users)

I'd report it to the Zendesk. They got onto it pretty quickly the last time the gaming services "broke" things. I would also disable all auto updates so i have control over what gets updated. If it happens to me, I will just roll back to one of my regular "C" drive backups. I have deliberately set up my OS on a small partition to make backups small and manageable.

The P51 from FSX Acceleration ports across very well, including instruments.

This sums it up. Solid Bridge Explanation You would think that Asobo would have at least addressed the bridges along the "showcase" route before its release.

Unfortunately, some people report that this still doesn't work for them. I am confident that the problem is caused by a mandatory “gaming services” update. The update replaces version 10.0.19041. 4332 with version 10.0.19041. 4271 and the sim won’t load. I restored an older backup of my OS drive (C:) and on bootup, I quickly paused MSStore from updating the gaming services app. With automatic updates disabled in MStore, the Gaming Services update now waits for me to manually update (which I will not do until they fix the problem). I have passed this info on to the ZenDesk.

Perhaps you could replace the contents of the folder with the 1.8.3 files, but leave the manifest and layout files from 1.9.5.

Be aware that with scenery mods, the Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\contents.xml file is updated when the sim finds them for the first time. An index file is also created in the \Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\SceneryIndexes folder. If you remove the mod folder (or rename it), the original reference remains in the content.xml file and associated index file. I'm not sure if this causes any issues, but it is untidy.

Unfortunately, there are still some <10kt water issues that have to be fixed. This applies to 1.9.3 and 1.9.5

There is a vote taking place on the MS Forum. Please add your vote if you feel that the water still requires improvement (given that many feel that it is not as good as it was at release) https://forums.flightsimulator.com/t/water-image-quality-has-degraded-since-1st-release/301380/11

This may help .... https://forums.flightsimulator.com/t/mod-tiny-nameplates-different-edition/248669

Do we have any more theories on why it gets over-written for some and not for others? Is it a MSStore vs Steam thing?

My question is, whether the dependency in the manifest file is required to ensure the correct file is substituted. My hunch is that there isn't another instance of the BaseInstrument.js file. If there was, (in another folder branch), there might be an issue if the dependency is not specified correctly. I could be wrong.

Thanks kaosfere, I was under the impression that the dependencies specified which top level folder to look in for the BaseInstrument.js file. It certainly seems to make a difference with liveries as all the textures are effectively named the same and there has to be some way of pointing to the right directory tree. I stand to be corrected.

In the manifest.json, that patch refers to asobo-vcockpits-core It should refer to asobo-vcockpits-instruments I'm surprised that it works. Also, the 1.7.14 version of BaseInstrument.js has changed, so it is wise not to use the patch as it will reverse the changes the devs added since 1.7.12.