Known Issues

Network Prediction Plugin Known Issues#

Epic have provided their own list of issues with the Network Prediction Plugin on their Github. These will also apply to Gunsmith retroactively.

Some of these issues have been fixed by Sir Kaizoku’s NPP Fork. I will not officially support these changes for Gunsmith but it may improve the player experience to implement them in your own project.

100ms Delay On Received Packets#

Due to how the Network Prediction plugin works, any packets received on the server from the autonomous client will be buffered by 100ms before being executed. This is to ensure that packets have arrived correctly and are ordered as intended. This delay is also applied to packets received by simulated proxies from the server. Because of this delay, most authoritative actions (such as applying damage) will take up to 200ms + Round Trip Time before the client confirms that is has been applied. This can leave an undesirable delay if the action is not being predicted.

Other AAA games such as Overwatch reduce this buffer time based on the quality of the players connection. This query has been raised on UDN twice and the response is that Epic know about the issue and expect to implement this feature by the time Mover is out of experimental.

Note: This is only an issue in with NPPs Fixed Ticking Policy. In Independent mode, packets are executed instantly and multiplayer development is similar to standard Unreal networking.

Limited GAS Support#

Due to how GAS is implemented at the networking level, the Network Prediction Plugins Independent ticking policy is the only supported mode for GAS interactions. This means that the rollback and predictive features of Gunsmith will not be available but extra effort has been made to ensure the rest of the Gunsmith functionality interfaces nicely with GAS. Some of that functionality has been documented here.

Movers Interpolated Vectors Can Be Zeroed#

When using Interpolated mode in the Network Prediction Plugin, the MoveDirectionIntent and Velocity vectors in the FMoverDefaultSyncState struct can equal zero when interpolating between two opposite vectors. This means that anything that reads from this (such as animations) may sometimes act unpredictably and will therefore get out of sync. A workaround for now is to copy the following code to the end of FMoverDefaultSyncState::Interpolate:

void FMoverDefaultSyncState::Interpolate(const FMoverDataStructBase& From, const FMoverDataStructBase& To, float Pct)
{
  // Engine interpolation code

  if (MoveDirectionIntent.IsNearlyZero() && !ToState->MoveDirectionIntent.IsNearlyZero())
  {
    MoveDirectionIntent = ToState->MoveDirectionIntent;
  }
}

This fixes the case for MoveDirectionIntent but Velocity is a bit more of a niche case as you may want to know that the velocity has zeroed out in some cases. It is recommended to check if MoveDirectionIntent is not zero when Velocity is zero. If so, you can simply discard updating your cached velocity vector that frame.

The relevant Epic thread can be viewed at (with Epic Pro Support access) https://epicprosupport.epicgames.com/s/question/0D5QP000015BOy50AG/movers-movedirectionintent-can-be-0-when-switching-to-the-opposite-direction-in-fixed-interpolation-mode.

Bug status is available to view at https://issues.unrealengine.com/issue/UE-273828.