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.
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?