Download

[Fix Incoming] Seriously damaging change to Online Subsystems in 4.20

https://answers.unrealengine.com/que…ml?sort=oldest

You now cannot create your own Online Subsystems as plugins, as you have to modify the engine to support a custom OSS. This seems like an enormous step backwards and a huge oversight. I can’t really understand why this was necessary? IMO the engine should be opening up to supporting more modular features.

There have been several major changes to OSS’ in 4.20 which initially led to many projects (particularly Steam) not working online at all until the 4.20.1 hotfix. Not to be a pitchfork-wielder, but this feels a little bit like features are being shoehorned in from Fortnite and we’re suffering as a result.

Please maintain modularity - it’s one of the engines strengths and frankly needs more focus.

I’ll also raise a pitchfork here.It’s been frustrating that the current version of of Unreal doesn’t match the most recent version of steamworks, but this is unwise.

Also interested in this

Adding a fourth voice to the issue, it’s a gigantic problem for us.

I bet this is coming from someone not tracking state of the pre-built (Launcher) engines… With head too deep into GitHub ecosystem.

Adding a sixth voice.

Pitchfork raised.

I’m adding a voice too.

+1 here, doesn’t effect me yet, but could affect our networking going forward - don’t really want to have to end up doing custom engine builds for the entire team when half of us work remotely.

It’s been a few days and seen some tweets go out about this. Wondering when it will have anyone look into it =/

Unless you poke someone at Epic directly (via @ here or on Twitter or on Discord), no one will chime in to explain why it was done and what do expect moving forward.

Tried twitter with no avail. Not sure who to tag here, but feel free peeps.

i support this thread, hoping someone from Epic will read it.

Hey all, just wanted to let you know we hear you and I’ll start the conversations internally about this.

Thanks!

Please try not to break the engine in future updates @Epic

Hey all,

We’re looking at getting a fix in for this. I don’t have an ETA for you at this time, but stay tuned.

Thanks for bringing this to our attention.

~Tim

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 * 43 bytes). Additionally for cross play we replicate other platform unique ids (10k * 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.

Thank you @Crzyhomer for (what is for this forum’s standard) a very swift and very detailed response. Looking forward to the fix!

Thanks for a detailed response, this certainly explains a lot! I’m glad that ultimately the new code will result in some net optimizations. Also, big thanks for (hopefully) squeezing it into a Hotfix!

Editing the title to reduce pitchfork-ness.

Any updates on this? I believe we are running into this and its critically holding up development.

Cheers!