No worries, we’ve all been there. Sometimes one just gets stuck in a rut. It is all part of a learning process, though.
Ok, I assumed it did something like that. Then I stand by my suggestion of putting it at the beginning of ExecuteAbilitiy. You need the information both for simulating and animating the damage, so it should be done before any of these.
You’re talking about when the connection wires light up while your running the game? Yeah, those are not very accurate. Use break points or PrintString nodes to be sure of what happens.
Like I said, don’t worry about it, we’ve all been there. Sorry if my tone came across as annoyed; that was not my intent. I agree that it is often easier to learn stuff while you’re working towards a goal.
There is no such functionality included in the toolkit, so I’m afraid you would have to add that yourself.
Sure, it is possible, though there are a few steps to it. Movement in the toolkit works by the unit first simulating movement by essentially moving a reference of the unit from cell to cell in the GridUnits map. After this the grid indexes are converted to actual in-game locations and the unit actor is moved between these locations using a spline.
So for a trap you would want to add a check to each step of the movement simulation that sees if anything happens on that specific tile before proceding to the next. If a trap is found and that trap is supposed to stop the unit you need to make sure only the grid indexes up to the index of the trap are converted to locations.
There is an event dispatcher in the toolkit created for just this sort of thing. If you look in the SimulateMove function of BP_Unit you can see that the “OnEnterTileSimulate” event dispatcher is called whenever a unit enters a new tile (during simulation).
You can bind an event in your trap actors to this event dispatcher. When the dispatcher is called, compare the grid index to the trap to the grid index output from the OnEnterTileSimulate dispatcher. If they are the same that means that the unit has entered the tile of the trap.
At this point you deal damage to the unit. Then, if you want movement to stop you first want to stop the simulated movement. In the SimulateMove function add a branch that exits the loop if true, similar to the “contains” node for the GridUnits map that is currently in the SimulateMove function. Set whatever variable is input to this branch to true when the trap is entered to stop the simulated movement.
Now you need to make sure to only pass the locations up to the tile index of the trap into the QueueAction macro, instead of the entire path. You can do this by storing the index of the trap when it is triggered, using Find on the PathIndex array to find the array index of this grid index and use this to create a new array of locations from the PathLocations array stopping at the index found in the last step and feeding this into the move action. You would then want to queue an animation for displaying the unit being hurt by the trap right after the move action has been queued (as it happens right after movement stops).
Those are the steps I would go through to create something like this. It is a bit complex, I know, so let me know if you have any questions.
There might be several reasons for this depending on what you have done. Check the event graph of BP_Unit_Anim and compare it to the event graph of your new units. Are there any differences? What about ABP_Unit compared to your new animation blueprint? Maybe you have forgotten to add notify events to the new animations? Let me know what differences you find and I’ll try to figure out what has gone wrong.