UNetDriver::UpdateGroupFilterStatusForLevel not properly removing PIE prefix before comparing against list of client-visible levels?

Development Programming & Scripting Multiplayer & Networking
, ,
1

Hey Epic Friends!

We’re seeing what _looks_ like a bug in PIE in UNetDriver::UpdateGroupFilterStatusForLevel. (this is the code that handles make sure a streamed-in-level on the server will replicate its embedded objects to a client even if the client loaded the level before the server. specifically this line is the prolem:

const bool bIsVisible = (bIsPersistentLevel && WorldPackageName == Connection->GetClientWorldPackageName()) || Connection->ClientVisibleLevelNames.Contains(LevelPackageName);

what we’re seeing is that ClientVisiibleLevelNames contains level names with the PIE prefix stripped, but the LevelPackageName contains the PIE prefix- so there’s never a match. I think we can fix by just stripping the prefix when fetching LevelPackageName but I’m wondering if there’s potentially something worse going on (especially if this hasn’t show up for you all?)

thanks very much!

Josh

[Attachment Removed]

2

Hi,

In testing this, I did observe that the entries in ClientVisibleLevelNames contained the PIE prefix. I believe the call to NetworkRemapPath in APlayerController::ServerUpdateLevelVisibility_Implementation should handle adding the prefix to the package name before UNetConnection::UpdateLevelVisibility is called.

To get a better idea of the problem, I have a couple questions.

First, are all of your server and client instances running in single process PIE, or are some running as separate processes?

Next, where is your server calling UNetConnection::UpdateLevelVisibility? Is this from ServerUpdateLevelVisibility or some other function?

Thanks,

Alex

[Attachment Removed]

3

Thanks Alex!

it’s in PIE, all in same process- we do have some custom calls to ServerUpdateLevelVisibility, so I will investigate a bit and get back to you. It’s good to know that the expectation is that the PIE prefix _should_ be in the ClientVisibleLevelNames. Is the expectation that on the server the prefix in there matches the PIE prefix on the client (so that each connection has its own prefix index) or is the expectation that the PIE prefix is based on the server (so that all the connections in the server world have the pie prefix that matches the server’s pie instance id?) knowing that should help us debug a bit.

Thanks!

Josh

[Attachment Removed]

4

Hi,

The expectation is that the paths on the server will have the server instance’s PIE prefix. When sending a path name, NetworkRemapPath_local will just remove any PIE prefix, and when receiving a path name, NetworkRemapPath_local will add the PIE prefix needed for that instance.

For example, if both the client and server are running in single process PIE, the server’s level package name may be “/Memory/UEDPIE_0_Lvl_ThirdPerson_1234” while the client’s may be “/Memory/UEDPIE_1_Lvl_ThirdPerson_1234”. Before the client calls ServerUpdateLevelVisibility, NetworkRemapPath is used to strip the PIE prefix “UEDPIE_1_” from the package name, and then the call to NetworkRemapPath in ServerUpdateLevelVisibility_Implementation on the server will add back “UEDPIE_0_” to the name. Conversely, if the server sends the package name to the client, the prefix is stripped and “UEDPIE_1_” is added when it’s received.

NetworkRemapPath is also used so that standalone editor instances can connect to PIE instances, such as when “run under one process” is deselected, as in this case, the standalone editor instance won’t have PIE prefixes on its package names.

Thanks,

Alex

[Attachment Removed]