Hy guys, if you (like me) use FTE for you games, probably you have noticed that, from version 5143 and up, FTE f***s up view when moving mouse.For example you could render a grid, and when you move the camera, you would see your grid in persective view as normal and a blinking (like strobo light) grid position in [0,0,0 ] with [0,0,0] orientation on the background! It's so fast the blinking that I tried many times to capture with Windows screenshot tool but it's impossible to take a decent picture!

BIGFATPS: I'm using purecsqc installation (so no progs or qwprogs.dat are involved). If you guys are using in your mod a ssqc + csqc or only ssqc based mod/game installation, please post here if version 5143 works ok for you. You have to compile it on your own, or, instead, just grab the 5152 which it's avalaible on Spike repo

cl_threadedphysics predates csqc and does not play nicely with it. in order to do so, it would need to invoke csqc on a different thread, but the qcvm is inherently unthreadable (self, temps, locals, etc). the default has always been 0 and it doesn't appear in any menus. the current intended behaviour is for csqc to no longer receive CSQC_InputFrame calls when this cvar is active (DP lacks these calls too), but it also doesn't get tested much.

cl_loopbackprotocol controls the protocol used to connect the internal client to its internal server. when using my purecsqc mod the internal server is not meant to be in use at all (do NOT use the map command - purecsqc registers a csmap command that should be used instead), so this cvar will affect absolutely nothing in the specific case that you state.

recent builds have focused on emulating DP's csqc a little better, primarily in order to run xonotic (requires a new default.cfg as well as a few other xonotic-specific fixups, so don't expect it to work out of the box without those).probably I broke something in the wrong bit of code while trying to work around xonotic's flawed prediction logic (which is a bit of a nightmare tbh). if its flickering exactly every 1 in 64 frames then that'd probably be a simple off-by-one issue... other frequencies would be race conditions...

Well, could you "group" them under a define or something? In that way I'd just recompile with the define on and that's it.

Spike wrote: the current intended behaviour is for csqc to no longer receive CSQC_InputFrame calls when this cvar is active (DP lacks these calls too), but it also doesn't get tested much.

Whaaatt? And how can I handle input? Without CSQC_InputFrame I feel naked! Well, I could use .think but it doesn't feel quite the right place for those stuff.. I (ab)use of it even on my only-csqc games!

Spike wrote:cl_loopbackprotocol controls the protocol used to connect the internal client to its internal server. when using my purecsqc mod the internal server is not meant to be in use at all (do NOT use the map command - purecsqc registers a csmap command that should be used instead), so this cvar will affect absolutely nothing in the specific case that you state.

Again I used words improperly! When I said "purecsqc" I didn't mean your purecsqc mod but a pure CSQC installation starting from scratch (basically no qwprogs.dat, only csprogs.dat with CSQC_Ent_Update and CSQC_Parse* stuff off and pr_csqc_formenus 1 set in .cfg). Even for craFTEr I started from blank project but it has same issues with new version of FTE (v5143 and up)

Spike wrote:recent builds have focused on emulating DP's csqc a little better, primarily in order to run xonotic (requires a new default.cfg as well as a few other xonotic-specific fixups, so don't expect it to work out of the box without those).probably I broke something in the wrong bit of code while trying to work around xonotic's flawed prediction logic (which is a bit of a nightmare tbh). if its flickering exactly every 1 in 64 frames then that'd probably be a simple off-by-one issue... other frequencies would be race conditions...

But, if I set cvars as I wrote above, will it work as previous versions? I mean, without problems? Or could it lead to crashes or weird behaviours?

LITTLE OFF TOPIC: are you still working on the NOLEGACY define? Because, that WOULD BE GREAT to add a NOLEGACYPURE define that takes in consideration only CSQC (so there wouldn't be need for the pr_csqc_formenus 1 at startup) and that don't even compile all the quake* stuff but only .iqm and skeletal, input, audio and render stuff (probably not even BSP)

Regarding NOLEGACY:People who are likely to use NOLEGACY are those who are writing stand-alone total conversions.Such people will also want to customise/rebrand the engine.This means that official builds using NOLEGACY are basically irrelevant. The way I see it, depending on those builds without also being a total conversion will just result in confusion and problems for people (your users, that is). Simply put, its a compile-time feature rather than a user feature...For instance, Eukara's 'The Wastes' mod has its own config_wastes.h that rebrands+enables only the things that his game requires, including NOLEGACY.(do note that the gpl requires that such configs are public - if you want to make your own+icon then I can commit them to fte's svn, but please ensure that any builds you distribute report their svn version and that they do so without an 'M' postfix.)

Spike wrote:This means that official builds using NOLEGACY are basically irrelevant.

yeah, that seems fair.But you didn't answer my primary question: from 5143 and up, which should be the correct method to handle input in csqc-only games?Should I leave things I always did (CSQC_InputFrame() + setting cvars cl_threadedphysics & cl_loopbackprotocol ) or should I do something different?Could it be possible to make the engine "understand" when it's a csqc-only game and setting those cvars by itself, plus pr_csqc_formenus set to 1 (because it's a bit annoying relying on default.cfg for that)?