hook_l at pyrogon.com
Mon Mar 3 18:28:55 EST 2003
>From a user's standpoint (as opposed to a coder's) I would welcome
>any change that would encourage mod-making, especially if they were
>cross-platform. However, this looks like it would be a huge project
>and potential major nightmare.
I think lack of portability and tools was one of the #1 reasons that
the Quake 2 mod scene didn't really kick off. Requiring a C compiler
was just too big a burden for most users, whereas Quake C "just
Lua supports compile-on-load, so you can reload the game without
shutting down the server. That's nice. Lua also has a strong
community of game developers and (finally) some decent documentation.
Lua5 Final should be out in March, and I think that will be the
version we target, once I figure out what they changed from 4.0.
Right now the entire game is loaded through a single library entry
point, GetGameAPI, which in turn exports a set of game functions.
As part of the short term plan, we keep ctf/ and game/ as is, and
then we fork a ctf_lua. Add Lua core files to that project, then
start from leaf and work back to the core game APIs until they're all
that's left in C (that and registered functions, obviously). Easy,
just tedious, but that's what theoddone33 is for =)
In the process of doing that we figure out which functions in
q_shared.c will have to be registered to Lua, and this will probably
give me an excuse for more anal retentive code cleanup =) (Come on,
like no one else cringes when they see "vectoangles()" and then
This is assuming my latest "patch" (I'm not sure it counts as a patch
when it's 700K uncompressed) is accepted. If it's not, then the
current stuff will get forked and hopefully i.o. will host it, and
things will get very quiet here again ;)
More information about the quake2