[q2x] cmds

[Brian Hook]

> commands (I.e. Cmd_AddCommand() is not used). I assume this is to
> stop the cmd space being polluted with game commands and/or because
> they have a different calling mechanism (with ents).

I'm not sure, I haven't delved too far into that end of things.

> So the problem I have now is how to go about the game/server side.
> I think this should probably have its own Lua state to be separated
> from the client(s). The cvar system doesn't seem to be separated,
> they all seem to use the same cvars (when run on same machine). I
> assume these values must be broadcast between the server and
> clients, and when we have a single player machine they all just use
> the same cvar space. So, since I don't fully understand how this
> works, this may well break when tested on multiple machines.

I don't believe that the server and client broadcast cvars to each 
other.  The reason for this is that they don't need to know about this 
stuff, so a dedicated server will never use/see cl_, cg_, vid_, etc. 
and a client will never use/see sv_*.

> confused where this is, as there is a clgame, which seems to be

clgame is basically a stub.  Eventually it will be its own DLL/Lua 
scripts, but right now it's just hard linked.  It only exists to make 
sure I remember it =)

> * The client side has its own Lua state.

Yes, except that instead of thinking in terms of "client" and 
"server", you should probably think in terms of "executable".  There 
is only a single binary that is run whether you're a client or server 
(discounting dedicated servers, which are just an 
optimization/special-case), and that binary is the one that contains 
Lua state.

If the binary is a client, it has client state.  If it's a server, it 
has server state.  If it's both, well, it has both.

> * Game and server share a Lua state.

Yes.

> * Necessary cvars are communicated between the two states (using
> existing system?)

As I stated earlier, I don't _think_ that they actually communicate 
cvars, ever.  The two communicate primarily through the standard 
packet mechanism or the "strings" interface.

> * Game/server side contains all the game logic and client side is
> much simpler.

Yes.

> Brian: I'm back off to the UK for 3 weeks tomorrow so I very much

Enjoy!

> doubt that I'll have time to do the server side before I go. 

No rush.

My feeling right now is that you should probably get it to a point 
where you think it's working and functional.  At that point, screw it, 
we commit it to CVS and see what dies =) You may want to make sure at 
least basic multiplayer still works.

> work is done). My idea was to get the config, bindings and command
> line stuff working with Lua "externally" (which it is) and then go
> back and convert the internals to Lua (which is mostly donkey work
> changing getarg(N) over to lua_tostring(L, -N)).

Sounds like a plan.

Brian