So I’ve been trying to do this correctly for almost a day, and I just couldn’t get it to work, so I must ask for help
I have a gun (In-game) which is supposed to rotate the player in the direction of the mouse when you shoot
I have tried using “CFrame.lookAt()” but the problem with this is that It will make the player look straight at the Mouse Position, meaning if the player fires up, it will make them look at the sky, which I don’t want happening
I tried googling how to do it and it improved, but it has some problems, this is the current code which I gave up with:
This is a gif of the problem in-game
As you can see, if the player shoots while standing still, it works fine, but if moving, it sorta hops back, like a little teleport
(Note: The rotation needs to be serversided, the mouse position is sent to the server through a remote event)
What could I do to fix this?
Sorry If I took too long to explain, I was tryna figure out how this website works
Why does the rotation need to be serverside? Player movement shouldn’t be handled by the server, but by the client because otherwise you get that nasty lagback which is your problem here. I ran the code on my client and it worked, all though it produced a different logic error.
Ok, I tried doing in on the client, now there’s another issue… theres a huge desynchronization between the player turning and the bullet firing, example here.
I assume It’s how I made the gun, all the LocalScript does it send the Mouse’s position when you activate the tool, the Server Script checks if you can fire the gun and all the logic
Because of this I need to send the info from the Server Script to the Local Script somehow, and the time it takes to fire a remote is too long and creates a desync?
Most games fire the bullet on the client and then send the information gathered to the server, which fixes this huge issue of desynchronisation. You may say that this approach is insecure and easily exploitable, however you can do checks on the server such as recasting any rays to get an idea if the event was spoofed or created by an alternative source.
The bullet should only be rendered on the client anyways. So the order of events should be more like this:
Player/client fires gun
Raycasts/physics checks are done on that client
Client sends event to the server with the data (who/what/where it hit)
Server verifies that info (making sure the bullet could realistically hit what the client says it did)
Server fires remotes to every client in the vicinity of the player who shot it
Each of those individual clients renders the bullet
This has two main benefits:
The server doesn’t need to bother computing how to draw the bullet (it’s a lot more efficient to do stuff like that on a clients computer)
Individual clients have control how the bullet is rendered. This means that you could add settings where players on low-end devices can opt to not have the bullet drawn at all.
Wow, that sounds good, I think that might be too advanced for me at the moment tho…but i’ll keep it in mind.
Also wont doing all those things before rendering the bullet on the other clients make it so they see that they’ve been shot way later than when the Shooter sees it?
