RANT: What's wrong with CSQC

[Spike]

a few lesser-known notes:
qc-friendly docs were going to be released alongside the reference implementation.
the reference implementation was going to be the csqcwinquake engine (so named because of the project file, was meant to be sw+gl) that you can google for if you care. And yes, NQ. Nothing to do with busses.
it was going to be a mostly complete implementation, but was going to omit things that required too many engine changes (like skeletal objects, which need skeletal models first).
it was going to be able to use prediction (but only when driven by csqc).

I ported fte's csqc stuff over to it, started fixing up the issues (and reevaluating parts of it in the process). except I got bored. and dp's implementation got released. and used. and it was incompatible. and meh. but mostly I got bored and paranoid about how it would be received.
I assume most of it works. however, its not a readable reference, so its kinda pointless. its also quite invasive. networking changes are kinda bad too, but at least they're meant to only apply when csqc is active.
it later resurfaced when I gave a copy to xavior when he was trying to add csqc to ezquake.
I've cleaned up FTE's code quite a bit since then, as well as made concessions to try to support some dp-isms that don't break other stuff (hopefully...). I really don't remember how much of it was implemented, there appear to be a number of notable 'TOFIX' tags lying around in it though. So don't expect it to work with any mod not explicitly written for it...

I kinda regret trying to support anything but huds with it. hud-only csqc support would have been easy, useful, portable, and completable. there would have been all sorts of nightmares with trying to do anything advanced like entities (beyond using them just for field space), but at least it would have served as a gateway to a more complete implementation.
yeah, most engines would still not support 3d stuff, but at least csqc hud support would have been a nice easy thing to drop into a project and could have been widespread now.

if someone with lots of motivation wants to go through it and finalise it, feel free. or rework it to gut all but huds, again feel free. there are actually a few mods that it can be tested against now, so hurrah for that, or someone could make a decent diff from rmqe.
the problem I find is with motivation, and keeping it for long enough to finish it. everything always ends up as a race against time eventually.

[Baker]

[Spike]

yeah, I really should point out that the rmqe source is a 3rd implementation of csqc. and once again, it expects a different layout to the system fields. this is because its a work-in-progress, except its not really in progress any more.
the specific cause is that its trying to reuse the ssqc builtins that it can with csqc, including entity fields and things (in a vauge attempt to get traceline working - a necessity if you're going to do things like chasecams eventually).
there's no easy way around that. which is why csqcwinquake used fte's qclib for its vm, which can remap entity fields however it needs.
but on the other hand, maybe the rmqe defs should have been the ones to be standardized - its not like the other engines really care that much, even if they might moan about it.

[goldenboy]

[ceriux]

would be cool to see something like fitzquake with csqc in it.

[toneddu2000]

[LordHavoc]

[ceriux]

i'm not exactly sure if i agree with you toneddu2000, when theres too much info my brain kind of gets melty i have problems paying attention. i kind of like the qc tutorials we already have, but id like the csqc tutorials to be just like them, but with better comments explaining what each line is doing. if there is some kind of equation explain what its doing and why.

when theres too much jibberish mixed with a tutorial it becomes hard to follow. the extra information is nice... but i become lost in it.

as an example this : http://sourceforge.net/p/fteqw/code/HEA ... idiots.txt

it has way too much going on. i downloaded the text file and i read and read and read all the information in there is lost among all the non nessisary information.. (not that its not a good tutorial/document)

i like to see an example and a semi detailed comment about whats going on in the specific line. its much more straight forward and leaves a lot less to shift through.

[toneddu2000]

[ceriux]

[LordHavoc]

[Spike]

[toneddu2000]

[ceriux]

toneddu i think predraw is explained in here : http://sourceforge.net/p/fteqw/code/HEA ... idiots.txt

[Spike]

the predraw method (and by method, I mean function stored in a field) is invoked by the addentities function (just before the engine implicitly calls addentity on the entity for you - note that in FTE you can inhibit the engine's auto addentity call by returning TRUE, giving you a chance to revert temporary field changes or whatever).
because addentities is called each frame, the predraw function is also called each frame too, for each entity.
this gives you a chance to edit the fields to interpolate or extrapolate the entity as you feel fit before it is submitted to the renderer, with exact timing info and stuff.
naturally, you can use it as a second think function, but often you'll get smoother results by using it exclusively instead of .think.

I'll make a mental note to actually test the example when I've more time on my hands, I don't see any obvious reason why it wouldn't work. I was messing with skeletal objects yesterday so I know skel_build works in that mod at least.
be aware that a fixed lerpfrac 0.5 will blend two separate animations in a way that you might percieve as buggy. I believe I wrote it that way to invoke some curiosity. fte now has a 'modelviewer' command that you can use to check what the engine sees in the model, in terms of frames and framegroups and skins and bones and stuff. its rudimentary but gets the job done. note that DP doesn't necessarily see the same thing for all model formats - fte strictly sees what is in the model, while in my experience DP has a tendancy of unpacking framegroups and throwing away the animations.