Jump to content

Sending packets regularly


imadnsn

Recommended Posts

There are a few properties I wanted to synchronize between my server and client by sending packets from server whenever the properties change. The issue was that those properties changed every tick, so I made them change only twice a second which is the best pace I found for what I'm doing.

 

My question is, what is the rate of sending packets per seconds generally that should worry me when implemented? Taking in account for other packets being sent by the mod or other mods regularly.

Link to comment
Share on other sites

Maybe you could make it when the client needs the propertie, the server sends a packet to the client with that propertie, instead of synchronizing the all the time.

Don't PM me with questions. They will be ignored! Make a thread on the appropriate board for support.

 

1.12 -> 1.13 primer by williewillus.

 

1.7.10 and older versions of Minecraft are no longer supported due to it's age! Update to the latest version for support.

 

http://www.howoldisminecraft1710.today/

Link to comment
Share on other sites

That would be worse, because then I'd send two packets every few ticks when rendering Gui.

Also keeping it server-sided is better because I can use the data on different things update the data regularly instead of every time something needs it.

 

But that's not my problem anyway, all I want to know is how and when packet sending might make the game a bit laggy especially on multiplayer, so I can avoid overusing it whenever I can.

Link to comment
Share on other sites

Hi

 

It depends a lot on how big the packets are.  To give you some context, Vanilla queues up Chunk updates (which are quite large, up to 10k depending on compression) to send at no more than 5 per tick.

Over a LAN, you can easily send several MB per second with almost no delay and the system can easily keep up with it.  Over the internet it is much much slower, as little as 10k per second or less, and with variable arrival times of the packets by up to hundreds of milliseconds or more.

 

A much better solution is to code the client and server to run independently as much as possible.  The client predicts what is happening on the server and just adjusts it every now and again based on a synchronisation packet.  This works very well for moving objects, for example.  Depending on what your properties are, the client might be able to predict the updates very easily.

 

Another important thing to think about is whether you can tweak the game mechanics to make the rapid updates unnecessary.  Is the player really able to follow 20 property changes per second?  Could you add a delay or smoothing to the property change and make it a feature of your gameplay rather than a limitation?

 

-TGG

 

Link to comment
Share on other sites

Thanks for your post, well you've got what I was thinking.

I actually deliberately didn't send all the info I will need on the same packet, only the ones that change regularly, I'm planning to make different packets that send whenever values change.

 

A player level won't change every 10 ticks, and it wouldn't make sense to send them with the health or hunger, for instance.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.