Instead of deleting the entire directory every time someone disables their mods why not just temporarily rename the Mods folder?

[skdursh]

Possibly relevant backstory: I am new to Satisfactory and so might be missing some key issue here.

Main point: I recently started playing Satisfactory and have fallen in love with the game. Loving it as much as I do I have begun to delve into modding and so have begun using this manager to facilitate that. After installing a good number of mods I was curious about the folder structure worked for modding this game and how the manager itself worked and noticed that when I disable mods via the manager it is in essence completely deleting the Mods directory from the Satisfactory folder, which I feel might not be the greatest route for reasons I'll talk about briefly. Curious about why it was being done like this, I re-enabled the mods and waited a few minutes for the mods to be moved back to the game folder and then I went into the Satisfactory folder and simply changed the name of the folder "Mods" to "Mods (disabled)" and launched the game. I was wondering if perhaps renaming the folder was not enough or if the game might not function with an improperly labeled unexpected folder, but no, as far as I can tell the game is running flawlessly as if it was an entirely vanilla install without any Mods whatsoever in the folder structure. So this makes me wonder then WHY does the manager compeltely delete the folder instead of simply renaming it? While it might be a negligible issue if only done from time to time, deleting a bunch of files for no reason and then moving them back isn't exactly great for harddrives as every harddrive whether SSD or HDD has a read/write limit before the harddrive starts to function improprerly. It just seems really unnecessary to completely delete the folder and however many GB of data is there when to me all it appears that you actually need to do is rename the folder to something the game isn't looking for. If there is some reason why this doesn't work like I imagine it does, please let me know, but otherwise this just looks like as unnecessary shortening of the harddrive's lifespan for arbitrary reasons.

[Jarno458]

While not a bad idea, i think this issue belongs to https://github.com/satisfactorymodding/SatisfactoryModManager

[mircearoata]

I have moved the issue to the correct repo.

Part of why this is done is because you can have mods that are not managed through SMM, specifically if you're a mod developer. SMM should not touch any file that is not managed by it, so renaming the folder would not respect that.

Another part is technical, turning mods off actually switches the install to the vanilla profile (an empty profile that's not displayed in the list), while still showing the previous profile as selected, making turning mods off behave the same way as just switching to an empty profile.

And then, for SMM v3 (currently in beta), the profile lockfiles (list of exact mod versions, including dependencies, based on what mods you chose in each profile) are now stored in the Mods folder, so moving it would add an unnecessary step of checking both locations for the lockfile.

One thing I was considering was adding an option for symlink/hardlink, caching the extracted mods as well, not just the downloaded zips, however symlinks and hardlink on Windows require admin or enabling developer mode.

Another option on Windows is junctions, but that requires the cache to be on the same volume as the game, so if you enable junction mode you must either have only one drive on which you have the game (on Epic, Early Access and Experimental are two different games, and Dedicated Servers can also be managed through SMM, so those would need to be on the same volume too), or clone the extracted cache to every disk, meaning either additional work for allowing configuring the location on each drive instead of a single cache location config, or having a fixed path for the extracted cache on every drive, which might not work for everyone because of permissions.

Repeated writes are only an issue for SSDs, for HDDs what matters is the time they have spent spinning, and power off-power on cycles. And assuming you downloaded all the mods on SMR which are at most 25.5GB (I cannot get an accurate number without downloading all the mods, but based on a mod dump I have from November 2022, mods are compressed to around 1/3 of the raw size, and currently all mods on SMR are 8.5GB), and you have the cheapest SSD, of the lowest size from Amazon (a $13 120GB SSD), that would have a 60TBW, meaning ~2500 2-way vanilla toggles (so 2500 times turning mods off, and 2500 times turning mods on). Assuming you play at least an hour before turning mods off or on again (though you would probably play more), that would mean 5000 in-game hours before your drive fails. At 8 hours a day, that would mean 2 years of turning mods off and on again (once again, on the cheapest, lowest capacity SSD available; on a more reasonable 500GB SSD, that it would be 8 years, and for a 1TB device it would be 16 years, since TBW scales linearly with disk capacity; both of these numbers are slightly higher than the expected lifespan of a SSD).

Regardless of the math above, not having to extract the mods every time would still be a nice feature, even if just for the theoretical improvement in mod install time (I don't have any numbers on the speed difference between extracting and creating a symlink), especially on HDDs/SATA devices. However, at the moment it would have way lower priority than other tasks that still need to be done, such as proper dedicated server support, modpacks, synced profiles, and automated mod development environment setup.