Feature request - allow moving instead of copying, a way to handle huge mods #7
Comments
|
Yeah it could speed up the process for some big mods. It is possible to do that, however this will mess up the conflics between mods. For example if mod1 is applied which moves a file called "file0", and then you apply mod2 which modifies also file0, the file0 of the mod1 will forever be lost. Maybe I could add an option in parameter.ini like "apply_method" which could be ether copy or move. The thing is that I would prefer that this could only be done by editing manually the parameter file. Like that nobody would use this apply_method by chance, since it present a risk to loose mod files. What do you think ? |
|
That could be a good idea because advanced users will usually be aware that they are overwriting files. I think the app should provide a warning as a reminder if "overwrite mode" is turned on though, something like "WARNING THIS WILL OVERWRITE file0, proceed?" Or another idea is that when a file is going to be overwritten you could make the app backup the file that will be overwritten. I know some of this begins to get quite complicated though, just trying to think of a good way to do it. I will post again if I think of a better solution. Thank you for the app by the way, it has been very helpful! |
|
Hard links would be great here, unfortunately fat32 doesn’t support them. |
|
However, it’s possible to do some hacky stuff with editing file system tables to do it manually. Unfortunately, things like fsck will see it as corruption and “fix” it so I don’t recommend it |
|
You might also be able to do something similar with mounting |
|
could it be better to support "compressed mod" ,just like the .bnp format or standard zip/7z archive. so that it could be better handling big mods. |
|
It would also make distribution easier because it would be one file instead of a folder |
|
It depends on if it can be extracted directly to the destination, or if it has to be extracted to a temp directory then copied. Both would save on disk space, but the second one would take longer. |
|
Tbh most mods have their files already compressed individually or in groups. Eg skyrim uses bsa. So just something like tar would be fine |
|
here is an idea, if you keep a cache of file paths that says what mod a given file belongs to, when smm detects that a file will be overwritten it can move the conflicting file back to the /mods/ path before it moves the new file to its place. |
|
Another solution could be rename the mod file under atmosphere/contents so it gets disabled, you could only toggle on/off with SimpleModManager. The overlay works wonderful with small mods, but it takes too long to enable bigger mods. Example
No need to move the file around. |
|
I'm making a mod distribution format :) |
|
Build system is in python |
|
Includes icon and metadata like description and author and stuff |
|
JSON Schema for mod.json for parsing |
My suggestion would be to offer an option to move mods instead of copying them. I know this means you can't compare size anymore with your current method to see what's installed, but currently the tool can't be used with huge mods because copying is too slow.
Perhaps you could set a size parameter for copying or moving in the parameters.ini file, if the mod exceeds the specified size then it will be moved to the contents folder instead of copied.
Or maybe as an ultimate solution you can find a way to make the app do moving globally instead of copying? It would be much more efficient, faster and no duplicate files on your SD card.
The text was updated successfully, but these errors were encountered: