Concatenate long configstrings?

[res2k]

As Paril commented here: Paril/q2repro@82b5600 a couple of bytes could be saved by sending long configstrings (notably the statusbar) as one string, instead of splitting them up.

Things to consider:

• Concatenate implicitly or explicitly on writing?
  Implicitly would mean we detect "back to back" configstrings and write a longer string without an ID in between. (Ie the client provides CS_STATUSBAR + 0 ... CS_STATUSBAR + n).
  Explicitly means the client sends possibly long strings as one (ie the client just provides one long CS_STATUSBAR) and the library splits it up.
• Similar question for reading: Provide a single configstring, or still separate parts?
• In any case, we probably need to know the "max configstring" depending on game type.
• I would like to avoid the library having to have knowledge which configstrings can be "long" or not.
• ... which probably means write as a single string, but reading still returns separate parts.

[Paril]

It's a tough one because it's protocol-specific. In re-release, only CS_STATUSBAR and CS_GENERAL are "allowed" to span multiple lines; for security reasons, every other string should only be allowed to reach the end of the line (null-terminated). I guess what you could do, though, is just offload that concept to the protocol callee, so basically q2proto would just treat the entire configstring "block" as one large binary blob (it doesn't care what is in it, it just knows that there may be gaps that are unused and can be skipped over). Assuming the callee also ensures that everything is null terminated as it wishes, we can also leave the null termination bytes out of the data (so CS_AIRACCEL for instance would only send a max of 63/95 chars, since the null termination is assumed by the callee).

Maybe there's a compression method we can use that supports the 'assumptions' that configstrings have, like that they always start on a 64 (or 96) byte boundary.

[res2k]

My thinking right now is:

• The q2proto client_read functions just pass through the config strings as they appear in the received message(s). So when processing these message, they should be checked against the maximum length for a specific configstring index - which is good practice, anyway.
• Regarding the q2proto server_write functions, we really only need to look at q2proto_server_write_gamestate, since that's the only function taking more than one configstring at once. Here I think we can do some automagic and combine configstrings that directly follow each other in memory into a bigger string.
  Caveat: this can mess up things when a configstring is not null-terminated - it may be combined with the following string and sent as one, but the client may restrict it's length, losing any data beyond the first string. But I think that's okay: configstrings are supposed to be null-terminated anyway, so any configstring not null-terminated probably indicates some bug anyway (with the exception of statusbar & general, of course).
• Otherwise, configstrings are sent one-by-one anyway, so we can't combine automatically right now, so the client would have to do so. (Though we could add a way to send multiple configstrings at once, should that turn out to be useful.)