Glad to hear it is a good fit I had assumed they would work together well as they are both grid based and my toolkit is set up to make automatic walkability maps intelligently.
The turn manager is spawned by the game state at the beginning of the game, which holds a reference to it. Iāve implemented an interface in the game state so you can access the turn manager, action manager and grid manager from it without casting. Get a reference to the generic game state (Get Game State). Then make a call to the BPI_Singletons interface and Get Turn Manager.
You can also do it the lazy, slightly less performant way and GetAllActorsOfClass(TurnManager) and then get index 0 from the output array.
Iāve played around with this a bit more, Iām able to move correctly around the grid if I randomly generate the map before I run the game. However if I generate the map at runtime the Grid manager will revert to whatever dungeon architect had spawned previously, is there something I need to call to get the Grid Manager to update to the new geometry?
(Iāll promise to stop spamming this thread soon )
No worries. Iām sure this is of interest to several other developers using the toolkit. You will want to make sure that the grid manager runs all its setup after dungeon architect has generated the dungeon. The specific function you want to delay is the ActivateGridManager event which is called from the game state at the start of the game.
The safest option is probably to delay all the ATBTT startup events until after Dungeon Architect is done. Look in BP_ATBTT. There is an event called ActivateATBTT which sets in motion the chain of events that activates all actors in the appropriate order. Disconnect this event from EventBeginPlay and call it manually after DungeonArchitect is done (you might have to delay for a tick after DungeonArchitect is seemingly done, as freshly spawned actors often take until the next tick to be accessible)
Hi one more query when I call ActivateATBTT from a custom event after Dungeon Architect has initialised everything works correctly, apart from the fact that the stealth mode no longer works correctly. All the Enemy units are activated and aware of my position. Iāve run some tests and even on the Advanced example map when I call the event manually Iām having the same issue, so it doesnāt appear to be the order of events firing between the two plugins/toolkits. Any ideas?
Nah, gameplay is overrated Glad you got things working.
I guess I forgot to add the option of delaying the stealth functionality. Spawning the grid manager and placing units after the game has started is not something Iāve tested extensively yet, so it is not surprising that it is not working properly for less central features such as the stealth system. Should be easy enough to fix, though. Iām away from home until Sunday, so I cannot test it out myself, but here are some ideas:
It could be done lazily by having the begin play events of the stealth components check every tick if the turn manager is accessible from the game state (is valid) and finish setup once this returns true. That is pretty bad design, though, and having every unit with a stealth components running tick events simultaneously is not very performant. Should not matter much for most games, but I would want to do something better for an official implementation.
My first thought is to disable EventBeginPlay for the stealth components of both the grid manager and units. Then in the turn manager, after the initiative order array has been set up I would get a reference to the grid manager from the game state and check if it has the stealth component. If it does I would then run the event normally handled by EventBeginPlay before looping through all units in the initiative array and similarly running new custom events in place of their EventBeginPlay events for all units that have the stealth component. I might be getting the ordering wrong for which of the GridManager stealth component and unit stealth components that should be activated first, but other than that I think it should work.
Irrespective of whether such a change fixes any issues it is good practice to explicitly specify the order in which interdependent blueprints are activated, so I will be doing something like this in a future update. Thanks for making me aware of the problem.
Hey! Again Iām afraid Iāll have to ask you to be a bit more specific. With click-on-tile action do you mean that this is tied to the click event of a BP_Ability child actor? Also what do you mean when you say you want to move to a tile without actual movement? Do you mean moving the reference to the unit from one index in the GridActors map to another? If so, that can be done using the SimulateMove event. You can see an example of how to implement that in the event graph of BP_Unit. If you were to run simulate move without queuing the move action the unit reference would be moved in the array, but the actor itself would keep its location.
Hmm, hard to know what is going wrong here, but what you are doing should work in theory. Here are some possibilities for what might be happening:
You do not add the components properly to your custom array. Check with a print string that you are actually looping through a filled array.
You are in fact deleting it, but a separate spline is showing because you ran the regular function as well, or something. When looping through the components, print their transforms and see if it lines up. Change the color of your custom spline to make sure that is the spline you are seeing.
Maybe youāre adding things twice. In addition to adding to your custom spline mesh array for your custom function, try adding to the same array for all functions and see if the number of components corresponds to what you want to see.
Maybe youāre perpetually re-adding the components through some recursive node loop you are unaware of. Add a print string or break point to the function you use for generating the spline meshes and see if it keeps getting activated.
Hmm, there is a bug here, but what you are seeing is actually working as intended. There is a public enum in BP_Ability called MoveCost, which determines how move cost is calculated. It has four different enums by default: StaticCost, PerMoveAttributeValue, FromPathfindingCost and SameAsAbility. They are defined as follows:
StaticCost: Movement costs a number of AP based on the StaticMoveCost variable no matter how far the unit moves.
PerMoveAttributeValue: The ability looks at the move attribute value of the owning unit and the move cost of the tile. The movement costs AP equal to the move cost divided by the move attribute. So a unit with a move of 4 would use 1 AP to move between 1-4 tiles, 2 to move between 5-8 etc. Or at least that is how it is supposed to work (see below).
FromPathfindingCost: The movement costs a number of AP equal to the move cost of going to the tile. So with no difficult terrain, moving 4 tiles would cost 4 AP.
SameAsAbility: Similar to StaticCost, but based on the APCost variable instead of StaticMoveCost.
BP_Ability_MoveAttack is set to use StaticCost by default and has a static cost of 1. Therefore if you have 4 AP and move your full speed you will have 1 less AP and can now move one less tile. This is what you are seeing.
Iām guessing you want something either like PerMovementAttributeValue or FromPathfindingCost. FromPathfindingCost works fine, but it seems PerMovementAttributeValue does not work correctly. To get this working you have to change the reference to PossibleMove in the PayMoveAPCost function in BP_Ability to the move attribute of the owning unit, like so:
https://i.imgur.com/lVwWIkc.png
Hope this gives you the result you were hoping for. Thanks for making me aware of this bug.
Unfortunelly, neither changing BP_Ability_MoveAttack MoveCost value, changing the reference in PayMoveAPCost nor both, changed the unitās behavior.
My project uses a deslocation system similar to Fallout 1 and 2, where a character has about 5-10 APs total and a normal tile costs 1 AP to step in. So, to move your unit to an adjacent tile, it costs 1 AP only, two tiles 2 AP, 3 tiles 3 AP, etcā¦*
Nevermind, aparently I changed some values in BP_Ability and forget to reset. Now the unit moves to as expect but it cost one AP just to get out of inertia, this means that a 5 AP unit moves just 4 tiles distance, per turn.
Settings:
No changes in āPay Move AP Costā
BP_Ability_MoveAttack āMove Costā set to āFrom Pathfinding Costā
Unitās Move Max AP = 5
Unitās Move AP = 5
Unitās Move = 1
Ok, good that it mostly worked. Thanks for making me aware of the issue with move distance for units with multiple action points. The reason this is happening is that Iām using the PossibleMove value to find the move distance at the activation of BP_Ability_MoveAttack. PossibleMove as set up in BP_Ability equals CurrentAP * Move - APCost. This was intended primarily for the AI to see the max distance it can move and still use the ability. For Ability_MoveAttack, which is a hybrid ability with both moving and attack this does not work exactly right for player controlled units with more than 2AP.
To fix this go to BP_Ability_MoveAttack in the EventPlayerActivate event and make the following change:
https://i.imgur.com/hjDp76r.png
Also, make a similar change in the ClickEmptyTile event:
https://i.imgur.com/WsVyZdD.png
And allow movement to be calculated with just one AP left:
https://i.imgur.com/rCrjynW.png
That should do the trick. Iāll look into having a more elegant solution for the next update.
I did the changes and the blue range area did get equal the unitās AP, but I could only click on adjacente tiles to move, I did some minor adaptations and got the expected behavior. (hope I had not created a bug haha)
Yep, the changes you made look correct. Did not have the time to test it thoroughly, so good that you figured out the correction Thanks again for making me aware of the bug.
Iām releasing update 1.9 of ATBTT today! Got it done a lot quicker than expected. There are a couple of pretty big changes in this update, though of course much less than the full refactoring in the last feature update. Iāve sent it to Epic and it should hopefully go live early next week. The biggest changes were added to make the toolkit more flexible.
The thing that has been altered the most is how the player controller communicates with abilitites. In 1.8 the player controller did a lot of the heavy lifting, such as tracing for the ground, querying the active unit for its ability etc. Now most of that stuff has been moved to the ability itself. Or more specifically BP_AbilityBase, which is now the parent blueprint of BP_Ability. This makes it possible to change more basic aspects of abilities through overriding.
Another change is that the initiative array no longer holds only units, but instead any actor that implements the new BPI_Initiative interface. This makes it easier to implement events happening between unit turns, such as environmental changes, or selecting different actors than units.
Big units are out of experimental in this update and should be easier to work with. To enable it, increase the max unit size value of the grid manager and set the size variable of units appropriate for their size. Note that 1-tile units in games with big units should have size set to 1, while games not using big units are suggested to have all sizes set to 0 for optimization reasons. Units in games with big units should also have pathfinding type set to Big. Big units now works for both hexagonal and square grids and for unit sizes. Note that even though Iāve made the option for big units, including them adds a new level of complexity to many aspects of development, so beware of this when deciding whether or not to include this feature in your game.
In addition to these major changes there are several smaller changes and bug fixes that can be seen on my Trello here.
I am curious now the toolkit has been through your major 1.8 update and the project structure has been through its major change, what is your suggest method of upgrading 1.8 -> 1.9 in a working project? I had tightly integrated 1.7 and started adding custom functionality for multiplayer that I never expected you to add. Now you added it in 1.8 we decided a major overhaul of our project was due.
I dropped your new 1.8 project as a folder in the root of my project directory and started recreating child blueprints, but it seems youāve changed a few more files and their parent to child relationships in 1.9. I would love the ability to reference your library and continue updating it in my project as you make improvements and add functionality, but it would be a lot of effort to keep reintegrating the toolkit every update if my childblue prints are then referencing the wrong blueprint.
tldr: how do we set up our projects and update our projects to best maintain compatibility going forward?
Hi, Iām testing the toolkit and Iām trying to do the things shown in the 4th tutorial (https://www.youtube.com/watch?v=xqVTbk-FEBU&t=440s) but for some reason the rotated tiles and the basic geometry stairs cannot be stepped on by the paws, the heightmap is in Multilevel (Iāve also tried with One Level and false and I get the same result), I ticked the decals to see if UE was recognizing the tiles and the stairs, but they arenāt working properly.
Iāve tried this in UE 4.17.2 and 4.20.0
What can I do?
Iāve also tried with a mesh I modeled on 3DS Max and it isnāt recognized by UE, the grid is floating above the mesh (Where the pawn is located is where the grid is set).
How can I fix this?
Hello. I am making a game using ATBT.
I have one question for you.
For the path of move. Is there any way I can move around with the attached screenshot?
I gotta say: Iāve been making my last game inside Unity but after seeing this asset Iāve been looking more and more into UE4. Nothing on Unityās asset store comes close to what this marketplace item appears to offer in terms of features. Iāll find one asset that does pathing and multi level floors, but then nothing in terms of AI or gameplay, then another asset will do the opposite and have units, obstacles, etc, but canāt offer complex maps. Iām really close to just buying this asset and learning UE4 around it, but I know I need to learn the basics of the engine first.
This comment isnāt so much as an ask for support as much as itās a comment on how well developed this asset looks. So good itās almost converted me from one engine to another.
I had assumed they would work together well as they are both grid based and my toolkit is set up to make automatic walkability maps intelligently.
)
Glad you got things working.