I am working on my game, which is primarily in first person. I have a collider sphere welded to the player’s PrimaryPart, and is 100 studs in diameter. This whole system works well, however there is a weird issue.
The part itself refuses to stop transferring its velocity to the player. Although it isn’t too noticeable normally if you were outside first person, my game is entirely first person so you can clearly see the little vibrations or bops.
Since the player has physics, the part (collider sphere) needs to be unanchored. However, doing so randomly applies a velocity to the player that seems to correlate with gravity, causing them to randomly (very slightly) go into the floor for a frame or two, making the camera bob randomly when idle.
(The parts movement when welded to the player, and the player bobbing)
You can click this for a YouTube link if the above video doesn’t work
I have tried not welding the sphere to the player, and instead opting to use a renderstepped loop to loop position the sphere to the player, but that has the same issue even when I set the part velocity to 0 in the loop.
(The parts velocity despite it being set to 0 every frame)
This can’t vibrate, as when it does it affects what the collider is detecting-- making these annoying light flickers, and various loading issues for my game.
What are some alternative methods I can use to stop the part from vibrating the player, or vibrating in general? Using lerp / tweens won’t suffice as that slows down the collider’s snappiness when moving with the player, which has issues if the player is moving quickly (being flung)
Have you tried turning everything off for that part—CanCollide, Massless, Anchored? Weld it to the player and just let it be stuck there with no updates to it at all. It’s just a visual thing, right?
The way I have it laid out is it will (programatically) spawn a sphere only on the client side via a local script. It then welds the sphere to the player model’s PrimaryPart, and then repositions to be on the player. The sphere properties are as follows:
I saying just make it be a visual thing for that part and not have it do anything…
Do the rest someplace else. It’s fired from working for making trouble.
The issue is this part is a collider. I might not be understanding what you are saying, but it has to be with the player-- It uses Touched and TouchEnded events to get parts within a radius for optimization purposes, and if it jitters or doesn’t come with the player it will not handle parts I need it to correctly.
I see, I thought it was that visor-looking thing. Hard to guess at a problem like this.
Maybe the timing is off with the FPS, and that adds up after a bit and causes jumps.
Possibly add a stepped wait to whatever is updating that to keep everything in sync.
local rns=game:GetService("RunService")
rns.Stepped:Wait() --this line would be in the loop vs a wait.
Found a solution!! It is kinda odd, but works flawlessly!
I was reading the docs, and found an event under the RunService. This event is called PostSimulation, and it is fired after every physics update. I found that instead of using a RenderStepped loop, using a PostSimulation loop was better for this as it would fire after every physics update, allowing me to counter the physics that were just simulated.
I tried the PreSimulation event, but that still had the issue-- This makes sense since it would have processed the physics for it after firing, so this worked out!
Here is the velocity of the part while idling now :3