VFS Locking in MSFS 2024

Unfortunately, for some items the dirty way is the only way. Locking html_ui, even only in part, will deminish the existing spectrum of addons. In all honesty, personally I wouldn’t take that route. Yes, it is madness. But it is also flexible. What ever you/Asobo do with that “locking list” will be wrong for somebody. There will be endless discussions why something has been locked, and something else wasn’t, and as to why, etc. etc.
The whole concept cannot be about making things easy for us developers. IMHO we must always be able to do absolutely everything to fulfill customer wishes. Including potentially screwing up their sim. Putting hard restrictions on anything will always lead to controversy.
Just my 2 cents.

Best regards
Oliver

1 Like

I’m on the fence with this one as there are benefits/detriments to both locking the files or allowing overrides.

Without inventing other layers of conflict resolution within the sim, I can only suggest a user selectable sandbox mode that allows mods to override, with warnings available or with the ability to note what mods might be conflicting, or the ability to select/deselect mods in-sim from the world map, etc. This would need a very simple UI so not to overwhelm and confuse the end user, and would empower them to have more knowledge and control of potential conflicts.

Just for the record: testers who have access to the 24 beta are reporting that a certain feature of one of our payware apps is non-functional now, apparently because of this VFS lock. That is “not good”. I can only plead to please not lock the VFS in any way.

Apart from the problems with existing addons, any lock limits the options that we have in the future. I appreciate the sentiment that you want to provide a safer and more structured approach. But we cannot know the requirements of the future, nobody can. Having to wait until a certain access to certain locked things in MSFS will be available “officially” and “properly” in the SDK (or at all!) is not something I look forwad to.

=( I really hoped they would not go with the lock. This mean one big feature of my tool most likely not available, either.
Let’s hope they still change their mind.

I completely agree with @SimbolFSReborn . This issue arises because some of you are making changes for your own benefit, disregarding the impact on others. Specifically, modifying shared files without considering the other addons that depend on those files. As a result, these addons stop working due to your changes.

When users come to us with complaints, we often have no choice but to recommend uninstalling your mods.

If you need to make changes to shared files like navsystem.js (or others that you are undoubtedly aware of), the solution is straightforward: create duplicates, adjust their paths, and modify them as much as you need without affecting the rest of the community.

This approach is simple and ensures that your good intentions to improve the simulator truly benefit everyone, rather than serving individual interests. Let’s exercise a bit of common sense in this matter.

6 Likes

@CodenameJack447 The market will handle that naturally. It will identify the responsible party, and customers will decide how they want to proceed.

As discussed previously, conflicts are bound to happen. I still believe the game should not restrict players from modifying the base files. This new approach seems to further limit the game’s customization potential, making it even less appealing for modding enthusiasts. But hey, at least @SimbolFSReborn will get fewer support emails. :+1:

Don’t appreciate your passive agresive message to be honest.

Read very carefully the entire thread and my original request to Asobo where I explained the entire issues in detail and what specifics files should be protected instead the entire module. I am requesting Eric again on this topic to reconsider the list in order to help the community to continue to thrive.

You clearly lack the visibility of the core problem here, is not about me or you, is about who matters the most, the users experience and them having the ability to enjoy the simulator without external factors damaging their experience.

So please stay professional and leave dramas outside of this, or the very least don’t tag me if you wish to engage on such.

Best,
Raul

4 Likes

@WithinRafael , saying “we do all this for the community and evolution” sounds great—if it were true. But let’s be honest: your primary motives are economic and rooted in seeking recognition, with little regard for the rest of the community.

Your passive mention of @SimbolFSReborn only highlights your individualism and makes it clear that you only care about issues when they directly affect you. Meanwhile, the rest of us have been dealing with the consequences of bad practices like modifying shared simulator files for years.

Your link refers to modding game files, which is fine in principle, but let’s be clear—this isn’t NexusMods, where users download free mods and are appropriately warned about potential issues. Here, we’re talking about products sold on the Marketplace, which modify the game’s base files for individual profit rather than contributing to a broader benefit. Worse still, the fact that these base file modifications are omitted or downplayed for convenience exposes the underlying motive.

The consequences are clear: a new update is released, and suddenly, other addons stop working correctly because the creator of a mod that alters the base files hasn’t kept their product updated or aligned with the changes. This causes a domino effect, impacting the functionality of other addons that rely on the same shared files.

But that’s just one factor. The other, more significant issue is the complete disregard for how such modifications indirectly harm the rest of the ecosystem. We shouldn’t have to deal with complaints caused by your addons, nor should Asobo. Furthermore, our reputations shouldn’t suffer because of the problems you create. If bugs or conflicts arise due to your alterations, it’s unjust for the blame to fall on us—or on Asobo.

If you and others truly were the skilled programmers you claim to be, you wouldn’t need to alter shared files in the first place: You do it because it is the easy way and also out of laziness. “Shared” means exactly that: they’re not exclusively yours to modify as you please. Adopting good practices, such as working with duplicate files, customized paths, or modular systems, would entirely prevent these issues. This approach ensures your work is sustainable and compatible with the broader community. It’s a simple and efficient solution that allows you to innovate without disrupting the ecosystem we all share.

It’s no surprise that measures like this have been implemented. If, after four years, this lesson hasn’t sunk in, perhaps stricter restrictions will finally make the point clear.

Ultimately, this is the difference between what some consider “evolution” and what others see as “protection.” True evolution happens when the simulator grows in a way that benefits everyone, while protection is necessary to ensure that growth doesn’t come at the cost of stability and fairness for the entire community. Evolution without protection isn’t progress—it’s chaos.

P.S: When I say “you,” I’m not referring to you personally (I don’t know if you do modding by altering core files). I’m referring to those individuals who do modify the base files with the aim of profit, hiding behind the notion of “doing it for the common good.”

2 Likes

@SimbolFSReborn apologies if my previous message came across as a personal attack. That was not my intention at all. I attempted to use your problem to highlight the challenges and imbalance we face between fostering creativity and addressing real legitimate concerns raised by developers like you about the ecosystem. (I recognize Asobo took a heavy-handed approach in restricting file access that goes beyond what anyone asked for!)

@CodenameJack447 I respect your passion about maintaining a stable and fair ecosystem. And I do understand your concerns about marketplace addons causing issues due to poor practices. I agree that Asobo/Microsoft needs to guarantee compatibility and stability in that space.

I’d like to ask you to consider my perspective as well—someone who doesn’t have a stake in the official Marketplace. My focus is on exploring ways to modify the simulator creatively and expand the Flight Simulator community as a whole, reaching beyond aircraft to create broader, more diverse experiences. But I’ll be honest—I’m not sure how to strike the right balance here; it’s a challenging issue. Maybe the answer is that Flight Simulator is best suited for serious commercial work and is just not ideal for broader creative experimentation. (Nothing wrong with that.)

1 Like

@WithinRafael I understand your point of view, and I acknowledge that I may come across as rude or overly firm at times. However, I am always open to respectful debate, and you have every right to refute my comments if you disagree.

Let me give you an example to illustrate my approach. In my addon, I use a copy of the Mapinstrument element, and its file path is:

html_ui\Pages\VCockpit\Instruments\Rafale\Map

If you inspect the HTML composition, you’ll see that my file paths do not point to the core files but instead to duplicates and diferent paths. This serves two purposes: it allows me to modify them as needed and ensures that no other addon is affected, as none should access these paths. Even though the files retain the same name, they are isolated.

In other words, when I need to modify a base file, I isolate it in a different path to prevent any impact on other third-party addons:

This isn’t limited to a single aircraft. For another plane, I’ve similarly isolated the same files in a completely separate path to prevent conflicts even between my own planes:

For reference, the original file path is:
html_ui\Pages\VCockpit\Instruments\Shared\Map

And here is its HTML composition (shown on the right in the comparison):

This approach adheres to two principles:

Respecting the rules of the ecosystem. No other third-party addon should access my files unless explicitly intended by that third party.
Ensuring complete freedom to modify. I can alter my duplicate base files as much as needed without affecting the originals.
If a base game update is released, only my product would break—not others—because no one else relies on my files. Similarly, any modifications I make to my files will not interfere with the functionality of other addons. This protects the work of others and maintains stability across the ecosystem.

For these reasons, I cannot understand why some developers insist on directly modifying core or shared files. This practice often stems from laziness, self-interest, or a disregard for the broader impact on the community. But even more concerning is the possibility that such actions are, at times, intentional—an attempt to give their product an unfair advantage by deliberately sabotaging competitors’ addons. By altering the shared code in ways that render others’ work unusable, they not only harm their peers but also erode trust within the community. This kind of behavior goes beyond negligence; it reflects a calculated effort to prioritize individual gain over collaboration and the health of the ecosystem as a whole.

I fully support the implementation of measures to address this issue. If certain developers cannot follow such a straightforward and respectful approach voluntarily, then enforcing it becomes necessary.

You don’t need to directly alter the base game files in a way that affects other addons. All you need to do is create duplicates and isolate them in custom paths where they won’t interfere with anyone else’s work. It’s that simple.

2 Likes

The problem as I see it is that the support cost and user experience issues are externalised to others rather than the package that causes the issues. I think on balance locking core files like the vcockpit-core package makes sense as various developers continually deal with their avionics being broken by mods to these files.

TMBK this will only work when you are making aircraft. But if you are creating mods to instruments or other core elements, that are not related to a specific aircraft model, this is not an option. Example: my WebFMCs that are streaming the content of the CDU screen to the outside world, or the G1000 and G3000 bridges that made those instruments work with a StreamDeck. All of them that were dealing with default aircraft are dead now. Previously we could implement our own packages and override the files - a solution which is easily reversed, should there by any trouble.

IMHO the current “solution” to all this in MSFS 2024 will achieve the exact opposite to what was intendend. It is still possible to hack into the actual core files of the simulator - and as matters stand, that is the only option left to all developers of such programmatic addons.

Nearly every simulator (except MSFS) that I can think of has a native message system to notify the user when modified files trip an integrity check (also still non-existent in MSFS).

Seriously, how complicated is it to just fetch a list of all files scanned in the community folder and notify the user via message box, “Hey, this file is overriding this core file.”

Done. Crisis averted.

Those might be better implemented as plugins rather than overriding files Plugins Overview | MSFS Avionics Frameworks and Instruments (applicable to both MSFS2020 and MSFS2024).

No doubt. Unfortunately that doesn’t work for me. I suspect that the Instruments that I’m trying to plug into don’t support plugins (or at least don’t support global ones).

Edit: I couldn’t let it go. I now managed to convert the first two items to plugins. The problem was, that when I followed the instructions in the specs, the plugins wouldn’t compile. Checking them with the Coherent Debugger, not even the first “import” was acceptable. I removed all that and just plunked in my own JS code - and it started working.
Many thanks @tracernz for the pointer!!

1 Like

I would like to add a follow-up to this.

Plugins are great - if and when their “stubs” are implemented in the various instruments. Sadly, that is not the case. The majority of instruments of the default aircraft either don’t have the plugin logic at all, or they don’t allow global ones.

It would be great if global plugins were independent of the actual instrument implementation (but keeping the match to an instanceID etc. intact). So they could be created even when the instrument’s developer forgot to implement the global plugin stub.