Hi Javier! On Mon, Aug 15, 2011 at 11:47 AM, Javier Maria Torres <javier.maria.tor...@gmail.com> wrote: > I've been trying for some time to build a client that would act as a middle > layer to Erlang and Java VMs, so it becomes easier for agents (i.e. bots) in > those languages to hook up to real servers. My idea is to replace the > renderer with an API to query the game world, and send the commands from the > VM agent instead of the client QVM (as far as I could understand how q3 > works). Do you think your client could make this task easier?
First off, I'm not an expert in this area. I hope someone chimes in if I'm wrong. :) I need a little more information about this. How much of the cgame and client are you planning on keeping? Do you want to do a wholesale replacement of the client QVM? e.g. do you want to create the cgame functionality in the JVM instead of QVM? Or are you looking to query the client or cgame state and inject commands under certain conditions? Do you care about compatibility with vanilla quake3? With other mods? I'm a little confused on why you involved the renderer part. The renderer API is very simple. There aren't any interesting data structures passed in from a game state point of view if you were looking to get a backdoor handle. Are you talking about replacing the renderering calls with functions that query the client's state? You could do that, but be sure it's what you want. The client state and cgame QVM state have different data structures. If you want to get at the cgame QVM's state (like clientInfo_t in code/cgame), I don't think there is an API call. My impression is that it's mod dependent anyway so you can't have a truly generic way of doing it. The contract that a mod is bound to is the enum/functions (aka traps/system calls) below. Other than that, I think it can store data however it wants internally (subject to QVM limitations). Here's an overview of the QVM <-> executable interface. code/cgame/cg_public.h /* Interface via enums defined both ways */ code/ui/ui_public.h /* Interface via enums defined both ways */ code/server/g_public.h /* Interface via enums defined both ways */ code/client/cl_cgame.c /* Maps from cgame requests to client functions */ code/client/cl_ui.c /* Maps from ui requests to client functions */ code/server/sv_game.c /* Maps from qagame requests to server functions */ code/cgame/cg_main.c /* Maps from client requests to cgame functions */ code/ui/ui_main.c /* Maps from client requests to ui functions */ code/game/g_main.c /* Maps from server requests to qagame functions */ In general, when you see a function named *SystemCalls it is from QVM -> exe and when it is named vmMain, it is from exe -> QVM. The API for the QVM to call is quite large (50 or so functions) while the API for the client/server to call into the QVM is tiny (5 or so). If you assume that the cgame QVM is from the ioquake3 code (vanilla quake3), then you could expose more game state through new vmMain enums. However, you are creating a truly standalone game which breaks the mod API and it may not be your goal. The demo player would be a good base for any type of project like this since it stripped out parts you don't need like sound and rendering. However, I have another branch that may be of interest if you want to see how the QVM <-> client interaction happens. In that same github directory, there's a t/sqlite3 where I record all QVM <-> client calls into a sqlite3 database. Actually it has support for all, but I only enable a subset because otherwise you will have millions of entries. In some cases, it's serializing the arguments and/or results so you can browse those later as well. For instance, I keep the entire snapshot every time rather than just a delta so I can see what the QVM was looking at. I'll be adding the QVM <-> server part soon. _______________________________________________ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
