[1602] Some of default instance settings set by a world creator MUST be respected because of license/agreement issues | Voters

[1602] Some of default instance settings set by a world creator MUST be respected because of license/agreement issues

かいざー

There is an urgent need to fix the issue in the open beta where features disabled by the world owner (such as emojis, stickers, and the drone camera) can still be enabled when creating an instance (or possibly even afterwards).
If a feature is enabled by default but has been explicitly disabled by the world creator, there is always a reason behind it.
Actually, there are some worlds that cannot permit stickers to be placed due to the terms and agreements of the assets used or other reasons.
If we can override the world author's settings in such worlds, the world will be deleted because the agreement cannot be met.
While it is good to have a system that allows disabling certain features, enabling features that have been deliberately disabled disregards the creator’s intent. This could lead to a significant loss of trust within the creator community.

March 17, 2025

xCirrex

Drones are cool, but also opens up a lot of "cheating" in worlds where you are supposed to explore to find hidden stuff. Let me disable it permanently as the world author. The flying mode camera has the same issue, but at least that is limited by a range (would be cool to let us set that range).

naqtn

Cause the dev team doesn't do anything on this post, I'll link to the Developer Update saying the current status. https://ask.vrchat.com/t/developer-update-march-27-2025/42391#p-77872-instance-settings-feedback-13

よぜ［4oZEF］

There is already a “tool to make worlds sticker-incompatible,” so those who have Unity projects at hand can prevent the application of silly stickers.
However, when you can take this kind of countermeasure, I can't help but wonder, “Why did you force an update that disregarded the wishes of the world author/creator in the first place?”
Even if a tool can be used to take countermeasures, it is still necessary to re-upload the file, and as a result, world authors are forced to take measures that they did not need to take before, and while the burden on creators increases needlessly, the user experience remains unchanged. In other words, “in a bad way,” nothing has changed.
There was a world modeled after an actual museum, but it was changed from Public to Private in relation to this change.

るいざ・しゃーろっと

I completely agree with かいざー’s opinion.
In particular, features like emojis, stickers, and the drone camera can become problematic in realistic, life-like worlds, worlds created by companies, or performance-oriented worlds.
I am genuinely concerned that if the creators of such worlds choose not to upload their creations to VRChat, the platform as a whole will become less interesting.
Here is my proposed solution:
Please leave room for world creators to opt out of features like drones and stickers via the web interface.
By default, users would be able to toggle these features on or off, but if the world creator or another rights holder does not wish them to be enabled, there should be an option to explicitly opt out.
Personally, I believe only a small number of world creators would actually choose to opt out.
In worlds that are not explicitly set to reject these features, it would be best to allow users to enable them in private instances, just like in the current open beta.
By doing this, I believe we can alleviate the concerns of world creators while still expanding the range of actions available to users.

Lhun

I agree with you Kaiza. Even in a non-commercial setting, World features like Drones, stickers and other things can spoil a world's flow or allow for cheating in adventures or puzzles. 
World creators should be able to forbid certain features, perhaps a middle ground would be the ability to petition the creator or VRChat to evaluate why the setting was disabled if there's no logical reason to do so, but I agree that if a world creator disables a feature like portals or stickers or the drone there is probably a pretty good reason.
I'm also in agreement for user freedom to a point, so in that case I'm a little on the fence. 
It was mentioned below that a talented avatar author could override it anyway but the vast vast majority of users are not able to achieve such a feat. 
That being said, VRC+ features are paid features that users expect to be able to use, most of the time. Giving the option to disable them on group instances and whatnot is actually cool of VRChat to do, as it allows unique experiences or curated events that don't want the distraction of more visible user created content and features for things like live performances. 
This is a nuanced topic.

°sky

while i agree creators should be able to set the defaults for an instance, they shouldnt be able to force things off.
also i am unaware of any legally binding licenses which require stickers to be disabled, as this could immediately be overridden by an avatar sticker system instead. 
i doubt this would even be enforceable?

Тayou

I disagree with this entirely. 
I am not sure how any of the instance settings have to do with licensing, and I think if a instance is private the instance owner should be able to play the game the way they want to. 
If the world has network features I suppose enabling some of these things against the world creators will could break  some leaderboards or something along those lines, but that could easily be fixed by exposing the settings to udon, so the world creator can just block score submission.
As it stands world creators already have more power than they should, being able to disable avatar scaling, and the non-persistence of the force camera near distance setting. 
If someone could explain the "license/agreement" part to me maybe I can make more sense of this....

Lhun

Тayou I represent some communication at Virtual Market, and in short there are licenses with commercial companies. These companies sponsor and pay for the event. 
Being able to use a sticker to cover up important information or things like that that change the experience in a negative or defamatory way going viral can be a problem. 
Sanrio and others require avatars (mochipoly) for that reason and we've had events that are similar. Unfortunately, I agree with this canny. World creators must be able to create the intended experience, commercial or not.

Тayou

Lhun the override is currently only possible in private instances. those instances are not publicly discoverable and are ran by small friends groups. 
If we were to imagine this scenario in real life;
Lets say for example McDonalds opens a new store and wants their logo and values presented there.
Now I build a replica in my backyard and invite my friends to play there, doing things that McDonalds would never allow.
McDonalds shouldn't and wouldn't care. Its private and closed off to the public. Sure someone could take a picture of something inappropriate there then, but thats not exclusive to any of the vrchat features discussed here. People can already do that with avatars. Would you want avatars to also be restricted in those worlds? Only allow a select whitelist of avatars?
I get your point... for public worlds. But not for private ones.

Тayou

A better analogy is actually, that your world upload is a blueprint, and anyone can build the blueprint, if they build the blueprint publically you get to enforce some rules.

If the blueprint is built in private you don't get to see the result, and therefore shouldn't have the power to enforce any rules on it.

Lhun

Тayou Japan's law differs significantly, however. I'm not a lawyer, but it's my understand that while that might work in the USA, it doesn't work there, which is why people from Japan are the ones concerned. Japan's defamation laws prevent things like "unauthorized modification" that can cover things. I think they're being cautious.

Lhun

Тayou That being said I guess if this can only be overriden in private instances it's not a big deal but in public ones it's a problem, one great example is someone overriding a QR code with a sticker that leads to a malicious website.

miraichan_

Lhun Your contexts are clear, really thank you.
(Sorry if I missed something) However in fact, people can override the settings of the world creator except for Public instance
.
And I don't think a lot of persons who agree with this would take pictures in Public instances to upload to X. because just for comfort or to avoid risk.
Personally, it would have been nice if people could at least override Invite and Invite+ only. (or, non JP server?)

Susinopo

I think it’s nice to world creator can set between Forced OFF / Default OFF / Default ON for these settings. Current state is pretty bald.

jumius（ゆみうす）

I agree with this proposal, as I believe it is more friendly to world creators.
However, I have some doubts about the argument that allowing stickers raises licensing issues. This is because everything that can be done with stickers could already be achieved using avatar gimmicks, such as world-fixed gimmicks.
Stickers simply make something that was already possible with avatars easier to do. If stickers are considered a licensing issue, then allowing users to freely choose and use their avatars should have already been a problem from the beginning.

moonorama

I think that this would work well for IP protected worlds that would like to have an established brand image in vrc without too much chaos happening, but I think it would also impact 99.9% of other worlds uploaded in a negative way. Say for example, the creator of Grapple Island were to disable drones, period, across all instances. Not even in private ones. No one can possibly have fun the way they want to with the drone. And it harms nobody by doing it in a restricted instance. For non-ip worlds, I cannot support this canny.
1st edit: Maybe I got something wrong lost in context. If needed, you can explain in comments.
2nd edit: Another idea. Maybe world creators could have some sort of a way to toggle the ability for the world limitations to be completely changed for other instance types. So IP protected worlds could toggle the setting off, so all instances must abide by the same type of instance "base settings". On the other hand, another creator could leave the settings on so that they can allow people to change the base settings in other instances? Just a way to protect both sides.

→