For anyone else potentially curious about moving a projectile “forward in time” on its natural trajectory, the only problem I faced was my own oversight. I had the logic firing off in the constructor of the projectile itself, and it is imperative that it is ran in onBeginPlay (or, at least, after onBeginPlay fires). Adjusting projectiles’ location/velocity prior to onBeginPlay will typically result in erratic behavior due to the logic that exists inside onBeginPlay. I totally spaced this when I was crafting this rudimentary lag compensation.
This solution is working exactly as intended now.
If you’re curious about lag compensation with projectiles, my setup is as follows:
As the server, upon spawning the projectile, get the player’s ping from the player state. Multiply this by 2 to get the single-trip latency at the time of spawning the projectile. Fire off a projectile path prediction method, and set the max sim time to the aforementioned latency divided by 1000. Break the result, get the last index of the path data, and set your projectile’s location + velocity to the results. Voila, you have now synced your server’s projectile with the client’s dummy projectile, within a margin of error (due to the fact that ping constantly changes, and we aren’t measuring the time THAT particular packet took in transport, which is very likely to differ from ping at least slightly, and potentially greatly due to lag spikes).
Few notes:
There is still the conundrum that after “fast forwarding” the projectile, the replicated projectile still takes time to update on the client. Therefor, for the sake of example, if you had the client fire a dummy projectile, then implemented this rudimentary lag compensation, and had the client delete their projectile to account for the server’s replicated projectile being created, the client is likely to see the projectile move back a bit. I would personally recommend simply not replicating the server’s projectile to the owning client to account for this, and leaving the client’s dummy projectile alive.
As always, relying on client data for positioning/velocity of projectiles (or nearly anything else) is a HUGE security hole. That means any random shmo with Cheat Engine (or similar) could fire projectiles from any area of the map, including 10 units in front of another player’s face, at any velocity they choose. There are tremendous amounts of incredibly intelligent people out there who would find this hole within about 5 minutes of tinkering in your game. Be cognizant of that when developing, and have your server do the leg work so you can trust the data.
This solution alone does not account for where the client sees other characters at the time of firing. This will absolutely result in clients getting direct hits with projectiles that the server sees as total misses, therefor they deal zero damage and frustrate players to no end. To truly have lag compensation, one would need to record player positions for a set duration, then have logic in place to check for hits based on where they were as opposed to where they are now. That, or have logic in place for when a client gets a direct hit with a dummy projectile that will have the server check if the player was at that position 4*ping milliseconds ago (must account for one-way latency to hit the RPC, PLUS one-way latency prior to the point of hitting the RPC). The latter would be far more light on the server.
I’m no expert on this topic, so take my findings with a grain of salt.