EXT_CSQC_1

[Spike]

I was gonna post this is reply to LordHavoc's reply in the cs_project topic, but its offtopic there, and tbh deserves a topic of its own. Anyway...

As you may know, EXT_CSQC was never really polished. The implementations (both of them) differ from the spec as documented, and it has many features missing that might be useful. It was never properly finished.

The full EXT_CSQC_1 spec is still not finalised fully. And I'd like your input on features and things.
These are the things that come to my mind. I'm sure there are some other issues that can be raised by anyone else.
Many of the items on this list are differences between DP and FTE.
And many of them are to remind me to fix issues in FTE. :)



CSQC_1 features some stat changes based on LordHavoc's recommendation (ie: strings are variable length).

Another thing is the final progs header crc. FTE still accepts any. This was for whatever support could be obtained from the spec when it was properly finalised, and its time to properly finalise it.

Sound events. FTE and DP both do that differently. FTE's is flawed in that it stops triggering if the csqc doesn't know about the entity (phs > pvs, so quite common). DP's is awkward as the sound isn't always linked to the source entity.
Imho, adopt DP's as standard, but add an extra ent parameter, in case csqc is meant to know that entity. This saves a findfloat call.

+showscores is yet another difference. FTE allows/expects the csqc to register this command itself, while DP adds specific handling into the api. FTE also has +showteamscores which DP does not. Personally I prefer FTE's mechanism as standard, as its logically extendable to other similar commands (eg: the +showteamscores command). Although which commands are similar is arguable.
Edit: Apparently nexuiz supports +showscores just fine.

Engine entities/Deltaed entities:
Automatic interpolation is supported.
Fields overwritten each frame are:
entnum, modelindex, skin, (frame1time nyi), (frame2time nyi), frame, frame2, lerpfrac, origin, (velocity qw players only), angles, colormap, scale, alpha.
Update: Callbacks for every single entity every single frame whether it moved or not was resulting in some really noticeable FPS loss. Now, you register a function to be called when the engine would link an engine edict - based on its model name (actually its modelindex). Wildcards should be supported (delayed precaches will need to remember it). if supported (nexuiz players need such selections). Registering by model cuts out a redundant ent-copy and prevents the qc from having to ignore ents it didn't care about. This saves a significant amount of fps for me. It may also allow engine greater code reuse for other engines.

movetypes? Currently its an implement-your-own aproach, and touch events are not easy.
Expanding csqc to do it automatically is possible, but may result in conflicts between current/future mods. It was intended to be a separate extension.

clientside prediction. specifically touching other entities.
there's no touchtriggers function. EnumerateTriggers, pass a function pointer and get told about all the triggers in the box? Extend to solids?
Prediction is fully implemented in my csqctest mod. Moving platforms are a little awkward, but the rest works fine.
Teleporters can be predicted, but finding the triggers is via a linked list in qc.

serverside (custom) prediction handling.
qc is called upon receipt of a movement command. QC must copy entity fields into globals before calling the predict builtin.
QC could just use the ent and predict based on that, but the function is intended to be shared between ss and cs, so the csqc needs to be able to revert the ent to a previous state easily.
I'm having serious doubts over the use of pmove_* in the first place now. input_* is fine still.
csqc ought to read movevars itself. the builtin set are too specific.
The main problem at the mo is triggering touch events. With no parent ent, touches cannot be done via the engine. With no self, the ssqc pmove code can't trigger events either, and tracelines will hit itself.
If self is moved, instead of using globals, this would presumably be more intuitive to qc coders. Touch functions can be called by engine code (and added to qc code). This can work in csqc and ssqc, automatically, no need to worry about touching triggers, as they'd be auto-touched. csqc ents need to be aware that its touches need to be revertable, or might not occur that frame (q3 predicts item grabs).
Thoughts on this?

[LordHavoc]

[Spike]

[Spike]

Posts updated. I could really do with some feedback on how you'd like to do things.
Particularly the default-prediction function. Change to ents, or stick with globals?

If I don't get feedback, I'll just end up doing things the easy way then moan when noone follows the 'standard'. Be warned. :P

[Chris]

* full bone controllers, access to all bones / joints / tags in a model and offsetting them / getting and setting data.

* client -> server communication in which I can specify a function to receive the string / float / vector passed in, not have it have to be stuffed into only a couple functions like Gamecommand or ParseClientCommand and deal with a giant switch statement (also server -> client would be nice to have this as well)

* multi-anim support, be able to play multiple animations on the same model by determining which bone in the hierarchy to play below (or above, the exact implementation is irrelevant as long as it is easily exposed to qc and works).

* engine side prediction of origin / angles optional flag for csqc entities

* net priority beyond the "if its distant send less". So I can give priority to things that I feel in qc are more / less important

* post processing effects, whether this be premade glsl shaders exposed to qc or otherwise, just allow for things like motion blur, capture screen and overlay, warping effects, color desaturation.

* sound occlusion abilities / integrate third party sound software for pitch modulation, and premade abilities like reverberation etc.

* properly integrated physics (beyond movetype_bounce etc) such as basic rigid body with constraints control that is handled engine side for optimum speed and exposed to qc thoughtfully with general architecture and attention to use (also known as, well documented)

* built in compression algorithms that automatically compress certain pieces of data and extrapolate that data when sending to csqc.

* flag to expose server side entity to csqc but not have it handle the prediction

* special care for simulated players in csqc in which the prediction is handled by engine however csqc has the information about them when they are relevant (ie, being rendered on screen)

* not needing to change map, ability to do some sort of data streaming for progressive maps so you stream in another map, have qc handle cleaning up it's entities and making pseudo garbage collection and allow not having to load a brand new map.


* render viewport to brush / poly(s)

* make your damn compiler support unique data types / structs

* custom iterators that can be specified in engine to be cataloged for quick access (yes you can make it in qc, but it really shouldn't have to be)

* (.)string to (.)void(...) support in csqc/svqc, so I can set up function pointers read from a text file

* seek currently playing ogg/audio file exposed to qc

* true type font or better means than conchars (ew)

* vector graphics, when I run at 640x480 I can't read any text and images are all blurry

* save / load picture from file directly and put this onto a model / poly / brush. (slow bad example but it would work: if I want what I see to be rendered as a half transparent shader over a person)



- These changes might not all be pertinent purely to csqc, but hell I want them.

[Spike]

[Electro]

oi! keep me out of this

All in all looks like good stuff. Just hopefully some of it is documented better from now on and has a kind of CSQC basemod that is made, making use of it all. Otherwise all this will kind of get lost in the wind.. that is traveling ridiculously fast..

[goldenboy]

csqc really needs to be supported by more engines. (Engines that mappers will use, engines that multiplayer types will use)

I have been aware of the things csqc could do for RemakeQuake for quite some time now. But it's not supported well enough. Or documented.

What I'd want: That it works in software, that it is supported by more engines (remaining crossplatform, too), that it is better documented.

As for an example mod ... RemakeQuake could demonstrate a csqc inventory and other stuff pretty well, if it comes to it... I'd estimate that is still some time away though. I would be open toward this, not sure about the others (we have our hands full with other stuff right now). Perhaps some time after qexpo we can start thinking about this. We do eventually want some stuff that would apparently best be done with csqc, though. So we would be a natural ally.

Just thinking out loud

[Urre]

Chris said an important one, csqc->ssqc communication made sane.

The way it works from ssqc->csqc seems more sane and specificly dedicated for the task than all the interpretation and parsing you need to do when sending info from csqc to ssqc.

I currently have the csqc control the clients position completely, and want to send this information to ssqc for proper pvs updates, overriding the current ssqc position of the client. I also send mouse click events, which vary depending on context, and it feels very convoluted and weird right now, sending commands through the console and whatnot...

The area of uses will expand for me, and I bet Chris already has a wider span of tasks where csqc needs to communicate to ssqc.

On a side-note, mostly DP specific and doesn't have much to do with the spec, I really want packetloss handling and DP7 distance-handling for shared ents. Currently none of those are supported, even if they exist for regular serverside entities. I bet FTE would benefit from these features as well.

I'll post more thoughts as they arise, but the communication is a big one.

[mh]

[Spike]

[Chris]

I always thought of it you target what function you want to send to which'd have an identical function signature. So for example in csqc:


void SendDataToServer(string funcName, string data);

So then you have a function that takes the following parameters after it possibly and then in svqc you have that function which gets filled with those values passed. And converts string to the proper function name and inputs the 'data' parameter as it's only argument.


For more complex things like say you don't want to deal with parsing a string and sending any combination of floats / vectors I don't know, I just dislike having to use only a couple of outlets to send data to, I also don't like how any data being sent to and fro from svqc/csqc with the current method is easily replicatable via the console making it extremely easy to mess with just by chance. Whether the whole system is safe or not something not exposed to a simple console terminal is still miles better.

I don't pretend like I know the best way to implement this, there might be a better design out there, this was more a knee jerk reaction to how I'd feel I'd use it.

[Spike]

[Spike]

[Urre]

I doubt most will care in the end, but if you want to do things right, you would drop that requirement. Especially seeing you've already had software renderers as the main reason not to implement a bunch of graphics-specific features as part of the base spec. I'd say this is especially important if we are to see csqc really happen in engines on other platforms, like various handhelds and whatnot.

Concerning the csqc->ssqc talk, have I got it right if I interpret your example as the first two parameters of the send function being the last two parts of the function name in the recieve function? Cause that seems pretty awesome.