Server R7 Protocol

skyjake

<i>This post was originally made by <b>skyjake</b> on the dengDevs blog. It was posted under the category: Engine.</i>

In light of the changes needed to fix the problems currently plaguing netgames, I am incrementing the server version number to R7 (i.e., revision 7). Likewise, the Doomsday version number is incremented to 10900. This means that clients running 1.8.6 or older versions will not be able to connect to 1.9.0 servers, and old demos recorded with 1.8.6 or older versions will not play in 1.9.0 (unless a compatibility mode is implemented in the protocol).

In practice, I am adding new delta identifiers and increasing the size of the flags fields of at least the sector and side deltas. Old clients would not understand these new delta types and would exit with an error message. The old delta identifiers will get an "_R6" suffix (e.g., DT_SIDE_R6) but retain their numbers.

Compatibility with old demos can be retained if we allow that SV_VERSION can be 6 in the handshake, and make sure the R6 delta types are handled correctly.

DaniJ

What changes are needed to fix the current problems?

skyjake

I mentioned a couple of things in the post (delta flag fields, new delta types). The introduction of a new delta type alone necessitates incrementing the Doomsday version number so that old clients can't connect to a newer server and get confused about new kinds of deltas that they don't understand.

The other changes that I know of (so far):
<ul>
<li>The client will be expected to do more stuff locally, like animate the psprites during firing animations. In the future the server won't be sending any pspr deltas for interactive pspr animations (perhaps none at all under any circumstances).
<li>Under poor network connection circumstances, the way player commands are sent to the server (e.g., door opening) seems broken. For example, when the client tried to open a door, the door would begin to open but very shortly afterwards another use event closed the door, before the door had risen more than a few units. This may require protocol-level changes.
<li>Sometimes (also when the connection is poor), certain mobj deltas (gun puffs) are apparently processed in the wrong order, resulting in clmobjs with the wrong state (puffs that look like imps). This may require that the mobj deltas are sent or interpreted in a different way.
</ul>

More issues will probably be raised by further debugging.

skyjake

In demo recording, something has to be done about the psprite animations, though. Perhaps a client that records a demo will need to write the psprite animation data into the demo file itself.

DaniJ

<blockquote>The client will be expected to do more stuff locally, like animate the psprites during firing animations. In the future the server won't be sending any pspr deltas for interactive pspr animations (perhaps none at all under any circumstances).</blockquote>
That reminds me, we could do with having a look at how psprite movement is handled. If I remember correctly we need to move the position update notifications into a game-side ticker (not 35hz) so that Doomsday has a better chance of interpolating them. Currently the movement of the chainsaw in particular is very jerky due to the infrequency of postion updates.