Hi all, terribly sorry for the late answers. It seems like I’ve stopped receiving post notifications after Epic switched to the new forum style. I should probably have guessed this would happen, but it did not cross my mind. I’ll get to your questions now.
Yeah, this is why I don’t like to give estimates… As with anything in game development things always take a lot longer than what you suspect. The update is feature complete at this point, but since I’ve done a complete revamp of many of the core systems I have a lot of testing, commenting and cleanup to do. Especially features that are highly dependent on other subsystems, such as the skill system, has taken a lot longer to get done than I originally estimated. I’m working on the toolkit whenever I have the time and I’m making constant progress, but it is hard to give an exact time for when it’s done, as my previous guess proves…
Hmm, you could have this controlled by a HUD widget. Use a timer that is called after Activate Unit. Have a float track in the timer that goes from 1-30 and output it to a text box in the widget. When the timer Is finished, call the End Turn event in the player controller. You could do something similar with the longer timer for all the units of a faction. When it ran out you would have to code it so that all units of the current faction are set to the end of the Initiative Order array in the game mode before starting the turn of the unit then at index 0 (the first unit of the next faction)
-
Sorry, no. Only one grid is supported at a time. I am looking into how I can change the toolkit to make it work, but It will at least not be in the next update. Depending on what you want you can fake it, though. By having a large grid that is split in two by a gap it will look like two grids. You can do similarly using multi-level grids to have something that function and look like two separate grids, even though they are created by the same grid manager.
Hi there! LoS in ATBTT is handled by the RangeTrace trace channel, meaning that any mesh or collision box that blocks RangeTrace in its collision properties will block LoS. For movement, this is handled by the PathTrace and WallTrace channels. Objects blocking PathTrace can be stepped on, unless they have a height difference higher than what is determined in the HeightImpassableCutoff variable in BP_GridManager. Blocking WallTrace does nothing unless you check TraceForWalls in the public variables of BP_GridManager.
If enabled, traces will fire in all grid direction for each tile, and any traces blocked by WallTrace will cause the EdgeArray to remove an edge between the tiles on either side (making it impossible to pass between the two). Try setting your destructioble meshes to block WallTrace and enable TraceForWalls. After destroying the destructible meshes make sure to run the MakeTilePassable function in BP_GridManager for the appropriate tile index to make it possible to pass through after destruction.
If you do not wish to use the WallTrace option you can also make your destructible meshes child actors of the BP_Tile blueprint, which includes public variables for setting the cost of the edges surrounding the tile (0 makes it impassable from the selected direction)
Thank you for the suggestion. This support thread has of course become pretty huge over the years, and it takes ages to sift through it all. Epic requires sellers to have a support thread, though, and I like to have all support in one place. I hope to make some FAQ’s and similar in the future, to make it less necessary to search for ages for common questions. Right now I’m focused on getting my update out, however.
As for what features are needed in all games, and what are more game specific, this is a choice I made a while ago. I wanted to have a core toolkit which includes features that are used by most TBS games. Then I create game examples on top of this that have more game specific features. The 2D game example and the SciFi tactical map are such examples. These allow me to show users how to implement much requested features without bloating the basic toolkit. This is why shooting lasers is not a feature of the default toolkit, but is included in the SciFi example.
I agree that a simple move to command is missing from the toolkit, and as such this is one of the things I’ve added to the WIP update. I will give you a rundown of this tomorrow (sorry, it was late at night when I saw all the new forum posts)
Thanks again for the suggestions. Keeping things generic is something I always try to do, and there is of course some room for improvement in this area. An AfterEnterTile event is also something I have added to the coming update.
Thanks, adding such a check for the camera spawning is a good idea. I’ll have to look into the second issue. Thanks for letting me know.
Thanks. You have an eye for finding bugs Is this in the default toolkit or the SciFi examples. I know there are some rare initiative issues in the SciFi example which I’ve fixed in my WIP project.
As mentioned I’ll give you a rundown of how to achieve this result tomorrow. Kudos for figuring out most of it already. I’ll give an explanation for how this works in the toolkit when I give you my solution. Don’t worry about asking too many questions. You gave valuable input and pointed out some bugs I need to address, so thanks for that
And again, sorry to all for the long wait. I’ll enable notifications in the new forum and hope it works. And I’ll try to remember to check by frequently even if I don’t get notifications.