Author Topic: force disconnect when loading datablocks  (Read 3990 times)


as soon as blockland tries to load datablocks, i get booted and this pops up
help

Delete your loving pc

User was banned for this post
« Last Edit: March 18, 2018, 09:59:17 PM by Badspot »

if you're on steam verify cache

uninstall/reinstall blockland glass or
if you're on steam verify cache

Delete your loving pc

User was banned for this post
good night alt right


If you aren't on Steam, deleting m.dts and allowing the launcher to redownload it may help.

Its an error related to when the server sends a TSShapeConstructor datablock. The shape path is sent along with the names of each sequence and their corresponding dsq name, and it has nothing to do with the cache. Notice how the sequence name itself is completely blank..

I had a friend who made a player type with a massive amount of sequences and this started happening arbitrarily, and because of this it was difficult to debug. But there are two[1][2] garage game topics that address this problem directly, and the issue is writing too many bytes per datablock packet, something that would happen with craptons of sequences. An easy fix for addon makers would either be reducing sequence/dsq file name length or using that "stuff multiple sequences into one dsq" trick to substantially reduce the number of bytes written.

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.

It seems that as long as you do priorities right and export the animations as part of the .dts, there generally is minimal problems regarding animations being correct or the model crashing servers.

Note that all of this was noted while using ports exporter - may have different results with 2.49b's exporter.

The quickest fix is to just disable whatever mod is causing the issues, otherwise fixing the actual add-on is the only way to remedy.

I always wished these errors were more descriptive for servers hosts to debug easier

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

honestly the netcode is forgeted in general considering the packet size limit is so small, and the default packet rate so slow. unfortunately the existence of prehistoric internet speeds prevents just forcing fast packets alll the time, sigh

^ that is the exact same bug that was causing stuck loading, file downloads also wrote too much stuff into the packet buffer even though it doesn't actually fit.