[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

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)

[markps]

Thanks everything is working perfectly! Now to add some gameplay

[markps]

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?

[RC_Malokai]

Hey , Monokkel ,


So we're still working on the same feature and we have a question. Can you advice best way to solve this :

Its click-on-tile action


What we need to is to be able to "move to" next selected tile (without actual movement)

[Monokkel]

Thanks everything is working perfectly! Now to add some gameplay

Nah, gameplay is overrated Glad you got things working.

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?

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 , Monokkel ,

So we're still working on the same feature and we have a question. Can you advice best way to solve this :

Its click-on-tile action


What we need to is to be able to "move to" next selected tile (without actual movement)

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.

[RC_Malokai]

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.

hey Monokkel,
Thanks

our next problem are splines. We can't get rid of extra ones
We tried standard means , making it hidden in game etc but they don't budge.

you can see example on the screen shot + our attempted solution ,which should work in theory but somehow doesn't .

any advice ?

[Monokkel]

hey Monokkel,
Thanks

our next problem are splines. We can't get rid of extra ones
We tried standard means , making it hidden in game etc but they don't budge.

you can see example on the screen shot + our attempted solution ,which should work in theory but somehow doesn't .

any advice ?

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:

1) 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.
2) 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.
3) 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.
4) 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.

Those are my ideas for different places to look.

[BrunoCaxito]

I downloaded the v1.83 and noticed an issue with the Units Current AP/Max AP properties.

When I change it to any value, after runs out of moves, the caracter restores its AP-1. I recorded a demonstration video.

Is this intended, a bug or I'm missing something?

PS: Sorry for the bad english.

[Monokkel]

I downloaded the v1.83 and noticed an issue with the Units Current AP/Max AP properties.

When I change it to any value, after runs out of moves, the caracter restores its AP-1. I recorded a demonstration video.

Is this intended, a bug or I'm missing something?

PS: Sorry for the bad english.

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:


Hope this gives you the result you were hoping for. Thanks for making me aware of this bug.

[BrunoCaxito]

Thank-you for the reply.

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

[Monokkel]

Thank-you for the reply.

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:



Also, make a similar change in the ClickEmptyTile event:


And allow movement to be calculated with just one AP left:

That should do the trick. I'll look into having a more elegant solution for the next update.

[BrunoCaxito]

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)

Thank-you again.

[Monokkel]

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)

Thank-you again.

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.

[Monokkel]

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.

[Curiosichi]

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?