My character gets stuck in place when I go into first person, as well as somehow prone to flinging, and gets flung when I’m standing still in first person.
I specifically said that they didn’t have CanCollide on in my reply. I even made sure they didn’t before posting it.
Hello, quick question, how would I go about making an aiming system with this?
Well, this is a very useful resource but… this script doesn’t work properly with my gun setup.
I connect the gun to the Torso (more flexibility with animations because you’re not stuck to the right arm) with a Motor6D instead of the Right Arm like a normal tool, and well, the gun doesn’t move.
Edit: Forgot to mention, RequiresHandle is off on my guns. The issue is more likely that RequiresHandle is off.
I think the conflict is probably because I’ve connected the gun to the Torso and not the Right Arm (as stated I need more control with animations), because the arms move and sway, but the gun just stays there.
I think that a way to fix this would be to have an option of including the Torso in the viewmodel that’s off by default. (I’m using R6)
Nonetheless, it’s still a nice script. Just can’t really use it with the way I have my gun set up.
it’s because the option “RequiresHandle” is disabled
it works with tool that uses Handle since it’s custom grip
2 Likes
The System seems to not work after you respawn, I have looked into the code but I still don’t know why.
EDIT: I think I didn’t do something right so that’s why it does not work
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