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.

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 but the response is that Epic know about the issue but have no current estimates on when it would be implemented.

No GAS Support#

As GAS uses the default Unreal networking model, the expectations from the system are very different to the expectations from the Network Prediction plugin which mean the two are incompatible. GAS executes all packets instantly while NPP adds them to a buffer to execute later. They also both run on a different tick which means logic will be executed at different times. It is recommended to implement this plugin very early in a project and then build on top of the Network Prediction plugin to ensure all timings are correct and resimulations are kept to a minimum. Mover is a good example of another system that runs on top of NPP and works well with Gunsmith.

I would like to recreate GAS on top of NPP as another Unreal plugin at some point but that depends on demand and sales of this plugin. Please let me know on Discord if you think you’d use it!

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.