Ver código fonte

Attempt to clarify reliable vs unreliable RPCs

David Snopek 3 anos atrás
pai
commit
999cf71bf9
1 arquivos alterados com 2 adições e 2 exclusões
  1. 2 2
      tutorials/networking/high_level_multiplayer.rst

+ 2 - 2
tutorials/networking/high_level_multiplayer.rst

@@ -172,8 +172,8 @@ Synchronizing member variables is also possible:
 
 Functions can be called in two fashions:
 
-- Reliable: the function call will arrive no matter what, but may take longer because it will be re-transmitted in case of failure.
-- Unreliable: if the function call does not arrive, it will not be re-transmitted; but if it arrives, it will do it quickly.
+- Reliable: when the function call arrives, an acknowledgement will be sent back; if the acknowledgement isn't received after a certain amount of time, the function call will be re-transmitted.
+- Unreliable: the function call is sent only once, without checking to see if it arrived or not, but also without any extra overhead.
 
 In most cases, reliable is desired. Unreliable is mostly useful when synchronizing object positions (sync must happen constantly,
 and if a packet is lost, it's not that bad because a new one will eventually arrive and it would likely be outdated because the object moved further in the meantime, even if it was resent reliably).