I cant watch the video due to poor connection here but I can tell you that hit result is not likely to go across the RPC. Connecting the wires doesn’t guarantee that it arrives, especially not when it is trying to be used out of the scope of even the same machine it was generated from. Likely it will come up invalid or nonexistent at the destination machine. You CAN pass it through the RPC nodes though.
EDIT: For some reason people are still finding this, so for those, heres a fun fact. Its not a movement issue, its just lagging. Theres too many projectiles to replicate, so your router blows up. Use a linetrace, it least for rapid fire, its much better for MP performance.
Video:
Image from video:
Spawn projectile Run on Server → Multicast script… thing (idk what blueprint “code” is called):
Are you talking about the uh… BP “code” (still don’t know what tha’ts called) in the projectile’s BP? Because to be honest I can’t quite tell what youre talking about- omg I’ve just had an idea one sec
Nope, didn’t work. Anywho moving on, I don’t really get what you’re talking about, sorry.
(The video’s there for a reason, (I can’t describe the issue) so watch it when you can, if you feel like helping lol)
Okay I’m at a better connection now. That is a very very good explanation video.
You may need to run some network diagnostics like the Net Stat console command to find out what exactly is causing the lag. It could be too many reliable Multicasts in rapid succession.
You can eliminate some of those by removing all the nodes in your screenshot (you can probably do whatever they’re doing without sending anything across network, because if you destroy a replicated actor on the server, then it gets destroyed on all Clients without using RPC nodes).
RPC nodes are Remote Procedure Calls. They are the ones where you set them to Run On Server, Run on Client, or Multicast.
I suspect due to the rapid fire nature of the weapon that you might be saturating the network with excessive RPCs due to using reliable multicasts where they aren’t needed. But I can’t be sure.
After removing the nodes shown in your screenshot, look into your Blueprint code/graphs for the weapon or character that spawns the bullets. Show how that one operates, as I think the problem might be about that rather than the bullets themselves (especially if you remove the nodes shown in the screenshot)
Without looking at the full code, I can probably say that you need to ensure fully that the client is sending a request via RPC to the server to spawn the bullet. On the server, ensure it has authority, then spawn it. I didn’t see that in the bit of code above.
That being said, you don’t “need” to actually spawn a bullet to track on the client 100%. They don’t need to be synced visually. If you have the server handle the logic of collision, the client use dead reckoning to estimate positions to make it look synced.
I agree. Let the client trust its own version of the bullet, spawning it separate from the server version by using Authority switch. And spawn one on the Server too, just only count hits from the Server version.
The trick then becomes how do we make sure everyone except the server and the instigating Client sees another replication of the bullet?
In my multiplayer game I have a relatively small number of bullets coming from each player, and I don’t allow strafing in the vehicles that are doing the shooting, so I haven’t had to deal with rapid fire bullet problems.
Alternatively, you could use line traces for the actual hits and spawn the bullets just for show, but that only partially solves the problem.
I am mostly interested in what could be causing the lag. There must be a tutorial or something out there on how to handle rapid fire weapons over network. How does Unreal 1 handle the Stinger weapon for example? Or Unreal Tournament handle the Link Gun’s projectile mode?
Dead reckoning does it for you - most network games use the technique to simulate smooth motion. You can tell right away when a game de-syncs or lags, you get the rubber band effect.
I should have explained it better. The basic process is:
Client pushes shoot button. This command is sent to the server, guarantee delivery if you want. At this point, the client can spawn an object to illustrate immediate feedback, but this object is only on the client and may be short lived depending on how you spawn.
The server receives the command and processes it. If you have bullets that need to be spawned and move through your world, the server now performs this action. If it were me, I would only “spawn” the data for the bullet: position, directions, etc. and sent that to the clients, letting the clients spawn local objects that are only tracking positional information. This will help with smoothing motion.
The clients received the spawn bullet command and do so.
At this point, a bullet is shot. Now it’s up to the server to maintain the logic of the bullet - for example, move it, did it hit something, etc. Clients never need to worry about this, unless you want to predetermine what is happening on the client prior to receiving the command from the server.
Now, clients, to keep things smooth, use dead reckoning to move the object. Since you know the last know valid position of a bullet from the server (which can send periodic updates of positioning), and you know the direction the bullet was traveling, you can determine the most current position of the bullet and move it there on the client machine. This is not the object the server spawned - its the client version of the object that you are moving. If you spawn an actor on the server, then let the replication system move the object, otherwise you get jitter and rubber banding.
To smooth it more, between updates to positions received from the server, you interpolate based on fps, network packet speed, etc.
1 Like
Some people say that for rapid fire, it’s best to only send the server a start shooting signal and a stop shooting signal, and let the server do all the shooting of bullets that actually count, and let the clients receive the start and stop shooting signals as well and do their own shooting of fake bullets just for show.
is there a tutorial on how to do this?
I think I saw some but I don’t have any links handy at the moment. Let us all know if you found a good one!
PSA to any future readers. You Do Not Replicate Projectiles.
First off you should be working with Object Pooling for projectiles. Very easy to do in BP.
You need 3 projectile classes.
One for each proxy (Autonomous [client], Simulated, Authority [server])
Clients projectile is setup to only do impact fx on hit.
Component setup is as follows.
Mesh here has no collision. It’s used for visual effect like a tracer.
Hit FX are handled by the Bullet Pool actor component.
On hit he pass hit data to a function in the pool, then send the projectile back to the pool.
Client projectiles and shooting in general is 100% responsive and FX based.
Server projectile
This projectile only ever lives on the server. It handles damage.
It’s On Hit event is identical to clients in the way that we are calling Projectile Hit Manager in the bullet pool, yet the servers pool functions are overwritten with specific processing.
On the client/sim it just does decals, squibs, sound. On the server it calcs and applies damage. No FX are done.
Sim Projectiles
These have an audio component to allow for flyby audio. For when a projectile is close enough you can hear it whizz.
It calls back to the same bullet pool class as clients do so it has the same logic. Just decals etc.
Servers…
End of day the server is only broadcasting 2 vectors to sims in a multicast.
Muzzle location, projectile velocity
With these 2 vectors sims can request a projectile from its pool, tell it where to teleport to and what velocity to apply to the projectile.
Client fires local only shot, then RPC server to shoot
Server shoots using its own calculated values. Then Multicasts two vectors to Sims.
Sims use those vectors to shoot in their simulation (other players screens).
2 Likes