by Spike » Wed Jan 02, 2019 4:51 am
don't change anything before defs.qc's end_sys_fields. that's how you avoid it.
the vanilla qcc wrote a (now-useless) progdefs.h file for inclusion in the engine's code so that things matched (and generates the progs crc value from that file), so if you change the name/order/basic type of any of those system defs that the vanilla engine can see then you change the progdefs.h and resulting crc too, which normally causes engines to refuse to load it.
(note that fteqcc's -Th2 [or -Tfteh2] args/pragmas also change the progdefs.h and thus the crc, but I doubt this is your issue. There is a pragma that allows you to force the crc, but only evil people use evil hacks like this so I won't name it here)
iirc, DP completely ignores the crc, linking purely by symbol names instead of hardcoded offsets.
FTE does something similar (though more complicated so that it can correctly handle aliases/renames/strips), however it also recognises known crc values and enables various compatibility modes in an attempt to behave the way the mod expects the engine to behave (assuming NQ/FTECSQC behaviours if its not recognised, which means any DPCSQC/QW/Hexen2/etc mods will malfunction in weird ways if they have the wrong crc).
Other engines will just reject your progs entirely.
So get the crc right by not modifying any of those system defs!
you can also #include "fteextensions.qc" before your defs.qc, and in doing so use the systemdefs defined within (this also works with a preceding #define CSQC or QWSSQC to change the type of progs you want to write). This allows you to freely change your defs.qc file (although you may need to delete your defs.qc's builtin definitions, at least where they're buggy or unextended.
.