You should only have to run it once, so if you are not overriding the Activate or PlayerActivate events calling these nodes again should not be necessary. Maybe you could post a pastebin of the Activate nodes for your custom ability?
Much appreciated! I’ll go through your points and see if I want to make any interjections.
Yup, you got it right.
I guess I haven’t covered this one yet. Might be good to do when I make my pathfinding tutorial. The basic purpose of this function is to move the unit reference between GridUnits indexes and check for any events that happen along the way, including adding and re-adding units to multiple tiles for big units and calling an event dispatcher every tile move. NewActionsCount keeps track of any actions that happen during movement. This can be useful if you have new actions that are called during movement. For instance, if you want to have the unit trigger an explosive half way through its movement you cannot have the whole move action play out and then play the explosion at the end, or the other way around. With this variable you have a way of knowing that new actions have been added to the queue.
Well explained. For AtCustomIndex, by default an action will be added to the end of the array of actions. If you specify a custom index you can put it earlier in the ordering of actions. For movement, where queuing the movement action is called after SimulateMove (where other actions might be called), but you want movement to start before these actions trigger, this is handy.
Yep, all correct.
Not really a problem for performance. There are a couple of issues with doing game logic type stuff within actions. This stems from how things happen asynchronously. If a unit is killed, for instance, it is instantly removed from the GridUnits TMap. If you then try to access this index during the action where it is killed, it has already been removed, causing the code to fail. If you only work with variables that represent the “plysical” game world, such as locations, actors etc. you can be sure you never have this sort of mismatch. Also, since game logic stuff, such as most of the grid manager stuff, is not replicated, accessing these variables will fail for clients in multiplayer.
This was lazy of me and I regret doing so, as it is teaches bad practice. As long as you have a perfect overview of how server-side stuff is handled by the toolkit you can get away with using it in actions in some cases for single-player games. That is if you can be sure it will not be manipulated in such a way that there will be a mismatch. I would generally recommend against this, though, and should not have done so in a tutorial.
Yep
6-Why is there a need to have two events here? The Multicast event is never even called by other BPs so there is no need to separate it as a function from initializeQueuedActions. Is this due to the way Multiplayer needs client & server communication be written, or just an author’s coding habit?
[/QUOTE]
There are two events because the first part of the event (which sorts through actions and stores them in lists) only works server-side, so no need to call it client-side.
Indeed. Useful if you want stuff to happen at the end of movement.
Finding locations in a map uses UE4’s built-in C++ functions and is really fast. Certainly faster than my blueprint function.
This is a C++ thing. For some types of variables it is preferable to create a copy in memory instead of pointing directly to its memory address. Epic have chosen to only allow passing variables referencing blueprints as copies. This is not something you can change in blueprints, but it will generally not matter.
No, they are removed from this array immediately on death. To the grid manager game logic a dead unit means a unit that is neither in the GridUnits TMap or the InitiativeOrder array. If a unit was kept in GridUnits after death, AI units would still try to target them with abilities, and units would not be able to move into the tile they died, for instance.
Thanks, I’ll fix that in the next update.
Thanks again for doing this. Among other things it helps make it clear to me what subjects I have covered well and what I should revisit in later tutorials. If you don’t mind I’ll post a link to your post in the description of the relevant video.