I'll check the setup cmd in the cvs. I had to advance VERSION_CS from 1022 to 1023. Every server which sends now VERSION_CS >= 1023 back, can handle the setup cmd in future. The form is: setup <cmd1> <paramter1> <cmd2> <parameter2> <cmd3> .... At this stage, the setup cmd has only one regular cmd: cmd parameter --------------------------------------------------------------- sound 0 / 1 So, we can set with this cmd only sound on/off like with the setsound cmd. (in future then we can rip off the setsound cmd). So, a valid setup cmd looks like setup sound 1 The server then will collect the cmds and send the status back to client. The client recieve from upper setup cmd, a "setup sound 1" back. If the server can't send sound commands (in fact he will EVER do it yet, but perhaps we code a version which can't), he sends a "setup sound 0" back to the client. This shows the client, that the server has got the cmd right, but this is, what the server has set it. Means, the set to 1 has failed. Also, you can send this to the server: setup sound 1 bla 22 foo 4 Then the server will send back to client: setup sound 1 bla FALSE foo FALSE This will show the client, the server knows and set the sound cmd like expected, but bla and foo are unknown to him. Well, then the client can decide what it want to do. The setup cmd use a list for settings, so its easy to include cmds.