actually @val im pretty sure the exact opposite is true. stuffing too many sequences into one dsq seems to cause a bunch of problems the bigger it gets. i had to drop TSShapeConstructor use entirely for my dueling swords as after adding the scimitar, half the animations were just straight up broken if i used a TSShapeConstructor + dsq.
Indeed, the sequence path and names are sent over the network as a string which is limited to 256 bytes, and further (for no reason) limited to (shape path + filename + names) of 90 bytes. So, somewhere around a dozen names-- not surprising you experienced errors. Use the multi-seq DSQs as a supplement, not a single solution. And I'm sure you know but not using a TSShapeConstructor will mean not being able to dynamically load animations into models with similar skeletons.
On another note, I dug into the source to see why this bug happened randomly. Manually adding up the bytes of my friend's playertype sequence names didn't place it anywhere near the fixed packet size of 1023 (technically 1500), which meant a write error would only happen with the company of other event's/ghost's data. There doesn't seem to be any checks if the per-packet bitstream has ample room for another chunk of data to be stuffed in it. The process is something like this per tick:
Server end:
1. Allocate a bitstream, size is specified as 1023 but write limit is 1500
2. Write headers, connection related info
3. Write client related data like control object, move acks, etc.
4. Write events, before each event is written the code checks if the bitstream is full, using the 1023 limit
5. If not, write the event (without any checks if the event is too big even for the 1500 limit)
6. Write ghosts (even if stream is full, although it should error out quickly)
7. Write the final buffer to the client. Size can even be over the 1023 limit (ie, 1200 is valid)
Client end (simplified):
1. Receive bytes, number read = number sent as mentioned
2. Read events until nothing can be read anymore (unpack half written events too)
3. Interpret events (process)
What happens when more than 1500 bytes are written, in the case of a TSShapeConstructor event stuffed into a nearly full stream? The stream sets an error flag, resulting in a null string (hence blank sequence name in OP), but absolutely nothing is done anywhere-- it just sends that forgeter like any other piece of legitimate data. And there's supposed to be even more data after that, not to mention ghost updates haven't been written either, but as the stream keeps erroring out the size doesn't increase making it capped at 1500 bytes. So the client gets an incomplete buffer and is expected to just go with it (there's no error handling for this either, but any read functions should return 0), this causes a buffer overflow sometimes when I was testing it. In the right scenario it will cause this exact missing sequence error with whatever unlucky model.
This is a rare but serious bug in the net code. It's easily fixable-- even with a DLL!! Need some kind of check to make sure I made some test code to trigger the bug on my LAN server. I can trigger it every 5 joins or so, and like I said some of them end in runtime errors.
Result
