home *** CD-ROM | disk | FTP | other *** search
/ Magazyn Amiga 14 / MA_Cover_14.iso / source / c / q1source_amy / qw / client / docs.txt < prev    next >
Encoding:
Text File  |  1997-03-09  |  3.7 KB  |  119 lines
  1.  
  2. The QuakeWorld connection process:
  3. ---------------------------------
  4.  
  5. servercount
  6. Each time a server changes maps, it will bump the servercount variable.  The signon
  7. messages sent from the client to the server will include a servercount, and if the
  8. server detects that it has changed levels while the client is in the process of
  9. connecting, the client connection process will be restarted.
  10.  
  11. svc_skinlist
  12.  
  13. MAX_SIGNON_BUFFERS...
  14.  
  15. +attack;wait  : this both does the attack and prints a chat?
  16.  
  17. put frag counts in userinfo as *frags?
  18.  
  19. no forward to server commands unless active?
  20.  
  21. changelevel / reconnect confusion
  22.  
  23. syncing the fixangle over the reliable channel with the first update
  24.     option to put the update in the reliable message?
  25.  
  26.  
  27. --------------
  28. A "connect <server>" command is executed on the client.
  29.  
  30. CL_Connect_f() disconnects from the current server if connected, 
  31. sets the current server to the new value, and sends the first connection packet.
  32.  
  33. The connection packet will be resent by CL_CheckForResend() every two seconds until the server connects.
  34.  
  35. A connection packet is an out of band packet containing "connect <userinfo>" with userinfo quoted.
  36.  
  37. --------------
  38.  
  39. The server receives the OOB message in SVC_DirectConnect()
  40.  
  41. It can respond with an OOB client print of "banned" or "server is full" if the client
  42. cannot enter the game.
  43.  
  44. If the client can get in, the server will initialize a new client_t structure with a
  45. netchan_t, and respond with an OOB message containing S2C_CONNECTION.  Further
  46. communication will be through sequenced netchan_t messages instead of OOB messages.
  47.  
  48. The client_t->state is set to cs_connected
  49.  
  50. --------------
  51.  
  52. if S2C_CONNECTION packet is dropped, the connect message will be resent after two
  53. seconds and the server will recognize the address and reuse the allocated client_t FIXME:bug?)            
  54.  
  55. When the client receives the S2C_CONNECTION, it initializes cls.netchan and sends
  56. a "new" string command over the netchan to the server.
  57.  
  58. cls.state is set to ca_connected    FIXME: change to cs_connected?
  59.  
  60. --------------
  61.  
  62. The "new" usercommand on the server is issued by the client every time they enter a level,
  63. which is why none of the information is sent in the initial S2C_CONNECTION message. 
  64.  
  65. "new" sends over 
  66.  
  67. Before the client can begin playing in the server, the following information must be sent:
  68.  
  69. gamedir
  70. svc_serverinfo
  71.     PROTOCOL_VERSION
  72.     servercount        // for detecting when the server
  73.     gamedir            // for deciding the add-on directory (qw, ctf, etc)
  74.     playernumber    // the client will allways be in this slot
  75.     the qc string of world.message    // usually the level's full verbose name
  76. cdtrack
  77. fullserverinfo
  78.  
  79. when received, the client changes state to ca_onserver.  When the client receives
  80. all the information needed to render a frame, the state will be changed to ca_active
  81.  
  82. .....
  83.  
  84. svc_soundlist
  85.  
  86. .....
  87.  
  88. svc_modellist
  89.  
  90. .....
  91.  
  92. prespawn passes the contents of the sv.signon_buffers, which hold
  93. static entity spawning, static sound spawning, and all the entity baselines
  94. FIXME: don't need to pass all baselines, uninitialized probs?
  95.  
  96. .....
  97.  
  98. "spawn" sends all dynamically changing state (fullclient updates, lightmaps, frags)
  99. and ma
  100.  
  101. FIXME: 32 clients could be up to 16k in updates, which overflows the 8k packet size
  102.  
  103. FIXME: there is an updating hole between the sending of spawn data and the client
  104. being notified 
  105.  
  106.  
  107. "begin"
  108.  
  109. Actually spawns the client into the world as a visible entity.
  110.  
  111. The client_t->state is set to cs_spawned, so normal datagram updates begin
  112.  
  113. -----------------------
  114.  
  115. When the first valid packetentities_t arrives at the client, cls.state is set
  116. to ca_active, and rendering can begin.
  117.  
  118. FIXME: make sure player and packets are both valid
  119.