Question Questions about meta.json in the var package.

[shichao402]

Why does the structure design of meta.json in the var package not include version?

Why does the filename {CreatorName}.{PackageName}.{Version}.var use the original author's name for CreatorName, rather than a transformed name (e.g., spaces converted to underscores)? This confuses me. It seems that var files could easily be renamed incorrectly, leading to unexpected issues. For example, duplicate downloads might automatically add suffixes like "(1)" to the filename, or repeated copies might prepend text like "Copy (1)."

 

[hazmhox]

The question are:

• Have you experimented issues or not?
• Why would you need to rename a .var ?
• Why would you need to know the structure or what the meta file contains?

Those are questions for 95% of users, they don't care, look or think about that. They launch the game, download the files, and that's pretty much it.
No one complained since the .var format exists, and even tho some things could be normalized, nothing critical has ever happened.

So my question is: why do you feel concerned about that and what is your question or (actual) problem exactly? Because there's not much we can say besides "well it's like that ¯\_(ツ)_/¯"

 

[atani]

Why does the structure design of meta.json in the var package not include version?

Why does the filename {CreatorName}.{PackageName}.{Version}.var use the original author's name for CreatorName, rather than a transformed name (e.g., spaces converted to underscores)? This confuses me. It seems that var files could easily be renamed incorrectly, leading to unexpected issues. For example, duplicate downloads might automatically add suffixes like "(1)" to the filename, or repeated copies might prepend text like "Copy (1)."

Many things can come out from altering or making VAR files:

• the "copy (1)" is a Windows thing when downloading to a folder with a identically named file:
  • this is on the user's side to pay attention. Don't download from websites straight to AddonPackages, instead download somewhere else and then move over to AddonPackages. If there are same named files, Windows will ask what to do, overwrite or make a copy.
• manual editing of a VAR:
  • hopefully if you're changing anything here is because you know what you're doing and be able to correct things if you make a mistake
• alternative packagers:
  • the prefered way is to use the built-in packager and understand how it works. There's a guide from ZRSX that explains how to do and package content, a easy and quick enough read to understand the processes involved. I think there's very few usecases where alternative packagers are helpful over the built-in packager.
• ignorance or not caring about proper packaging or consistent distribution:
  • many creators don't know or care about how to share their content in a good way. Human sloppiness cannot be fixed with any format.

anatomy of a VAR - Guides -

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...

hub.virtamate.com

 

[shichao402]

The question are:

• Have you experimented issues or not?
• Why would you need to rename a .var ?
• Why would you need to know the structure or what the meta file contains?

Those are questions for 95% of users, they don't care, look or think about that. They launch the game, download the files, and that's pretty much it.
No one complained since the .var format exists, and even tho some things could be normalized, nothing critical has ever happened.

So my question is: why do you feel concerned about that and what is your question or (actual) problem exactly? Because there's not much we can say besides "well it's like that ¯\_(ツ)_/¯"

My inquiry is purely driven by curiosity about the design rationale behind the current structure of VAR files. As I expressed earlier, what puzzles me is why this system appears to embed significant metadata directly in filenames (like version numbers), rather than storing it internally as complete package metadata.

This contrasts sharply with package managers I've worked with (npm, NuGet, etc.) that maintain self-contained manifests within the package itself. For instance, critical information such as version control in those systems isn't dependent on filename parsing but rather explicit metadata fields.

The VAR approach seems particularly unique in the VAM ecosystem. What I find truly fascinating is that this design apparently works flawlessly for 95% of users without causing issues - as you mentioned, there have been no significant complaints despite its unconventional approach. This paradox (unorthodox structure yet perfect practicality) is exactly what sparks my technical curiosity about its architecture.

 

[shichao402]

Many things can come out from altering or making VAR files:

• the "copy (1)" is a Windows thing when downloading to a folder with a identically named file:
  • this is on the user's side to pay attention. Don't download from websites straight to AddonPackages, instead download somewhere else and then move over to AddonPackages. If there are same named files, Windows will ask what to do, overwrite or make a copy.
• manual editing of a VAR:
  • hopefully if you're changing anything here is because you know what you're doing and be able to correct things if you make a mistake
• alternative packagers:
  • the prefered way is to use the built-in packager and understand how it works. There's a guide from ZRSX that explains how to do and package content, a easy and quick enough read to understand the processes involved. I think there's very few usecases where alternative packagers are helpful over the built-in packager.
• ignorance or not caring about proper packaging or consistent distribution:
  • many creators don't know or care about how to share their content in a good way. Human sloppiness cannot be fixed with any format.

anatomy of a VAR - Guides -

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...

hub.virtamate.com

I agree with the point that Human sloppiness is something that no format can solve, .
Generally speaking, in my conception, filenames are very easy to modify.
Because it's a normal operation for users. Moreover, VAR files are very accessible to users.
So I'm actually quite curious. I wonder what kind of motive prompted VAM to heavily rely on filenames as important information. This could be quite interesting. As the previous respondent mentioned, there are so many VAR packages now, but nobody is complaining about any problems, perhaps they really haven't encountered any problems. This is the most curious and interesting part.

 

[hazmhox]

Filename "use" (as a technical mean to achieve something, for instance, gather release version) is generally tied to two aspects: convinience or performances.

For instance, why reading a meta file, when you can grab the release version from a string you already got since basic string manipulation (like a split) has pretty much zero overhead. Especially when you know that you're gonna have hundreds if not thousands of files in the folder.

You're gonna say that the meta file exists anyway, but it's probably like most design choice in that situation: "well I did it like that at the time and refactoring it was not my priority". Also, since the system relies on the version to "show/hide" var files in the UI, but also select the proper var to load, this is something that can be done without loading the meta file. Only knowing it's filename is enough to filter out what is needed or not.

Finally, the reason why there is no problem and nobody complained, it for what I told you earlier:

• 95% users are not power users and just "players" (besides moving/deleting a var, they don't even think about the tech part of it)
• The 5% remaining are creators and kind know (for the most part) what they're doing

Even tho, you will find in that 5%... persons doing bad things and botching a .var file, most of them won't as they have a logic that goes with a standard OS use. ie: don't rename a file for a random reason, don't manually modify meta files just for the fun etc...

And when you think about it. Windows is the same, you could go and modify library files or rename critical dlls in the OS without limitation. You'd have a weird surprise at the next boot, but nothing prevents you to do it.
Just like you could rename the .dat files in a Unity game or .pak files of a UE game... no one does that

One thing I agree with what you said earlier is, naming should cleanup user inputs. It drives me nuts to see files with
"UberLook[v3.3](Thing){CreatorWeirdness}.var"

 

[shichao402]

Filename "use" (as a technical mean to achieve something, for instance, gather release version) is generally tied to two aspects: convinience or performances.

For instance, why reading a meta file, when you can grab the release version from a string you already got since basic string manipulation (like a split) has pretty much zero overhead. Especially when you know that you're gonna have hundreds if not thousands of files in the folder.

You're gonna say that the meta file exists anyway, but it's probably like most design choice in that situation: "well I did it like that at the time and refactoring it was not my priority". Also, since the system relies on the version to "show/hide" var files in the UI, but also select the proper var to load, this is something that can be done without loading the meta file. Only knowing it's filename is enough to filter out what is needed or not.

Finally, the reason why there is no problem and nobody complained, it for what I told you earlier:

• 95% users are not power users and just "players" (besides moving/deleting a var, they don't even think about the tech part of it)
• The 5% remaining are creators and kind know (for the most part) what they're doing

Even tho, you will find in that 5%... persons doing bad things and botching a .var file, most of them won't as they have a logic that goes with a standard OS use. ie: don't rename a file for a random reason, don't manually modify meta files just for the fun etc...

And when you think about it. Windows is the same, you could go and modify library files or rename critical dlls in the OS without limitation. You'd have a weird surprise at the next boot, but nothing prevents you to do it.
Just like you could rename the .dat files in a Unity game or .pak files of a UE game... no one does that

One thing I agree with what you said earlier is, naming should cleanup user inputs. It drives me nuts to see files with
"UberLook[v3.3](Thing){CreatorWeirdness}.var"

Thank you for clarifying the design rationale! I agree that prioritizing filename parsing for efficiency—especially given how rarely most users modify .var files—is a pragmatic approach. The balance between performance and usability for the majority of users makes a lot of sense.

From a purely technical perspective, I find it interesting how metadata could optionally reinforce this design. For instance, if meta.json mirrored critical fields like version or CreatorName, it might act as a fallback for edge cases (e.g., accidental filename corruption) without complicating the core logic. That said, this is just a hypothetical observation—I fully recognize that every design choice involves trade-offs, and the current system clearly serves its intended audience well.

Your explanation helped me appreciate the "invisible" robustness of relying on filenames, even if it initially seemed counterintuitive. Thanks again for sharing your insights!

 

[atani]

The use of filename version checking is quite useful for me when I update something in a VAR that is not going to change the contents of the meta.json, like for example a image that was updated. I just replace it, bump the version, and all good.
This more permissive approach is very helpful for basic changes, but of course, the person needs to understand what he/she is doing. Would be more annoying for the power users if VaM forced a more restrictive or double checking format. For community made content, more flexibility with the format is good I think, even if mishandling can introduce errors.

 

[shichao402]

Thank you for the explanation! I now have a much clearer understanding of the design philosophy behind VaM’s .var packages.

 

[hazmhox]

You can select the answer that fits your original post then