Great! I’ll do that, then.
You’re thinking about it the correct way, and indeed being able to move the move action before or after the action happening during movement does not solve the problem of having an action play while movement is still ongoing. It does however work as a marker to signal the need for calling custom logic to allow for this. The challenge of finding the best way to have actions happening within other actions is one of the issues I’m most hoping to find a better solution for. I’ve tried a few different approaches, and you’ll see them at various places and in various versions of the toolkit.
The first is my original overwatch shot implementation, where the event dispatchers called during each move step called an event in BP_StatusEffect_Overwatch. This event checked if the moving unit could be seen by an enemy unit with overwatch for each step. If it did, it ran the server side code for shooting the unit and bound a new event to the move action. Now during the move action, each step would trigger a different dispatcher, which would fire this new event in the overwatch status effect. If the grid index matched the one which was fired at during simulated movement, the overwatch shot animation would trigger.
While this worked it was pretty hacky and cumbersome, and sometimes buggy. This is why I’ve removed it temporarily while trying to find a rework. You’ll see two other implementations for actions happening during movement in the 2D example and in the experimental map, either of which might be what I end up using for a new overwatch ability.
For the 2D example map I simply treat each movement step as a separate action. This creates a potentially huge queue of actions, but it is very straightforward. In the experimental map things are a bit more involved, where I intelligently create a separate action for each part of the movement where something differs. A final overwatch implementation might involve queuing three actions: 1) Movement before overwatch shot; 2) the overwatch shot and 3) movement after the shot/death.
I’ll put it on my long list :P. The correct way is to calculate the stuff using the grid manager before calling the action and passing the output of this into the action arrays.
Should not matter in this case. Though if you have lots and lots of different such actors in your game there are better options. I would then recommend using my GridObject system, which I use for picking up items and activating switches in the 2D example map.
Yes, it is a common issue and looks quite confusing the first time it happens. I’m thinking of adding some sort of warning message if the toolkit detects that something like this is happening, though I haven’t thought of a good way to do this yet.
This could involve storing the clicked index in the ability when you have clicked, but not executing the ability completely. Then you could run an event on the UI to show a button. You could perhaps do this by getting the HUD from the player controller and calling an interface event. This button could then find the active ability through the player controller and call an event (such as ExecuteAbility) on this ability, using the variables you stored from your inital click.
So what you’re saying is that all the abilities have the same attack range, so you feel it is necessary to find the targets anew every time you activate a new ability? The functions for finding units is quite efficient, so if it is a performance reason for this I would not worry too much about it. However, if you still want to do this, I did something similar for pathfinding for the AI. If you look at the AI code in BP_Ability you’ll notice that before pathfinding is calculated it checks a variable in the ability system component of that unit to see if pathfinding has already been calculated that turn. If so it uses the pathfinding output stored in the ability system component. You could do the same thing for storing targets if you feel the need.