From nick at rockstarvancouver.com Tue Dec 9 20:20:21 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 9 Dec 2003 17:20:21 -0800 Subject: [q2x] Refactorization Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FBF9@iggy.rockstarvancouver.com> > > Great. I'll try and build that sometime soon. > > Cool, let me know how it goes. Okay I got latest on Sunday and rebuilt but I'm still getting a load of errors trying to play the Q2 demo. I managed to get past the incorrect server version problem by avoiding the recorded demo but then I still get bad tga errors. I'm trying with command line args (from memory :/): +gamedir +set developer 1 +gamemap base If you wanted to play the demo with this code base what command line args would you use please? Perhaps it's just my ignorance? Nick From hook_l at pyrogon.com Tue Dec 9 20:24:08 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Tue, 9 Dec 2003 20:24:08 -0500 Subject: [q2x] Refactorization In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FBF9@iggy.rockstarvancouver.com> Message-ID: <200312920248.176025@centrino> > +gamedir +set developer 1 +gamemap base +set gamedir +set developer 1 +map base > If you wanted to play the demo with this code base what command > line args would you use please? Hmmm, not sure, I haven't tried it with the demo in, er, forever. You don't have the full version lying about I assume? Brian From nick at rockstarvancouver.com Tue Dec 9 20:28:41 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 9 Dec 2003 17:28:41 -0800 Subject: [q2x] Refactorization Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FBFA@iggy.rockstarvancouver.com> > From: Brian Hook [mailto:hook_l at pyrogon.com] > Sent: Tuesday, December 09, 2003 5:24 PM > To: q2x at icculus.org > Subject: RE: [q2x] Refactorization > > > +gamedir +set developer 1 +gamemap base > > +set gamedir +set developer 1 +map base I tried that as well but no luck. At least I'm not miles off. :) > > If you wanted to play the demo with this code base what command > > line args would you use please? > > Hmmm, not sure, I haven't tried it with the demo in, er, forever. You > don't have the full version lying about I assume? Yep. I had a look in a couple of shops recently buts it's not stocked anymore. I think I had the CD at some point but I leant/gave all my CDs to friends when I left the UK. Mmm it could well have been amongst those. Also, I look at the retexturing project. There doesn't seem to be a complete pak file you can download, it's individual textures. This seems a bit like hard work, did I miss something? Nick From nick at rockstarvancouver.com Tue Dec 9 20:32:48 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 9 Dec 2003 17:32:48 -0800 Subject: [q2x] Refactorization Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B22@iggy.rockstarvancouver.com> > Yep. I had a look in a couple of shops recently buts it's not stocked > anymore. I think I had the CD at some point but I leant/gave all my CDs > to friends when I left the UK. Mmm it could well have been amongst > those. To ask another question: are there any known working distributions of Q2 maps that are entirely separate from Q2 resources? > Also, I look at the retexturing project. There doesn't seem to be a > complete pak file you can download, it's individual textures. This seems > a bit like hard work, did I miss something? I take it Q1 textures and pak files can't be used with Q2? :- http://www.quake.cz/winclan/qe1/ Nick From hook_l at pyrogon.com Tue Dec 9 20:39:42 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Tue, 9 Dec 2003 20:39:42 -0500 Subject: [q2x] Refactorization In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B22@iggy.rockstarvancouver.com> Message-ID: <2003129203942.381041@centrino> > To ask another question: are there any known working distributions > of Q2 maps that are entirely separate from Q2 resources? No idea, but doubtful. > I take it Q1 textures and pak files can't be used with Q2? :- That's my recollection. Brian From nick at rockstarvancouver.com Wed Dec 10 14:24:36 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 11:24:36 -0800 Subject: Plan of attack Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FBFF@iggy.rockstarvancouver.com> Brian, how complete are your changes now? Do you still have big structural changes to make? Can I start hacking away at the Lua stuff? I noticed yesterday some q2x files. What are these? My initial thoughts for Lua conversion are: * Add a global Lua state somewhere - where do you think is the best place? * Try converting a single monster, e.g. "light guard" (m_solder.c?) over to Lua. Probably need to... * Create table ("class instance") for each monster with a tables for sound, animation sequences etc. * Config files create monster instance and appropriate data in monster tables. * AI state based so can keep current update as in self->monsterinfo.currentmove. * First get m_*.c files querying Lua state for animation and sound data, then wrap calls and move everything into Lua. i.e. make Lua API for entity database etc. Nick From hook_l at pyrogon.com Wed Dec 10 14:42:13 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 10 Dec 2003 14:42:13 -0500 Subject: [q2x] Plan of attack In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FBFF@iggy.rockstarvancouver.com> Message-ID: <20031210144213.747313@centrino> > Brian, how complete are your changes now? Well, it's in a somewhat stable state -- knock yourself out =) > Do you still have big > structural changes to make? yeah, but we probably shouldn't wait for those... > I noticed yesterday some q2x files. What are these? Specifically which ones? > * Add a global Lua state somewhere - where do you think is the best > place? Maybe the easiest first step would be to switch to Lua for the console variables? That's supereasy, and gets you used to the overall structure, and gets Lua in place. As for the global Lua state, there should probably be one for the client and another for the server, at least for cvars...I'm not 100% sure, I'll have to think about it some more. Brian From nick at rockstarvancouver.com Wed Dec 10 14:54:37 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 11:54:37 -0800 Subject: [q2x] Plan of attack Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC00@iggy.rockstarvancouver.com> > > Brian, how complete are your changes now? > > Well, it's in a somewhat stable state -- knock yourself out =) Ok. I'll send you periodic src zips and you can merge them :) > > I noticed yesterday some q2x files. What are these? > > Specifically which ones? .q2x :) When it looks for available .pak files. > > * Add a global Lua state somewhere - where do you think is the best > > place? > > Maybe the easiest first step would be to switch to Lua for the console > variables? That's supereasy, and gets you used to the overall > structure, and gets Lua in place. Ok. > As for the global Lua state, there should probably be one for the > client and another for the server, at least for cvars...I'm not 100% > sure, I'll have to think about it some more. Won't all this be in qcommon so there'll only be one but it'll be instanced twice? -- more reading to do! Nick From hook_l at pyrogon.com Wed Dec 10 15:12:48 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 10 Dec 2003 15:12:48 -0500 Subject: [q2x] Plan of attack In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC00@iggy.rockstarvancouver.com> Message-ID: <20031210151248.875491@centrino> > Ok. I'll send you periodic src zips and you can merge them :) Ummm...let's hold off on that. Once you get something up and running and stable, we can talk =) > .q2x :) When it looks for available .pak files. Oh, right...Q2X is a .ZIP file intended to get rid of PAK files eventually. > Won't all this be in qcommon so there'll only be one but it'll be > instanced twice? -- more reading to do! Yes, that seems reasonable, but Lua may be used for different things and I'm not sure how comingling there should be. On the server, it will implement the game and cvars. On the client, it will implement client presentation and cvars. For "common" stuff, it will implement cvars. Brian From nick at rockstarvancouver.com Wed Dec 10 15:23:20 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 12:23:20 -0800 Subject: [q2x] Plan of attack Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B2F@iggy.rockstarvancouver.com> > > Ok. I'll send you periodic src zips and you can merge them :) > > Ummm...let's hold off on that. Once you get something up and running > and stable, we can talk =) Aha, the experienced open source project manager at work! > > .q2x :) When it looks for available .pak files. > > Oh, right...Q2X is a .ZIP file intended to get rid of PAK files > eventually. Right. > > Won't all this be in qcommon so there'll only be one but it'll be > > instanced twice? -- more reading to do! > > Yes, that seems reasonable, but Lua may be used for different things > and I'm not sure how comingling there should be. I was thinking cvars would be in a separate state to the game objects. Cvars are q2x config and not related to gameplay (?) Of course they could all go in the same state and we can namespace them. > On the server, it will implement the game and cvars. > On the client, it will implement client presentation and cvars. What do you mean by presentation? > For "common" stuff, it will implement cvars. Nick From hook_l at pyrogon.com Wed Dec 10 15:50:22 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 10 Dec 2003 15:50:22 -0500 Subject: [q2x] Plan of attack In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B2F@iggy.rockstarvancouver.com> Message-ID: <20031210155022.453712@centrino> > Aha, the experienced open source project manager at work! Hardly. What will probably happen is that I'll be too lazy to do the work and I'll ask icculus to give you cvs write access =) > I was thinking cvars would be in a separate state to the game > objects. Cvars are q2x config and not related to gameplay (?) Of > course they could all go in the same state and we can namespace > them. This won't work, because the subsystems may want to access cvars for debugging/testing and just to generally query about the state of things. If you look at the cvars that Q2 uses, they're pretty much a catch all that covers EVERYTHING. > What do you mean by presentation? Right now the user interface, for example, is hardcoded into the client. In Quake 3 this was solved by adding the "cgame" (client game) portion, so the game was broken down into a pure (game agnostic) client, a client side game portion (that knows to present game specific server data that the client has received), a pure server, and a game specific server portion. Brian From nick at rockstarvancouver.com Wed Dec 10 16:08:49 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 13:08:49 -0800 Subject: [q2x] Plan of attack Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC02@iggy.rockstarvancouver.com> > > Aha, the experienced open source project manager at work! > > Hardly. What will probably happen is that I'll be too lazy to do the > work and I'll ask icculus to give you cvs write access =) First Q2X, and then the World!!! > > I was thinking cvars would be in a separate state to the game > > objects. Cvars are q2x config and not related to gameplay (?) Of > > course they could all go in the same state and we can namespace > > them. > > This won't work, because the subsystems may want to access cvars for > debugging/testing and just to generally query about the state of > things. If you look at the cvars that Q2 uses, they're pretty much a > catch all that covers EVERYTHING. Ok, cvars just go in a table in game Lua state with everything else. So... what about command format? Should the .cfg files be changed into Lua files? Should: set var value become: var = value or cvars.var = value or set(var,value) Of course they can stay the way they are and just the guts change. It would seem a bit odd to have 2 scripting languages in the game though. > > What do you mean by presentation? > Right now the user interface, for example, is hardcoded into the > client. In Quake 3 this was solved by adding the "cgame" (client > game) portion, so the game was broken down into a pure (game agnostic) > client, a client side game portion (that knows to present game > specific server data that the client has received), a pure server, and > a game specific server portion. I'll have a look at this and we'll discuss this at a later date. Do you mean we should have a widget system etc? Nick From hook_l at pyrogon.com Wed Dec 10 16:33:29 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 10 Dec 2003 16:33:29 -0500 Subject: [q2x] Plan of attack In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC02@iggy.rockstarvancouver.com> Message-ID: <20031210163329.041755@centrino> > Ok, cvars just go in a table in game Lua state with everything else. Right. > So... what about command format? Should the .cfg files be changed > into Lua files? Should: New file extension, like .cfglua or something, and I'm happy just making it a directly executable Lua statement inside of a cvars table. > It would seem a bit odd to have 2 scripting languages in the game > though. The goal is just a single scripting language. > I'll have a look at this and we'll discuss this at a later date. Do > you mean we should have a widget system etc? Well, that's a by-product -- eventually, yes, a widget system of some sort would be nice, but the important thing is making sure that the game presentation is not hardcoded into the client directly. Brian From nick at rockstarvancouver.com Wed Dec 10 17:26:59 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 14:26:59 -0800 Subject: Editor Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC03@iggy.rockstarvancouver.com> What level editors do people use? Brian, do you have any thoughts? I take it you like Radiant? I used to quite like Quark. I guess at some point it would nice to be able to have an IDE with Lua editing and possibly debugging etc. Nick From hook_l at pyrogon.com Wed Dec 10 17:32:49 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Wed, 10 Dec 2003 17:32:49 -0500 Subject: [q2x] Editor In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC03@iggy.rockstarvancouver.com> Message-ID: <20031210173249.078973@centrino> > Brian, do you have any thoughts? I take it you like Radiant? I used > to quite like Quark. I like Radiant, but I'm not a level designer, so my opinion carries no weight. > I guess at some point it would nice to be able to have an IDE with > Lua editing and possibly debugging etc. Uh...one step at a time my anxious friend =) Brian From nick at rockstarvancouver.com Wed Dec 10 17:40:06 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Wed, 10 Dec 2003 14:40:06 -0800 Subject: [q2x] Editor Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC04@iggy.rockstarvancouver.com> > > I guess at some point it would nice to be able to have an IDE with > > Lua editing and possibly debugging etc. > > Uh...one step at a time my anxious friend =) But we're practically there, I have the game... compiling! I'd like to knock up a couple of simple test levels, when I get round to the server bit, so I wondered what was the easiest level editor to do this with. But then I just had to take the leap didn't I! :) I know how much work editors can be as I've done a fair few tools in the past. I have very little spare time so I wouldn't take the decision to start on something like that lightly. Nick From nick at rockstarvancouver.com Mon Dec 15 19:02:47 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Mon, 15 Dec 2003 16:02:47 -0800 Subject: cvars Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC1A@iggy.rockstarvancouver.com> Started work, did quite a lot at weekend (Had a power cut at home for 36 hours, which was nice). You weren't joking when you said everything uses cvars were you? :) Had to add q_common.h to q_local.h because cvars are used in AI but cvar API not seen. Is this bad? I'll let you know when it's all working. Nick From hook_l at pyrogon.com Mon Dec 15 19:45:03 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Mon, 15 Dec 2003 19:45:03 -0500 Subject: [q2x] cvars In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC1A@iggy.rockstarvancouver.com> Message-ID: <2003121519453.295176@centrino> > Had to add q_common.h to q_local.h because cvars are used in AI but > cvar API not seen. Is this bad? That should be okay. Brian From nick at rockstarvancouver.com Tue Dec 16 14:14:04 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 16 Dec 2003 11:14:04 -0800 Subject: [q2x] cvars Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B6B@iggy.rockstarvancouver.com> > > Had to add q_common.h to q_local.h because cvars are used in AI but > > cvar API not seen. Is this bad? > > That should be okay. As it turned out it wasn't! :) The DLLs are dynamically linked so I added a few more functions to the interface: still learning. I think this conversion would be easier if the project were C++ but what the hey. Nick From hook_l at pyrogon.com Tue Dec 16 14:20:11 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Tue, 16 Dec 2003 14:20:11 -0500 Subject: [q2x] cvars In-Reply-To: <911F8C8EB7A8084AAEDD55CEDC54D8F84B0B6B@iggy.rockstarvancouver.com> Message-ID: <20031216142011.789453@centrino> > think this conversion would be easier if the project were C++ but > what the hey. Dude, let's not even go there. Brian From nick at rockstarvancouver.com Tue Dec 16 15:44:02 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 16 Dec 2003 12:44:02 -0800 Subject: [q2x] cvars Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC1D@iggy.rockstarvancouver.com> > > think this conversion would be easier if the project were C++ but > > what the hey. > > Dude, let's not even go there. Way! Will be doing more work next few days as I have some time coming up. Nearly finished the GL DLL conversion and then will be onto the scary task of debugging it. Hey, maybe it will just _work_ :-D Currently there is just one Lua state which everything looks at. I'm gradually getting an idea for how everything works but haven't quite got my head around how the client/server thing works with cvars yet. I assume values must get transmitted through the coms stuff between client and server for remote/dedicated games. Not quite sure what happens if server is your localhost. I.e. are there 2 "game instances" running, client and server, or are they just one? There only seems to be one cvar set though. Nick From nick at rockstarvancouver.com Tue Dec 16 17:06:31 2003 From: nick at rockstarvancouver.com (Nick Trout) Date: Tue, 16 Dec 2003 14:06:31 -0800 Subject: [q2x] cvars Message-ID: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC22@iggy.rockstarvancouver.com> > Will be doing more work next few days as I have some time coming up. > Nearly finished the GL DLL conversion and then will be onto the scary > task of debugging it. Hey, maybe it will just _work_ :-D I've put an API to alter the cvar structure, so the whole cvar structure is private. My initial idea, was that cvar seems like an obvious thing to store in Lua, but it could be stored either side. This could be done either way now with little effort: cvars stored in C with Lua API exposed, or cvars stored in Lua with Lua C API from C to game. How do you see this project going Brian? Performance allowing, as much as possible into Lua, leaving a skeleton q2x framework? I know in one of your posts you mentioned that in order to do a "proper" game engine work over it would mean altering the client and server, as well as the game DLL. I suppose the idea is stripping the framework right down to a few bare libraries wrapping the coms, graphics, i/o etc and do everything in Lua? I'm interested because it might affect my decisions. I hope this isn't a repeated question. Thanks, Nick From nicktrout at shaw.ca Thu Dec 18 23:16:23 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Thu, 18 Dec 2003 20:16:23 -0800 Subject: [q2x] cvars References: <911F8C8EB7A8084AAEDD55CEDC54D8F851FC22@iggy.rockstarvancouver.com> Message-ID: <005301c3c5e6$dce067f0$6400a8c0@quith1> Okay, Lua cvars are working with q2x now. Game seems to play okay and you can load other levels and use gamemap. Bit messy at the moment (but only in q_cvars.c) as I had to get the old system working in parallel with the new one to debug it. There is a single #define which turns this feature on and off. I'm leaving all the old code in, either #define or commented out until the system is all working. Might starting converting over all the commands to use Lua functions now. Nick From hook_l at pyrogon.com Thu Dec 18 23:24:45 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Thu, 18 Dec 2003 23:24:45 -0500 Subject: [q2x] cvars In-Reply-To: <005301c3c5e6$dce067f0$6400a8c0@quith1> Message-ID: <20031218232445.175594@GATEWAY> What I was going to say about cvars before was that the main exe, be it client or server, is responsible for managing the cvars in use by any subsystems, like the renderer or game logic. This is what that ri.cvar_get() stuff is all about. Good job on the transition, let me know when it's done =) You're using Lua 5 I assume? Brian From nicktrout at shaw.ca Thu Dec 18 23:40:25 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Thu, 18 Dec 2003 20:40:25 -0800 Subject: [q2x] cvars References: <20031218232445.175594@GATEWAY> Message-ID: <007b01c3c5ea$387c1160$6400a8c0@quith1> > What I was going to say about cvars before was that the main exe, be it client or server, is responsible for managing the cvars in use by any subsystems, like the renderer or game logic. This is what that ri.cvar_get() stuff is all about. Ah yes, I figured that out. I assumed it was all statically linked initially because the DLLs point to cvars in the main exe, but of course it's not, there is an export mechanism (which I added a few more functions to). This is part of the slight untidyness. Instead of cvar_t pointers I'm using references to Lua tables. Some functions use strings to get cvar values and some use references, ie. Cvar_VariableValue("my_cvar") vs. my_cvar->value. I made all of cvar_t private (so just about every file in the project has been touched) so my_cvar->value is now Cvar_GetValue(my_cvar) (where my_cvar is a Lua reference). Using references like this should be slightly faster than using strings to access vars but it would be nice to have a more homogenous interface, i.e. everything uses strings or everything uses references. I don't know if it's worth tidying this up right now as significant other portions of code may change. > Good job on the transition, let me know when it's done =) Righto. I'm off on holiday for 3 weeks on monday so I'll try and get as much done before then. No laptop I'm afraid. > You're using Lua 5 I assume? Yip. Nick From nicktrout at shaw.ca Sun Dec 21 17:31:35 2003 From: nicktrout at shaw.ca (Nick Trout) Date: Sun, 21 Dec 2003 14:31:35 -0800 Subject: cmds Message-ID: <000701c3c812$31885290$6400a8c0@quith1> I have client side working with Lua syntax functions instead of commands. It's current a hybrid system which is emulating the argc/argv argument system that was there previously. I create a Lua closure which redirects function calls to a cmd.dispatch function which takes the variable args table and pokes it back into the argument system and calls the unchanged (*_f) function: function cmd.add(name, fn) -- check not a variable if cvar.values[name] then com.print(string.format("cmd.add: %s already defined as a var\n", name)) return end -- check not exists already if _G[name] then com.print(string.format("cmd.add: %s already defined\n", name)) return end _G[name] = function (...) cmd.dispatch(name,fn,arg) end end As you can see I've created a few namespaces, "com", "cmd" and "cvar", which contain the Com_* counterparts etc. from the game. I changed all of the key up/down +/-, config set and binding stuff over to Lua calls and this all seems to work fine. So every time you hit an action key to move or fire a Lua string is being compiled and executed! Its a pretty fast compiler, there won't be any problems until a significant amount of traffic is generated like this. If this does become an issue the bindings etc can be precompiled in wrapper functions and the functions called directly without compilation every time. This will also generate less/no garbage. Basically you can play the game and run around but game and server commands are a little confused at the moment as that side is still using the arg system, not Lua. It seems that the game avoids using the cmd registration in favour of "if then else" checking of 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). 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 started off with the Lua stuff in qutil but moved it to qcommon, but it's not all common. The Lua initialisation (state creation), error handing and general Lua utilities should probably go (back) in qutil. Any client specific functionality (e.g. creation of client Lua state and registration of client functions) should probably live in the client code (in a CL_ file). I'm a bit confused where this is, as there is a clgame, which seems to be effects, and the rest seems to be in q2x. So I guess the client Lua stuff should go in q2x. The server specific stuff will probably get initialised here too (in a separate state, SV_ file). If I divide the two states like this, this means the cvars will have to get communicated between the states (which might happen already). So, does this sound right: * The client side has its own Lua state. * Game and server share a Lua state. * Necessary cvars are communicated between the two states (using existing system?) * Game/server side contains all the game logic and client side is much simpler. Brian: I'm back off to the UK for 3 weeks tomorrow so I very much doubt that I'll have time to do the server side before I go. I might have a poke around in the code while I'm done. Let me know if you want a copy of the changes I've made. I'll say this is code in transition: a lot more work needs to be done make the whole code base Lua compatible. You might even leave the arg stuff in as an interface so that other languages could be used (but I think this could get very messy unless a significant amount of abstraction 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)). Nick From hook_l at pyrogon.com Sun Dec 21 18:12:39 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 21 Dec 2003 18:12:39 -0500 Subject: [q2x] cmds In-Reply-To: <000701c3c812$31885290$6400a8c0@quith1> Message-ID: <20031221181239.272798@GATEWAY> > 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 From theoddone33 at icculus.org Sat Dec 27 01:44:25 2003 From: theoddone33 at icculus.org (Dan Olson) Date: Sat, 27 Dec 2003 00:44:25 -0600 Subject: tolua5 Message-ID: <20031227064425.GA27089@localhost> I've heard rumors that someone patched tolua 5.0 alpha to actually work. Have either of you seen or acquired this patch? I switched email addresses a while back and didn't realize that I was subscribed to about 5 mailing lists with the old address. Just resubscribed to this one, so maybe someone could post a quick update of what's been going on? -- Dan Olson From hook_l at pyrogon.com Sat Dec 27 01:44:03 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sat, 27 Dec 2003 01:44:03 -0500 Subject: [q2x] tolua5 In-Reply-To: <20031227064425.GA27089@localhost> Message-ID: <200312271443.048002@GATEWAY> Oy vey, the long and short of it is that Nick basically got Lua mostly hacked into there a bit, and I'm leaving it alone until he gets it fully committed and is happy. Only the cvars are being converted at this time. Brian On Sat, 27 Dec 2003 00:44:25 -0600, Dan Olson wrote: > > I've heard rumors that someone patched tolua 5.0 alpha to actually > work. Have either of you seen or acquired this patch? > > I switched email addresses a while back and didn't realize that I > was subscribed to about 5 mailing lists with the old address. Just > resubscribed to this one, so maybe someone could post a quick > update of what's been going on? From nicktrout at shaw.ca Sun Dec 28 15:36:57 2003 From: nicktrout at shaw.ca (nicktrout at shaw.ca) Date: Sun, 28 Dec 2003 20:36:57 +0000 (GMT) Subject: [q2x] tolua5 Message-ID: <38576b3842f0.3842f038576b@shaw.ca> > Oy vey, the long and short of it is that Nick basically got Lua > mostly > hacked into there a bit, and I'm leaving it alone until he gets it > fully committed and is happy. Only the cvars are being converted > at > this time. > On Sat, 27 Dec 2003 00:44:25 -0600, Dan Olson wrote: > > > > I've heard rumors that someone patched tolua 5.0 alpha to actually > > work. Have either of you seen or acquired this patch? > > > > I switched email addresses a while back and didn't realize that I > > was subscribed to about 5 mailing lists with the old address. Just > > resubscribed to this one, so maybe someone could post a quick > > update of what's been going on? Merry Xmas from Blighty! To reiterate what Brian said: I've got Lua 5 into the project and have cvars, config scripts and client/server messaging converted over (so basically client side is working). Brian answered some questions about the structure of the client-server code and so I have a better idea about how to proceed with the server side conversion now. Rather than have a client and a server state I think we'll just use a single state. This can be quite easily namespaced if necessary (and will save memory). Currently I'm patching Lua into the old arg system that Quake uses to call functions (hence it's a little hacky). Eventually the arg system will be removed and all functions converted to use the lua_to() functions. I'm thinking of writing some Python scripts to do this. The game runs on the server side, which is the biggest job to tackle. Again I'm thinking of writing some scripts to covert all the C m_*.c files over to Lua. I'm not using tolua at the moment. Brian stated in an earlier email that he'd rather we used the Lua C API explictly. I don't really have a problem with this since the Lua C API is very easy to use and most of the tricky work can be done in Lua and a simple function call made, rather than do the work in C. -- I would like the details of where to find the tolua patch though since I have another project which needs tolua5. Thanks. I'll be back in Canada on 11th Jan and will try and carry with work, albeit in "hobby" time. I'm hoping the conversion scripts will greatly speed up the full conversion to Lua. I think the plan will then be to check in my changes and test the game for cracks before proceeding. We may have to do some multiplayer tests. I may be able to test this at home if I can get q2x compiling on my linux box. I don't really want to spend a lot of time on that though. Someone could be looking at a Quake2 editor in which we could embed Lua ediiting and debugging? Nick From hook_l at pyrogon.com Sun Dec 28 15:59:40 2003 From: hook_l at pyrogon.com (Brian Hook) Date: Sun, 28 Dec 2003 15:59:40 -0500 Subject: [q2x] tolua5 In-Reply-To: <38576b3842f0.3842f038576b@shaw.ca> Message-ID: <20031228155940.879264@GATEWAY> > Someone could be looking at a Quake2 editor in which we could embed > Lua ediiting and debugging? My take is that once we get this Lua-ized, and then I finish additional cleanup, we do a 1.0 release which should be as functional as good ol' Q2, but just a bit cleaner. That would be quite an accomplishment. >From there, we refactor some more and client-side game working as well (the stubbed cl_game stuff), which means an overhaul of the UI system. Basically once we're happy with the code, then we can stress over the tools. That said, Q2 really doesn't use any scripting in the tools, and all the AI is hardcoded, so I think stock tools should be fine. We could migrate the .map file format over to Lua, but I think that would just be wanking since it won't really buy us anything (whereas game logic written in Lua buys a lot). Brian From theoddone33 at icculus.org Sun Dec 28 18:59:51 2003 From: theoddone33 at icculus.org (Dan Olson) Date: Sun, 28 Dec 2003 17:59:51 -0600 Subject: [q2x] tolua5 In-Reply-To: <38576b3842f0.3842f038576b@shaw.ca> References: <38576b3842f0.3842f038576b@shaw.ca> Message-ID: <20031228235951.GA30643@localhost> On Sun, Dec 28, 2003 at 08:36:57PM +0000, nicktrout at shaw.ca wrote: > I'm not using tolua at the moment. Brian stated in an earlier email that he'd rather we used the Lua C API explictly. I don't really have a problem with this since the Lua C API is very easy to use and most of the tricky work can be done in Lua and a simple function call made, rather than do the work in C. -- I would like the details of where to find the tolua patch though since I have another project which needs tolua5. Thanks. I ended up downloading luacheia5, which had the luaSDL stuff built-in. That's all I really wanted to use tolua5 for. > I'll be back in Canada on 11th Jan and will try and carry with work, albeit in "hobby" time. I'm hoping the conversion scripts will greatly speed up the full conversion to Lua. I think the plan will then be to check in my changes and test the game for cracks before proceeding. We may have to do some multiplayer tests. I may be able to test this at home if I can get q2x compiling on my linux box. I don't really want to spend a lot of time on that though. Someone broke Linux compilation pretty fricking thoroughly. Current CVS is a mess and I frankly don't know how it even compiles on Windows. I'll see what I can do about it. -- Dan Olson From theoddone33 at icculus.org Sun Dec 28 21:21:27 2003 From: theoddone33 at icculus.org (Dan Olson) Date: Sun, 28 Dec 2003 20:21:27 -0600 Subject: [q2x] tolua5 In-Reply-To: <20031228235951.GA30643@localhost> References: <38576b3842f0.3842f038576b@shaw.ca> <20031228235951.GA30643@localhost> Message-ID: <20031229022127.GA30993@localhost> On Sun, Dec 28, 2003 at 05:59:51PM -0600, Dan Olson wrote: > Someone broke Linux compilation pretty fricking thoroughly. Current CVS > is a mess and I frankly don't know how it even compiles on Windows. > I'll see what I can do about it. > It wasn't as bad as I thought. People were mixing byte and qbyte in ways that shouldn't have happened. I might have missed some changes (I didn't even look in the win32 files, but all "byte" should be "qbyte", all "true" should be "qtrue", and all "false" should be "qfalse". I also fixed an annoying bug in the SDL version that kept it from displaying any real graphics, so a Linux version is starting to shape up. It still has a few bugs left to iron out. -- Dan Olson