Is there any way I can affect the ping and packet loss rate in Godot 4.0.2?

Godot Version

4.0.2 stable


Hello, community! I’ve started developing a multiplayer game, and I’m using udp protocol (PacketPeerUDP, UDPServer) to transfer data between server (host) and clients. After implementing the synchronization, I noticed that the frequency of changing the position of other players is very small. I suspect that this is due to some packets being lost during sending. I tried to make it so that clients can immediately send data about themselves to other clients, but I have not been able to implement it… So my question is: Is there any way I can affect the ping and packet loss rate in Godot 4.0.2?

Here is my project: TT.rar - Google Drive

I hope someone can help me…

Not easily,

for dropin RPC you can randomly return before calling the RPC, for delay you could sleep thread or add a wait.

If using MultiplayerSynchronizer you can just increase the replication time. This will be like dropping packets.

There is also the possibility that could be natural jitter. One solution to that is to buffer states so you can manually time the state changes. Or maybe I’m missing understand the problem…

Look. I use the UDPPeerConection class to send data from the client to the server. On the server side I use UDPServer to receive this information, and send it to all other clients (so that other players can see each other). I don’t use MultiplayerSychronizer because it can only synchronize the same object, and I don’t need that… (If I explained it badly and you don’t quite understand what I mean, you can look at my project from inside, maybe then you will understand what I mean). I also tried implemented waiting for sending packets by using the timer node’s timeout signal, but this only made things worse… Anyway, during the course of the game itself other players change their location quite rarely… I’ve heard of interpolation and extrapolation, but I don’t know how to implement that in godot… I just need to remove these hiccups from other players so that their lags are not so noticeable.

Like I said you can buffer state packets. To interpolate and extrapolate you need at least two packet states to have a trajectory. You can also just only interpolate on the current position and the new position. No buffer required. To extrapolate you need two old states to calculate a forward trajectory if any.

RPC and MultiplayerSynchronizer work in the exact same fashion targeting node paths to find the RPC endpoint or sync node.

The UDPserver is just a connection protocol. It has nothing to do with how RPC and MultiplayerSynchronizers work.

I can’t unzip a rar on my phone, so I’ll assume you probably have a monolithic node that handles collecting all the data to sync from a single node?

This guy has a nice vid series on it.

1 Like

That’s so disapointing, about you cannot unzip that right now… Yes, you are right about the last statement.

And thank you for videos!

I probably could unzip on my computer, but I’m just not sitting next to it.

Early on in the video series he talks about clock synchronization. Which is important to decide to interpolate and extrapolate.

I don’t want to dog on your approach, I think that kind of monolithic control over the data can be beneficial. But there is a type of anti pattern happening here. Since you are trying to do what the network architecture is already doing.

If every node wants to signal to its remote counterpart you just need one RPC in every node to communicate some info. This data is collected by the Godot network infrastructure packed and encoded and sent to the client in a stream of packets. Then on the client side the stream is decoded unpacked and distributed to the node paths that they originated from.

With a monolithic approach you collected everything in a single node before making that exact same trip as before. Upside you can manipulate and pack the data before sending it out, without having to dig into the opaque network architecture that Godot provides. Downside is that your monolithic node will become harder to maintain the bigger it gets.

As far as I know there is no easy means to tinker with the default multiplayer api because its not documented well and you can only read so much source code. It’s supposed to be very customizable under the hood… Although I gave up trying to understand it for now.

A PacketPeer is just the class that physically sends the data.

Your UDPserver is just a helper class that creates a packetpeerUDP which is wrapped by the multiplayer api that marshalls RPC data to the packetpeer for transport.

It’s just that when I tried to send some information that was in a variable on the server via rpc message, when receiving this message, the client itself inserted its own variable into the message, so synchronization didn’t happen. That’s why I thought that the best solution in my case would be to use UDPServer…

So are you manually calling put_packet/put_var?

Anyways even if that is the case you just need to throttle sending the actual packet. There isn’t a silver bullet for this and will need to be a custom “hack” in any case. At least native to Godot, maybe a plugin exists.

I’d be curious to understand this more? This seems impossible unless you are not typecasting the function parameters or you mean a dictionary or array?

Fundamentals of networking is that there will be packet jitter, there will be dropped packets and they will come out of order. So write in defense of these things.

Yeah, I know it’s unavoidable. I just thought there was something I could do to minimize it. And yes, you’re right. I was initially trying to pass information through rpc functions… I feel so stupid after that.

Before you go tearing things down. Give this a read.

If you want to keep your efforts going this guy has some great articles on this subject. I think you could still make it work.

Thank you so much! You’ve made my day, man

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.