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)
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.
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.
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:
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!
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 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.
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
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
