I’ve been doing a lot of experiments with VR and I’m trying to make an interactive experience between VR users and desktop users. So I can eventually expand it into a more comprehensive game. With some notes taken from how Skeds VR Playgrounds handles movement I’ve hit a wall.
My issue is
Even though players stick to the ‘platform’ - with any quicker movements they slide off. I want them to have a little more grip
My current implementation
Client sends server data of hands position, the server then updates a Body Mover and Body Gyro when it gets this new information
Density of the hand is 100 (A vast improvement from the default value for sticking)
Friction of the hand is 2 (No noticable improvement)
SOLID = CLIENTS VERSION OF HAND (NON-COLLIDED, FOR CLIENT VISUAL ONLY)
RED = SERVERS VERSION (Network ownership default (aka whoever is the closest player excluding the VR player since they do not have a character)
Have you thought about maybe playing around with constraints? What if you attached something like a RopeConstraint from the player’s foot to the block? That might help to some extent, also including the possibility of messing with it’s properties to achieve the right amount of grip.
I’ve never seen any game that didn’t have this problem. If you’ve played Tradelands, they had a fix where the player could press a certain button when they are on a fast-moving boat that would weld them to it.
I’ve had to fix things like this by replicating physics manually but if there are better solutions then maybe use them. I have a Remote Function that constantly checks and logs the ping of players by their response time and I essentially shift everything on all sides using CFrame, velocity, and rotvelocity based on their ping and the physics states.
This can be used to make sure that clients are compensating for the desync in the movement of objects and you could move the person if they are standing on it as well by finding their current position on the object and trying to maintain it, or again, simulating them on the hand locally.
The hard part about doing this though is the fact that you might have to clone the things you want to replicate, but this is the only solution I could find because roblox doesn’t natively use Client Prediction.
The main concept here though is that essentially, the client simulates all physics for itself and corrects based on ping and server results, with server adjusting inputs and controls for latency.
This also resolves the button problem as it would activate much sooner as the server will be near synced to the client (when the arm starts moving) and the client will activate it itself locally a bit sooner.