In first place I say I'm working with Darkplaces engine. Well I know we
can use FRIK_FILE instead parms to carry globals values from one level to another. anyway let me know how I can increase the number of parms. I thought of modifying three files (progdefs.h, sv_main.c and prvm_offsets.h)
(BLUE is new code)
progdefs.h
float parm13;
float parm14;
float parm15;
float parm16;
float parm17;
float parm18;
sv_main.c
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm13);
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm14);
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm15);
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm16);
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm17);
PRVM_ED_FindGlobalOffset_FromStruct(globalvars_t, parm18); etc...
prvm_offsets.h
PRVM_DECLARE_global(parm13)
PRVM_DECLARE_global(parm14)
PRVM_DECLARE_global(parm15)
PRVM_DECLARE_global(parm16)
PRVM_DECLARE_global(parm17)
PRVM_DECLARE_global(parm18) etc...
I need something more than this? I wonder if this modifitacion would work without problems. Thank you very much
more parms?
more parms?
hi, I am nahuel, I love quake and qc.
Re: more parms?
This is a very interesting question.
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: more parms?
WAIT WAIT
i read somewhere (xonotic thread) i think they were encoding the parms so each parm had like 24 bit values...
here
http://www.desura.com/tutorials/quake-c ... le-storage
i read somewhere (xonotic thread) i think they were encoding the parms so each parm had like 24 bit values...
here
http://www.desura.com/tutorials/quake-c ... le-storage
LordHavoc Sep 16 2013, 1:06pm said:
The lhbitparms code in util.qc in dpmod may also be of use, it allows some extremely fine grained packing of up to 31 bits per parm or 30 bits per cvar (there are a bunch of gotchas on cvars though).
lhbitparms can also extend to using cvars for even more storage (as seen in Prydon Gate), but means you need to copy those cvars to globals, and have a RestoreGame() function that stores the fields back to cvars so that any "restart" commands will have the cvars set properly before the DecodeLevelParms is executed.
Another thing to explore is using fopen (part of FRIK_FILE extension) and load/save character information in a separate file (Prydon Gate does this for multiplayer mode).
Re: more parms?
generally I point people at frikac's prydon gate for parm encoding.
engine hacks will require you to tweak NUM_SPAWN_PARMS too. and this will generally break saved game compat.
from the mod side, define the extra globals *after* end_sys_fields and they should work.
FTE already supports up to 64 parms, and yeah, uses a different saved game format.
engine hacks will require you to tweak NUM_SPAWN_PARMS too. and this will generally break saved game compat.
from the mod side, define the extra globals *after* end_sys_fields and they should work.
FTE already supports up to 64 parms, and yeah, uses a different saved game format.
Re: more parms?
Quake C source = code_crazy_(Prydon_Gate_src).zip
The night is young. How else can I annoy the world before sunsrise? Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Re: more parms?
thank you for the help.
Thank you again
well, do you mean .sav incompatbility with*.sav files of modified engine -so this hacked engine will not work fine saving games- ???? or do you mean incompatibility with *.sav files from an unmodified engine or vanilla quake???Spike wrote: engine hacks will require you to tweak NUM_SPAWN_PARMS too. and this will generally break saved game compat.
Well, i understand but why should I do that? For problems with compiler?Spike wrote: from the mod side, define the extra globals *after* end_sys_fields and they should work.
Thank you again
hi, I am nahuel, I love quake and qc.
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: more parms?
All entity field declarations in defs.qc BEFORE end_sys_fields are referred by the C code and thus expected to be in that exact number and order (in other words, just don't mess with that part of defs.qc).
After this point is guaranteed the C code won't try to access directly any other entity field, so it's safe to add/remove/alter order/etc.
Personally I use a defs2.qc file (placed just after defs.qc in progs.src) to declare all my mod stuff and just avoid to mess with defs.qc directly as much as possible.
After this point is guaranteed the C code won't try to access directly any other entity field, so it's safe to add/remove/alter order/etc.
Personally I use a defs2.qc file (placed just after defs.qc in progs.src) to declare all my mod stuff and just avoid to mess with defs.qc directly as much as possible.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)