owlboy: That works as long as the world has the ability to kick or deny people the ability to participate if they deny it the permission to hide nameplates.

Hiding nameplates isn't just for spooky worlds, it's also needed for games where players need to be able to hide for various reasons, including hiding behind cover. It'd be pretty silly to be playing a Battlefield game and see a giant glowing nameplate of someone on the enemy team sticking out of a bush at night time. You'd immediately shoot at that bush until the nameplate disappears. So there's not much of a point in having cover. Not allowing the world to hide nameplates puts players at an advantage and players have no way of knowing if everyone is following an honor system and hiding nameplates. So it's not fair to players of the game to allow players to deny the world permission to hide nameplates without the world being capable of taking appropriate action.

Merlin: That's a good point.

I imagine two options for world creators then:

Too much important UI is currently only on nameplates. So a lot would have to be done to make sure that is all easily accessible in the new UI. And I trust this will be the case.

Side tangent: Do you also assume then that worlds requiring nameplates to be off would not allow custom avatars? They would constantly force you into an avatar of their choosing during gameplay? Maybe this should be clearly labeled in the UI/metadata for the world too? "No custom avatars"

Extra super off-topic tangent: I really wish Canny would get their act together and support Markdown.

owlboy: There are situations where allowing the world to dynamically change it while also being able to guarantee it has the ability to hide nameplates could be useful. Allowing dynamic changes would open up the possibility for players in the world to vote to allow nameplates if the world wants to add voting over that. Or you may want to allow nameplates in the lobby but not in the game. Or you may want to allow nameplates when people are spectating. So for the optional worlds it'd still be good to allow the world to know what permissions it has from the user similar to Android app development.

The main thing that's only visible in nameplates is what features players are using on their avatars, and which of those features you are filtering with the safety system. It would be good to have that info elsewhere.

For avatar enforcement I'd hope for more fine-grained control over different aspects that may affect gameplay. There's a canny for being able to detect whenever someone switches avatar so that worlds could calibrate systems per avatar, or swap the player back to some specific avatar: https://vrchat.canny.io/vrchat-udon-closed-alpha-feedback/p/add-onavatarchanged-event

But it could also be good to add the ability to lock avatar switching so people could use their custom avatar, but could only switch avatars in lobby. Another thing that may be useful could be enforcing an avatar height requirement. Saying that all avatars must fall in the configurable range of 5ft to 6ft and re-scaling the avatar to fit that requirement or allowing worlds to detect the avatar height and switch players who don't fall in that range. There's a lot of things that could be exposed for world authors to use if they think it's necessary, they should all be separately configurable, and they should all be able to change while in the world, but those need different canny posts.

Yeah canny needs to support markdown.

Merlin: To add on to this discussion: there are a lot of features needed for game worlds that make VRChat not behave like VRChat. Hiding nameplates is just one of them. Forcing/unforcing temporary avatars, showing placeholder avatars for blocked people, and restricting avatars based on criteria are only a few. How many of these things get added to Udon is ultimately up to the dev team and what 'permanent solutions' they decide upon. As TCL stated before, they'd rather make their own temporary avatar sub-API than simply give us access to avatar ID data and avatar changed events so we can implement whatever we want ourselves.

Kaj: Yeah there are a ton of things that are needed for game worlds to be viable. VRC should implement API's that are specifically for stuff like locking people to specific sets of avatars and the like, but there's still reason to implement more general things like avatar switching callbacks as noted in the canny for the OnAvatarChanged event. You might want to just recalibrate something when a person changes their avatar and if they only provide specialized API's without more generic things, they prevent the more general cases not covered by "I want to lock people to a specific subset of avatars."

VRC shouldn't just leave people with an OnAvatarChanged event to implement locking to a specific avatar themselves. But yeah they also shouldn't say "but we have an avatar API that allows you to lock people to certain avatars, so you don't need an OnAvatarChanged event" because it prevents other important functionality which depends on that generic event such as recalibration. Or, if you want to make the world interact with a specific avatar in a specific way, you would want the ID to check against, but at the same time you wouldn't want to lock people to only using that avatar.

There are valid places for both the generic and specific API's. Leaving out either side in favor of another that has limited functionality just means people are going to be doing hacks that are likely to break when the API falls short as has happened so many times in the past. You'd think they would understand that by now.

owlboy: I'd say a icon on the world icon before joining works, there's already one showing that it can mute you / listen to you.

owlboy: Alternative solution: Slip a mention of this into the ToU and only allow a 'disable nameplate override' if the world allows World Debugging and you have it enabled

Hagbard Celine: This would be a really cool implementation