This is probably because you have a good device, but also in a live game with tons of players and people with low-end devices this could be problematic.
It’s local, nobody from outside gets affected.
Also just read up about bodyposition, I’d assume you’d just need to do this:
Bodyposition.Position = Camera.Position
Put it in the event of course.
Yes nobody outside will be affected, but i’m talking about the players themselves. If a player is using a low-end device or maybe let’s say as you’re building your game you’re obviously gonna add new things to it can be a problem.
So you suggest trying Bodyposition? Or am I wrong now?
Excuse my stupidity. That’s why I was afraid to post on forums and always try to find a solution in a secret way.
Yeah bodyposition, I realised now that it’s probably the best choice. It’s smooth and probably more performant than tweens.
1 Like
I’ve never actually used BodyPosition before, so I need to learn it first. I’ll try it once I get the hang of it, you know. I’m a newbie and open to learning anything new.
Its quite simple, its almost the same as just setting a pos normally
So could I basically replace the Lerp with this and always give it the new position?
Yes, if it doesn’t work make sure you use the .P property. See here:BodyPosition | Documentation - Roblox Creator Hub
1 Like
Alright thank you, I will try it at the next day. I’m currently really tired of scripting. I have been sitting on this problem four hours.
1 Like
Camera updating is kind of a pain because in every engine there is a different way it needs to be done to avoid jittering. That’s super strange that the speed and whether or not the character is touching the wall affects it.
Just for kicks, maybe try updating the finish pos based on heartbeat? It’s possible that the jittering is from the target being updated at a different rate than the camera? (Since the character is updated based on the physics loop.)
-- Edit: Code requested to be removed, some parts omitted
local finishPosition = ... -- Initialize the finish position
game:GetService("RunService").Heartbeat:Connect(function()
-- Set finish position
end)
game:GetService("RunService").Stepped:Connect(function(_, deltaTime)
-- Set start position
-- Lerp between the finish position and the start position based on the time and distance
end)
The problem also might be with the alpha parameter of the Lerp:
local Magnitude = (StartPos - FinishPos).Magnitude
local Distance = (Magnitude+7.5)
...
-- deltaTime = about 1/30
math.min(deltaTime * Distance, Magnitude)
The alpha should be a [0-1] value, otherwise the lerp will go past the target, which would be undesirable in this case. I’m not sure what the equation above is trying to do. Usually I just used a fixed percentage, maybe 0.05 or something. That might be something to try to narrow down the issue.
Another issue might be that the camera’s subject is set to the part, but the part’s position could be being updated after the camera.
If this is a problem, you’d want to use:
-- Update right before the camera's update
RunService:BindToRenderStep("DelayedCameraEffect", Enum.RenderPriority.Camera-1, functionToBind)
Therefore, I’m looking for a different solution that eliminates the jiggle without increasing my character’s hitbox with a part or causing other negative effects
It might be possible to not parent the solution part to the character, then set the part to massless (which makes it so it doesn’t affect the physics of the character). That way it wouldn’t affect the hitbox (since it’s not parented) or the physics.
1 Like
I will try it in a minute, I just gotta finish something!
1 Like
Okay, I tried it, and honestly, I think we all misunderstood each other. The issue isn’t with the camera but with the character itself. However, I believe you’re not entirely wrong. For now, I think I’ll go with this solution, since dealing with the wobbly character feels like black magic to me at the moment.
I’ll definitely keep all your guys ideas in mind and test them out as well. However, for now, I’m considering your suggestion as the solution. I appreciate all your help—thank you!
1 Like
Oh, that’s very interesting. It’s probably with the character controller (which is a total blackbox) then because the part is parented to the character.
I’d try not parenting the part to the character (and using Humanoid.Died to destroy the part) or using .Massless = true.
1 Like
Yeah, I’m not sure why, but the player’s character seems to follow its own set of rules. I’m actually glad I found a quick workaround and your suggestion has been helpful for the issue. We’ll see if any new problems come up later, but I need to implement what others suggested about not letting it run constantly.
1 Like
Funny but if I do massless the jiggle is back, I love roblox.
1 Like
If you parent it to workspace instead of the character, does it still happen? If it’s not parented or welded to the character it (probably) shouldn’t affect the character.
Nope, it doesn’t work as expected, but I’ll try out the suggestions you all gave me later. For now, it’s fine since I can stabilize the character by adding a second part in the opposite direction. It’s not perfect and not exactly what I want, but I’m tired of dealing with the camera and want to move on. With BodyPosition and your suggestions, it might actually improve. Just a guess, of course.
Looks goofy if you can see it.
1 Like
I noticed a bug report, this might actually be an engine bug from the new adaptive physics update rates. (It’s said in the thread it’s the actual character shaking too, just like you’re seeing.)
You could try turning off the adaptive stepping and seeing if that fixes it:
2 Likes