this is becoming a conversation of your games implementation, and meandering away from your initial question. Has the initial question been answered, or a reasonable alternative been proposed?
on the side of multiplayer for Broadcast-Response style gameplay Unreal is already setup, if you want Lock-step determinism, or Rollback that would take some reworking of the engine to different degrees. To just get networking to function is already built in, you just need to identify which variables need to be replicated, and what functions need to be sent to the server for propagation.
The UInputAction bindings typically are bound once, though you “CAN” unbind them (the best way I could find to was needing a bindingID which I stopped there and didn’t pursue it) it is easier and less error prone to use multiple UInputActions bound to the same/similar functions though different MappingContexts and/or to just put your logic in the bound function.
if you want the same button to do different things at different points here are a few different methods you can look at
- enum controlled InputMappingContext selection, and logical switches in bound InputActions
How can I disable InputAction except some Input Action In Enhanced Input? - #5 by gardian206 - in C++ switching the MappingContext would look something like this:
Removing Input Contexts when Using the Enhanced Input System - #6 by gardian206
imagine each wire coming directly off a Blueprint:InputAction_[input]_Event() as a bound function call.
for rational as to why the Ability Decals would be attached or parented to the Pawn: if the location is relative to a given location (so it has a limited radial distance, or it can only be within a given arc length of the forward) then you you either need to cash that information either through a pointer to the Pawn using the ability (so you would have like a TObjectPtr<AMyCastingCharacter> AbilityUser floating around on the ability, and you would need to assign it somehow), or through a attach OnStartCasting GetParent()->GetLocation() and/or GetParent()->GetForward() depending on the need, and manipulating it.
- the method with the held pointer you would constantly have to check if the Actor/Pawn/Character
!= nullptrto avoid access violations - for the implementation using attachment you only really need to check if the Parent
!= nullptrat the point of attachment, as destroy traverses up the Hierarchy to the highest node necessary then prunes bottom to top.
InitializeComponents() and PostInitializeComponents() are called by the engine on the object (because of the types of things done in them); like I have used PostInitializeComponents() as a last chance safeguard to ensure that a component the designer was supposed to attach was attached with at least a default version just to avoid access violations because again not every designer will remember “if the variable is a pointer to something that might not exist make sure it isValid before doing stuff with it”
or I will use the PostInitializeComponents() to register things with Singleton SubSystem Managers as I know the manager “should” exist, and using them can prevent the slow down of “GetActorsByClass()” as part of the trade off between semi-persistent memory and momentary performance hits. “frame rate: higher is better, but consistent is best” (most Gamer’s forget the last part though)