NSKuber

RPCs 101

Aug 1st, 2019
92
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 4.75 KB | None | 0 0
  1. How scripts work in general:
  2.  
  3. Script code is executed on each machine independently. If it is a world script (script entity) with "Auto run" set to "On host", then the script will run only on the host machine. If "Auto run" is set to "Always", or the script is a custom world script rather than a script entity, then it will run on every machine who starts the level. Note that world scripts (script entities) start only after "Waiting for everyone ready" period ends, if the gamemode has such period.
  4.  
  5. Scripts can interact with entities, which can either be obtained by linking in the case of script entity, or using worldInfo entity and different functions which return entities.
  6.  
  7. Entities can be synced or not synced (local). Some examples:
  8.  
  9. E.g., enemy puppet is a synced entity owned by the host. This means that most of the functions which somehow modify the puppet (apply damage to it, change its placement, etc) will only work on it when applied by the host, and these changes will also be synced to all clients (since the puppet itself is synced).
  10.  
  11. Player puppet is a synced entity owned by the host, but also a bit by the machine which is playing this player. This means, again, that inly host can actually use most modifying functions, but player can modify his own placement from his machine.
  12.  
  13. Static models which are placed on level are local, but some functions are synced, depending on which "scripting type" you set. This means that, after the start of a level, a client can e.g. delete a static model on his machine, but it will remain for all other players.
  14.  
  15. There are tons of other cases of what is synced and what is not and who can use which functions, but let's move onto the point.
  16.  
  17. Imagine that you (as a client machine) want to be granted some weapon. You cannot do this by yourself, because only the host has the power of using corresponding script functions. So you need to ask the host for it. That will be a "client" RPC (Remote Procedure Call).
  18.  
  19. Another example is, assume you are a host and you have a static model with "Local scripting", and you want to move this static model to another place on the level for everyone. If you do it just on your machine, it will move only on your level, but not on everyone else's, but you can send a "server" RPC to make everyone execute the code.
  20.  
  21. So here is how it goes: all machines which will use an RPC have to first create it. So it should be created either in a custom world script, or in a world script with "Auto run" set to "Always", preferably at the very start of the script. RPC creation goes as follows:
  22.  
  23. worldGlobals.CreateRPC(strType, strReliable, strRPCName, funcActualFunction)
  24.  
  25. So this is a global function with 4 arguments.
  26. First argument (strType) can be either "client", or "server". Explanation later.
  27. I'm not sure exactly what for the aecond argument (strReliable) is, but usually it's just "reliable".
  28. Third one (strRPCName) is a string name of the RPC. RPC will be called by this name later in the script.
  29. Fourth argument (funcActualFunction) is a function, containing the code which will be executed.
  30.  
  31. Now, let's explain "server" and "client".
  32. (1) If the RPC type is "server", then,
  33. (1.1) if the host calls this RPC, then the code in funcActualFunction will be executed on all machines on the server (on host and all clients).
  34. (1.2) if the client calls this RPC, then the code in funcActualFunction will be executed only on this client calling it (so just like a local function)
  35.  
  36. (2) If the RPC type is "client", then the code in funcActualFunction will be executed on (1) client calling the function and (2) on the host (which coincide in the case the host is calling the function, so it will be like calling a local function in that case).
  37.  
  38. Some examples:
  39.  
  40. worldGlobals.CreateRPC("server","reliable","SlowDownTimeEveryone", function(fFactor)
  41. worldGlobals.worldInfo:SetRealTimeFactor(fFactor,0)
  42. end)
  43.  
  44. worldGlobals.CreateRPC("client","reliable","PleaseSlowDownTime", function(fFactor)
  45. if worldGlobals.netIsHost then
  46. worldGlobals.SlowDownTimeEveryone(fFactor)
  47. end
  48. end)
  49.  
  50. Now there are two RPCs. If the host now calls
  51.  
  52. worldGlobals.SlowDownTimeEveryone(0.2)
  53.  
  54. Then the real-time factor will be set to 0.2 for everyone.
  55. If any client will call
  56.  
  57. worldGlobals.PleaseSlowDownTime(0.1)
  58.  
  59. Then this will be replicated on server, who in turn will call the first RPC again and slow down time for everyone.
  60.  
  61. Note that I used worldGlobals.worldInfo instead of just worldInfo.
  62.  
  63. RPCs don't have link to worldInfo, so you either have to use worldGlobals.worldInfo in their code, or assign
  64. local worldInfo = worldGlobals.worldInfo
  65. in the beginning of the script.
  66.  
  67. Another important note is that if you shouldn't use "server"-type RPCs in single-player, because they will stop working after loading a savegame.
Add Comment
Please, Sign In to add comment