We’ve been following the SDK stream (thank you for providing this, by the way) and have encountered some issues with a specific aspect of the new system: VFS override restrictions.
Our SimFX (visual effects) addon overrides the FX.xml file located in the ModelBehaviorDefs\Asobo\Generic folder to intercept and replace visual effects with new ones. This process is critical for the proper functioning of our visual effects packages, as there is currently no alternative method to swap a visual effect in the sim. Overriding the GUID in a VFX file only works if our package is loaded last, and that cannot always be guaranteed. Furthermore, the “Compiled Behaviors” feature prevents this technique from working entirely when the aircraft is configured this way. We would appreciate the opportunity to explore potential solutions with you. For instance, introducing a parameter in each VFX file that allows our effects to take precedence, regardless of what is loaded afterward, might be beneficial.
Another challenge we are facing involves our Flow utility, which offers custom nameplates that highlight friends and allow for customization. Locking the HTML_UI folder prevents us from implementing this functionality. Could there be an option to exclude certain folders, especially considering that this restriction seems to have been put in place primarily to protect avionics and core Coherent files, rather than the entire UI system?
While we understand the rationale behind locking VFS overrides, locking entire folders significantly restricts innovation and expansion.
I haven’t yet heard the dev stream, but it seems to me that with so many groups using these elements that there should be some sort of SDK framework to handle these overrides without touching the base sim.
What would an “equitable” solution be? If two addons override the same base file, how do you decide which takes precedence? It’s just reintroducing the same problems intended to be solved
The whole VFS issue could have been quickly solved if Asobo created an advisory message in the main menu saying: “Virtual File System overrides detected”, and provide a list of community and marketplace mod(s) overriding core files. (Edit: And provide the ability to export/dump this list to a text file).
This blanket ban solution is going to result in the opposite effect, leading many to directly modify core files instead of overriding them.
Overriding files is the whole idea behind the VFS system. The issue you mention can be resolved by allowing JS files to be loaded in the DOM without having to override anything. This could easily be achieved on Asobo’s side.
This would create too much confusion for the user unfortunately. The solution should be dealt with at the source. Blocking all UI mods is not a solution.
An equitable solution is a technical solution that allows UI mods (or others in a similar situation) to be made that are compatible and do not conflict. That is not possible with the current technical design. Essentially, it needs an extensible UI system, but that really needs to be designed in from the beginning and is not exactly trivial to do if that hasn’t been considered.
Unless you have detailed knowledge of the underlying implementation then you can’t make assumptions about how easy or difficult this may be to do, that’s Asobo’s call.
From my experience, it wasn’t part of the design of MSFS 2020 UI framework and doesn’t seem as if it is in MSFS 2024 either. Much as I’d like it was, I can also understand why it wasn’t.
They do seem open to looking into it, so maybe it’s flexible enough to implement a solution of some kind, or maybe not🤷 Time is tight though.
In any event, any solution needs to be equitable and open to all developers.
I could be wrong, but my understanding was you won’t be able to directly modify core files in targeted directories either because they will be locked out completely from being able to do so. Overriding is directly modifying, in other words.
Whether that’s a folder lock, detection of modified file rejection, or by not providing the source, which was previously open, I don’t know.
While I applaud the move and direction taken for MSFS 2024 on this regard as I am one of the most affected developers under MSFS 2020 with my products, I think it has been done in a way that is too restrictive (assuming I understood correctly from yesterday stream).
When you guys at Asobo asked me what I would consider it should be prevented from being logically overridden by the VFS system I provided a detailed list of folder and files with the detailed explanation of why, etc. that List was compiled not only based on my own experience with support coming towards airplanes, but also after holding conversations behind the scenes with many 3rd party developers in the community who create freeware content.
Do you think it would be possible to re-visit the list of things being blocked under MSFS 2024? my concern is, the supper restrictive move (and again assuming I understand this correctly) will be detrimental towards lots of content creators out there who are contributing positively into the ecosystem.
Ideally what we want is to strike a balance into preventing fundamental core files of MSFS 2024 being overridden but also allow the free spirit and contribution from many creators to continue bringing innovation and amazing things for the overall community.
I believe runshotgun has linked my detailed post back in 2023 where I explained each folder we considered it was dangerous to left open but if you need it again let me know.
I would like to thank you, Sylvain and Hugo for all the hard work you guys are putting into MSFS 2024 and for answering all our questions to us yesterday on the stream, it was very refreshing to see you guys as we were able to get detailed technical questions answered, it was also very welcomed to see how open minded you and the team is to listening to our feedback.
Thank you for everything guys, MSFS 2024 looks incredible.
