by Spike » Sat Aug 24, 2013 5:40 pm
There are no specific .qc files you must have (in fact, if your .src file starts with a preprocessor directive, you don't need any .qc files at all, though that's impractical when its large, but hey, #include to the rescue).
That said, you will need some equivelent of defs.qc to get the system defs+fields right, and so the compiler knows what the builtins are and their names and arguments and stuff.
The file I linked serves this purpose, and contains no actual logic itself, just defs.
DP specific:
DP requires that the following four functions are defined. I don't really know why. Any dp-specific csqc def listings will thus define them as not var etc, and the compiler will complain about them not being defined.
CSQC_Init
CSQC_InputEvent
CSQC_UpdateView
CSQC_ConsoleCommand
The file I linked should have correct definitions for these and will not result in errors if they are omitted as fte has no issues with them missing (although skipping CSQC_UpdateView would defeat the point of most csqc mods).
InputEvent and ConsoleCommand can be implemented as stubs by just returning false. Init can simply contain nothing. UpdateView requires something like the code I already wrote in my previous post, just without the drawpic call obscuring the screen.
To compile both a csprogs.dat and a progs.dat, you need to run the compiler twice, with two separate foo.src files. As far as the qcc is concerned, there's no difference between the two (any warnings about crcs are purely cosmetic, and are in an attempt to warn about people who acidentilly changed the top of defs.qc or whatever).
menu.src is a third form of src file that you might have.
With FTEQCC, you can put '#pragma sourcefile csprogs.src' in your ssqc's defs.qc file or somewhere if you want. this will get fteqcc to attempt to compile from csprogs.src after it has finished compiling from progs.src (automatically restarting compiling with an alternative source file).
Personally I tend to have all the src files as $mod/src/*.src with the common qc files in the same dir, and the module-specific qc files in an appropriate subdir (fte's built-in qcc can then be used via 'compile csprogs.src', woo). If you're invoking qcc via double-clicking it, having files NOT called exactly progs.src can be annoying, separate subdirectories can help with that, or you can just use that pragma.
.