Yesterday I sent you a long message, but unfortunately I got banned because I sent a tool from f95. They said it was pirated, but it was actually created completely by AI. Anyway, I sent you this yesterday.
"
Maybe you are overthinking the true source issue. VaM does not care who the original author is as long as the file loads. the main goal is deduplication based on what the user already has in their folder.
You can use this simple logic to avoid corruption and conflicts.
First build a hash index of all standard VARs currently sitting in the user's AddonPackages folder.
Then scan the bloated VAR. If an embedded file hash matches an external VAR hash, rewrite the JSON to point to that external VAR and delete the embedded file. External dependent VARS files are usually the original ones.
If multiple external VARs share that exact same hash, just pick the oldest one or the most referenced one. It doesn't matter which one; the game will load it regardless; in any case, this rarely happens.
If an embedded file was modified by the creator (which means it will have a different or same hash, and have a different size). The tool should just ignore it and leave it embedded; it may have been modified by the author.
If the embedded file hash doesn't exist anywhere in the external folder (either a custom asset or a missing dependency), don't extract it. Leave it embedded. It is either a custom asset made by that creator or a dependency the user has not downloaded yet.
If the user downloads the actual original VAR later, they can just run your debloat tool again to clean it up.
Ex: https://pixeldrain.com/u/H6QafETy
We have ShaoB.修女.1 and its two dependencies 6ye6.huayinzi3_0.1.var and Abie.A35.1.var.
Inside the bloated VAR ShaoB.修女.1.var, there is a file located at Custom/Atom/Person/Textures/FemaleBase/清新风/清新风5/genitalsN.png. The creator embedded this file instead of using dependencies. However, this exact file (same hash) already exists in both 6ye6.huayinzi3_0.1.var and Abie.A35.1.var in the local AddonPackages folder.
So, the tool should detect this hash match. It shouldn't extract the file to the loose folder, t should simply delete the embedded genitalsN.png from the bloated VAR and add either 6ye6.huayinzi3_0.1.var or Abie.A35.1.var to the meta.json dependencies.
If multiple external VARs share the same hash (like in this case), just pick the oldest one or the most referenced one as the dependency.
If the bloated VAR contains custom files (hashes that do not exist in the external AddonPackages folder), the tool must leave them embedded inside the VAR. Do not extract them.
I also have a tool for quickly checking these things, it comes from F95. You can try it if you want, here's the link to the application and its source code:
https://pixeldrain.com/l/XgbZ99Gw
I also just realized a huge problem. If I somehow delete a VARS file that I don't like, it can easily corrupt other VARS files. It's really troublesome; maybe this feature is a mistake to fix the flawed design of VARS files and the limitations of the UNITY engine. I don't know...
"
Yesterday I sent you a long message, but unfortunately I got banned because I sent a tool from f95. They said it was pirated, but it was actually created completely by AI. Anyway, I sent you this yesterday.
"
Maybe you are overthinking the true source issue. VaM does not care who the original author is as long as the file loads. the main goal is deduplication based on what the user already has in their folder.
You can use this simple logic to avoid corruption and conflicts.
First build a hash index of all standard VARs currently sitting in the user's AddonPackages folder.
Then scan the bloated VAR. If an embedded file hash matches an external VAR hash, rewrite the JSON to point to that external VAR and delete the embedded file. External dependent VARS files are usually the original ones.
If multiple external VARs share that exact same hash, just pick the oldest one or the most referenced one. It doesn't matter which one; the game will load it regardless; in any case, this rarely happens.
If an embedded file was modified by the creator (which means it will have a different or same hash, and have a different size). The tool should just ignore it and leave it embedded; it may have been modified by the author.
If the embedded file hash doesn't exist anywhere in the external folder (either a custom asset or a missing dependency), don't extract it. Leave it embedded. It is either a custom asset made by that creator or a dependency the user has not downloaded yet.
If the user downloads the actual original VAR later, they can just run your debloat tool again to clean it up.
Ex: https://pixeldrain.com/u/H6QafETy
We have ShaoB.修女.1 and its two dependencies 6ye6.huayinzi3_0.1.var and Abie.A35.1.var.
Inside the bloated VAR ShaoB.修女.1.var, there is a file located at Custom/Atom/Person/Textures/FemaleBase/清新风/清新风5/genitalsN.png. The creator embedded this file instead of using dependencies. However, this exact file (same hash) already exists in both 6ye6.huayinzi3_0.1.var and Abie.A35.1.var in the local AddonPackages folder.
So, the tool should detect this hash match. It shouldn't extract the file to the loose folder, t should simply delete the embedded genitalsN.png from the bloated VAR and add either 6ye6.huayinzi3_0.1.var or Abie.A35.1.var to the meta.json dependencies.
If multiple external VARs share the same hash (like in this case), just pick the oldest one or the most referenced one as the dependency.
If the bloated VAR contains custom files (hashes that do not exist in the external AddonPackages folder), the tool must leave them embedded inside the VAR. Do not extract them.
I also have a tool for quickly checking these things, it comes from F95. You can try it if you want, here's the link to the application and its source code:
https://pixeldrain.com/l/XgbZ99Gw
I also just realized a huge problem. If I somehow delete a VARS file that I don't like, it can easily corrupt other VARS files. It's really troublesome; maybe this feature is a mistake to fix the flawed design of VARS files and the limitations of the UNITY engine. I don't know...
"