QSB network protocol

[Urre]

I felt it was easiest this way, let's just settle it with a vote.

I'm asking this because it'd be a lot easier to settle on what features to support if you don't have to care about network protocol compatibility, but it'd make multiplayer-mods made for QSB meaningless.

Note that QuakeWorld engines adopting QSB would have their own variant of this network protocol, QuakeWorld and NetQuake engines wouldn't need to be compatible between eachother.

Also supporting the old protocol would be a requirement.

[Downsider]

I know there's going to be a new protocol, but what should it support?

I'm thinking HUD and movement prediction are two definites.

[Urre]

It'd support whatever features the standard supports which are related to network changes. Prediction for NetQuake is definitely overkill, and hasn't been suggested earlier.

This is not about suggesting new network protocol related features, but rather if it should be standardized or not. Otherwise QSB 1.0 would be a singleplayer standard only.

[Spirit]

I say yes. The engine land is in good shape and the important engines would have it implemented, I am sure.

[mh]

Yes from me too. It's well past time we had a standardised extended protocol.

[frag.machine]

Yes, QSB should require a new protocol. But this doesn't mean discarding support to protocol 15 (I believe this must be required in fact) and, optionally, any other engine-specific implementation (DP7, FitzQuake 666, etc).

[Baker]

Yes. And maybe it can have some kind of compression and support download of maps, models, sprites and sounds.

[Spike]

Clients should support something a bit better, but I'm not sure its practical to mandate incompatibilities on servers, as I previously mentioned.

The preconnection stuff *needs* fixing. QW/DP/Q2 are example improvements here. The current stuff is b0rked with NATS, routers, and the smurf stuff, etc. If there was one replacement, this would be it, stating the protocols that the client supports so the server can give a clean message saying what the client needs to support to connect (or perhaps where to get a compatible one from).

NQ's lack of delta compression results in large demos, and a lot of data flowing over the net. Thinking about it, many engines already have extensions to their existing entities for alpha/scale/etc. Adding such extra fields by adding full delta compression at the same time would potentially reduce conflicts with existing demos from such engines (nehara comes to mind).

Sending the gamedir name would also be good. It doesn't have to be supported clientside, but a nice message saying you're running the mod from the wrong gamedir would be nice. Download support would greatly simplify things too, but questionable - not all engines safely load all data formats (id's did not).

Prediction is too tricky really. It can't really be done without the mod supporting it too, at least not accurately and without huge hacks and assumptions. I do not feel it to be practical without some client side game code of some kind also in the standard. So no prediction.

Clientside game code also applies to HUDs, although a Q2-like hud-string aproach may be workable.

QW engines would need various bits expected by most NQ mods - svc_particle would be the obvious example. QW is a bit more current.

Behaviour should be defined for engines that do not provide everything. Eg: engines unable to render alpha treat ents with low alpha values as invisible, as opposed to silently ignoring alpha. This applies even if the full QSG standard requires alpha. This allows gradual compliance.

[goldenboy]

Just one thing, I thought protocol 999 would be a good name perhaps.

[Spike]

Just one thing, I thought protocol 999 would be a good name perhaps.

that would only be a good name if you're creating it in an emergency. :s
Having said that, adding 1 and using the version number*1000 would not be too bad a plan.

[ceriux]

what would be wrong with multiplayer mods again?

[Spike]

public servers generally prefer to allow as many clients as possible.
By using an extended protocol on a dedicated server, you effectively ban a whole load of clients (any that don't support the extensions).
You can draw your own conclusions from that.

Depends on the server implementation, tbh, so imho any such extensions shouldn't be made to exclude the possibility of dual-protocol servers.

[Team Xlink]

what would be wrong with multiplayer mods again?

They might not work because of the new protocol, unless there was backwards compatibility with the stock protocol along with the new QSB protocol.

[Downsider]

I've always wondered why a new protocol was needed for something like movement prediction of the character and why no NetQuake engines support the prediction. Isn't just simply doing the same movement code that the server does on the client as well?

[ceriux]

ahh ic so basically if they didnt use the qsb engine the multiplayer mod would be useless? but if it was developed specifically on it. then there would be no problems?