InsideQC Forums

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

This is a very interesting question.

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

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).

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.

Quake C source = code_crazy_(Prydon_Gate_src).zip

thank you for the help.

Spike wrote: engine hacks will require you to tweak NUM_SPAWN_PARMS too. and this will generally break saved game compat.

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: from the mod side, define the extra globals *after* end_sys_fields and they should work.

Well, i understand but why should I do that? For problems with compiler?
Thank you again

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.