Quake 2 protocol question- maximum edicts

[qbism]

In Q2 code MAX_EDICTS is 1024. The comment says that's the max possible without changing protocol. But isn't the max 8192 like Q1? Entities are passed as shorts, and sound entity parsing shaves off 3 bits, leaving 13 bits (8192). Is there anything else in message parsing that takes 6 bits leaving 10 (1024) ?

taking 3 bits for channel in CL_ParseStartSoundPacket:

Code: Select all

   if (flags & SND_ENT)
   {   // entity reletive
      channel = MSG_ReadShort(&net_message);
      ent = channel>>3;
      if (ent > MAX_EDICTS)
         Com_Error (ERR_DROP,"CL_ParseStartSoundPacket: ent = %i", ent);

      channel &= 7;
   }

[Spike]

you can encode the extra ent bits into the flags byte, as there's 3 unused bits there, or just add a flag to separate ent+channel.
Also, make sure you fix signed->unsigned in cl_parsemuzzleflash* too
ultimately, the gamecode decides the max, not the engine.
you might want to make sure that the various places that parse entity numbers parse an unsigned short and not a signed one.
beware of local arrays. if these arrays are too big they can segfault you.

Vanilla NQ protocol has a max of 65536, once its been fixed to use unsigned shorts instead of signed... and muuuch bigger datagrams.
Vanilla QW protocol has a max of 512 due to entity delta encoding, and 2048 due to sound encoding.

[qbism]

Using the unused bits is interesting because it doesn't break protocol. A modified client can still connect to a vanilla server.

[Spike]

you can achieve the same thing by using a different/new svc only where the old svc is not sufficient. less surprises when the vanilla clients see bigger numbers, but up to you really. what do other q2 engines do?

[qbism]

other q2 engines-
kmq2 uses additional byte flags for more sounds, animation frames, etc. similar to QIP or FQ extended protocols.
r1q2 uses spare bits to reduce packet size, q2pro is similar. They each use 27 bits instead of 32 for framenum as an example (the other 5 are framenum offset from previous frame). Svc commands only need 5 bits.
BerserkerQ2 uses extra byte flags and packet compression but didn't dig deep enough to see how compressed.

[Knightmare]

you can encode the extra ent bits into the flags byte, as there's 3 unused bits there, or just add a flag to separate ent+channel.
Also, make sure you fix signed->unsigned in cl_parsemuzzleflash* too

By fixing this you mean adding a cast the first ReadShort() call in CL_ParseMuzzleFlash() and CL_ParseMuzzleFlash2()?

Code: Select all

   i = MSG_ReadShort (&net_message);


to

Code: Select all

   i = (unsigned short)MSG_ReadShort (&net_message);


Using the unused bits in flags isn't required for a modified client (which supports a new protocol) to connect to a vanilla server, as the client can just check the protocol version and parse accordingly.

Putting the 3 extra bits into the flags byte could be done like this:

Code: Select all

flags |= ( ((unsigned short)ent & (32768|16384|8192)) >> 8 );


kmq2 uses additional byte flags for more sounds, animation frames, etc. similar to QIP or FQ extended protocols.

I didn't add any new animation frames to KMQ2. I did add larger model and sound indexes, larger 24-bit map coordinates (20.3), 2 more models per entity (modelindex 5 and 6), and entity alpha and looped sound attenuation.

[qbism]

I didn't add any new animation frames to KMQ2. I did add larger model and sound indexes, larger 24-bit map coordinates (20.3), 2 more models per entity (modelindex 5 and 6), and entity alpha and looped sound attenuation.

Oops, thanks for clarification. I'd assumed it was extended protocol, but stock Q2 can send a short for animation frame.

[Jay Dolan]

Hm, hopefully I'm wrong, but I think you'll run into overflows on connecting if you add a buttload more entities. Un-vis'ed or poorly-vis'ed maps with only a few hundred entities already have this problem. No?

[qbism]

Overflows may be related to signed vs unsigned code errors? 3.24 does fine right up to maxentities, usually 1024.

[Spike]

he means packet overflows. trying to send 65000 entities to a client in a single packet is basically doomed to failure when a packet is limited to 1450 bytes or so.

additionally, vanilla q2 uses a ringbuffer for its entity states, this ring buffer is *meant* to contain enough slots for 16 frames of up to 64 entities. essentually, the more entities you send within a single frame, the less frames you can use before it starts to bug out.
while this doesn't necessarily limit the size of a map, it does limit the complexity. you can't have too many entities within a single space or you'll have problems.

both fte+dp have changed their network protocols to alieviate this. by sending data based upon pending flags, and having the client report when a packet was dropped (causing the server to re-add the dropped flags to the pending state) the server no longer needs to track complete state for every entity (just 64ish ent index+flags per frame), and the client no longer needs a complete copy of the last X frames.
This method scales better with memory usage, and avoids repeatedly resending everything until its acked, both of which are significant when you potentially have 65k entities visible at once.

[qbism]

additionally, vanilla q2 uses a ringbuffer for its entity states, this ring buffer is *meant* to contain enough slots for 16 frames of up to 64 entities. essentually, the more entities you send within a single frame, the less frames you can use before it starts to bug out.

16 x 64 = 1024, same as max edicts. Coincidence? I suppose that over a network, usable max could be less than 1024 considering some combination of packet loss and small packet size.

Un-vis'ed or poorly-vis'ed maps with only a few hundred entities already have this problem. No?

...and during gameplay in a coop situation, more entities are created, then everyone fires their bfg...

[Spike]

make a map with 900 ents in a single room. see what happens.