A new standardised protocol?

[metlslime]

[mh]

[Spike]

FTEQW's extended QW protocol strips out any additional features that clients do not support, on an individual feature basis. This keeps it extensible, but if I use bits badly, the only way to fix it is to remove features again later...
You'll find that many things the server sends are sent on a per-client basis anyway. Entities, for example, are the bulk of the data sent over the protocol, they're the thing that most engines modify first. And they're always sent on a per-client basis (with the exception of baselines).
Its fairly trivial to do this really.
If you use different svc ids, then the client says what it supports, and never even has to check to see which version is being used.

Yes, FTEQW supports DP5 through DP7 protocols in its client, but only 6 and 7 on the server. Or something like that. It probably doesn't support the more recent changes to DP7 though.
Unlike the differences between QW and NQ, DP7 vs NQ has no major incompatibilities. The major differences are simply limits, stats, and entities. Although yes, there are a couple of other twiddles around the place.

If the mod doesn't use the extra features of a protocol anyway, then it really doesn't matter if the protocol is downgraded.

FTEQW demos have an additional bitmask in the svc_serverdata (svc_serverinfo for you NQ people), which specifies the extensions used in that demo. This is a re-statement of what the client already knows, of course, but its useful to at least warn clients that there are features in the protocol that it might not recognise. You can only play that demo with a client that supports all the original features. This is a bit of a hinderance but not a major issue.

Just think... If all engines supported csqc and the same protocol extensions to support it, then any other protocol limitations could be worked around... *cough*

[mh]

Point me at the info and documentation on CSQC and I'll happily support it.

Right now I'm having a hard time finding anything useful; the best I can find is this: http://www.fteqw.com/wiki/index.php?title=EXT_CSQC which looks like a journey through trial and error - not my idea of fun. Same applies to attempting to reverse-engineer something from another engine.

If it's so cool and useful and solves all problems, it really should be made more accessible to people.

[Urre]

mh: you know, people keep saying that all the time. I guess it's different when it comes to integrating it to your engine, but learning the qc side of it probably isn't as hard. But I can understand people not being entirely keen on learning how to create an entire codebase based on incomplete lists of system globals, builtins and functions. Dresk did most of the hard work, and I just expanded on that. If you know qc, and feel adventurous, it's kind of fun actually.

I've promised to write up some tutorials or something of that kind for csqc, will have to get started on that soon...

[mh]

I think this slight sidetrack has highlighted one absolute must-have for any proposed new protocol. Whatever comes out of this discussion absolutely NEEDS to be documented properly. It might be the greatest protocol in the world, but if it can't be implemented quickly and easily in existing codebases (including stock GLQuake), it won't really get much uptake.

[LordHavoc]

[LordHavoc]

[Urre]

[LordHavoc]

[scar3crow]

[Lardarse]

Possibly off-topic here, but I can't see a more suitable topic for it, and I don't know if it deserves a topic of its own:

How to include .alpha support in an engine when nothing about it is mentioned in the QuakeC: http://www.celephais.net/board/view_thread.php?id=60190 posts 11 and 14.

[frag.machine]

/me bumps the thread with a slightly different but related topic...

I was thinking about how sending coordinates values as longs eats so much network bandwidth when I stumbled in a really simple idea to avoid it. It's so simple that either it's likely to be wrong and just don't work (although I must confess I cannot see why not) or somebody else already had this insight and I didn't realize it . Anyway...

Let's say that we split the world in a three-dimensional grid of cubic sectors with 8192 units side, the first sector starting at the lowest coordinates values ('-maxx -maxy -maxz') and the last sector starting in the highest (that's it, 'maxx-8192 maxy-8192 maxz-8192'). Then, when we want to send a coordinate, instead of sending 3 longs (12 bytes) we do some math and send instead the corresponding sector index, and 3 shorts representing the coordinate offsets inside this sector. In the client side we apply the inverse calculation and restore the x, y and z values corresponding to the sector and add the offsets to this to get the final coordinate values. I did a quick math, and assuming a 256 sectors grid (so the index would fit in a single byte) we can have coordinates ranging from '-32768 -32768 -8192' to '32767 32767 8191', the biggest drawback in this case is that Z values couldn't be as big as the other axis (but frankly, I don't think it's a big deal, and one willing to expand it could just use a short to send the sector index instead and still would save a good ammount of bandwidth).

Anyone here can see a reason why this would not work ?

[Spike]

[metlslime]