Option to turn off nameplates in worlds
D
Dylan
Just thought it could be a idea that a SDK option to turn off nameplates. this could just be a area that it hides it so that people are not as visible in certain worlds
Log In
Fax
Merged in a post:
Option to HIDE nameplates for worlds
MetaRick
I think with the onset of all the VR film and media using VR Chat as a performance stage, it would be amazing for world builders to choose if they have nameplates shown or not.
Fax
Merged in a post:
Add a 'Force Nameplates Off' feature to the Player API
Kaj
An official/supported way to do this would be much better than the workarounds already implemented on some maps.
ʙɪɢ․
This would be an essential feature for game worlds
Sacchan
Since the update that changed nametags, this is even more needed because as they become huge in the distance, stealth tactics are no longer an option in any game world.
I'd like to be able to force nametags off using udon, that way you could have nametags enabled in a lobby area, but disabled during a match.
-Mino-
That's been an option from the start. In the newest update, you can press R on desktop, or hold the menu button in VR, and go to Options, Nameplates, Visibility, Nameplates Hidden.
Mimi
Half the game worlds I have played in Udon, I hear people say "haha I found you because I saw your name plate" so yeah, this needs to be a thing
owlboy
Just thinking out loud here:
Merlin
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.
owlboy
Merlin: That's a good point.
I imagine two options for world creators then:
Dynamic nameplate visibility control - Optional
- Users can reject it
- The world can dynamically change it as they wish, depending on the content
Dynamic nameplate visibility control - Mandatory
- Users are removed from the world by VRChat/the client when they reject the request (I'm not sure how I feel about playerApi.KickPlayer(player); yet.)
- The world is clearly labeled as "no nameplates" in the UI before you enter
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.
Merlin
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.
Kaj
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.
Merlin
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.
Adeon Writer
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.
4Bakers
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
Sure. Similar to audio zones. So if a player enters trigger just disable it. Should still be visible for players outside.
Demirramon
Hagbard Celine: This would be a really cool implementation
Aev
Instead of having it as a world option, I'd really love to see this as an option when you create a new instance. I'd also like it to fully disable nameplates for the instance, not just default to having them toggled off.
R
Ron
It's on our side for the moment and was really only used for some worlds last Halloween. Can't add it to the SDK right now but can think on it some more.
D
Dylan
Ron: sweet thanks for the reply
Load More
→