Create a new version of VRCStation
hdorriker
VRCStation needs an alternative for many reasons. Here are some:
- Too many issues with the introduction of every new feature.
- Too many undocumented behaviors which seem to change from (client) update to update.
- Full of difficult-to-reproduce, obscure bugs that are much too time-consuming to debug for more casual creators.
- Excessively sensitive to implementation and usage factors to the point of total absurdity (Try putting an Udon behavior on the same object as a Station and writing to another Udon behavior's variable.)
- Changes behavior based on the number of people in a world.
(I've seen this several times and it breaks the game.)
- It doesn't even know which player is sitting in it.
- Solutions to some Station issues are already in the SDK but not implemented apparently such as the animator fix for full body tracking which exists in the Avatar SDK but is missing in the World SDK.
- In practice, UDON Solutions and workarounds to VRCStation issues can work less effectively over time, demanding constant maintenance and causing worlds to stop working entirely.
PROPOSAL:
Because numerous existing worlds currently make (hard fought) use of VRCStation's quirks for actual features, you can't simply get rid of it, as this would break a huge number of very cool worlds. Instead of re-engineering the existing VRCStation (nobody wants that!), Create a brand new VRCStation alternative and creators may choose between the two (an extremely worthwhile choice to present compared to the alternative of not fixing anything).
This new VRCStation2 should have the following:
- The Player must never be misplaced or "thrown" because of playspace origin or other factors separate from and totally irrelevant to the transform of their head. Players must always be positioned where they are expected to be at all costs even if it hits the frames a little to correct it (because the UDON acrobatics we have to do to make this happen without this assurance are going to hit frames harder anyway. Nothing is being saved by doing this quickly but incorrectly. I cannot stress enough how important this is.)
- The Station must have a public variable or method by which to get the VRCPlayerApi object of the player seated.
- The Station must be movable by any mechanism by which a GameObject can be moved (Animation, RigidBody, updating the value of the transform position/rotation), with no exceptions or conditions. Usage of this must be as simple as possible with no hidden/undocumented behaviors.
- The Station must not immobilize the arms of a player by default. In practice, players are expected to be able to interact with things with their arms when seated so it would never make sense for this to happen without the world dev explicitly specifying it.
- The Station must have a facility for player exit by calling a method on it/sending an event. This is imperative for ergonomics and feature-rich worlds.
- The Station must have the ability to NOT restrict FBT movement, as this is widely used by many players and there are entire forms of emergent gameplay and experiences which depend on this. There is currently a community workaround for this, don't break it.
- Stations should be able to sync their positions relative to their host GameObject.
If a player is adjusting their seat, their position should be synced because without it, players don't know where each others heads are and this interferes with social interaction. It is unreasonable to require a world dev to have to crack into Networking in order to sync the position of seats because Networking is among the most difficult parts of UDON and most world creators will just skip it if this syncing isn't included in the component (and you can't really blame them, some people just want to casually make a room with a couch or something and don't have time to learn Networking).
- Stations should orient the player to match the Up direction of the Station's local transform, and NOT the Up direction of the world. The current implementation which orients to world's up creates a huge amount of nauseating misalignments where players end up sideways in a seat because it's on a vehicle, if the vehicle isn't completely flat, and in-practice it is absurd to ask players to only enter a vehicle when it's on flat ground.
This might be a lot of things, and in general with some exceptions, it matches the functionality of VRCStation, but the key is that the new one needs to prioritize expected behaviors and cannot have the entropic "decay" in reliability exhibited by the current one.
I have spent many hours trying to drag VRCStation into doing exactly what it's supposed to do, entirely because I needed to get events from it or any myriad of other various ways it can find a reason not to work right. This component's vagaries have even evaded the skills of friends that are far better at this kind of thing than I am. This component is a disaster and it's only getting worse with time.
Surely, I can't be the only one who is at the end of their patience and resources in dealing with VRCStation. So please, for the sake of future world development and the health of the platform, please consider creating an alternative to the existing VRCStation component.
Thank you.
Log In
hdorriker
It’s been 10 months, nothing has improved and VRCStation is even less reliable now.
I feel like I’ve written multiple dissertations by now on how VRCStation is choking this platform to death. But its replacement must not adopt any of its defects, which is easy to do by simply making sure it is developed by someone who has actually used it and built worlds. VRCStation2 must only do two things: 1. Parent players to objects no questions asked, or 2. Seat a player by allowing the world absolute and unrestricted control over the avatar controller because the world dev knows where the player should be in the world, period. Everything should be exposed to Udon, and the guiding principle of its software architecture should be maximum utility to the end world developer because we are better at making things ergonomic than anyone else.
The behaviors of the current Station are hostile to this and it is unacceptable.
kawashirov
Also stations should place ppl relative to selected bone (hips by default).
This is nonsense when ppl fell or pop out of chair because size of their avatar.
`Squishy
100% agree. Much needed.
A very small additional request I'd like to add to any efforts to rework stations, would be an opt-in checkbox for stations on avatars, to enable the user of the avatar to "sit" on their own avatars stations. Whilst the reason it's disabled is very obvious and makes sense as a default, there ARE fun usecases for this that used to be possible in the past, and I would love to have that back.
Please and thankyou! Would make me happy!
Jar
Please also allow entering stations when using a non-humanoid avatar.
DrakenStark
Things I'd love to see from stations:
- Allow/Denial and an appropriate function or highlight color/style in response so the player may receive feedback appropriately. Sometimes we want to acknowledge there is a seat to players, but don't always want it to be accessible without letting the player know there is a requirement that hasn't been met.
- Hide or change Highlight color/style, similar to a regular interactable object.
- Allow desync and instancing on purpose as these are huge. There are a lot of use cases where purposefully desyncing players is extremely useful. Could be for making an immersive radio, creating non-euclidean effects, or centralizing players locally for extremely large worlds to avoid floating point errors. (Local player at Vector3 .zero with all other players and objects being relative.)
- Force relative or a specific avatar size. Could be a case where a player needs to drive a vehicle, which there's little point if they aren't tall enough to see or too tall to fit. Allow a secondary Transform to mark where a player’s head should be and scale them to match the hip of the station and the height of the head point. Another case could be where a vehicle needs to change size, just as a player could.
- Tie-in with a player object pool. There is no way to attach anything to players currently, which is a sore missing feature that stations have been used to work around. Allow player bones and armature to have constraints through a station if not directly made possible for players directly. Teleporting objects every frame via Udon is very taxing and creates significant frame based drawbacks where even toggling can become unreliable without additional checks being made in those already taxing Update functions. An alternative is highly desired.
- Inherit, intercept, interpret, or ignore normal player movement controls. (Allow all normal movement and jumping, allow some movement and optionally jumping, allow no movement and jumping and optionally control something else, or allow exit via movement or optionally jumping.)
DAG-XR
Since I started VRC, I've probably thrown at least 10 bug reports to the canny regarding VRCStations. I'd love to see an overhaul in the next year or two. I always turn seats off everywhere I go if I can help it.
If I recall, the original VRCStation code is from Unity 5.3 or 5.6
DrakenStark
DAG-XR Still have nightmares of players getting stuck in a station somewhere on remote clients and being completely ignored because other players were required to invisibly direct a player they couldn't see to the station they were stuck in for them. Can only imagine the distaste many folks had for stations after that. Really a pity considering there's so much they could do if they were more reliable and did what players intuitively expect them to behave.
DAG-XR
DrakenStark That was probably the worst ever bug. God forbid if you try to ever enter a VRCStation that isn't evenly leveled (avatars and vehicles); your viewport and motion sickness will have a field day.
hdorriker
DAG-XR
There's something about that which feels it was originally a good intention that went bad to try to prevent motion sickness or "griefing by world devs" (which doesn't make sense since people can just leave...) and it ended up making the issue far far worse in practice by guaranteeing mis-rotation in many common cases.