Quake 2 protocol question- maximum edicts

[qbism]

[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]

[qbism]

[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]

[Spike]

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