SvcSplitScreen edge case (potential solution?)

[p2r3]

While testing some Portal 2 co-op splitscreen demos for my own parser, I managed to record a demo in which both my parser and UntitledParser misread SvcSplitScreen, causing the next netmessage to fail: fakeplayer.zip

In most demos, SvcSplitScreen comes alone in a Packet message, but this one is at the very top of the first SignOn message. I'm not sure why, and I haven't been able to replicate that since. This misread causes the very first SignOn to be dropped, which of course spells doom for the string tables.

Since there's no available engine code that doesn't use protobuf for this packet (I'm not even sure where y'all got the current definition), I can't know for sure what the issue is. I theorized that the data buffer might consist of full bytes, which is how I came to the "solution" of reading an extra 8 - length % 8 bits.

This seems to work - string tables are parsed fine and no other issues arise - but I'm not sure if I just got lucky. At the very least, this fix can't hurt. Since SvcSplitScreen usually comes alone in a Packet, it won't break "normal" demos, and it might fix unusual ones like this one.

Never mind! I thought I had figured out the issue, but I did indeed just get lucky. Upon further testing, I do get a sensible output if I read the packet as 13 bits (1 bit "remove" flag, 11 bits "length", 1 bit ???), but I won't pretend to understand why that is. My way of confirming this was to check that the immediate next netmessage, which in this case was SvcPrint, contained an intact string.

[p2r3]

I imagine that the currently documented format for that packet is just completely wrong, and that something else is being encoded in those 13 bits. At least it's consistently 13, and the bitstream is consistently 0101000000000, at least for Portal 2.

Again, given that the message is almost always in its own packet in a normal demo, I can't imagine it'd hurt to simply parse it as 13 bits of unlabeled "data" in every case.