Yes indeed I found that VM_Call and VMmain() (the latter being to add more VM calls if I understood well) are what are needed, as nicely explained here:
http://www.cs.rochester.edu/trac/quagents/wiki/ServerProgrammingDealingWithVMs "Getting Into the VM Getting into the VM is very easy. Each module of VM code has a *_public.h file hosting a large *Export enum of function names. Add the function you want to be calling from outside the VM to that enum, go to *_main.c and add a case for that value and function into the switch in the vmMain(...) method. You can then call your function from outside the vm by using VM_Call(...). You should give VM_Call a legal vm (which can sometimes be a pain to get a hold of!) and the enum value you defined." However, what I had in mind was a way to acces the variables of game/*.c files. A kind of generic variable fetcher to be more clear. By using VM calls, one has to make one VM call for each variable you want to get, because there's no way in C to pass a meta-reference to a variable (what I call meta-reference is like in python or php you pass a string as argument, and then you can use this string as the name of the attribute you want to get, eg: $var = "health"; $ps->$var would get the value of health from a player's state). A workaround I think would be possible would be to declare in a *_public.h file an enum of int identifiers of the variables you would want to fetch, then add in vmMain() add a call to a new function you create which would switch on a given argument, over the enum of identifiers, and then fetch the correct value. Eg (not tested): in g_main.c edit vmMain() and add: case GAME_VARIABLE_FETCH: return VariableFetch( arg0 ); in g_public.h add your enum of identifiers: typedef enum { HEALTH, SCORE, MISSILEHIT // etc... } varFetchList_t; in one of the g_*.c or in your own, add: void VariableFetch( int varname ) { switch ( varname ) { case HEALTH: var = // way to get health value here return var; break; case SCORE: etc... } } However, while this approach is very simple to implement, it breaks compatibility with mods since mods won't provide this vm call. Thus I have found other ways to get the values I want from the accessible variables offered by *_public.h by using a few clever tricks. Indeed it's often possible to derive a value you're looking for by deriving from what is available to the engine (for example, you may not know when some kills someone else, you only know when someone dies and the last attacker client num, but with these two infos you can derive that the attacker killed someone). I hope this may be useful to someone else, and if someone has a better idea to access all variables from the gamecode I would gladly hear about it. 2013/5/2 Lally Singh <lally.si...@gmail.com> > VM_CALL? > > > On Wed, May 1, 2013 at 7:46 PM, Stephen LARROQUE <lrq3...@gmail.com>wrote: > >> Is there a way to do just the opposite of trap calls, which is to access >> some game private data from the server system (eg: fetch variables stored >> in g_main.c from sv_main.c)? >> >> If there's no currently implemented way to do so, do you think of a clean >> way to implement a generic way to do that (do you think that's possible?). >> >> Note: I assume that the data one tries to access in game code is also >> defined in the server code, or is generic like ints. >> >> _______________________________________________ >> 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. >> > > > _______________________________________________ > 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. >
_______________________________________________ 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.
