Developer Update - March 27 2025

Official Dev Updates
23

I think the situation could be remedied a bit with some changes to the items themselves. Note that I do not consider this a proper solution and am firmly on the side of world creators having the final say, but I’d still like to propose a compromise.

  • Stickers: make it easier/clearer to mark in the SDK which surfaces can/can’t be stickered.
  • Emoji: generally not a ton of a problem but being able to set zones where these don’t work could be nice.
  • Prints: Mandatory (or at least default) 90-second despawn for Prints like with Pedestals. Also an instance option for prints/pedestals/etc to force a 90 second despawn rather than just on/off. Some people don’t hate Prints, just that they linger for too long and make a huge mess.
  • Drones: Fix the collision issues with driving/swimming systems. Making it so the drone only collides with static non-moving colliders would be a good start.

If these got fixed, there’d be less demand for worlds being able to block them.

1 Like
24

Strong agree; for instance (my brain wheels are turning after seeing the first part) a world themed after a furry convention could have a “fursuit headless lounge” room but mark out the “fursuit headless” and write “portal”* in what looks like red marker; and then (by default) only allow portals to be placed over there… that restriction would add a bit of a thematic flavor while also keeping undesired sights (in this case portals) out of the main dance area.

*disregard that “portal” has a dual meaning in the context of IRL fur cons connected to VR in particular; obviously for this reason the language used by such a world would have to be tweaked from this suggestion

2 Likes
25

Who came up with the idea for the “Instance Settings”? Do you guys not actually play VRC yourselves? :roll_eyes: How does something like this even make it all the way to rollout?

Didn’t a single UX designer take a look at it?
I could sketch out a better solution in Paint in 30 seconds. :shushing_face:

2025_03_27_23_53_23_VRChat
2025_03_27_23_53_23_VRChat593×640 56.3 KB

Please just save the settings of the last created instance for the user, so they only need to change them if they actually want something different next time.

And if you really want to be good to us, give us the option to create 18+ instances right there in that menu as well. :sweat_smile::grin:

4 Likes
26

I’m genuinely baffled this update made it to Live. Definitely needed more time in the oven.

4 Likes
27

I don’t think it’s a bad update by any means. I just think the instance settings thing seems to have resulted from solving two problems separately, instead of as one whole solution.

Edit: I guess to provide some context:

World creators can set max or min avatar height to help prevent users from breaking their world, or even disable it completely. They can set recommended max, full max, all factors that change how people interact with a world. Plus like I said earlier, special surfaces to restrict stickers to.

To me, there isn’t a whole lot of difference between Public, GroupPublic, Group+, and Friends+.

So, if the world creator can change these settings but they only apply to public instances, why even allow world creators to change it at all if it’s just going to be overridden?

And then if world creators don’t want people using stickers in their world, they’d have to use that special surface and place it somewhere people can’t access. Even the drone can be enabled (iirc) (which could be abused for game worlds).

So my thoughts are: if the instance creators can override the defaults to enable them (which is most instance types on VRChat to my knowledge), then it doesn’t make sense for the world creator to be able to adjust that at all.

I do think instance owners should be able to disable them if they are enabled by default. But not the other way around.

And really, if these options are enabled by default (which they currently are), it shouldn’t be a big deal.

For example: I have a movie watching world. It is really clean and has surround sound, and it’s whole purpose is to watch movies. Because of the lighting, you can’t even see stickers that well, if at all.

I am considering disabling some of these features so movies or any media enjoyment aren’t interrupted, since those features aren’t really necessary in this world. Sure, anyone can access the world, but the wotld also serves a specific purpose. If people don’t like that my world disables those features, they can absolutely just not use my world.

Edit: I also guess to directly answer the question, “who has authority over an instance, and when?”

The world creator defines the entire experience of the world in the first place. Worlds (especially game worlds) inherently control instance behavior through their mechanics or systems. To me, I see these toggle-able features as an extension of that.

6 Likes
28

I think it would be the best to let world author decides, where each option can be “enable by default”, “disable by default”, “enforced enable” and “enforced disable”. The first 2 means can be toggled by instanced owners, and the later 2 are the final say by world authors.

8 Likes
29

My main request - when a world author enforces restrictions on platform features (avatar scaling, stickers, portals, etc), require disclosing those in a new “limited features” section, like third-party DRM notices on Steam. That’d make it much easier to avoid the frustration of moving folks around only to be disappointed and/or stuck (as in Xipher’s case with disabled portals).

Asides from that, personally, I am strongly in favor of letting the decision for instance behaviors (including avatar scaling, portal placement, etc) reside with those moderating the instance.

Public instances? That’s the world author (because nobody else is really there to moderate).

Private instances (Invite+, Friend+, Group+)? There’s someone else involved in moderation and making sure folks play nicely together.

Sometimes the brokenness of being the “wrong” size or whatever is the whole point, such as “Mini Mini Golf” where everyone in a group agrees to be too small to easily use the putter.

A compromise might be providing a way for the world author to detect when overrides have been applied. Then, if there’s some high score system or the author gets bug reports, it’d be easier to tell if it’s from someone overriding what they intended.

4 Likes
30

When are you planning to add tags to instances and add instance search capabilities?

This is much more convenient for gathering people with similar interests.

Today’s groups are difficult to manage and introduce more problems, resulting in a lack of use of group instances. At the same time, group management authority and human energy are limited, resulting in poor use of group instances and difficulty in searching for similar instances.

31

I agree a disclaimer stating why something is disabled is essential “e.g. Drones are disabled because they break the driving system this world uses”. It’s not just the creator being petty, there’s a reason for it.

Firm but fair. Overrides could also be printed into debug logs and an in-world disclaimer could be added at spawn stating that overrides have been applied, this isn’t the way the world’s intended to be experienced, this and this could break cause of that, support won’t be provided if overrides are applied, proceed at your own risk, etc. I’d much prefer if it were something detectable via Udon so creators could potentially adapt their games around the overrides (e.g. well if you’re all gonna be different sizes in Laserdome, let’s spawn an equal-size target panel in front of all of you to keep things fair).

1 Like
32

Honestly I think the approach of having default settings which can be turned off by instance creators is the best approach. This means for public instances they are enforced, but for private/group instances people are able to customize the experience by preference.

2 Likes
33

The reduction in voice latency is HUGE. I want to know more on what was causing the latency, what they did to optimize. A whole half second reduction is a huge huge improvement to the “chat” part of vrchat. The latency of the internet to my friends half way around the world had enough latency as is, so optimizing the software/game to reduce the latency as much as possible is really good!

2 Likes
34

I want to say that on/off options on the website or SDK is one way to set restrictions in the world. Technically, it’s the same as using layers, colliders, or coding Udon to control the features (Dorones, Prints, etc).

If we agree that programmed restrictions (by layers, colliders, or codes) are acceptable to keep a good experience (for example, having a drone racing game as the author designed, even in private instances), then logically, the on/off settings should not be overridden by instance owners too, because the override might break things like the game mechanics.

Some might say: “More features, more fun. Let us use everything, even if it breaks stuff.” Okay, that’s a possible choice. But those restrictions are the world’s mechanics. You came to experience it as intended, right? Visiting a world is opt-in. You pick it; you get its rules. Don’t like it? Go to another world. There’s no need to force freedom here.

VRChat changed this now, instance owners can turn on features creators turned off. This breaks the world’s design, like smashing things the creator worked hard to build. It’s not just about mechanics; it’s disrespect to their effort. That drains their will to keep creating. And if creators quit creating, we all lose, players included.

21 Likes
35

I argued in my post (Developer Update - March 27 2025 - #34 by naqtn) that these on/off settings are part of the world’s mechanics, like colliders or Udon code, not rules to control people. To me, letting instance owners override them, even in private instances, risks breaking the creator’s design.

You see this as “a rule of behavior for players,” like it’s about bossing them around. I see it as protecting how the world’s built, it’s not about behavior, it’s about the system working as intended. Overrides don’t just tweak fun; they can ruin what the creator made. It’s not telling players how to act; it’s keeping the world from falling apart.

Before this change, creators used these settings to shape their vision. You might think that was a flaw VRChat needed to fix. Objectors like me see it as an important tool for creation. If overrides keep breaking that, doesn’t it make building good worlds harder?

6 Likes
36

lovely it’s nice design VRC+ :+1:

37

I think the current confusion comes from the dev mixing three concepts in the instance settings design. Here’s how I see it:

  • #1: Control as World Mechanics
    • Built into the world via layers, colliders, Udon code, etc. (fine-tuned, runtime-specific control)
    • Checkboxes on the website/SDK (simple on/off, easy to set up)
  • #2: Control as Instance Moderation
    • Toggling features (e.g., drones) off for moderation
    • On-the-fly switching added in the last update
  • #3: Players’ Wish to Use Features Freely
    • Requests to flip features off=>on for fun
    • Expectation to always use them (“Why tie us to the world author?”)

This update forced #2 (moderation) into focus, especially for drones. They can annoy players if misused, so instance owners need an off switch, even if creators enabled them. Fair enough.

Before, we had just #1 in the settings: a binary setup (on or off) as world mechanics. Adding #2 should’ve meant three states: “on as mechanics,” “off as mechanics,” “off for moderation.” Instead, the dev stuck with two values (on/off) and didn’t redesign the system. Then the instance creation UI (those checkboxes) blended in #3: “on” now also means “players want it on.” That’s where the lines blurred.

Now, “off for mechanics” and “off for moderation” aren’t distinct. The “instance settings” screen feels like a mashup — we can’t tell what it’s controlling anymore. Creators lose clarity on how their worlds will work, and players argue over freedom vs. rules. That’s the root of this mess.

5 Likes
38

Redesign Instance Settings for Moderation Only

The “instance settings” screen is mixing too many things – world mechanics, moderation, player wishes – as I wrote. Adding more like avatar scaling or avatar rank gate turns it into a pile of random requests with no clear goal. Users want tweaks for calm art one day, loud games the next – everyone pulls different ways. Software with no strong design breaks fast and shortens product life. We need to fix this weak point.

Make It Moderation Tool Only

I suggest redesign this screen just for moderation. It’s what we needed – like turning off drones when they disrupt, not changing world mechanics or creator plans, no player wants. Only moderation tools. Here’s how:

What Moderation Tool Should Do

Features It Controls:

The tool’s control must meet all these conditions:

  • Needed for all players’ comfort (moderator’s call, not personal).
  • Can’t be managed by existing tools like Shields or Blocks (why add it if they’re enough?).
  • Can apply to all worlds (Udon handles specific ones).
  • Has common use cases (like muting Stickers in calm rooms).

How It Works:

  • On=>off toggle for control (and back to on after) – this handles most moderation needs.
  • Off=>on toggle? I don’t see a case where moderation needs to turn features on against creator settings. (If you have one, tell me – does it justify overrides?)
  • No overrides on creator mechanics without a good reason to allow them – as I said, breaking worlds hurts more than it helps.

Why This Is Needed

Now, this screen is unclear – checkboxes might set mechanics, might moderate, might just please players. Creators can’t trust their worlds stay right, and moderators don’t know what they control. More random ideas make it harder to keep VRChat strong. Redesign for moderation, or confusion grows bigger.

7 Likes
39

As last time, noting that while I don’t have anything of substance to add, all the feedback here is passed on to the team!

While it doesn’t necessarily address every point here, I think there might be a minor change coming to the Instance Creation flow to make the process less cumbersome. Unsure if that’ll make it in this next release, though. We’ll see!

1 Like
40

More Thoughts on Instance Settings Design

“Who Has Authority Over an Instance, and When?”

Some say instance owners or world creators should have final say. I think this question misses the point. Even before the last update, Accessibility options let users tweak Bloom Intensity or Color Filters, overriding creator visuals. That’s not “players beat creators” – it’s Accessibility having higher priority. We should focus on function priority, not who’s boss.

The Label on the Screen

The label “instance settings” on the screen is strange because “region” and “instance type” on the previous screen are also “instance settings,” right? This overlap makes me wonder if the dev team knows what this screen should be. It’s not just unclear – it’s a bit of a tangle, isn’t it?

They Are VRC+ Features

Someone might say, “They’re VRC+ features – that’s what this screen is.” But that’s not a real criterion. Yes, all current items – drones, stickers – are VRC+, but that’s just how it is now, not a rule. Renaming it “VRC+ features” might skip the real problem instead of fixing it. We need a clear purpose, not a label trick.

User-Addable Elements

One definition could work: “Items users add to the instance via the client, not avatars.” Current items on the screen – Emojis, Stickers, Sharing Pedestals, Prints, Drones – fit this; users add them, and they need moderation, like I said.

What about User Portals? Some want them added too. They could fit this way – no overrides, of course. (Technical note: Portals are set in the scene descriptor, not the website. That’s inconsistent – migrating it would be hard with old assets, but not impossible.) More user-addable elements will come, and this keeps moderation talks simple and general.

41

This topic was automatically closed after 14 days. New replies are no longer allowed.