I’m also getting this issue, its cause the Rootpart is anchored, but unanchoring it messes everything up.
I ran into this issue when I implemented a ragdoll system. I think the issue is that there are constraints that are attached to the arms. You’ll have to disable constraints attached to the arms to fix this.
2 Likes
Hey, Yellowfats! This is a great system. I have one tiny problem though, is it possible to adjust the sideways offset of the ViewModel? If not then it’s fine, if yes then it would be great if you could tell me how C:
Edit: Nevermind, I found it out, I just had to change the value in camera.CFrame.RightVector for those who have the same issue as me
1 Like
@yelowfat (not sure if you have topic notifications disabled so…)
There seems to be an issue with damaging other humanoids with melees in first person. Awhile ago I made a post saying that tools hurt my own character. I added that fix in, but that shouldn’t have damaged me in the first place, because if it was damaging me, that means the melee was only working on me to begin with.
After the script patch to make it ignore my character, it does 0 damage to anyone, but when I zoom out it works just as expected. Certainly not wrong with anything in my setup.
Is there a possible fix? If so, thank you in advance.
1 Like
This is really cool but… it breaks my tool in first person?
Nevermind, fixed it. Is there a way to implement aiming with this script for guns with the aimoffset value?
Edit again: Figured that out too
My code (yes its kinda bad)
local ValName = "CanAim"
local UIS = game:GetService('UserInputService')
local OffsetX = 0
local OffsetY = 0
local OffsetZ = 0
UIS.InputBegan:Connect(function(i,g)
if not g and i.UserInputType == Enum.UserInputType.MouseButton2 then
if game.Players.LocalPlayer.Character:FindFirstChildWhichIsA("Tool") then
local tool = game.Players.LocalPlayer.Character:FindFirstChildWhichIsA("Tool")
if tool:FindFirstChild(ValName) then
print("StartAim")
game.Players.LocalPlayer.Character.EasyFirstPerson.AimOffset.Value = Vector3.new(tool.CanAim.Value.X - OffsetX, tool.CanAim.Value.Y - OffsetY, tool.CanAim.Value.Z - OffsetZ)
if game.Players.LocalPlayer.PlayerGui:FindFirstChild('GunGUI') then
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.HL.BackgroundTransparency = 1
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.HR.BackgroundTransparency = 1
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.VD.BackgroundTransparency = 1
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.VU.BackgroundTransparency = 1
end
end
end
end
end)
UIS.InputEnded:Connect(function(i,g)
if not g and i.UserInputType == Enum.UserInputType.MouseButton2 then
--if game.Players.LocalPlayer.Character:FindFirstChildWhichIsA("Tool") then
--local tool = game.Players.LocalPlayer.Character:FindFirstChildWhichIsA("Tool")
--if tool:FindFirstChild(ValName) then
print("StopAim")
game.Players.LocalPlayer.Character.EasyFirstPerson.AimOffset.Value = Vector3.new(0.1, -0.3, 0)
if game.Players.LocalPlayer.PlayerGui:FindFirstChild('GunGUI') then
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.HL.BackgroundTransparency = 0
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.HR.BackgroundTransparency = 0
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.VD.BackgroundTransparency = 0
game.Players.LocalPlayer.PlayerGui.GunGUI.Crosshair.Main.VU.BackgroundTransparency = 0
end
--end
--end
end
end)
2 Likes
Known bug: Touched events don’t register in first person!
I discovered this bug a while ago and since then it remains the only bug I haven’t been able to fix - mostly because I’m not entirely sure why it’s happening.
Currently if you zoom into first person, server touched events for the arms and any parts connected to these two (including tools) will not fire. My guess is that because the real arms are being attached to a viewmodel that only exists on the client (which means any code attaching the viewmodel to the camera won’t replicate the arm’s positions to the server), the touched events don’t fire. But when I disable the character’s shoulder joints and attach the arms to the view model’s client joints, this changes how the server perceives the character’s arms, likely due to the fact that many properties of the character are designed to replicate client changes to the server automatically (such as playing animations, destroying limbs locally, etc).
However I do realize the severity of this design oversight, and a fix for it will hopefully be out soon.
7 Likes
Looked through and I seem to be the only person who ran into this issue (or I’m blind lol), but when I go into First Person my character just freezes and can’t move. I thought it might have been Realism or my skinned mesh StarterCharacter but even removing both of those it still doesn’t work. I even tried removing a majority of the game scripts that could affect this but to no avail. Hoping anyone can help out.
https://cdn.discordapp.com/attachments/931410559608422450/931410664591872030/2022-01-13_23-50-33.mp4
@yelowfat (would DM but just in case others run into this issue also I’m posting it here)
I figured out that R15 / Rthro Ragdolls by @EchoReaper is causing this issue. I’m hoping you could sort out this out and possibly make it compatible? I’m not advanced enough myself to figure out why this module breaks it, so I hope you can help me out.
Thanks.
Now i am facing this issue, i dont know how to fix it, my arms keeps getting locked in the air when i leave the gun/tool i am using.
any fixes?
1 Like
Hey @yelowfat, it’s Nilociety!
I wanted to ask a quick question regarding the way you work with having the arms actually face in the direction the player is facing while in first person. Since this script is supposed to be an EasyFirstPerson thing, I don’t expect it to be highly capable of pulling off a pretty good FPS system, however I was wondering if there is some way I could replicate the angle in which the player is facing to the server?
I have a gun that when the player shoots, a visible bullet is shot. Since this script takes the players arms and turns it into a viewmodel directly, I was wondering if there is a way to safely replicate the clients angle to the server? If this isn’t possible without causing glitches, is there way to modify the script which clones fake arms for the viewport instead?
My main issue is when I shoot, the bullet comes from the regular Fire Point of my Gun Tool. This causes an inconsistency with this script because if I’m facing down at the ground, the bullet will shoot from a point in front of the player, instead of from the Viewmodels fire point.
I adjusted my script to tell the server the fire point of the client, which does give me the results I’m wanting, however this method is not secure at all. This is what I’m trying to achieve however:
Video Link: EasyFirstPerson Gun Replication Demo - YouTube
Obviously the way the gun works here is very barebones, but the point about how I can use the server to handle the Fire Point with this would be amazing. Thank you in advance for any help you can provide.
Replicating character tilt angles to point towards the player’s camera direction on the server is a very common practice, and usually you can go about it in two ways:
- at some interval (use every .2 seconds for example), tell the server to tilt the character’s waist and/or other joints to face the camera
- same as the above method but take it one step further and on each interval the server tells each individual client to adjust the character’s arms locally, resulting in a much more smooth experience and saves the server from having to move the character’s joints.
The way I counter this in all my weapon systems is to fire your bullet tracer locally on your client using the viewmodel as the bullet’s start point, and then tell the server to make each other client replicate the bullet but this time starting from the “Regular Fire Point” of your gun tool. The other players replicating your shot won’t show up on your screen since they are all doing it locally.
It seems like currently your system is creating the visual bullet on the server. I wouldn’t recommend this because it can make for a bad user experience due to input lag (lag between you clicking your mouse and the server registering that shot and creating the visual bullet). Most shooter games hide the effects of input lag by giving instant feedback locally on the shooter’s client, while having the other clients replicate your shot individually on their clients. The other players will technically suffer the effects of input lag, but since they aren’t the one shooting the gun nobody is the wiser.
Good luck with your gun system, and if you have any further questions feel free to message me!
1 Like
I actually did this shortly after thinking about it even harder than I did before. I initially thought I was over complicating the situation. I took a minute, did my top down design again, and realized I could have done it this way instead (which I did end up doing before you responded)
I didn’t initially account for this. I’ll definitely think about this further, and implement it if the way I currently have it setup, proves to be a problem.
I will, thank you so much for the help!
The issue was the rootpart in the viewmodel was Anchored
can’t demonstrate the fix due to file size limit error 
1 Like
I had considered this fix before but it seems to create other problems for the system. It does fix the touched events not firing bug, but for whatever reason it entirely breaks nearly any raycast-based weapon system I’ve tried with it, with the issue appearing to be serious inconsistencies between player limbs and weapon parts on the server versus on the client.
I did some more testing today to see if these problems could be mitigated still to no avail - but I will continue looking for a complete solution to this issue.
2 Likes
My guess is AssemblyLinearVelocity on FakeRootPart wasn’t updated
I’m going to try suggesting possible fixes, please don’t cringe as I’m only basing this off the evidence in this post; I HAVEN’T CHECKED THE SOURCE CODE YET.
What you could do is locally build a completely new rig from scratch in Workspace. Give it everything a normal rig has: a head, torso, arms, legs, Humanoid, Motor6Ds, the works. Make every part the same size and position as its real character equivalent. Clone any tools, parent it to the fake rig, then set all the body parts’ LocalTransparencyModifier to 1 except for left and right arms. Make them all anchored, massless, untouchable (CanTouch = false), and unqueryable (CanQuery = false). Clone the real character’s shirt onto that fake rig and give the fake rig the same skin color. Repeat for everything; essentially just build a new player character clone. It should appear as a pair of arms floating. Ensure that HumanoidRootPart is the primary part.
Do all the fun arm movement calculations on the fake rig. You can also call :PivotTo() to ensure the fake rig is at the same position as the real character.
Listen for tool updates on the real character, and update their respective fake Instances as needed. This should work as you’re not affecting any stuff on the server. As the server isn’t seeing the stuff you made locally, .Touched events on the server should be unaffected. This leaves the real arms unaffected.
Hope this helps 
I may have gone overboard with the fixes… which might not even work 
2 Likes
Wish this was included in the post, I spent over an hour debugging this 
1 Like
Hey, thanks for creating this! I wanted to share that I created a fork of this system to massively improve the codebase, add optimizations, and fix a few unhandled issues! https://github.com/MonzterDev/First-Person-Camera-Roblox
3 Likes
you sure that it’s fully working for everyone?
i’ve looked at the settings and this is what i got
doesn’t sway and doesn’t move at all, atleast managed to see my arms