Allow world creators to disable avatar collider flight and block avatar-spawned colliders
Godfall
World creators currently have no way to prevent avatars from using collider-based flight (GoGo Loco, OpenFlight, etc.).
The problem:
Avatars can fly anywhere using collider exploits, bypassing intended world boundaries and progression. This also allows anyone to cheat in PVE/PVP games.
World creators have zero Udon or SDK-level control to detect or prevent either of these
Proposed solution:
Add a World Descriptor toggle or Udon node to disable avatar collider-based flight (strip or ignore avatar colliders that interact with the player capsule)
Add an option to block avatars from introducing new physics colliders at all.
Expose these as per-world settings so social/hangout worlds can leave them enabled while game worlds can lock them down.
This would be similar to how world creators can already disable avatar scaling — just extending that same philosophy to avatar physics exploits.
Log In
Uzer Tekton
World authors can already decide where you can go or not go, how fast you can walk or not walk, and how tall your avatar can be or cannot be. World authors can also give you a proper flight mechanic if they choose to.
Avatar flying with collider is not a feature, it is an uncontrolled bug VRChat took too long to fix. And they should have done it 200 years ago.
Edit:
"collider-based flying is considered a bug and will eventually be fixed" this bug was recognised as early as 2019 so why is it still not fixed in 2026?
And why is this bug now suddenly being legitimized as an optional toggle with a "world tag" that VRChat is experimenting with the FISH world? What is even worse, is that the "flying feature" would be enabled by default (by not having a tag), why?
Corbí
Uzer Tekton 7 years of bug, a bug exploited by the most famous asset for avatars, used by a lot of them... So famous that it's a core mechanic of some avatars like birds, drones, etc... Fixed in a week because some map asked for it.
RanmaKei
Uzer Tekton I understand the argument that collider-based flight started as a bug. At the same time, after many years it has effectively become part of the avatar ecosystem. Many avatars and communities have built systems around it, especially flying species like birds, drones, and similar avatars.
In a platform where avatars can introduce their own colliders, locomotion systems, and physics interactions, emergent movement behaviors like avatar flight are a natural outcome of the system’s openness rather than an isolated exploit.
Because of that, removing it outright would impact many existing avatar systems and established user behavior. Whether it ultimately remains or is replaced by something more official, the platform still needs ways to handle how avatar capabilities interact with gameplay worlds.
My main point is that worlds should have stronger contextual tools to manage those interactions rather than relying primarily on broad capability disables. Competitive worlds absolutely need ways to protect progression and prevent bypassing mechanics, but systems like spectator modes, progression gating while certain avatar states are active, or gameplay zones that react to those states can solve those problems without removing avatar capabilities entirely.
So, the goal isn’t forcing gameplay worlds to allow flight everywhere; it’s making sure the platform supports both expressive avatars and gameplay-focused worlds through better interaction systems between them.
RanmaKei
This feels like an architecture issue more than a feature issue. Global toggles that disable avatar mechanics encourage creators to block capabilities instead of designing gameplay systems that interact with them. Over time that shifts the ecosystem toward restriction rather than creative integration.
A better approach might be handling this at the instance/host level rather than the map level. Instance hosts are already responsible for moderation and session management, so giving them the ability to enable or disable mechanics like flight for their instance; potentially limited to group roles; would provide flexibility without encouraging worlds to broadly disable avatar capabilities.
For game worlds, another approach could be implementing a spectator system that either allows users to manually enter spectator mode or automatically detects flight on a per-user basis and temporarily shifts those users into spectator mode (disabling gameplay progression while flight is active, or for a short duration afterward). This keeps progression and scoring unified for active players while still allowing spectators to observe and socialize.
In worlds like Fish!, many visitors spectate rather than actively play. They are there primarily to socialize and talk while watching others. Supporting this behavior without restricting avatar capabilities helps maintain the social nature of the platform.
For these reasons, expanding tooling for world creators would help support both avatar expression and gameplay integrity. Better tools would allow creators to accommodate diverse avatars while still enabling innovative gameplay systems.
SpaceShark12385
This right here is a fabulous compromise
RanmaKei
SpaceShark12385 Added a Feature Request suggestion "Improve World Creator Tools for Handling Avatar Flight and Mechanics" to address solutions that solve the concerns world creators have while supporting avatar systems. Please take a look and upvote if you think its a good idea.
Alianna
RanmaKei Beautifully said, I agree instance owners should control these settings not world creators.
PLAYERS CREATIVITY should always take priority.
The content of the world is secondary, it's an experience and players should have the choice to choose how they want to experience it.
In the case of the Fish world players flying provides limited or no advantage over others. Additionally, there are plenty of free avatars with flight systems players who would like to fly can use, so nobody is actually left out.
Lasty, most older players are completely aware of flight systems, I guarantee Godfall knew about these before the release and durning the design of their world. With that said they should have designed the game around the use of the flight systems.
SilphScope
RanmaKei While this would be difficult to implement, I'd be all for it. Only game worlds that have a clear and direct need for anti fight should be allowed it as a world level toggle, and as some have said, there are still workarounds for them already. Reducing flying exploitation for some groups by making it moderation focused could even help large groups moderate large worlds much more efficiently, too, by allowing moderation to move more quickly than others.
Truthfully, the Fish! world anti-fly was a clear abuse of VRChat feature implementation. It wasn't needed nor handled well and it pushed me away from the world in its entirety despite not using flying almost at all. It doesn't affect progression as much as the dev of the world claimed (late game is just sitting in one spot and spam casting a rod, with no time to fly) and only served to forcefully disable parts of my avatar against my will.
I will boycott any world which implements the feature as the Fish! world did, unless it is similar to the way you have described. Any feature which changes an expected function should be handled with care. Of this becomes the way it's implemented, I will happily embrace it with open arms.
SilphScope
Unintended or not, I fear for world creators having
any
control over user-uploaded avatar assets. What's next? Disabling avatar lights on a system level? Sounds? Meshes? I'd rather risk people cheating with these "exploits" than begin to travel down this slippery slope. World creators should be able to protect their product any way within the world itself, but should not get any control in disabling avatar assets. If it's part of a fully default avatar (i.e.: scaling, microphone, movement, etc), that is fine. Anything outside of that scope should be the player's decision outside of specific and targeted VRChat moderation ONLY.
Player's rights matter too. Arguably more than world creator's rights, as we pay both VRChat's and world creators through our patronage.
KonKin
SilphScope Disabling avatar lights would be good too for game worlds that want you to be in the dark, this can already be done via forcing a shader unto the player by the way, but it would be good in these instances (game worlds) to avoid having to bloat out performance for anti cheat measures, chill worlds however shouldn't be using this as the experience there is to socialize and chill out and there should not be stuff like "Paid flying", as game world creators we just want platform provided toggles/measures to give us control on how we want our games to be played and to protect the integrity of our games for our users who constantly voice people with avatar gimmicks ruining their experience who will just jump on an alt account the moment VRC bans one of them.
World creators have the same rights as avatar creators, we are all players and we make our own things, we should be able to decide what can be done within our User generated content as much as people who make avatars, saying world creators have less rights is downright dehumanizing and just puts it out there how much some people really care about the users who make the experiences they go into, it's stuff like this that drives creators away from making fun stuff once they learn how little some users care.
I am all for world creators to have more security options to personalize and safeguard their intended experience for their users, that being said being a patreon does not entitle you to step on said creative decisions and is a very toxic mentality as patreon should always be "hey I like this person's work, I want to support them!" and not "Hey I support you, do my bidding or else".
For game worlds the reason we want this is to avoid false negatives from using custom systems, that we already know happen a lot.
SilphScope
KonKin Within very limited bounds, yes, world and avatar creators have the same rights. It's just not something that can be easily defined with a simple toggle. When in doubt, it is often easier and safer to protect player rights as there are often just too many variables to consider to leave in the hands of a world creator.
Avatar light? Maybe it's due to headset settings making the world appear darker than intended.
Avatar flight? maybe it's to moderate an instance. Maybe it's to fix a bug around movement
Unless an experience is heavily built upon its use in competitive environment (i.e. much more than just a leaderboard) and considers these issues in a thought out way, then I'm sorry, intended experience MUST give way to player decisions and comfort. Anything else risks a slippery slope that I do not think should be tested.
KonKin
SilphScope "Within very limited bounds, yes, world and avatar creators have the same rights. It's just not something that can be easily defined with a simple toggle. When in doubt, it is often easier and safer to protect player rights as there are often just too many variables to consider to leave in the hands of a world creator."
A: Creators are players too and they should be protected as well within their creations, being a world creator does not make your creation completely malleable by another, it's like building something in an exhibition for example and someone comes in and goes "ugh I don't like that I can't destroy your creation, the staff should make it so I can go and ruin it because not being able to infringes upon my rights as a person"
If you do not like a world you don't have to go to it, nobody is having you at gunpoint to visit one and there's always other plenty experiences if one isn't for you.
"Avatar light? Maybe it's due to headset settings making the world appear darker than intended."
A: You can adjust your own headset light setting to properly show things that aren't normally visible in the dark, that's a product related thing, I'm talking about lights that give you unfair advantages in game worlds and brightens up the entire world because of a massive global light or a light an enemy in the world can't detect for example, I've gotten multiple reports in our world about users who just straight up use giant lights to diminish the experience, so to combat that a toggle would be awesome so we don't have to mess with possibly unoptimized shader methods.
"Avatar flight? maybe it's to moderate an instance. Maybe it's to fix a bug around movement"
A: Moderation of chill worlds like furry hideout and such I completely understand and I don't think they would disable it as such so nothing would change there, out of my years of working as a game dev I have never encountered a need to utilize flying tools to fix a movement related issue, in fact, utilizing said stuff like gogoloco fight can actually mess with checking for movement collision results or cause false positives in it (one of these being changing the value of JHeight and the flight of GoGo causing it to fully ignore the issue thus resulting in no bug fix of the system).
KonKin
SilphScope"Unless an experience is heavily built upon its use in competitive environment (i.e. much more than just a leaderboard) and considers these issues in a thought out way, then I'm sorry"
A: creators have been asking for ways in competitive games to turn off said features, a game world can be competitive without a leaderboard and trying to compare it to something like an esport (if that's what you implied on the vagueness of your example) for it to be considered one is a bit ridiculous, tone deaf and out of touch from what the gaming community side of VRC has been talking about in multiplayer games with scores and such,
"Intended experience MUST give way to player decisions and comfort"
A: This is a very vague statement on what "player decisions" and "comfort" means because it opens up a hand for malicious client users to use that as an excuse to trample on the experience of other players.
"Anything else risks a slippery slope that I do not think should be tested."
A: Change will always come, we have tested that over and over on VRC with the inclusion of protective systems that have made it harder throughout the years and in turn has increased the overall player base as much as people like to post "VRC died long ago!" it's still growing and it's kept afloat by those very same world creators / organizers / group leaders and staff who provide a sea of playable content for this platform, so yes it should be tested, staying in your comfort zone leads to stagnation.
SilphScope
KonKin it is vague on purpose. Competitive nature can be seen by many lenses, through heavy use of scripting and rules to enforce a very specific and linear gameplay loop, levels, unlocks, pvp elements, etc. I'm not going to go down a list which ones do or don't need these levers, only that they should exist in a fashion where no other option exists and the experience is measurably damaged without these controls.
Player comfort and decisions are also vague. You're talking about removing something from someone's avatar while within a world... If you don't see that as a BIG red flag, then I'm sorry, we will never see eye to eye.
For the record, I don't agree with intentionally circumventing game mechanics. I also don't agree with circumventing avatar assets... The policing of an experience should be left to the users, by the users. I do not respect world creators who refuse to respect that the users and their creations are at an equal level of importance, and overreach of too many levers of a world creator is a concern.
These toggles at best should be granted on a case by case basis very sparingly to worlds that actually need it, or just not exist altogether. If it is a checkbox that world creators can just click, then I know we will see some very bad changes where world creators do so without reason to do so, likely then charging for a solution. This outcome could hurt players options for worlds very badly if left unchecked.
KonKin
SilphScope I can see how you'd think that's a red flag, however that can already be done internally via Udon, you'd just be giving the creator of said world the ability to NOT bloat their world with anti gimmick behavior and again I'm fully against creators attempting to lock stuff like flying or seats behind paid walls and I'll never be okay with that, however I do want better security for world content creators and having the ability to say what can and can't be done in the world we create with the ease of these tags that are toggleable.
Worlds can already do all of this without the tags via udon, there's already prefabs that completely kill avatar flight and seats to a great degree, so what exactly are we losing here? in fact we already know how to completely disable OVR lunges/movement and everything has been going fine, so what's the actual harm here?
SilphScope
KonKin The harm is this sets a dangerous precedent for worlds going forward, at least without a TOS change enforcing very strict usage limitations, or refusing to give the power to world creators themselves in order to make it a case-by case as needed change. Being forced to reach out and explain the necessity would heavily restrict which world creators seek it.
And I am aware there are ways to do it already, but the udon implementations are purposeful design. A limitation to implementation, as previously stated, prevents abuse. I have concern that making it open and easy to use could incentivize bad actors.
Instances already have a lot of levers to self enforce any sort of policing. This has worked for close to a decade, it should continue to work going forward, nothing changed to make this necessary. One way to make this tag system less abusable would be to allow it to be overridable by any moderator of the instance in question. This keeps the sanctity of public worlds in place, but allows more private instances to exist as they always have if they so choose.
As currently implemented, I do not think this is a good idea and will take my business elsewhere every time. If finding worlds becomes in any way more difficult, I will pull my funding, assets, and subscriptions out of VRChat completely and leave for a competing platform, or none at all. In my mind, world authors should only have power so much as to put systems in place to protect their premium systems, and public instances (persistence data carrying over DOES count to this, but only if it is noticeably unfair). Anything else should fall on the players to self police.
KonKin
SilphScope it will become more common as prefabs are made to give creators more ease to regulate the content allowed in their worlds, letting groups bypass this for example just like how they can bypass the toggles of items very easily defeats the purpose of the toggle completely for the world creator and forces the creator to implement settings that will at the end of the day result in bloat of the world, regardless of this bloat a majority of players still play said worlds because those same players ask for measures to lower the amount of cheaters / malicious users, it is no longer 2019 VRC, it's 2026 and things are changing for the better.
If you feel like you need to leave the platform due to changes that is a decision no one will contest you on and anyone can do whatever they please when they don't like something, on the flipside as much as I love alternatives to platforms, there is currently no "competitor" that's even close to the level of quality and ease of access VRC provides to their users to this day or has the server size to accomodate.
Self policing players is why we have a ginormous repository of videos on people having public crashouts in open group instances power tripping.
As the platform continues going towards a more game centered approach because the new generation of users likes gaming , the more those anti gimmick systems will be implemented in said worlds and at that point the tags would not matter, which is why having the option to have those tags for worlds that require them in general would be a good step forward for protection of our user base.
SilphScope
KonKin If people can't handle their own moderation through the tools offered to them, applying a heavy handed approach hurts others. I am a firm believer in allowing a system to self sort, I've seen heavy handed approaches backfire far too often. And yes there are alternatives and I've watched them grow more popular by the day. Even if there were not these alternatives, I held onto VR for 10 years before I joined any social VR platform. I can go back to those days, they're not so long ago.
I vote with my wallet and time. I do not agree that a world that just so happens to include a game component automatically constitutes a "game world". I do not think any world that does not show a present need these toggles should be allowed to use them. I do not intend on changing my mind, nor showing respect to those who believe intended experiences outweigh the enjoyment of the masses.
Where this line should be drawn stands to be seen. But in my eyes, it should be drawn much more on the side of the players and avatars if it comes to a decision between the two. I have always been an end-user first individual. So much so, that even if I made a game world, which I had considered before, there's no way I'd even consider policing something seen as an exploit if it had ANY valid and reasonable use, as I believe in freedom to make your own fun above intended experiences in every situation.
At the end of the day this is, of course, my opinion. It will not be swayed by any means. I've always been one to push for my own brand of fun and only recently in the last decade or so have there I seen this strange blind faith in developer intent. Games are meant to be fun. If I'm having fun without disrupting others having their own fun, I'm playing as intended, above and beyond what any dev has to say about it. And that is the way I will always think.
KonKin
SilphScope That's fine, at the end of the day I've been aware I cannot convince someone who has already made up their mind from the start but still wanted to converse about it and everyone is entitled to an opinion.
I speak out for a majority of both the community of users who have been asking for a long while and creators who have also asked for this for ages, some of those creators losing passion due to how anti creator VRC has seemed providing almost no way to address player feedback when presented with users who will enter the game lobby, use said gimmicks to circumvent and even ruin other's fun.
If you've never developed a game you will never understand where these asks for more control over our created content comes from, we want to create a fair and performant experience for our game worlds mainly for our users who dislike said cheaters and ACTIVELY ask us for measures, but when those measures take up performance it stinks.
I would encourage you to make a game world and learn new things about the process if at any point you'd like to see the state of the game world development cycle experience.
SilphScope
KonKin That is understandable that others want that control. But those that do not, also matter equally and are often a silent voice. Hence why I mentioned having it be defaulted to on and toggleable by the moderator of the instance. In that situation, you'd have the best of both worlds of freedom and structure as public game worlds could have the restrictions remain on indefinitely unless the world author themself joined the instance to disable it. More difficult to implement? Yes, but I'd rather wait for a difficult implementation than risk a bad one.
Combating cheaters is a game of measuring risk and reward. Too much, and you hurt those who found their own fun, too little and yes, other experiences suffer. Not something I trust to leave to a random world creator, I've been burned by far too many people who are incompetent or too self-important to realize their vision is short sighted.
Plus... exploiting and cheating are very different. Everything discussed above is
technically
an exploit, not cheating, and that is a VERY important distinction. Exploits are unintended systems already present in a software utilized for an advantage, cheating is using outside clients or unfair rule breaking to gain an advantage. I've speedran, I've happily exploited before. But I've NEVER cheated in any competitive sense (I owned and used a gameshark and game genie back in the day, solely for replayability~). The conflation of these terms is something I heavily advise against.KonKin
SilphScope we wouldn't like for group owners to be able to turn it off it defeats the entire point of adding the toggle, it shouldn't be on by default but it should be there for the world creator to enforce on their creation.
Using flying avatars counts as cheating since it is an outside tool of the intended game's code to gain an unfair advantage in games with it IS cheating, if we go by your own words, while we can term it out semantically as much as we want in the end gaining that unfair advantage IS considered cheating even by mod makers.
On a related note EAC helped bring down a lot of script kiddies and crashers and the problem has become lesser with more security measures being implemented with the exception of usual suspects who do it to gain attention, a lot of people didn't like EAC, but the community/playerbase has grown way more ever since those days and continues to do so.
I know people can mod their game in other games to have their fun but I am talking about multiplayer experiences with progression and a bit of competition.
Adding the toggle ability would be a total net positive.
SilphScope
KonKin Sorry, HARD disagree. Invite, friend, and group instances should never include the world creator's intent in their premise, scope, or limitations. They are for a specific set of people with specific preferences, an A and B conversation the world creator can C themselves out of. If a world creator cooked a steak, and I decided to take it home to enjoy with friends, they should never tell me what condiments I can put on it or how to eat it. They should just be glad I enjoyed it.
The only case where this concept of leaving the toggle for instance moderators to decide might not apply is in competitive persistent data... which in most worlds is highly abusable already and in need of reform, and not something I will even consider until then.
As for flight... It's an inbuilt unity function. It's an exploit, the functions exists in the system for a reason, but use of flight is not using them as designed. Not cheating, as there are no external factors. You are just factually wrong, sorry. OVR flinging? Now that could be considered cheating. But not gogo flight.
Adding more toggle capacity solely for world creators to avatar assets and functions that cannot be removed even in a solo instance will make me blacklist and boycott any map makers that use it, as for me and my uses, it's a net negative that I cannot abide by. It is not a "total net positive" if ANYONE is affected negatively.
We are done here.
KonKin
SilphScope If these are not implemented as on/off toggles, VRC world creators will just continue to utilize said jank systems to completely get rid of avatar gimmicks, there is no negative to adding these when said systems already exist in a jank manner and can be easily implemented.
The steak comparison is very null to what a world experience is, Food is something you buy and it's yours, VRC worlds are creations world makers create for the love of their art or profit, sometimes both, you do not own someone's world as they've never sold it to you.
If I go to someone's game lobby, utilize said exploit to gain an advantage in a multiplayer game, then yes it is still cheating. The external factor is that they utilize UGC functions that modify the usual gameplay mechanics to gain an advantage which even the most prolific users who even stream themselves doing it (In another language) call it cheating, a vast part of the community heavily disagrees with you, just because you do something that's "In the system" does not mean an exploit does not come with consequences such as being banned for cheating and such, Exploiting something even has a phrase funny enough.
" Cheating the system."
You can blacklist and boycott all the people you don't like at the end of the day we look at the bigger picture of the community who has recently grown on the gaming side of VRC, this happened during EAC where people didn't like it and a minority left, then came back , you are entitled to your opinion, but we like progress and to see this platform and community grow as a whole with more features to boost the creator side and empower/inspire more creators to make fun worlds, a side that's very vocally a lot of times asked for these features to lessen the load.
We like to see VRC grow one step at a time & there's no "competition", only passion projects that require a lot of funding.
We can continue this conversation for as long as you can handle it, I like talking with people to see their opinion.
SilphScope
KonKin The steak analogy is because being a chef is a service industry. Making a game world is a service industry. I could make a million examples... Streaming a movie, you cannot tell me how I dress or what brand of TV I use, or whether I want to watch it at 2x speed. But at the end of the day, world creators supply a service, and their singular goal should be happy players, because happy players are the ones willing to support the world. No offense, developer intent or artistic value is not ever a good excuse to trample on that.
Flying in and of itself is an exploit, not a cheat. If I go into a lobby and everyone is okay with it, the rules of the lobby are not broken and no cheating happened. If I go into a lobby and they do not want it, then yes, cheating happened. Utilizing an exploit to cheat has to break a direct, present, and local rule and is nuanced. If a category of speedrun banned an exploit, that does not suddenly make all use of it cheating. It is just an cheat only in that very specific category of that speedrun.
I don't care about EAC. Never mentioned it, won't still. It's irrelevant to my situation and this situation, I don't have any words to say there.
I believe in end user above anything else. To that end, I refuse to put any money into any avatar base that bans public avatars. Does that mean I seek to abuse it? Of course not, and I've only made 2 or 3 public models out of my dozen+ purchased bases. But I believe in the right to do so. I believe in as many freedoms as I can be given within reason. I develop on Linux, use FOSS whenever possible... I just want choice, no matter if I even plan on using it.
A phrase I like to use... "others rights end where mine begin." This, in my eyes, applies to your right to protect your world integrity and intent, and my right to use my avatar assets. When in conflict, neither should have full control, and some common ground must be met otherwise neither side wins. That is why I recommended an instance moderator based setting. It's the closest to common ground that can be reached.
I'm mostly worried these toggles will be used maliciously to sell noclip or light addons, or to censor avatar features. It's why I wouldn't be happy with a world creator toggle unless it at least has HEFTY restrictions attached through TOS preventing abuse or turning it into a microtransaction. This should be a big red flag and a priority to anyone who actually loves the platform.
KonKin
SilphScope Like I've said before I agree these features should not be used to implement stuff like "Noclip/Fly if you pay xxxx Vbucks" , (I've already seen worlds that do this without the toggle last year) so in the end that toggle is not stopping anyone, I would want some restriction to stop that of course in any manner, but I would like for this toggle to not be easily bypassed by group owners, world creators are not servicing you, nobody is entitled to their content and stuff like tips and such are considered donations because you want to support your favorite creator, so at no point should any user believe "I can do anything I want with this person's content".
You always have the choice to not go to a world that you dislike, they are all user generated content.
If the toggle can be bypassed by groups/self made instances, it loses it's purpose for the creator of the content and we fall back to the tale old as time, having to implement anti cheats that produce false positives.
SilphScope
KonKin Again, while worlds are an art, the instances are a service. Just like a movie director cannot dictate in what manner I dress or act as I enjoy a movie on a streaming platform in my private home, neither should a world creator. They can ask for more money in exchange for extended rooms/features/convenience as long as it does not impede on my natural enjoyment. Think selling an extended version on a streaming service, or ad-free experience, vs something awful that shouldn't be allowed like paying more to allow my remote control to work or blocking it outright. Leave the end user content out of it, as long as it's private.
A person created the content, but their rights end the moment I make a private instance that the creator cannot join, as long as no one is adversely affected. That's where my rights, as an end user with my own assets, begin. No artistic creativity, intent, or any other honestly shoddy excuse matters to me. They put it up on a public platform, the moment it becomes an instance is where they lose absolute creative control over everything within. I'm not trying to be mean, but I feel I must be blunt to get the point across. This needs to remain the status quo, the world creator is no more or less important than the people inside, and therefore should never have absolute control over the instances themselves. Not being entitled, devs are free to update, abandon, or pull their content, just as I'm free to not play, join, or tip.
As for the proposed toggles, a lot is solved with a strict TOS barring paid noclip/similar. If you're against paid replacements to avatar restrictions, you should also be for a TOS update to make sure they never happen. If players are going to accept world creators getting toggles to restrict them, then the best case is world creators getting strict limitations in return for how they are allowed to limit them. Restriction for a restriction, as fair as can be, no?
And I think you're focusing too hard on worlds which only focus a game. I'm discussing all of VRChat, which includes social hubs, chill worlds with games, games meant for social experiences, and yes, full game experiences. You have to remember, this change can affect ALL of them and therefore has to fit every single one, no matter how popular games are getting.
KonKin
SilphScope Yup, I would be fine with a TOS that prevents creators from making abuseable systems like "Pay xxx to get here" as that's an abusive practice, In return , give world creators a toggle for anti avatar collider / anti avatar seats that creators can toggle are not bypassed by group owners/private instances.
SilphScope
KonKin That's a middle ground that I can accept begrudgingly if it's used rarely, sparingly, and only in worlds with persistent data that would otherwise be affected unfairly from within private instances.
I don't ever go to worlds like that anyway, honestly, and it's why it is hard to agree with a flat approach to a free boolean toggle. In mostly every world I visit, the restrictions have no place to exist in a private instance, ever.
I'm not going to trust every world creator, especially when predatory practices and senseless restrictions, by your own admission, already exist. I won't be willingly handing over my liberties for someone else's safety without a clear and present need. A want, or convenience, monetary gain, or artistic vision is never a need.
RanmaKei
SilphScope I made a suggestion for better world-tools to address the issue that I think is a good middle ground for players, world creators, and the platform that will solve several issues with avatar flight and mechanic issue.
Check out my Feature Request suggestion "Improve World Creator Tools for Handling Avatar Flight and Mechanics" Please upvote if you think it's a good idea.
There are also some worlds that already implement some functionality of what I propose that could accommodate players and game instances without global disables.
TheCreationKing
The "Fish!" world appears to have had an exception made for it by VRChat already, so my advice won't help Godfall.
But I have released an anti-fly that isn't suspicion based, a true flight detector. It's a free download on the BOOTH item "[Verbose]Jumps", for anyone else who needs anti-fly.
I'll avoid being self-promotional though, I have found 1 other system that's not mine that's also true detection. It's called "Anti-Collider board System" also on BOOTH, but it's not free. (And I routinely search for other true detection anti-flight systems)
Despite what creators consistently try telling me, neither of these systems are "probably easy to bypass". They both use a unique system that detects avatar colliders themselves. Both anti-flight systems have testing worlds, if you want to see for yourself. You don't even have to leave the ground for them to realize you're attempting to fly.
And yes, VRChat should just add this as a built in option.
Dor․
Some uses of flight are to combat physics jank (getting yeeted by physics, contextual to this would be getting yeeted by boats in the FISH world, happens too often and I get separated from my friends if it launches me so far that I drown or literally to another island), addressing the issues that encourage people to seek alternatives should be prioritized, otherwise you're just leaving people with a worse experience.
hdorriker
Dor․ Perhaps VRChat powers their servers from the energy generated by players being thrown from things or lag-dragged around on platform hook.
__Mira__
this needs to be a thing already for creators, its a simple tool that fixes everything with a growing base of cheaters
Corbí
I'm not entirely against this. It's something to think and talk because of how it changes the VRChat experience. But I don't think that develop a polemic feature and that only one world have it is the best of the ideas.
Corbí
This ticket isn’t even marked as tracked yet...
Beyond
I truly believe that the overall good this would do for the morale of world creators on the platform would outweigh anything negative that would happen as a result of a toggleable implementation.
This should have been something we had as an option from the start.
Galexion
This shouldn't have been a one time "special treatment" situation for fish. personally, it's the game that actually, really needed it the least. Games like SlashCo & Terrors of Nowhere had needed this sort of anti-cheat for years, since the solutions, speaking from experience, have falsely triggered on innocent players while others still resort to other tactics to cheat or get away with it anyways. I cannot tell you how many times I've been script killed for flying even though my feet stayed firmly on the ground. Fish easily could have added one of these anti-flying / anti-speed scripts and been fine, and personally I don't see why the studio behind fish didn't at least try before going directly to VRChat.
Tran Fox
There are already world prefabs out there to stop avatar flight (like NUMovement if you configure it for that) so if a world creator really wants to they can already disable avatar flight using one of those prefabs or by adding in their own anti-flight detection.
World creators can also semi-disable avatar stations by putting the player in their own station in the world to prevent them from using other ones.
That being said I really don't see a reason why the "admin_disable_avatar_collision" and "admin_disable_avatar_stations" world tags are admin only, if a world creator really wants to disable flight/stations they can already using semi-jank workarounds.
Pokéduel
Tran Fox I'll be honest, I don't quite see the argument here? Creators shouldn't rely on jank workarounds. Having an option to disable them using them using a toggle built into either the world descriptor, the website, or inside VrcPlayerApi, would make everything so much easier.
Plus, at any point these jank workarounds are susceptible to breaking. It should default behavior to having these collisions and chairs enabled by default, with the option to turn it off at a creator level, and that's only because its been a thing for years already.
Tran Fox
Pokéduel I agree that the tags / toggles / however VRC implements it should be easily accessible to world creators because there's already (janky) methods to work around it.
May have worded the initial one a bit weirdly lol.
hdorriker
Tran Fox this isnt the same. You cannot read colliders on avatars from the worlds SDK, and these colliders can wreak a lot more havoc on a world’s systems than just circumventing game mechanics with flight.
Load More
→