I haven’t been too good at documenting the camera stuff, so I understand that it can be a bit confusing. Firstly as of the latest Version you do not need to place the camera actor manually in the scene; this is done automatically in ATBTT_GameMode.
When you say that it hovers over an enemy, do you mean that the camera’s starting location is above the enemy pawn, or that it flies over to it/has follow cam. If it follows automatically you should be able to disable this by setting the default value of the variable Is Panning in the camera actor (BP_Grid_Camera) to true. If it’s just the starting location, you should be able to fix this by changing the spawn location of the camera actor in the event graph of ATBTT_GameMode (at the right hand of the top left section of the graph). To change how far out the camera is zoomed at the start of the game, you have to modify the default length of the Spring Arm component in the camera actor. Maximum and minimum zoom distances can be set in the public variables of the same actor.
Following the above steps should hopefully solve the problems you are having.
In the old version of ATBTT, you can change the camera maximum zoom from the camera blueprint by changing the relative public variable value.
I think that on new version you can change the same variable value.
@WisdomHELLy: Don’t worry about it. Thanks for covering for me Maybe I should do something to make the camera options more visible again, now that the camera does not need to be placed. I could create an optional override for the camera public variables in the Grid Manager.
Thought I’d show off one of the things I’m working on, since I just got it working like intended: XCOM-style movement borders
I’ve got lots of other stuff in the works as well, but I’m pretty excited about this one. Not only does it allow for some cool options for visualizing movement, but storing the edges of the tiles in movement range allows for a few other cool features. Like I said, so much more to come.
@ This looks awesome dude. Looking forward to it. Does it work with sloped tiles like the ones you showed in one of your recent videos?
Anyways actually I think this implementation is better looking than XCOM’s. They draw it through the middle of the tile causing it to have sharp turns in certain types of edges.
@: Thanks! Hearing it’s better than my inspiration is the highest for of praise Getting it working with decals is fairly trivial. Using it for maps with height that do not use height maps is a bit more tricky, however. The current implementation uses a flat border of several instanced static meshes. If these are different in height, the border will break. It should be possible to remedy this with rotation, but not for all types of maps.
Ok, thanks for the heads up. I haven’t generally tried to make the toolkit compatible with preview builds, since everything is subject to change. I’ll look into it when I have the time, though. The solution is probably simple.
Like you’ve suggested, a cast is probably not working and is returning 0 (false), which is the first index of the grid arrays. Unfortunately I’m at a conference, and won’t be back for a few days, so I can’t check it out. By all means try to figure it out before then, but if not you should probably just use 4.7 for now.
After changing the movement/attack system to AP based, I found that AI units doesn’t call Receive Damage after Attack Victim during “Attack on End” phase.
The effect is that I don’t see any attack animation and also the victim unit doesn’t suffer any damage.
That’s very strange.
I don’t understand why it happen. Maybe can the “End Move” event triggered before “Attack on End” branch deny any event call or animation?
Using UE4 debugger I see that it goes on “Receive Damage” event call but it doesn’t enter into it if I press Step.
Sorry for being slow in replying to your questions. I was away on a conference for a few days and forgot to bring my laptop charger
You are correct. The spline is created using the Find Path Within Pathfinding Array function in BP_GridManager, with the end point of the path being an input node. The function only works if there has been generated a CanMoveTo array (meaning the Pathfinding function has been run) and if the target index is within this array. The function finds the path by starting at the end index, looking at the parent of that index in the CanMoveToArray, looks at the parent of that index etc. until the index which was the origin point when Pathfining was called last.
The dungeon crawler example is not my first priority as I’m working on the mobile/2D stuff first, so it won’t be done for a while. Procedural generation will in any case be pretty basic in my example, as it will mostly be an example to learn from and build upon. Although it will be some time until I get to work on it, it is actually pretty easy to convert any of the other procedural dungeon examples on these forums to the toolkit. If you use a random dungeon generator that generates tiles/rooms that fit the size of whatever you use as your default tile and you resize the GridManager as appropriate to fit the area of the dungeon you can automatically get the toolkit to work with any dungeon by using the “Auto Height” feature.
That is indeed pretty strange. I assume you have studied how the blueprint is set up pretty thoroughly? When you call Begin Movement in your custom blueprint, is “Attack On End” set to true? Are you aware that “Attack Victim” is called on the attacker, but “Recieve Damage” is called on the victim? The blueprint is set up so that movement, attacking, damage etc. is independent of animation, so everything should work even if a pawn doesn’t have a skeletal mesh. “Attack Victim” is called in the regular toolkit even though “End Movement” is called beforehand. Try studying how things work in the vanilla toolkit, and see what parts of the logic chain your implementation differs. It is hard for me to say more than that without knowing more.
The strange thing is that “Attack Victim” is called (and so “Attack on End” is surely true) but “Receive Damage” isn’t.
Yes, my implementation differs from the out-of-the-box one, but this situation is quite strange because it seems like UE is not able to call the “Receive Damage” event correctly, because I’ve put some breakpoints in it but they are never called.
Honestly I checked that the victim of “receive damage” is correct, but I didn’t check for the attacker one. However, I didn’t change it, so I don’t expect a bug.
I will dig it out more and let you know if I’ll find something, meanwhile, I will try to send you my blueprint implementation with blueprintue.
Ok, getting the blueprintue version would help me a lot. I would recommend using a print string as well as a break point. In some cases I have noticed break points not working properly when used with a lot of blueprint communications, so use a print string after Recieve Damage is called just to be sure.
This looks awesome and I would like to use it for an RPG. So I was wondering, can its AI can be swapped out for one written in C++? Perhaps I could make my own AI for each creature type? In Fallout, the creatures moved across the tiles in real time, when there was no combat and switched to turn based during combat. Would that be possible with this kit?
@Ariegos: The toolkit is modular in design, so swapping out the AI controller with a custom C++ one should be relatively painless if you know how to use C++ with blueprints. The Fallout-style real-time/turn based combo is what I’m planning for my own eventual game, and is certainly possible. When in real time either use regular top down movement like in other real time games, or use my pathfinding with unlimited movement points depending on your needs. Then, when combat is initialized, get the locations of all pawns and populate the grid like I usually do in event begin play. If you allow units to stop between tiles in real-time mode you would also need to move all pawns to the closest tile, using a lerp or similar. So in other words, it takes a bit of work, but is absolutely possible.
In other news I’m still working on the 2D-template, which also contains lots of functionality that may be useful for all sorts of turn based games. I’ve just made a Fire Emblem/Advance wars style vision checking, that finds all possible visible tiles from all tiles you can move to. Since I can naïvely assume that all tiles that can be moved to can also be attacked I only do a vision check from tiles that are at the edge of the movement range, or adjacent to a wall (the same tiles that would be marked with an edge mesh in my last screenshot). This makes it a lot more efficient, but still quite a bit slower than my regular pathfinding/vision check combo. It’s still done in less than a millisecond on my desktop for the pictured example, but I hope to make it even faster.
One problem with the current solution is that it doesn’t work for troops that have a minimum range, as all tiles in move range might not be in sight range. That means that for such units I would have to calculate vision from all tiles in move range to achieve the same result. I’m unsure if I’ll be able to find a better solution, though pre-generation of movement/sight will make this a non-issue in games where units follow a predictable turn order.
Ok, great, though that really shouldn’t be your responsibility. I’m trying to look into it myself, but for some reason the launcher won’t let me open the preview. It gets stuck on 45% loaded when I try to begin a new project. I’m hoping I’ll solve this soon so I can figure out what needs to be changed.
Well, you’ve got me worried alright I’ve done two major rewrites before, and am not exactly looking forward to a third one, but you go gotta do what you gotta do. Thanks a lot for offering to lend a hand, though!
Edit: Ok, I’ve looked at it a bit. Seems like one of the big reasons for bugs is that 4.8 has chosen to connect up a few execution pins to the return nodes inside functions that were not connected before. For instance, this Destroy Spline Mesh function returns after only one segment of the spline mesh has been deleted. The same holds true for all such functions it seems. Deleting these new connections does at least solve some of the problems:
Edit 2: It’s almost working as before now. Seems like a reference to “self” had become disconnected from Unit_Parent when adding the pawn actor back into the Pawn Actor array after movement, as well as removing it after death. Still a few little hiccups, but it does fortunately seem like no big reorganization will be necessary.
Edit 3: Ok, I think I’ve got everything working as before now. I’ll do some more testing to be sure, and will make a conversion guide when I’m confident I’ve got all the bugs ironed out. I will not be sending the update to Epic, since it’s a preview build and the changes would screw up the 4.7 version, but converting should be quite easy for anyone who can’t wait to use the new 4.8 features with the toolkit.
Maybe I should do something to make the camera options more visible again, now that the camera does not need to be placed. I could create an optional override for the camera public variables in the Grid Manager.
Getting it working with decals is fairly trivial. Using it for maps with height that do not use height maps is a bit more tricky, however. The current implementation uses a flat border of several instanced static meshes. If these are different in height, the border will break. It should be possible to remedy this with rotation, but not for all types of maps.
I’ve done two major rewrites before, and am not exactly looking forward to a third one, but you go gotta do what you gotta do. Thanks a lot for offering to lend a hand, though!