The addition of the InstalledPackagesPathNextBoot property in UserCfg.opt breaks all apps that used the SDK sample code to find the path to InstalledPackagesPath.
Repro steps:
Use the non-beta SDK PackageInstaller code to look for the InstalledPackagesPath property in a SU2 beta UserCfg.opt file.
Result: The discovered path starts with xtBoot ".
Expected result: The discovered path is F:\MSFS2024 (the path on my system, will vary on other systems).
Additional details
This issue is caused by two logic errors in the SDK sample’s CustomAction.cpp file:
Even when the InstalledPackagesPath is found, the while loop continues searching through the rest of the .opt file
The string test for InstalledPackagesPath will also match InstalledPackagesPathNextBoot. That matching line is then used for the rest of the code
Our app, while written in C#, copied the exact logic from the 2020 SDK sample and simply updated the search paths for 2024. I assume pretty much every native app out there that targeted 2020 originally did something similar: update the search paths but leave file parsing the logic unchanged.
The result is any app using the 2020 (or non-beta 2024) sample code can no longer find the InstalledPackagesPath value due to this new property in the .opt file. There’s at least one thread about this over in the user forums, mentioning another possible reason this change could break existing apps.
This was clearly caught during internal testing since the 2024 SU2 Beta sample SDK code includes this change:
“Fixed PackageInstaller algorithm for detecting the Community Folder - avoids InstalledPackagesPathNextBoot being used instead of InstalledPackagesPath in UserCfg.opt”
That’s great for the sample code, but not for all the developers out there who already have stuff shipped that uses the prior SDK samples.
Proposed solution
Rename the new property to NextBootInstalledPackagesPath. This will allow MSFS2024 SU2 to still do whatever it needs to with that value, but the property name will not get picked up by apps looking for InstalledPackagesPath.
@kaiii3 and @vpilotfs You both participated in a thread regarding the folder location prior to the 2024 release. Make sure you aren’t impacted by this too.
Yes, that’s the change introduced in the sample in the beta sdk. The issue with that is it requires every application that ever used this sample code, which has been out since 2020, to put out an update before SU2 releases, otherwise they are broken.
Thanks for the heads-up, I’ll also update my vRAAS tool to check for a space behind.
Changing the name would probably be better indeed…
Let’s see what Asobo thinks about that, but I have the feeling they will not change it anymore.
There is no logic error here - it is the same as writing:
int a = 2;
a = 3;
a = 4;
In the end, you really want a to be equal to 4.
This is the real error which, as you noticed, has been fixed in the latest SDK.
Unfortunately this wouldn’t work for people who already have an InstalledPackagesPathNextBoot entry in their UserCfg.opt file.
To be honest the bug is in the installer, not the sim. Granted, this is because the code provided in the custom action of the SDK sample was poorly written (and I can easily state this since I believe I wrote it in the first place) - but the fact is that the sim itself is not at fault here.
We specifically fixed the custom action for the SU2 flighting so that affected products have time to update their installer - it may not even be required for those who have rewritten their own detection algorithm or spotted the mistake when integrating the sample code.
We specifically fixed the custom action for the SU2 flighting so that affected products have time to update their installer
I believe you are dramatically underestimating the impact of this change. There is four years worth of software out there that used the old sample code for their detection algorithm, and all of that software is now going to fail.
Simply updating the sample code for a sim update with a one-line mention in (incredibly long) release notes isn’t going to get all that software to update. They are going to find out the way we did: when the code causes an exception or doesn’t install correctly, and users start complaining. Furthermore, lots of software doesn’t have auto-update support, so developers can’t push a fix out before users hit this.
Unfortunately this wouldn’t work for people who already have an InstalledPackagesPathNextBoot entry in their UserCfg.opt file.
This property was a new addition for SU2, correct? Asobo can easily rename the property, then add a bit of code if necessary to migrate SU2 beta users from the old property name to the new name and clean up the problematic one.
This has impacted us as well and would require the distribution of 80+ updates to correct the issue. We would need to advise our customer base to avoid SU2 until then, which is ridiculous quite frankly.
What is the decision here? Will the offending line remain in usercfg.opt? If so, we’ll need to also make changes in our installers - not ideal. For now, we’re advising SU2 beta users to remove it themselves, but it’s reappearing it seems.
I want to confirm that this is a sim issue as Asobo added a new line of code at the bottom of the UserCfg.Opt file. This breaks all current installers. So to be consistent with 2020 I suspect this will get fixed. I do not want to update all my installers each time you change the installation path location on the UserCfg.Opt file. Looking forward to a confirmation this will be fixed as at this point since this is a beta I have no plans to fix anything. We will blame Asobo until it’s fixed.
It’s great to hear a fix is planned, but if this isn’t included in SU2 it’s not really a useful fix. SU3 will be quite a while after SU2, and everyone who has broken installers will be broken for that entire period.
Thanks for the feedback. This info helps so we can decide what to do for the meantime. And yes we will explain to customers that this broke due to an update from Asobo, but is planned to get fixed. I did not mean for my previous statement to sound like a pun. Now reading it again I for sure worded this really badly. I just mean we will inform the customers why it happened and how to manually change the installer path during the installation.
Just a quick note. The whole point of a beta is to make sure the beta works prior to releasing the final update and catch issues in time. So, we are reporting this bug to prevent the actual bug to reach SU2. What is the point of a beta if this bug gets ignored? I know you stated maybe. I hope you can make this a priority as I feel this bug is very important to not ignore.
SU3 is way too far out and I am sure many devs do not want to update their installers two times. That is far too much work for the devs and too much downloading for the customers.
Two parts:
1/ The “InstalledPackagesPathNextBoot” key is not written to the file if it is empty.
2/ The “InstalledPackagesPath” key is always written after “InstalledPackagesPathNextBoot” if the latter needs to be written.
As stated before, this is not a bug in the sim but in your installers. Granted, the issue comes from a poorly crafted piece of code provided within the SDK, but it is a piece of code that is now included with your installers.
This thread was started nearly 3 weeks ago and highlighted that the solution was already available to those willing to publish updated installers - which I understand some of you decided not to do.
We decided since then to make a small change that would help badly written installers to work anyway - but there are timing constraints in the publishing pipeline that may prevent this change to make it into the first SU2 public release.
We will discuss the options we have with the various stakeholders - they will make the final decision on whether this change should be in the first SU2 release or not.
