VaM 1.x Headache with duplicate morphs

[SlimerJSpud]

There are some plugins for Vam that use morphs. Sometimes, they package their own, sometimes they're in a separate package. The issue I see is that sometimes, Vam will activate the same morph from multiple versions. This can cause distorted expressions, eyes that are always closed, etc. Of course, the standard advice from plugin creators, and the mods here is to delete all old versions of updated plugins. There's a big problem with doing that. If you delete the old versions, then all those old versions show up when you scan for missing packages in game. Because there's no reverse lookup in game to see what var is calling the old version, you have to hunt them down manually, which is a huge PITA. I went through this with the excellent Life plugin. Life got an update so the pose morphs it uses wouldn't get saved in appearance presets. Life 14 is fixed. The problem is, creators are STILL releasing new scenes with Life 13, which has the problem. With 13 and 14 active in the AddonPackages folder, you get the duplicate morph effect I noticed. I went to the trouble of hunting down all the affected vars and marked them in Package Manager to ignore missing dependencies. If I download a new scene that uses Life 13, I have to immediately mark that one to ignore missing dependencies too. If you just blindly download all dependencies for a scene, you'll re-install the old version, and get duplicate morphs. The only good answer I see is for all plugins that use morphs to put them in a separate package and have the plugin always look for the "latest" version of the support file. Some plugin authors are doing this, most are not. This is a mess. I went through this for Life. Can you imagine doing this for Timeline? Timeline doesn't use its own morphs, but the issue with deleting old versions still applies. An exact version dependency is a "soft" error, shown in yellow in Package Manager. Deleting the old version and marking the package that uses it to ignore missing dependencies will force the scene to silently use the latest version. This is usually safe. The downside of deleting old versions and not marking the vars to ignore that is that you pollute the missing dependencies list with a bunch of stuff you've already decided not to download.

To sum up:

1. Vam has an issue with duplicate morphs from different versions of the same package getting activated at the same time. There's no simple way to fix this.
2. If you are about to release a new scene, please check to make sure you are using the latest version of all used plugins.
3. If you are a plugin author, please consider taking the morphs out of the plugin and packaging them separately.
4. If you want to do what I did to clean the mess up, use the Python script here to scan for anything that uses a particular var, or any of its versions before deleting them. It's a big help.

 

[RunRudolf]

The only good answer I see is for all plugins that use morphs to put them in a separate package and have the plugin always look for the "latest" version of the support file.

The proposed way is how I do it, but the separate resources package will be updated from time to time too I guess, so the problem may be reduced, but not completely solved. Creators ususally do not release separate resources package for each specific scene, but a general one for all their heavier dependencies. So if a creator wants to add another morph to the resources package and updates the package, the duplication is taking place again.

I think the above behaviour also applies to many other dependency categories, such as clothing presets etc., right? They are duplicated and distributed with every version update of a package. This might however not be as relevant in terms of performance as with morphs.

 

[SlimerJSpud]

@RunRudolf I didn't want to name names, but I think yours is the preferred method. The problem of duplicated assets like hair and clothes is different. That's a different level of Dependency Hell, LoL. In this case, morphs duplicated from one version to the next in the same package causes morphs to be applied twice, which can look terrible. Putting those morphs in the support asset, where it's safe to use only the latest seems to work better.