Networked Overlaps

Overlap events are straightforward in single player games. In the following video, the game runs in Standalone mode. As expected, BeginOverlap is called when the pawn enters the volume, and EndOverlap is called when exiting again.

In a multiplayer context however, things are a little more complex. There’s a lot going on behind the scenes, and the pawn may undergo several internal state changes during a frame that are completely hidden from the player. The physics engine does take note of everything though, and overlaps will be tracked and accumulated for any movement that occurs within a single frame. In the next video, we are playing as a client connected to a dedicated server.

It is expected that the overlap events are called on both the client and the server. However, you’ve probably noticed that the events were called multiple times on the client, which is undesirable. The server overlaps were called only once in this particular case, but when running a listen server you may experience a similar problem as on the client. We are not going to go into the details here, just know that this is the physics engine working as intended and that it is not really a good idea to try to prevent this behaviour. Instead, it is more practical to simply filter the overlap events as they occur. The easiest way to do this is by using the GMC Filter Overlap macro, which is part of the GMCv2 Blueprint Macro Library that comes with the demo project (available for download in the Discord). By putting the macro behind the event calls repeated overlaps will be filtered, and you’ll also be able to differentiate between contexts for the execution path.


You need to pass the overlapping component to the macro, which must be owned by a pawn of type GMC_Pawn that has a movement component of type GMC_MovementUtilityComponent to trigger one of the execution paths. Additionally, you need to pass a member struct of type GMC_FilterOverlapAux (you don’t need to do anything with this variable, just create it and pass it to the macro). Finally, you must specify whether the macro is placed behind a BeginOverlap or EndOverlap event by setting the corresponding overlap type. Remember that you always need to place the filter macro for both events (Begin Overlap and End Overlap), even if you are just going to use one of them. If done correctly, the right execution path will trigger for each overlap:

  • Server Move: Fires when the event is triggered during move execution on the server.
  • Client Move: Fires when the event is triggered during predicted move execution on the client.
  • Client Replay: Fires when the event is triggered during a client replay.
  • Simulation Interp: Fires when the event is triggered during interpolation of a simulated pawn.
  • Simulation Extrap: Fires when the event is triggered during extrapolation of a simulated pawn.

The last video shows the client pawn again, but with the filtering code demonstrated above added to the overlap events. As desired, each event now triggers only once for the client as well.