[SOLVED][FTE]Is #CLIENTONLY define really works?

[toneddu2000]

Hi engine masters! I'm trying to build updated version of FTE (v5224) using preprocessor define #CLIENTONLY .
I put it on top of client/quakedef.h but, when I try to compile it, it gives tons of errors because it searches for server structs / functions that, obviously, it can't find.
Am i missing a step?
Could you please help? Because I'd really like to compile FTE only client as 1° step, then second step would be more ambitious, but just go step by step for now!
Huge thanks guys!!

[toneddu2000]

UPDATE: I also tried to define #clientonly in common/bothdefs.h but also lots of errors. It seems that some files don't have the #ifndef CLIENTONLY part where server parts are used

[toneddu2000]

[Max_Salivan]

compile engine with make sv-rel CFLAGS=-DCLIENTONLY ???

[toneddu2000]

I don't understand ,was it a question or an answer?

[Spike]

if you're trying to strip out lots of stuff, you might want to use wastes/TW as a base.
cp common/config_wastes.h common/config_myconfig.h && make m-rel FTE_CONFIG=myconfig
causes it to read a custom config header based upon eukara's wastes config with a number of config options that strip out optional/vanilla stuff that simply isn't needed in (eg) The Wastes, which disturbingly makes it smaller than the no-server 'minimal' builds... I blame 3rd-party libraries.
I ought to split the minimal and standard configs into seperate config files too, if only to make the different configs easier to diff.

There are too many options for me to really care about every single combination of options, so yeah, expect it to bug out (usually by failing to compile) unless other stuff is also disabled too.
I probably also ought to go through and change the NOFOOs to FOOs instead, and all sorts of other cleanups, but gah. I don't much like cleaning code, usually I just end up breaking and not having the enthusiasm to hunt all the new bugs so I tend to do it only when there's a purpose beyond the code itself.

side note: building a server using only a client is a little folly.

[toneddu2000]

[Spike]

in terms of rendering, the basic idea is that FTE is 'just' trisoup.
the client generates batches of trisoup meshes. each batch has a single shader and a few other common properties. the backend logic of each renderer then takes those batches, walks through the shader passes, and draws the meshes accordingly.
the backends configure the shader logic via the sh_config struct, which controls the accepted aspects of the shaders (like whether glsl can be used or not, or the max number of textures per pass). the usable texture formats are configured the same way too.
so the model code is responsible for loading models, the image.c code is responsible for loading texture files and converting into formats supported by the gpu. the gl_shader.c code is responsible for parsing shaders and generating the internal representation of those. the client code handles bsp culling+pvs to add the various meshes into batches.
each renderer has a rendererinfo_t struct that tells the rest of the engine what to call in order to get any gpu work done - its pretty much all trisoup, textures, and buffers.
the renderer then has a fairly generic interface which allows FTE to support many renderers without too much extra effort, in theory.

rendering wise, GLSCR_UpdateScreen is the function that's meant to be responsible for throwing everything at the screen. So if you're trying to walk through FTE's rendering stages, start there. There shouldn't be any drawing elsewhere. Note that the other renderers have their own alternatives to this function, which sucks.
pr_csqc.c contains most of the csqc-only builtins (any externally-visible gunctions are meant to have a CSQC_ prefix, while builtins follow the PF_ prefix), with pr_cmds.c giving the ssqc-only ones, with pr_menu.qc giving the menu-only ones, supposedly. pr_bgcmd.c contains the generic builtins that might be used by any vm, while pr_clcmd.c gives builtins shared between csqc+menuqc, and pr_skelobj.c giving the skeletal object, ragdoll, and a number of model-related builtins shared between csqc+ssqc.
gl_shadow.c's rtlights are sandwiched between two shader sort values called from somewhere inside gl_backend.c or so.

but yeah, its a large project, with lots of legacy, the more you play with it, the more you'll understand it - practise makes perfect.... or something.

[toneddu2000]

[toneddu2000]

[Spike]

You're only allowed to throw stuff at the screen during CSQC_UpdateView or CSQC_UpdateViewLoading calls. If you're trying to draw within the callstack of any other entry point then you'll get those sorts of errors.
As a special exception, drawing to render targets is permitted elsewhere (as the results may still be useful).

Violating this rule is pointless as the next call to CSQC_UpdateView will scribble over everything anyway.
And these are warnings, not errors, if its shutting down then that's being caused by something else.

[toneddu2000]