hey everyone, sorry for the late response. The last couple of days have been really busy. Thanks a lot [USER=“641905”]leo bar[/USER] for helping @. I’ll add my own thoughts to your discussion.
So yeah, a Fallot 1 & 2 style setup with free movement normally and turn-based when in combat can be done in a few ways, and all have benefits and drawbacks. In an earlier version of ATBTT BP_Unit was actually a child blueprint of Character, meaning that it had access to all the movement component stuff. However, I felt that this added a lot of clutter and complication for stuff that most users were not going to use, so I refactored it out.
ou don’t just get the movement components, but also a capsule component and a skeletal mesh, which is useless for many different types of units. The origin of the capsule component is also at its center, which means that you have to take this offset into account whenever you want to get or set the location of a unit. It also meant I could not share the grid snapping/grid index calculation code from BP_GridActor to BP_Unit, meaning I had to code a lot of stuff twice, which is not really best practice. Taking all of these concerns into account I decided to refactor out the character stuff.
The fact that the movement components are included for all units, as you say, is highly unlikely to have any impact on performance. UE4 can handle an extremely large number of invisible actors without any issue (as long as they don’t have separate tick events etc.), so that is not really a concern.
So what to do if you want to have this sort of movement? Well you have discussed two of these already. One is to change it back to how it worked in earlier versions, and leo has explained this process in detail, so I don’t have anything to add there. Another is the one you are mentioning, which is to use characters outside of combat and then switch to units in combat. I would probably go with something like this personally, though I sympathize with leo’s concerns about elegance. Basically I would have each unit spawn a character blueprint and then attach itself to that blueprint. That way, whenever the character moves the unit moves with it. The unit would not have a skeletal mesh, but when animating it would call on interface events on the animation blueprint contained in the skeletal mesh of the character in the same way it normally does with its own skeletal mesh. I might be overlooking some potential issues, but as far as I can see that should be enough to get it working.
For moving to the center of a tile when combats starts you can convert the current location of the character to a grid index with ConvertLocationToIndex3D and find the value of that index in GridLocations. That will give you the center of the tile it is at. Then you can use MoveTo from the character component to move to the center. And if you’re not using character ( @wortek ) you can use a timeline instead and interpolate from the current location to the center of the tile, at the same time playing a short move or shuffling animation.
There is another possiblity to do this stuff without using character at all, though it has some limitations. Look at the ability BP_Ability_FreeRoam. This ability lets your unit move to an arbitrary distance and change directions mid-movement and is set up so the turn of the unit never ends. Depending on what you intend to do, this might be enough to get the result you want.
Regarding duplicating the player controller, using duplicate creates a copy of a blueprint that does not have any references to the blueprint it is duplicated from. It is essentially the same thing as if you made a new blueprint from scratch and built it identical to another one, node by node. UE4 has no way of knowing these two blueprints do the same thing, and so trying to cast or call events for the other blueprint will not work. You can get around this a few ways; some more hacky than others. Firstly, you could create a child blueprint of the player controller instead. That way, casting to the parent class will work, and you can choose to override or keep whatever you want from the parent blueprint. Another is to replace all regular events the player controller has with interface events, so they can be called on any blueprint that implements the interface. Lasty, you can just change all references and casts to the old player controller in the toolkit with the new one.
lastly regarding the bug with height maps, [USER=“641905”]leo bar[/USER], thanks for letting me know. As mentioned I’m busy enough that it might take a few days, but I’ll track down the problem and fix it. I expected there to be some issues with heightmaps after the thorough refactoring I did this update, so I’m not too surprised. Hopefully it is just something minor that needs tweaking.
I’ll try moving over my current stuff to there.
