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