Devlog KAG February Plans, plus Modded Server Feedback and Submissions

Thanks for the clarification @Diprog - I've covered stuff about bad deltas over here https://forum.thd.vg/threads/bad-delta-msg_inventory_putin-network-id-for-blobs.26326/page-2 but it's indeed a hard thing to track down.

Sorry for not finding time for this - as you might have noticed, noone else is working on it. I'll talk with joe about if we have the capacity for this in other regions, it should be fine but I need to set aside a day to focus on it (requires carefully distributing the files and getting the management script running, neither are particularly automated at the moment).

 

Unfortunately, no. As I wrote in that thread, by the time the bad delta is detected, all you can say is that something "went wrong processing the last packet", which is similar to the last frame but it could be spread across multiple frames for multiple users.
The only way to solve those issues is to go through and make sure that:

• You have matched up your onHits between client and server
• You are 100% sure that every time you prepare a bitstream for a command, it's done correctly and that all the command callbacks read it correctly (can often help to wrap these in their own functions so you can compare more easily)
• You are 100% sure that all the command IDs are added in the same order on server and client, and that none are missing on server and client.
  
• If you're doing anything with the "advanced" network functions like those related to createdata, that you do it even more carefully than you would all of the above.