-
Hi Guest!
We have recently posted a VaM2 2024 Progress Update on Patreon!
Check out the details here: https://www.patreon.com/posts/vam2-august-2024-111164439 -
Hi Guest!
We are excited to announce a new feature on the Hub: Favorites!
You can now add resources to your favorites, and organize your favorites into collections! You can check out the details in our official announcement!
VAM needs automatic resource/plugin update function.
- Thread starter EMPIR
- Start date
Automatic in what sense?
There's a button in the built-in Hub Browser that downloads all package updates.
There's a button in the built-in Hub Browser that downloads all package updates.
It's technically possible to do the automatic downloading of new versions and the automatic installation of those versions into the current scene with a plugin. CheesyFX does this with the CheesyPluginSuite which keeps his plugins up to date. I have some tentative plans of automating it for any resource, haven't yet had the chance to work on it.
As far as I can tell, the only real issues that arise have to do with backwards compatibility. For example, a newer version of a plugin no longer supports some triggerable parameter that the scene it is in relies on, thus the scene will lose some functionality like an animation, a UI button or slider no longer working, and the user has no idea how to fix it. The user might not even be aware that the automatic update caused that issue, and then goes to blame the author for a faulty scene. It would be up to the scene's creator to fix it in the first place. With other resources, it's easy to imagine things breaking if a scene or preset references a file with a path that no longer exists in the newer version of the package, but obviously this is likely to cause problems even currently (because most resources reference clothing, hair etc. vars by the ".latest" version).
There are many ways in which compatibility can break, and sometimes it's necessary. The versioning system in VAM is just based on incrementing integers (package version 1, 2, 3 and so on) which limits things. Ideally, the versioning system would be based on semantic versioning which would allow package authors to indicate the breaking of backwards compatibility with an increase in the major version number - so 1.0.0 -> 2.0.0 instead of 1.0.0 -> 1.1.0, for example. Those new major versions could be automatically downloaded but not automatically replaced in the current scene. The increase from 1.0.0 to 1.1.0, on the other hand, would be an example of a minor version increase which just indicates that new features are added, but doesn't break backwards compatibility, and such updates could be automatically applied in the current scene. SemVer would especially be beneficial for plugins, less so for other types of "simpler" resources which could just continue using the integer incrementation based versioning.
As far as I can tell, the only real issues that arise have to do with backwards compatibility. For example, a newer version of a plugin no longer supports some triggerable parameter that the scene it is in relies on, thus the scene will lose some functionality like an animation, a UI button or slider no longer working, and the user has no idea how to fix it. The user might not even be aware that the automatic update caused that issue, and then goes to blame the author for a faulty scene. It would be up to the scene's creator to fix it in the first place. With other resources, it's easy to imagine things breaking if a scene or preset references a file with a path that no longer exists in the newer version of the package, but obviously this is likely to cause problems even currently (because most resources reference clothing, hair etc. vars by the ".latest" version).
There are many ways in which compatibility can break, and sometimes it's necessary. The versioning system in VAM is just based on incrementing integers (package version 1, 2, 3 and so on) which limits things. Ideally, the versioning system would be based on semantic versioning which would allow package authors to indicate the breaking of backwards compatibility with an increase in the major version number - so 1.0.0 -> 2.0.0 instead of 1.0.0 -> 1.1.0, for example. Those new major versions could be automatically downloaded but not automatically replaced in the current scene. The increase from 1.0.0 to 1.1.0, on the other hand, would be an example of a minor version increase which just indicates that new features are added, but doesn't break backwards compatibility, and such updates could be automatically applied in the current scene. SemVer would especially be beneficial for plugins, less so for other types of "simpler" resources which could just continue using the integer incrementation based versioning.
Last edited:
I think this topic is most relevant for case when resources goes update just for change VAR license markers (BY,ND etc). Like was recently, and for further probable cases, which does not touch VAR` content itself.
For avoid cloning exactly the same things.
For avoid cloning exactly the same things.
