High-level networking: Add docs on get_rpc_sender_id()

tutorials/networking/high_level_multiplayer.rst

@@ -148,7 +148,7 @@ Generally, an autoloaded node/singleton is a great fit for this, to always have
 RPC
 ---
 
-To communicate between peers, the easiest way is to use RPC (remote procedure call). This is implemented as a set of functions
+To communicate between peers, the easiest way is to use RPCs (remote procedure calls). This is implemented as a set of functions
 in :ref:`Node <class_Node>`:
 
 - `rpc("function_name", <optional_args>)`
@@ -171,6 +171,8 @@ Functions can be called in two fashions:
 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).
 
+There is also the `get_rpc_sender_id` function in `SceneTree` which can be used to check which peer (or peer ID) sent a RPC call.
+
 Back to lobby
 -------------
 
@@ -247,6 +249,7 @@ The `remote` keyword means that the `rpc()` call will go via network and execute
 The `sync` keyword means that the `rpc()` call will go via network and execute remotely, but will also execute locally (do a normal function call).
 
 The others will be explained further down.
+Note that you could also use the `get_rpc_sender_id` function on `SceneTree` to check which peer actually made the RPC call to `register_player`.
 
 With this, lobby management should be more or less explained. Once you have your game going you will most likely want to add some
 extra security to make sure clients don't do anything funny (just validate the info they send from time to time, or before