when a dynamically created Component on the DS is synchronized to the client, executing an RPC in the client’s BeginPlay triggers an ensure, and the DS receives an incorrect packet, causing the client to be kicked out.
This is definitely unexpected behavior, as it should be supported to call a RPC from a component’s BeginPlay.
That being said, I’ve been unable to reproduce this in my own test project. To get a better idea of the problem, I have a couple of questions.
First, could you provide some more info on exactly how this component is being created? The “Client attempted to create sub-object” error occurs when the server receives a bunch referencing a subobject that doesn’t exist locally, which seems unexpected given that the component would have been first created on the server.
Next, is the owning actor dynamically spawned or placed in the map, and is it using dormancy?
Finally, is the server RPC reliable or unreliable?
Any other relevant info you can provide on your setup would be appreciated.
The details are as follows: after starting the game, the client calls the GM with “testactorcomp,” which triggers CreateTestActorCompInDS on the DS to create a Component and sets its SetIsReplicated(true).
Then, a Server Reliable RPC is called in the Component’s BeginPlay after being synchronized to the client, which triggers the error I initially described.
I’ve been able to reproduce a similar issue in my own test project, although I haven’t seen the “Client attempted to create sub-object” ensure. I’m still not sure why you’re seeing this particular error, as this should only occur on the server when the client sends a bunch for a subobject that doesn’t exist on the server. In my project, I’m instead seeing this ensure hit in UNetDriver::ProcessRemoteFunction: “Attempted to call ProcessRemoteFunction with object that is not supported for networking.”
It seems this requires the actor component to not be replicated by default. In my repro, the ensure occurs due to the order in which the component is registered and set to replicate in UActorComponent::OnCreatedFromReplication. As you pointed out, on the client the component is first registered with the world, which calls BeginPlay, and then it is set as being replicated.
When the RPC is called from BeginPlay, ProcessRemoteFunction checks IsSupportedForNetworking and IsNameStableForNetworking for the component. However, because it is not replicated by default and SetIsReplicated(true) has not been called for it yet, AActorComponent::GetIsReplicated (called from AActorComponent::IsSupportedForNetworking) will return false at this point, causing the ensure.
I’ve opened a new issue for this, UE-329327, which should be visible in the public tracker in a day or so. In the meanwhile, you should be able to work around the issue by either setting the component to be replicated by default (i.e. call SetIsReplicatedByDefault(true) in the component’s constructor) or by delaying the RPC call to after BeginPlay.
Hi Alex, thank you for your response! I just discovered that I can’t reproduce the server disconnection issue using the latest UE engine. After checking, I found that it was already fixed in 5.6: [https://github.com/EpicGames/UnrealEngine/commit/7bdaef80c451e638b2fe325b59cd2e0395553975]. However, I’ve been using the 5.5 environment. I think I now know what to do next. Thank you!
UE-329327 will remain open since I am still seeing that ensure hit in the latest version, but I’m glad you’re able to work around the issue now. If you have any further questions though, please don’t hesitate to reach out!