I considered doing that tool (updating jsons) for myself, because with many plugins it is no problem, a different dependency version (mostly plugins) does not break a scene in some cases. But it does in some other cases, and it would be really time consuming to know which one in which case. On the other hand, plugins bloat in VaM is not the reason of slowdowns. Anything that includes clothing, hair and morph it is. In terms of disk space, plugins represent a very small portion. Surely we do not like having about 100 Timeline versions installed, but it really does not affect performance. They just sit there for scenes that need them and VaM does the job of hiding them for you. And VarBrowser even hides them from VaM. Visually though, and in Vambropy for example, it is kind of ugly to see the same package repeated 100 times. I am thinking of a way, after what I have mentioned before about tagging older versions first, to hide them like VaM hides them, some "Show older versions" checkbox, something like that. But editing inside vars is another whole topic, a big community discussion IMHO.
I think over time when the entire VAM ecosystem is over, a community could appear to rescue all the content and repair it to work in the most optimal way, as is seen in some cases with old games where a love work keeps alive and optimizes a game and all a content created by a community, which would no longer exist if it were not for all that great work. It seems to me that in that case we could check complete collections relaunched with all the repairs (i.e. all the ispinox scenes running with the last known version of each plugin). Today, everything continues to change and nothing is definitive, so almost no creator is bothered to review all her/his content and update it with the last dependencies. Within a time who knows, if VaM2 ends up replacing VaM we probably forget about this all, or maybe not. Time will tell.
Unpacking clothing is something I did manually and automatized with scripts, even editing vars and removing duplicate clothing from looks and scenes, and it would require some steps, it was prone to errors (and editing vars is dangerous if your files are not organized because you may end with an archived var that is not 100% original anymore), it required to review in a previous temporary directory where all the content would go, because you have clothing with assets, clothing with sound (!), clothing with scenes and presets, scripts and textures for presentation purposes mainly, and files placed anywhere, sometimes in locations that have nothing to do with VaM conventions. So it is a little bit complicated to blindly unpack if you care about it. I remember I have tried some collections and ended unpacking what we liked, so it appears in gray, a local item in the clothing browser, in VaM. And it is a bit faster that way. Scenes and appearances have no problems with it because when package is not found, VaM tries with the UID and it finds it anyway. But you still see the missing dependency, and that is the reason for the "dummyvar", a empty package with only meta.json file, which I put in a subdirectory so it does not mix with the real packages. That turned into a feature in Vambropy, but I have limited the whole unpackingg thing it to clothing and hair packages wihout scenes, to avoid bloating Custom folder with unconventional stuff, to keep it simple. So a conventional unpacked clothing item is a Custom/Clothing folder, maybe a Custom/Atom/Person/Clothing if it has some presets, maybe an assetbundle if it has some-CUA, but that it is enough. Vambropy can unpack all clothing where in tags you read "clothing", "clothing, hair", "clothing, assets", "Hair", "Hair, assests". Of course you can edit the python script and modify to extend but I consider it an unnecessary thing in terms of optimization. With some personal favorites (a hundred, couple of hundred maybe?) simple clothing and hair items unpacked it is enough to give you an extra boost of performance. Having a whole collection unpacked I think it defeats the purpose of VarBrowser. I try to find some kind of balance but anyone can have a different view on it, that is the hard part to decide on a feature.
All the Vambropy menu functions are scripts that iterate on each package selected, so if you select a large bulk it should work. If there are invalid items in it (like a clothing with a scene) it should skip and not unpack but the rest should unpack.
If, for some reason, some unknown bug yet, you end with any item coloured as unpacked and it is not really, you can fix it by deleting it from the database. On refresh it will appear again clean with the correct color (make sure related dummyvar is manually deleted).
Reverting unpacking is done by checking if the real package contents is present in the Custom tree. If is not, if a single file is not found, it will not revert and you will need to manually delete the subdirectories with the clothing/hair items. That is another reason for deciding on simple clothing because if you delete a scene that was installed by unpacking a clothing, then the clothing uninstall feature would not work. So this whole unpacking concept maybe it is a little advanced to most users, an experimental thing most VaM users do not need to worry about.
