CSQC Modification Questions For Spike

[Baker]

Spike, fairly early in the year real life managed to suck up about all available time for several months and at least for a while I'll have some free time.

Your CSQC WinQuake prototype, which since it is even software compatible is globally Quake compatible, could you run down a short list of the features or capabilities this will give to QuakeC for an engine using the modification?

The goal in asking this question is to be able to "sell" to existing QuakeC modders, in particular in the NQ community but maybe some parts of the single player community as well, the basic CSQC features if a new "standard" baseline modified engine platform existed.

And the main reason I ask, being somewhat weak on QuakeC myself and having never written CSQC for DarkPlaces or FTEQW or Nexuiz, I have a fuzzy understanding of some of the benefits of CSQC as far as concrete specifics go and I'd like to be to explain them, especially in the form of "now you can do this, this and this".

[mh]

Seconded. I'd like something like this as well. So far all I've really seen of CSQC amounts to what's basically tech-demos, but I have a vague notion that it would allow a mod to call a lot of client-side code and access a lot of client-side objects (sorta like the client VM in Q3A).

However, my engine's architecture is sufficiently different from vanilla Win/GL that implementing CSQC on it would be quite non-trivial. If I'm going to go down that route I'd like to know exactly what I'm getting for my time/work investment, and that it's actually something that would be used.

[Spike]

Simple stuff:
custom huds. models on huds. team/flag status. button counters.
extended score boards/results (accuracy stats, favoured killees, captures, defends, etc).
inventory systems (eg: prydon gate could use a proper mouse cursor for its menus).
team/class/observer menus (particuarly customtf).
Secondary views (rear view mirror for quake rally, guided rockets, etc).
client side gibs (600 of them without clogging network, etc, nail grenades, semi-persistant ents).
client side spawning of particles (think hipnotic's bridges).
enforced fov/angles (flashbangs/magic-mushroom effects), locked view points (top-down mods, etc).
potentially better network performance (csqc allows sending nail start points and times, without constantly updating nails/rockets, so its much more compact).
next map selection menus (eg: nexuiz).
'proper' access to client-side cvars, for user-specific settings (eg customtf class works on all customtf servers, not just the one with frik_file enabled).
client-specific entity sending (enemy spies can have your team's colourmap for you, and thiers ffor thier team).

More complex things:
Custom player prediction code. And, urm, prediction code in the first place. :)
Unlagged shooting animations and other client-side prediction.
Client side cursors.
torch effects (dlights that don't lag behind the view angles).

Current dp/fte extensions:
Better animations (separate upper/lower sequences, etc with md3s/tags, without always breaking network compatibility).
Particle based effects. Glowing eyes, smoke rising from recently fired guns.
specific powerup shells.

Pending extensions:
clientside ragdoll, so the network doesn't die from sending bone positions.



Basically the idea of csqc is to give the modder access to parts of the engine that were previously unavailable to them (primarily the hud/config menus). Secondly, to provide access to features available to more modern games (yes, akin to q3a's cgame).

For the QC modder, it is not required that you actually manage any entities in csqc, but you do have to direct the engine to draw what it knows about.
Using CSQC does not actually mandate SSQC changes. DP requires all clients use csqc if the server has a csprogs, but that's not really intended by the csqc spec. Its perfectly viable to connect multiple different clients, some using csqc, others not. But you can also kick players if they are not using it, of course.
The engine supports both csqc and ssqc entity sending. csqc ents get the csqc versions, and clients without csqc get the ssqc fallbacks. Its entirely possible to provide effects compatible with either sort of client, without wasting bandwidth to provide for the other, and without even checking to see if the server+client supports csqc. :)

For the engine modder, it requires seperation of renderer and client. You must be able to draw multiple scenes (some without the world, ie: overlays) in order to provide the csqc with full control over the view. This will be the biggest issue for mh, and was the hardest part I found to get it stable with winquake too.
But the major major problem is that the qcvm needs separating to support two VMs running at once. I achieved this by reusing fte's qclib. Which is not the cleanest code around, but does get the job done, so the csqc winquake port has two separate qcvms inside. One is the old that supports all the qccx hacks. And one is the new, for running csqc itself (note that the csqc qcvm should ideally block most qccx hacks anyway).
Network changes are also required, in order to provide the csqc with notifications about changes on the server, so the mega-gibbings and stuff can work. Note that the provided code uses a versioning system, so it is entirely possible that the csqc mechanisms will result in a reduction in bandwidth spikes, assuming its used to do so (just do it with nails and you'll not spam people off nq servers).
Even without csqc-specific mod changes, the patch will extend stats to 32bit, so no more 255 ammo/health caps.
Engines must provide a compatible 2d interface. This does admittedly require stretching (which I don't think my sw version provided, but nearest pixel is conformant). Blend mode arguments are a DP extension, and its not required that they are even present... Unless you're using DP as a client. :/
I don't think mh will have any real issues with 2d stuff. just code cleanliness.
CSQC support in an engine is not trivial. It will make a lot of changes, and interact with code present in 90% of modified engines in some incompatible way or another, that a straight tutorial for adding support will be near impossible, and will be looong. Any such tutorial will need to branch into choice of base engines.
My csqc winquake engine thus does not support model interpolation, but should include comments saying which fields to read from in order to pass the information along to the renderer.

[avirox]

Join Megatf COOP (74.54.186.230:27500) using FTE and you can see some practical uses of CSQC in action. What coop currently has:

GUI class menus with descriptions of each class (WIP)
Real-time Experience Points HUD item (top-right)
Reload bar
Experience Point notification images
Misc GUI menus replacing silly centerprint ones

.. probably some other things I'm forgetting, too

I'm currently working on using physics stuff with CSQC, but that's a little more in depth I suppose. If you'd like I can show you a tech demo of my project Damascus which is a top-down Diablo style mod with mouse-controlled movement and attacking, etc.

Given the right amount of dedication, CSQC can do wonders where other quake mods have fell into mediocrity. My current plans revolve around a Streets of Rage coop mod for quake primarily using CSQC for special moves (key inputs), health bars, and random generated physics.

[frag.machine]

One thing that could turn CSQC really useful is the ability to process unknown network messages. Basically, if it's not a regular message, the C code gives to CSQC a chance to process it before assuming a network error and disconnecting. Actually, the same is true to the server side of the engine.

EDIT: neat ideas of features aside, CSQC needs badly of complete, consistent and objective documentation - maybe more than a simple reference implementation over stock GLQuake.

[mh]

Right now I'm wondering how possible it would be to selectively implement parts of CSQC. How modular is it? Or is it even designed that way? The way I read things is that you essentially have to rip apart and reconstruct almost the entire client side of your engine, and that's quite a daunting prospect. Being able to build it up in layers and bolt on bits would definitely increase the possibility of me taking it on.

[Spike]

mh, logically you could provide a seperate entry point and provide only 2d/stat/string builtins.
the full spec, however, logically has a single function which is called each frame, which does everything else... Well, there are some input and network notifications too, but that's the general ideal, its just a bit lazy.
The way the rendering is set up, is that the client calls the csqc to draw the entire screen.

frag.machine:
http://fteqw.svn.sourceforge.net/viewvc ... csqc_1.txt
let me know if there are any omissions.

[Baker]

[frag.machine]

[Spike]

[Baker]

[Spike]

[avirox]

[mh]

[Spike]