TypeHash invalid with a custom online subsystem
Since version 4.20, the client/server projects are returning
LogNet: Warning: Error with encoded type hash
I have a custom Online subsystem
The problem is that we cannot provide a hash type with the subsystem "Kadeo"
In NetSerialize function
With custom online subsystem, it return 0 since the subsystem cannot be registered in FOnlineSubsystemUtils in the private function CreateNameHashes()
How can I register my own online subsystem ?
asked Aug 07 '18 at 08:16 AM in C++ Programming
Apologies for breaking your custom online subsystem implementations. Two features that improved UniqueId overall came together to break the code in question.
1) UniqueId compression - up until now, in the interest of simplicity, we were simplify passing a string across the network. This was grossly inefficient, but for small player counts it wasn't on our radar. For Epic's unique id scheme, a guid, it was 43 bytes to replicate. We found that we could pack this into nibbles and save a ton of space. The code now serializes at 18 bytes, which is significant savings in FNBR where we replicate 100 user ids to everyone (10k replications x 43 bytes). Additionally for cross play we replicate other platform unique ids (10k x 64bit number in string format). These weren't as big a savings, but since they were straight up integers, we could pack them the same way.
2) UniqueId type - again for crossplay, we needed to better understand what type of UniqueId we were dealing with without having to cross reference other systems. Replicating the type without losing savings from 1 is the reason for the "hash/index" value that is causing you trouble. 5 bits of the packet were used to have room for 32 online subsystems. Of course this means we need to know ahead of time all the values. This is clearly not conducive to custom implementations.
We are going to fix this. We will use one of the bits to signify a custom Online Subsystem, and pack the name of your system into the packet. We thought about some way to deterministically register all known online subsystems, but this won't work given that not all will register in all scenarios (not all platforms register all subsystems). The simplest thing to do is sacrifice a little bit of the compression savings for simplicity and convenience.
We are looking to get an implementation in ASAP and have it available with the one of the next 4.20 hotfix releases.
Apologies for the delay in a response, we do not often get a lot of visibility into specific forum issues. I hope this addresses the concerns, the online team does care about the pains of other developers.
answered Aug 24 '18 at 07:29 PM
answered Aug 24 '18 at 12:40 PM
Thank you for taking the time to write the detailed explanation and looking into fixing this! Now it makes sense.
answered Aug 24 '18 at 09:06 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here