For my first person horror game, I made a module that gets a model from replicated storage and places it in the CFrame of the camera each frame. I then tried to create a lantern viewmodel that was effected by physics on the handle and hand by using cylinder constraints. The issue is that when I turn, the areas affected by the constraints just slide away?
Here’s a simplified version of my module:
local PLAYER = game:GetService("Players").LocalPlayer
local RUN_SERVICE = game:GetService("RunService")
local VIEW_MODEL_FOLDER = game.ReplicatedStorage.Client.Assets.ViewModels
local ViewModelService = {
currentViewModels = {}
}
function ViewModelService:LoadViewModel(viewModelName:string)
for i, viewModel in ipairs(self.currentViewModels) do --> Stop viewmodel repetiton
if viewModel.Name == viewModelName then
error('Viewmodel already exists!')
end
end
if VIEW_MODEL_FOLDER:FindFirstChild(viewModelName) then
local viewModel = VIEW_MODEL_FOLDER[viewModelName]:Clone()
viewModel.Parent = workspace.Camera
table.insert(self.currentViewModels, viewModel)
return viewModel
else
warn("Requested viewmodel doesn't exist!")
end
end
RUN_SERVICE:BindToRenderStep('viewmodel_bind', Enum.RenderPriority.Character.Value, function(dt)
for i, viewModel:Model in ipairs(ViewModelService.currentViewModels) do
viewModel:PivotTo(viewModel:GetPivot():Lerp(workspace.CurrentCamera.CFrame, 60 * dt))
end
end)
return ViewModelService
I don’t know exactly why, and I think it’s because there is not enough info.
If I had to make an educated guess… The movement of the handle is growing exponentially (getting faster as time goes on), which leads me to believe that the dt * 60 in viewModel:PivotTo(viewModel:GetPivot():Lerp(workspace.CurrentCamera.CFrame, 60 * dt)) is where the problem originates.
Why that is being effected and not other currentViewModels, I am not sure.
Maybe some more info on how the explorer is set up would be helpful.
I would recommend welding the model to the player on the client so that you do not have to update the CFrame of the model every single frame. CFrames will impact physics operations on objects over attachments.
I think if you just weld it to the player after adjusting the CFrame once then it should hold relative to the player and all the physics stuff should honestly just kind of work out. Make sure to make the lantern mass less and non-collidable and all that fun stuff incase it impacts the players movement.
However, I do not know how this will work out for the up and down aspect of movement, probably weld it to the players head and have some form of head follows camera movement script?
Since CFraming an object isn’t a physics movement it’ll create issues with Constraints.
I’ve used Motors (which are basically a rotatable weld) to create solid pivoting objects like a door that opens like a ramp. HingeConstraints still seem to be pretty springy/flexy for this kind of thing where players are interacting with them. I have a PrismaticConstraint hydraulic cylinder attached that was purely for visual purposes. The ramp would move, but the cylinder would glitch in steps so it looked very odd.
I kind of cheated by changing just one of the forces on the PrismaticConstraint in a loop while the ramp was moving. It doesn’t have to be a huge change because all it does is update the constraint to get it to match wherever the parts are CFramed to.
I found the solution to my issue: it had nothing to do with CFrame at all, I just needed to set the actuator type of the constraints to either servo or motor in order to stop them from sliding (which I thought was weird, because I saw that prismatic constraints are the slide-y ones?). I figure I have to learn more than just surface level about constraints, lol.