hey there, ive been having this issue for a while but believed it could easily by remedied by increasing my bullet acceleration value. Now that ive playeested the guns with several other people its become apparent that acceleration is not the issue at play.
im fairly sure the issue has nothing to do with the ray hit event on its own, rather the direction calculation.
its either that or the NPCS have some crazy bad latency, i dont recall anyone having this issue against real players last night during hte test, only npcs.
I think the problem is because of slight server-client lag. You might want to use fast cast on the client, and replicate the direction, bullet start position and all other relevant info to other players.
If the hit detection was done on the clients own machine, then it would always be 100% accurate
Same issue with a consistent laser that has to raycast very frequently. The start point of the laser is constant but the hit (end) point is jittery, not hitting the same spot.
Same issue here. NPC that uses raycasting on players within a certain area to check if they are behind walls detects the wall behind them. Sometimes it even detects ‘Terrain’ when the only terrain is ‘Air’.
I doubt it, seems like it’s raycasting not detecting things that are there, and detecting things that aren’t. It’s random and after some testing happens more often on unions, even if they are set to PreciseConvexDecomp.
while it may not be an option in your mind, it’s what you need to do. You need to detect on the client, and make sure it’s valid on the server. The basic idea is, you track the positions and go back to the position that the client saw at x ms ago, where x is the client’s ping. It’s very complex to make it have verification, but is worth it. You cannot fix this issue without moving the initial detection to the client.
Somewhat, you need to move all bullets to the client, and tell the server you fired a bullet, and the server does the replication. Once something is hit, the server checks where that thing was against a lookup table and if the check returns true, you do whatever you need to do with the bullet. I’d only detect against non anchored things, as they are likely the only things you will do damage to.
Not exactly.
Here’s how I have it sort of working:
user clicks
Client fires bullet, client tells server to replicate bullet, gives server any needed info
Server just fires a bullet from the positions the client gave, and it only has wall detection, and it doesn’t even need this, just makes it better should the client disconnect, so the bullet doesn’t fly forever.
The client waits for a hit
Once one is detected, it tells the server what part, position, etc it hit.
The server gets that, and compares it to a snapshot of the unanchored parts it took x seconds ago, where x is the travel time from the client’s computer to the server. This means you need to store snapshots for upwards of 10 seconds, which can be pretty taxing, but most players will play with a ping under 1000ms, so it won’t always be a large memory hog.
By using the snapshot, the server can use a worldmodel and fire a bullet from the last position the client reported, which you can update every 1/60s (yes, the network runs at 20hz, but since we don’t have a way of syncing it up, this means less latency.) by firing a remote event with all bullet positions, and the server just checks those against it’s copy of the bullets.
It’s very complex, but game development in general is very complex. You can choose one of three more common ways; with this being the best, since it takes the security from a server sided projectile and the correct client hit detection from client sided bullets.
I gave you the way to make hits actually work, you can choose the client sided only way; which will fix your detection issues, or just accept the your current way and have the hits not always work.
