I don't think this is a good idea, even though I have considered it. The first and most important point is that it will disrupt the entire dependency system of the VAM community. Once you unpack all the VAR files, any work you create in the future will only be visible to you. If you want others to see it, you will have to spend more effort to retrieve the VAR files you downloaded initially, and including someone else's data in your own VAR file is not advisable.
Moreover, this is an irreversible operation. If you want to reduce file size, you must delete old files.
As for the second point, if you only want to make the system run faster, I think using VAR Manager would be better.
You can keep only the VAR files and dependencies that you want to use in the current system and temporarily move the others elsewhere."
This is only a problem when there's a lot of VAR with morphs using "preload morphs": true. This you can either change in the VAR or inside VAM in the Package Manager.
You can find those relatively easy and disable the ones that shouldn't preload.
There's a lot of differences in VARs, they go from excellent packaging practices to absolute vomit level packaging care. The best thing you can do is first of all to not use bad packaged VARs, then not keep everything you download, then other things. Extracting VARs is not a procedure that I can see helping you without causing much bigger problems.
I'm sorry, but I can't agree with your opinion.
Under normal circumstances, unless we decompress all our .var files or encounter errors when loading these .var files with VAM, we cannot understand whether the .var files were fully downloaded at the beginning or if the file content is actually...
hub.virtamate.com
"When analyzing the contents of .var files, I found that many .var contents are not generated with VAM's packager but rather with various compression software. Although the file extensions of these files are all .var, the actual compression format is not necessarily zip, but may include formats like rar and 7z.
At the same time, .var files, aside from using non-standard characters in non-English names that make it impossible for VAM's downloader to recognize these var files, also contain non-standard character paths that render the contents of these .var files unusable in Windows operating systems not using that language. This is particularly true in the case of paid content, such as: person, CUA, or clothing paths that use a variety of different Chinese and Japanese paths.
Although my computer can identify these paths and I can try to modify what happened, in Windows systems not using these languages, VAM cannot normally import these contents with non-standard character file paths.
My script has been handled when dealing with these non-standard characters in .var files, and in principle, all should be checked. However, I still hope that creators can use standard characters in both file names and internal paths of .var files. "
What bigger problems might happen?
Perhaps I need to emphasize a little, in today's times and mentality, we cannot assume that users or downloaders will steal or unauthorisedly use their own creative elements for profit without the user's consent. If such a situation occurs, it is fine to take down the product afterward and reclaim the profits that should have been earned. Anti-theft measures that presuppose buyers' infringement always result in lower performance or even non-functionality of software or games. This phenomenon often occurs on the STEAM platform. To give an example, consider CAPCOM and some Korean developed anti-theft software. It's just a means of "punishing legitimate users without reason". In my region, there's a meme: "Are you also a victim of using genuine software?"
In fact, .var files are not a form of encrypted file format, they are a type of zip. And the fact that meta.json files cannot be fixed and individually saved is the most likely background factor for the creators' content to be unintentionally or deliberately misused without authorization. As a matter of fact, not all creators will upload a dependency.txt at the same time when they upload data. And large scene creators, such as VH34's free and paid content, do not use packager to generate .var files, but use zip to download and overwrite to ensure correct execution.
Not only the above reasons
Hi ive just tested clean install of newest VAM with just MCGruber benchmark and its dependency with my 2year var gatherer. And the difference was huge. New install: overall avg 178, old intstal 101 thats f..king 80%. All was ttested on same settings with no session plugins. Why the hell is...
hub.virtamate.com
The .var file is a good download source and a local database or verification provider for accuracy or authorization, but it is not suitable for operations that require the scene to be opened from inside every time it starts, or for monitoring changes in the addonpackages.
Including paid content, I have over 20,000 .var files, totaling about 600GB. All .var files have an average compression rate of 60-75% of the original file size. In other words, if they were all decompressed, even if I loosened the conditions and divided these .var files by 0.8X, the size after decompression would be at least over 850GB. However, what is the total file size after decompressing these .var files along a fixed path and allowing duplicate content to be overwritten? The answer is roughly 650GB. In other words, these .var files contain a considerable amount of duplicate content or "files that coincidentally use duplicate paths and names".
"Duplicated content or files that use duplicated paths and names" have a very negative impact on the memory management of software, and it's not just a matter of efficiency.
Would it be possible to have the script automatically repack each individual resource back into var format?
No, I would never bring about such a situation.
