That is correct.
Feedback on proposed Paid content submission procedures.
- Thread starter VaMDeV
- Start date
Okay. The wording confused me - when the announcement refers to ".var", it's actually referring to the content or resource and talking about a updating that. A ".var" is a file, e.g. everlaster.Something.1.var is a file. If I update a file, it's still everlaster.Something.1.var - if it wasn't, I'd be creating a new file, not updating a file. The content or resource that the announcement refers to corresponds to the Hub resource, which can have multiple ".var" files to indicate different versions of the resource. So, in the final actual policy that gets implemented, can you ensure that the wording is clear and is referring to content or resource, not to ".var". Thank you.
Now I have one concern and then a few questions.
Concern:
Let's say I've created a Hub resource Something, and scanned the first var package everlaster.Something.1.var. All of the information in the post is about that specific file, and the download link points to a Patreon post for publishing that specific file.
If I now publish a new version of Something on Patreon, that's a new Patreon post. The Hub resource still has the download link that redirects the user to the first version's post, and that file is still available. As far as I can tell, there's no connection between the Hub post and the second version at that point in time. I'm still advertising and linking to only the first version, even though another version is available. To me, this fulfills the agreement VaMDeV indicated earlier
1. I opted to make a new file everlaster.Something.2.var, but I'm still only advertising the first file, so based on that I won't have to scan the new file in and make an update to the Hub resource
2. There is clearly a match between the var file being advertised and the var file that is available for download via the download link to the specific Patreon post for that release
Basically what I'm saying is, what VaMDeV wrote above seems to be in contradiction with the idea that every update to the resource externally i.e. on Patreon must also come with an update to the Hub resource. My interpretation of what VaMDeV said is that if the original .var file that is being advertised is modified, producing a mismatch between the scanned file content and the actual file being advertised, only then must the file be rescanned.
Questions:
What specifically constitutes an update to the file in the Hub resource?
Is it only based on the filename - e.g. everlaster.Something.2.var is an update to the Something resource because that resource was uploaded as everlaster.Something.1.var.
Or is it based on the package meta.json, or other contents of the package, or a combination of these?
The reason I'm asking is because it is normal for me to have a plugin development phase on Patreon that includes alpha releases that I don't want to advertise on the Hub. I want to have the freedom to choose when I advertise the new features - I don't want to advertise something that isn't ready for that, e.g. may contain breaking bugs that I want to fix before advertising. In terms of the proposed policy, how can I work around this and prevent advertising work in progress new versions of a paid resource until I'm actually ready for that?
Last edited:
1. You create a resource. For that resource, let's say you have something.1.var and something_demo.1.var on your Patreon. You must upload both files and have them scanned.
2. You update your Patreon post but do not change the files or create new versions. You do not need to update your Hub post.
3. You update your Patreon and change the files. You add some tweaks and create something.2.var and something_demo.2.var, or you edit something.1.var manually. Now, you must go to resource -> update -> add a new version, and upload the new versions of your files and have them scanned, otherwise you will fail to be in compliance with our policies and we may investigate. This does not necessarily mean you will receive a warning, but if it looks like you're repeatedly neglecting to upload the new versions in spite of our policies, you may then receive a warning.
4. If we visit your patreon and find that something.1.var (or something.2.var if you have changed the version without scanning it at the hub) is very different in structure than the copy you gave us, we may consider that an attempt at deception.
My suggestion to you would be that if you do not plan to advertise your WIP updates, then do not release WIP updates on your Patreon, and instead wait until you have a finished product version to release.
- Messages
- 93
- Reactions
- Points
- 83
To be fair, point 2 is not applicable - the first-tier dependencies already tell VAM what their dependencies are, so if the user downloads all dependencies that VAM complains are missing, there is no possibility of the content not working because of the sub-dependencies being deleted from the meta.json.
The entire premise of deleting sub-dependencies is that they are not needed by the actual content that is being uploaded, they are only needed by the dependencies. The most common case is something like a demo scene for a look, and another scene uses that look, and the creator doesn't want to pollute their meta.json (and by extension, the dependencies on their hub post) with all of the extra unnecessary stuff that only the look's demo scene depends on. Deleting sub-dependencies is a workaround to VAM's own inefficiencies and shortcomings when it comes to dependency management, so I think the moderation team should allow workarounds that aren't causing any harm.
Unfortunately, VaM is currently in development freeze while work is focused on V2. The way the meta works with sub-dependencies inside the program and with the hub is what it is. So, we recommend that you do not edit the meta file. It may cause unintended issues within VaM for the average user accessing your Var. It also, as Ash pointed out, looks like a red flag to our moderation team. So for now, we appreciate it if the community works with the program as it was intended to work.
I have to have a way to upload work in progress downloads for my patrons to try out and provide feedback on before I advertise the content on the Hub. It is a critical part of the development process. I'm sure some kind of solution is possible - so please, don't just impose a strict policy that doesn't leave *any* room to maneuver.
It would be very helpful to have a clear, exact, unambiguous definition that says what the file that is published for download on Patreon must look like to be considered a change/update to the file that the Hub resource is advertising.
For example, if the definition is simply that the creator name and resource name of the var package matches, and the version number is the same or higher (i.e. "everlaster.Something.2" - "everlaster" matches, "Something" matches, 2 >= 1), then the WIP file on Patreon could have a different resource name - everlaster.Something_Alpha.2.var, for example. The only problem then would be loss of backwards compatibility. Is this or something like this a potential work around? If the definition is not based simply on the version number being incremented, then what is it based on?
And an alternative suggestion: have a policy-approved way of labeling/indicating on Patreon that a resource is a WIP version that it is not the one advertised on the Hub. So, despite in principle sharing its identity with the var package that was scanned for the Hub post - apart from the version number which has been incremented - there would be no mismatch/disagreement between the Hub post and the new file on Patreon because the creator is following the recommended way of labeling WIP version releases.
Last edited:
Fair enough. I just don't understand why it is a red flag I guess, i.e. what precisely is the potential harm. Do you have an example of what the unintended issues can be in VaM for the average user? As I explained, VaM already knows about the sub-dependencies through the meta.jsons of the first tier dependencies so I don't quite see what would go wrong in VaM.
Last edited:
Do I need to make health check for already existing paid posts or it's only for new posts and updates? I don't know how many people have this problem but my upload speed on hub is too slow, 10 minutes for 100mb. Health check in that case is gonna take a while
- Messages
- 93
- Reactions
- Points
- 83
Do I need to make health check for already existing paid posts or it's only for new posts and updates? I don't know how many people have this problem but my upload speed on hub is too slow, 10 minutes for 100mb. Health check in that case is gonna take a while
Just new posts after the feature goes live. It will not be required of existing posts.
- Messages
- 93
- Reactions
- Points
- 83
Sorry, I don't have any specific examples to give you. I understand It may seem like a harmless change. However, it makes it a lot harder on us moderator's to have to double check why someone's meta was edited if we allow everyone to do that. Simply put if we come across an edited meta file, innocent or not, we have to follow up as to why it was changed.
- Messages
- 93
- Reactions
- Points
- 83
If I understand you correctly. You want to post iterations of your WIP plugin on your Patreon for your subscribers to test. Then post your update on the Hub when you feel that it is ready to be advertised as a viable upgrade, correct?
That is fine. We completely understand that situation and have no problem with it. We do not expect every iteration of someone's WIP scene file, plugin, look or whatever to have to be uploaded to the hub for us to have a record of.
You do not have to change how you iterate on your work with your subscribers or your fans on your subscription service or your personal Discord.
You are only required to upload your PC var file for a "health check" when you want to advertise your work on VaMHuB.
I hope this answers your question.
Thank you, that sounds great.
Just to double check
The answer to the first question is "No. It means changing the contents of your advertised var package." Or is it that clear cut?
And the answer to second question is "No. You only need to update the Hub post when you want to advertise the new version."
Evening folks.
If i am using CC-BY looks and removed all of the ND / NC dependencies from those looks, before uploading to my patreon, then, can i use those looks in the first place ?
E.g i am using a goblin model that has an eye shader, - NC, but, in my scene, i remove it. Can i use such looks to create paid content or do i have to contact the original author of the looks and ask for the shader to be removed and a new version without it to be uploaded on the hub ?
Thanks.
If i am using CC-BY looks and removed all of the ND / NC dependencies from those looks, before uploading to my patreon, then, can i use those looks in the first place ?
E.g i am using a goblin model that has an eye shader, - NC, but, in my scene, i remove it. Can i use such looks to create paid content or do i have to contact the original author of the looks and ask for the shader to be removed and a new version without it to be uploaded on the hub ?
Thanks.
NeMech
Well-known member
According to the recent VAMHUB rules, items containing NC content cannot be CC BY.
Content that is "CC BY" but includes "CC BY NC" violates the rules, so it is removed from VAM HUB's publication rules.
I'm not the moderator after all, so I'd like to wait for the moderator's reply to see if this is correct.
Content that is "CC BY" but includes "CC BY NC" violates the rules, so it is removed from VAM HUB's publication rules.
I'm not the moderator after all, so I'd like to wait for the moderator's reply to see if this is correct.
Algorithm1248
New member
- Messages
- 13
- Reactions
- Points
- 3
That would still be an improvement over the status quo where paid vars are treated as unknown and ignored. But even if the uploader has permission, it's good to know whether the user will need to buy additional resources to make the content work; I've been bitten by this before.
Thank you, that sounds great.
Just to double check
The answer to the first question is "No. It means changing the contents of your advertised var package." Or is it that clear cut?
And the answer to second question is "No. You only need to update the Hub post when you want to advertise the new version."
We'll get you a clarified answer to this in the coming days. Rest assured, we don't want to disrupt or cause inconvenience to our valued creators. The new scan after all is aimed at protecting your content and safeguarding the effort you put into it. It shouldn't become a burden, otherwise it defeats the purpose of enhancing your Hub experience.
I would like to answer this officially and in more detail within the coming days. We are currently discussing this policy and will present an illustrated explanation that should help users to understand licenses, dependencies, and tiers and how they interact.
Good news. We did figure out how to display the dependencies tab on the Hub website. I am not sure how it will present in-game though.
What I want to know is how long before you start disabling vam installs on people's PCs because they appear to create stuff outside vams policy guidelines. Like everything else, you are ruining a great product by injecting a bunch of garbage to its process and overstepping your role. You say we can't use paid content in posts. You do realize that a good 50 - 60 percent of your free content is re worked DAZ stuff and decompiled asset bundles right? Hell even some of VAMs default content is from DAZ. (A lot of it infact) however I am guessing you have licensed it from DAZ to be above board though. Add to that the fact that even content outside of the hubs reach must now comply with the hubs guidelines is just rediculus. Bad enough we have to jump though hoops with the likes of patrion, mega and those types of platforms. Now this??? I suspect vam 2 will be released with even more invasive tools and compliance scanning abilities. ( If it comes out at all) The only things that should be automated is the detection of paid content inside of other paid content to protect creators works. stories or scenes that are posted outside the hub is technically none of your business. If it's not on the hub it's irrelevant. But seen as how this post likely won't see the light of day as far as actually being posted for others to comment on it doesn't matter. That's the beauty of moderation. Y'all can pick and choose what to post to paint a picture that the majority agree with you. I assure you, they don't.
Default VaM content is officially licensed from Daz, and as part of this standard commercial license from Daz, we have a responsibility to make sure no Daz content is distributed on our platform.
If you are aware of specific Daz content being shared, please report it to our team.
The purpose of our non-invasive file scans is to protect creator content from being redistributed or used without permission, and to protect licenses such as the ones stated above.
As has been stated many times in the past, it was MeshedVR's decision to allow free paid advertising on the Hub, and not to include spam, ads, or popups on our website despite the obvious secondary revenue that might bring. As a result of this free service, you agree to abide by our conditions for advertising your paid products for free on our website.
One of those conditions is that if you are linking to another paid site or service, then that site cannot contain any content that violates our policies.
To make an analogy - if you were a business and I worked for a city, and I were to allow you to create a billboard advertisement for your store, and then I found out that your store was actually selling illegal drugs on the side, then I would remove your advertisement and no longer work with you.
So far, the reaction from our community of valued creators to the new var checks has been overwhelming positive. If you have concerns specifically about your own content, we urge you to consult with the moderation team to see how best to make sure your content and your store page can be made compliant with our policies.
Last edited:
WolfmanVR
Well-known member
Here's my 2 cents and questions.... (some of this may be re-hashing above points, but I want my points on the record as well)
- Point #2 - "2. I have permission to use all assets and dependencies that are part of my resource, including any content used in videos, screenshots or marketing in my resource description.".
Are you suggesting we reach out to each and every CC-BY creator and "receive permission"? Isn't that implied by it being CC-BY? If not, then what is the point of this because I'm assuming we shouldn't be including anything else? Or is that referring to including NC/PC content that we have received explicit approval from other creators to use those dependencies in our paid content? I think an exemption needs to be made for explicit approval. My largest scene has NC content that I have documented proof I was given permission to use it.
- Point #4 - "4. If my resource requires dependencies and I am hosting those dependencies through my pay site as separate downloads, I have received permission from the original creators to do so."
If I understand Creative Commons correctly, as long as you give credit where credit is due, we should be able to host anything we want without receiving permission from the original creator. That's part of the definition of CC-BY. From creativecommons.org, CC-BY is defined as:
"You are free to:
Share — copy and redistribute the material in any medium or format for any purpose, even commercially.
Adapt — remix, transform, and build upon the material for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms."
- #5 is far too restrictive - "5. The .var file I am attaching to this form is identical to the version offered on my pay site. If I modify or update my .var, I will update my resource on the Hub and attach the new file to the update form. I further understand that as per Hub policies, I can only add or update 3 paid resources per week."
That means if someone adds something to their Patreon site, and then adds it to the HUB, they are not free to do what they want on their own Patreon site anymore. If they need to update the VAR several times quickly because they keep catching mistakes, or they are changing colors of objects in their scene, or changing lighting effects, etc, they will be in violation of the "3 times per week" rule. If we want to change minor things about our VAR fifty times a week that have nothing to do with dependencies, we should be in our rights to do so. At the very least, that rule should be changed to state "identical dependencies". As-is, this rule is too stifling and anti-creative.
My understanding is...
1. Permission is given by the CC BY license. Not implied, but explicitly given in the license terms.
2. Yes I agree. In the case of CC BY content, you have permission to redistribute the content based on the license itself. "I have received permission from the original creator" includes receiving the permission through the license itself. That's why someone chooses CC BY in the first place - to give everyone the permissions defined in the license.
3. This was discussed above. I had the same concerns but as mentioned on this post by VaMDeV, "We do not expect every iteration of someone's WIP scene file, plugin, look or whatever to have to be uploaded to the hub for us to have a record of." However the exact details of the rule seem to be a work in progress.
FluffyBunny
New member
- Messages
- 20
- Reactions
- Points
- 3
Hi, I will soon be publishing both paid and free content.
Some of the dependencies are NC, but I have agreements with the authors. Could you tell please, how does the health check accommodate this sort of arrangement?
thanks!
Some of the dependencies are NC, but I have agreements with the authors. Could you tell please, how does the health check accommodate this sort of arrangement?
thanks!
FluffyBunny
New member
- Messages
- 20
- Reactions
- Points
- 3
And... I just answered my own question by doing a better job of reading things lol
What was the answer?
