Projectile Compensation? (fastcast)

[VillusionaI (therealmarcus101)]

Alr np thx for help I’ll figure it out

[TheCraftNCreator]

@BendsSpace

The server’s knife is behind by the ping time, which always exists, so it’s always behind.

So would the hit detection.

@BendsSpace

If we’re talking about a knife model with client network ownership (ignoring the exploits), the replication would need to look something like this:
Client throws knife, create visual
Send remote to server (one-time 1 latency unit delay)
Server creates knife model, gives ownership to client
Client replaces their knife with the new one from the server they have ownership over
Client continuously replicates their knife’s position to the server (the server’s copy is 1 latency unit behind
The server replicates the position being replicated by the client to the other clients, each client is 2 latency units behind.
Knife hits something on the client, client has 0 LU of delay
Replicates to server (1 LU delay)
Server replicates to other players, 2 LU delay)

Note that ‘replicating the knife’s position’ is the exact same as how the client replicates their character’s postion to the server. A player’s character is always 2 LU behind for other clients.

Here’s the actual system using my ideas:

Client creates and throws knife, 0 LU
Client sends signal to server to replicate knife visually, (1 LU, 2 LU for other clients (Does not halt the procedure)).
Client’s knife hits something and calls hit, 1 LU
Server tells other client to take damage/die, 1 LU

The problem is that while yours adjusts for latency, it also means the the direction of the thrown knife is a whole latency unit behind. Nobody wants a gun that doesn’t shoot where you point it, or having to calculate for latency when throwing a knife.

@BendsSpace

Would be for who? The client has zero position delay, and can approximate hits in 0 LU and get confirmation in 1 LU. The server has 0 LU for position and 0 LU for hits. The other clients also have 0 LU for the position, 0 LU for hit approximation and 1 LU for hits.

Like I mentioned earlier, the delay is with the aim. It’s not just calculating where a moving target will be, it’s also calculating where you were aiming 1 LU ago.

@BendsSpace

Proper sanity checking requires the server to do all the work again anyways. In fact, because the server has an exact copy of the path and doesn’t need to do the sanity checking after the fact, the work load is equal or less, assuming proper verification.

From earlier, you could use the visual knife created by the server for sanity checks. By the time a client sends a hit, it should be roughly lined up with where the knife on the server would be. The knife that is 1 LU behind is given hit information 1 LU behind as well.

[RPD777]

How do you accommodate for the latency when simulating the knife movement for the other clients? Would need to ‘skip’ the knife ahead to ensure the hit time is the same I presume.

[TheCraftNCreator]

Think of it like this, we have a client that throws the knife. Everything is perfect for them.

A remote event is fired telling the server to tell the other clients to re-create the thrown knife, which would cost 2 units of latency from the two remotes fired.

Currently, the server is one LU behind, and the other clients are 2 LU behind. This might sound bad, but then you have to consider the time it takes for the client to tell the server it hit something, and then for the server to tell the other clients they got hit.

If you were to skip ahead, you’d actually behind AHEAD by a couple LU’s. So if you were on the recieving end of a knife throw, you’d be hit, but it would take a moment for the knife to do damage on your screen.