Guides anatomy of a VAR

This guide means to show what makes a VAR a VAR

A VAR is the prefered way to share content between VaM users, with the Hub hosting thousands of them as I write this guide. Yet, this file only exists from VaM version 1.20, if not mistaken, and before it were the Dark Ages of VaM content sharing. I joke and exagerate of course, but before VARs sharing VaM content was not as easy or controllable as is with it, but that's another story.


Before I continue with the guide, there are at least two existing guides that you should read if you have any intention to share content with other people, or even if you just want to make VARs for yourself to optimise your self-made content. Those are:


Is a VAR a zip file?

Yes, it is. Open it with your archive manager - winzip, 7zip, winrar, whatever you have - and you can see a VAR's contents.

So, is that it, just a zip file?

No, there's more than that.

First off, a real VAR name must follow this scheme: creator.name.version.var
If this is not met, VaM will not recognise the file as a VAR and won't load it, and there will be a error in the Error Log. The version must be a integer (whole number).

When you open a VAR it has in its root a meta.json file. This file is created by the built-in tool Package Builder when packing your files to a VAR - see first guide link above - and turns this zip-like file into a real VAR file usable by VAM.


Lets see in more detail what a meta.json file includes. Not everything there is essential to VaM, and manual changes can provide some benefits too (and downsides of course).
I will use a meta.json file from one of my resources as a example.



What content needs to exist in the meta.json fields?

While the file is needed for VaM to see the VAR as a real VAR, some contents of the JSON file are only for a user benefit. The absence or changes of content in some fields will affect some VaM functionalities or the Hub's when uploading the resource.

Which do not affect VaM or Hub functionalities?

• items 2 to 8, inclusive, and 11

The mentioned items above are relevant during the packaging procedure but don't seem to play any further role afterwards in VaM or when uploading to the Hub. The creator name (2) may be used as a filter option in Scene Browser, but I'm not sure.

Notes:

• Standard...Options and Script...Options: depending on what is set in the checkboxes, will set specific integers or "latest" in the dependencies list item versions.
• Content list: user information only, it can even be empty.
• Custom Options - reference issues: if you have items listed it's best to check what happened and if they break something in your content.

Which fields affect VaM or Hub functionalities?

Well, it's the ones not listed in the previous section

Notes:

• License type: if you upload the resource to the Hub, the license shown comes from here
• Dependencies: this is relevant when uploading to the Hub and in the Hub Browser inside VaM for downloading missing dependencies. The Standard/Script...Options you pick are very important on how should dependencies versions be treated
• Custom Options - preload morphs: only set it to True (checkbox checked) if you have a morph pack or need the morphs included in the VAR to be preloaded for some reason, as this impacts the loading time and FPS in VaM. Preloading the morphs includes them in the morphs list even if not in use.

Content in a VAR

Naturally, just a meta.json file makes a pretty useless VAR. Inside a VAR there can be many types of content, and you're likely to see next to the meta.json a folder named Custom and likely a Saves if there's a scene in it.

If you open a well packaged VAR, the folder structure inside will be similar to the folder structure in your VaM folder. For example, if there's a scene it's expected to be in the folder Saves/scene; if there's a appearance preset, in Custom/Atom/Person/Appearance; and many other options for content.


There may be VARs with content in other places different from the base VaM folder structure. While alternative folders may still work with the resource provided, it's a messy way to package something and more difficult to find them in VaM as they're not in the expected places.

Paths in the VAR's text-based files (JSON/VAP)

When you package your content to a VAR, if text-based files are included, like scenes (JSON) or presets (VAP), the paths within that reference files included in the VAR also are changed.

Path types:

1. Local file: "Custom/Sounds/mysound.ogg"
   • The local file is a reference to a file you have in your VaM folder. VARs should not have paths like this, if you share the VAR it won't find the referenced file.
2. VAR name file: "atani.mysound.1:/Custom/Sounds/mysound.ogg"
   • This type of path is present when referencing a file in a VAR, either in a local json/vap or in a VAR (not itself).
3. SELF file: "SELF:/Custom/Sounds/mysound.ogg"
   • The SELF means the VAR where the json/vap being read is in, itself.

Some examples:

• You make a scene that calls for a local file, the path calling for that file is type 1. You package the scene to a VAR, the local file is also imported to the VAR, and now the scene's reference to the file is type 3.
• You make a scene that calls for a file in a VAR (type 2). You package the scene to a VAR, there's no change to the path type. The VAR referenced is added to the meta.json file as a dependency.
• You open a scene from a VAR. The referenced paths to files in that scene can be type 2 or 3 depending on their locations. You now save the scene as a local scene file. All paths type 3 that were present earlier are changed to type 2 as the locally saved scene is not part of the VAR anymore.

Wrapping up, what makes a VAR a VAR?

A VAR is a zip file created by Package Builder that follows a specific naming scheme, includes a meta.json file and VaM suitable content. You could make a VAR file manually without using Package Builder, but Package Builder is there to help you, save time and warn you about potential problems.

Something you can do, I do it all the time, is to change existing VARs. Maybe you don't want part of the content, say a scene on a looks VAR because you already made a appearance preset for it, you can remove it. Or a VAR has dependencies you don't want to also have, open the meta.json file and remove those entries.
Of course, be careful when changing files in a VAR or the text in the meta.json file, accidents and mistakes happen. And as you may expect, if you change a VAR and later a updated version is available, you'll need to redo those changes on the new one.

Hopefully this guide and others have given you some insights on what a VAR is and how you can change it to suit your needs.