The Magnifying Glass mechanic is designed to be a mechanic that allows the user, and only the user, to see any actor derived from my HiddenActor C++ class. 

 

An example of a HiddenActor subclass the glass can see is a Blueprint actor I spawn through player's locomotive animation montages. This actor contains a footprint decal that changes color depending on the player that owns it. ​

 

When the player presses the UseItem input, the client-side UseItem() function gets called on that player's machine. This function then calls another client-side function that draws a sphere trace in front of the player's camera and reveals any actors hit by the sphere that inherit from HiddenActor. After this, the UseItem() function calls a server RPC function Server_UseItem() that executes server side logic such as playing the "Held Up" animation on all clients. When the player releases the UseItem input, a bound function for the OnEndUseItem delegate gets called that hides all HiddenActor entities client side, and plays the "Put Down" animation through a server rpc for all clients.

​

While developing this mechanic I ran into several challenges, the most prominent being how to correctly and efficiently separate client side logic from server side logic. Specifically, since the hosting client is considered the server in the Listen Server model, any logic done on replicated actors through the hosting client are replicated down to all clients. This raised an issue where any HiddenActor revealed by the host would show on all client's screens. To fix this I instead created a footprint actor component within the character class that is responsible for spawning footprints for each client individually and an Animation Notify to tell that component which foot decal to spawn and when. I stopped replicating the footprint actor so that each client has their own unique instances of footprint actors and it fixed the issue completely.