I have not really made a flowchart for this, but the general setup order is the following: Game mode starts up. Signals game state to setup reference to core blueprints (turn manager, action manager and grid manager) and initializes each of these in that order. Meanwhile the the game mode delays for two ticks while all of this is setting up. When that time has passet it sets the TurnState in the game state to TurnBasedCombat, signaling that the game is ready to start.
Whenever a new player logs in it first checks to see if the grid manager is done initalizing (last step of the above setup process). If it is it initializes the player controller for that player. If it isn’t it delays until it is. The HUD is initialized as part of initializing the player controller as well as the grid camera.
This means that the grid camera’s setup will be the last thing to run for any player logging in, so at the end of the grid camera’s setup it signals to the turn manager that a new player has joined and is possessing a grid camera. The turn manager keeps track of such signals from players joining to know if enough players have joined to begin the game and activate the first unit in initiative.
If you want to see more specifically what happens, add a break point right after event begin play for the game mode and step through the nodes one after one in the blueprint debugger.
@anonymous_user_fdc4a810: Like said, bUseUnitAttributes is used in the parent blueprint (BP_Ability). To find all instances where a variable is used right click it and choose “find references”. That gives you all references in the current blueprint. Click the binoculars icon afterwards to find references in all blueprints.
This is a mistake on my end, though. My intention was to have damage be set based on the damage variable of the unit in the MoveAttack ability. To fix this, make the following change in BP_Ability_MoveAttack (to override a parent function in a child blueprint click the override button in the function tab of the child blueprint in question)
For an explanation of why units were seemingly damaged without displaying it using your solution, see my videos on the action system. You likely input a damage of 0 into the queued action macro (the one in your screenshot, which is only used for animation and not underlying game logic), while still using the old damage value for the server side TakeDamage function happening directly after.