Download

[SUPPORT] Advanced Turn Based Tile Toolkit

Ah, of course. Sorry, should have seen that one. Ok, then it is going to take a bit more work. Keep the project as per my last suggestion, but make the following changes to the CheckIfTileIsVisibleFromOtherTile function in BP_GridManager (changes are at the end after the line trace). Should hopefully do the trick.

Still not work.
1)I create a collision box for BP_UNIT. I put set collision Response to channel - range trace - ignore on event Select Actor
2) I put set collision Response to channel - range trace -block on event End Actor turns.
3)make the following changes to the CheckIfTileIsVisibleFromOtherTile function in BP_GridManager (changes are at the end after the line trace)
Maybe it possible do it same think via ability system?

Good to hear!

Yep, you got it right. If you do not enable TraceForWalls this is the way to do it. However, with TraceForWalls enabled you have some other options as well. You could then skip having the invisible tile actors and instead use a single invisible wall mesh for each “level” of your staircase. An even better option could be to enable TraceForWalls and sett TraceForWallsHeight to something really low, like 5 or 10 unreal units. I think that should automatically give you the result you want without having to add any invisible walls (so long as the staircase itself blocks WallTrace). How TraceForWalls works is that it runs a line trace between each tile and its connected neighbors checking the WallTrace channel, removing the edge if it is blocked. It goes from the center of one tile to the center of the other, offset by TraceForWallsHeight. If you set this value low enough it will be blocked by a small height difference when there is a sudden drop, but not if it is a smooth incline. This may or may not work with the way you plan to make your level as a whole, but it should work well for what you’ve shown me so far. Test it out and see if it does what you want.

As an optimization measure when I first made the heightmap system, the toolkit will never add more levels than needed. More specifically, a tile will only count as a being at a higher level (meaning that is has a grid index higher than GridSizeX * GridSizeY) if there is one or more walkable tile directly beneath it. In your screenshot above this means that all tiles will be at the same level, as far as the Grid Manager is concerned.

Edit: Just noticed the stairs lead to the top of a bridge. So all tiles will not be on the same level. The tiles that are directly above the walkable tiles below the bridge will be at level 2. If you want to see this for yourself, enable PregenerateGameplayGrids and ShowTileIndexes. You will see that all tiles at a higher level will have a grid index equal to the tile below them + GridSizeX * GridSizeY. Just remember to disable PregenerateGameplayGrids later, as any changes you make to the grid after checking this will not go into effect before it is disabled.

That is just a rounding error that comes with floating point values. It is based on how such values are stored in memory. Integers will always be exactly what you set them to, but floats will be a tiny bit imprecise. I recommend reading an introductory course in C++ if you want to understand this more fully. It should not matter for your game though. UE4’s blueprint nodes are generally set up to take this into account.

Yep, basically movement cost equals height difference divided by HeightSlowIncrement. If you never want height difference to affect movement cost, just set it to be as high as HeightImpassableCutoff.

No worries :slight_smile:

Hmm, my guess is that unpossessing the unit causes the player controller to lose ownership of it. When a unit is activated, the player controller that owns it is told to activate one of the unit’s abilities. Since it does not own the unit anymore it does not receive the message. If you’re making a single player game this should be easy to fix. In the event graph of BP_Unit, fins where ActivateAbility is called on the owner of the unit. Replace the owner input with GetPlayerController.

You will also need to change the OwnsActor macro in BPML_ATBTT. Either remove all instances of it or set it to always return true if you’re lazy (though if you do this you’ll need to manually recompile all blueprints that use it due to an annoying quirk of UE4 when it comes to macro libraries).

No, what I suggested should work as I’ve tested it. It seems I failed to paste on essential node in above, though. Sorry about that. At the very end of the function, if TargetIndex == GridIndex returns false, you should add a return node with Visible set to false. Here is how I personally set up collision to be enabled/disabled in a child blueprint of BP_Unit:

https://i.imgur.com/Nf1SEi4.png

https://i.imgur.com/FcsSsky.png

Here is how it looks in game:

https://i.imgur.com/gfyKmUx.png

hi knut

that fix the problem…

thanks a lot, i was stuck on it for a long time, i think that just in the past hour i manage somehow to get it work in multiplayer - i made a custom event that run on server from which i posses the unit and also after unposses i run another custom event (run on server) that sets the owner to the player controller again. somehow i think its working, but i am not sure.

thanks again you helped me a lot

cheers
leo

edit:
well your solution didn’t fix the problem (i thought it did), but i manage to overcome it by other way.
thanks for the help

Share your solution later if you want Leo, I’m sure it could be useful to others in the future (;

Alright, experiments were made and here I bring my results to you, Knut and friends! Keep in mind that this isn’t so much a plead for a fix, but more of “how does this work” kind of questions. The more we know about the inner workings of sth, the better chances we’ll have of using the tool to its max capacity. I welcome anyone to comment and enlighten me on this matter:

(open image for a larger preview)

If I have CheckForWalls enabled, my CheckForWallsHeight needs to be at least over 37.5 for the unit to be able to climb the stairs. However, my unit is able to cut through from tile H525 to the floor above (img B), something which I would not like. If I replace the slope for a sudden drop (img C), top floor is inaccessible. Then I tried making this vertical drop super small (img D & E), and interestingly enough, top floor remained inaccessible. Even more interesting, if the slope is slightly altered in any way (img F), results are the same as C, D & E.

  1. Why does CheckForWallsHeight need to be at least over 37.5? It makes no sense to me. If the value should be just the height offset between neighbor tiles (the same description as HeightImpassableCutoff afaik), value should be at least over 150.
    If a line is being traced from center to the next center, should it not be bumping into a wall at tile H525 to tile H600 in img B?
  2. CheckForWallsHeight overrides HeightImpassableCutoff when TraceForWalls (TFW) is active, correct? If TFW is on, top floor is inaccessible in C & E, whereas if TFW is off, top floor is accessible in those same situations. For this reason, if I planned to have a more complexly modeled map (like, say, model the individual steps in my stairs), perhaps having TFW On would be more trouble than help, don’t you agree?
  3. The ONLY way a smooth slope will override the effects of CheckForWallsHeight is if it is a PERFECTLY interpolated slope? In img F, if I add an edge to the H525 slope and ever-so-slightly incline it downwards, the top floor becomes inaccessible. If it’s that specific, and if I’m not missing something else here, I really have a hard time imagining what real-life scenarios such a feature would truly be useful in, unless your map is entirely made of primitive, minimalistic shapes.

@Justo : I think you’re partly misunderstanding how TraceForWalls works, but my previous suggestion was anyways not a really good one, and this is not a problem that can be solved entirely with TraceForWalls. I forgot to factor in that going from an upward sloped to a flat tile will mean that there is a heightened center between them, which means using a really low TraceForWallsHeight is not recommended. I knew this from when I developed the system, but forgot about it when answering your question.

TraceForWalls is mostly useful in that it eliminates the need for using wall tiles, as you can just use any regular static mesh instead. It also means you are free to rotate any wall you use and the toolkit will remove edges appropriately, as you initially attempted to do with the thin wall tiles.

CheckForWallsHeight does not override HeightImpassableCutoff. They are entirely separate systems. HIC compares the height of adjacent tiles against the cutoff and removes edges between the tiles if the height is greater, while TFW runs a line trace between them and removes the edges if it is blocked. They serve separate, though in some cases somewhat overlapping, functions.

So, for your stair, here is one way you can utilize TFW to avoid having to place several invisible wall tiles by using two blocking volumes instead. If you were to use a 3D model for your stairs you could even include such collision boxes in the model itself, and you would never have to place invisible walls manually for that stair mesh again:

Hope that helps you see the utility of TFW. If you want to see exactly what TWF does I recommend finding the CheckIfValidEdgeCandidate macro in BP_GridManager and set DrawDebugType of the TraceOnGrid function within to WallTrace to ForDuration. Then check PregenerateGameplay to see how the line traces fire:

Dear all,

I have been using the ATBTT to create a school project game.
I have been looking the blueprints, however, have not found a way to do what I wish.
First is that if you fail and the enemy faction wins, I would like to link the game back to the main menu.
Second is how would I link level 1 to a picture that would display for 30 seconds-ish then link that picture to level 2.
Third is how to create a main menu that links to the first level, a picture of main menu blueprints included.
The last is how would you place a collectable on a level and if you collect it, then in the next level you would gain more health, damage or change the skin of the character.
Thank you in advance,
Shadow-Obsidian

No, what I suggested should work as I’ve tested it. It seems I failed to paste on essential node in above, though. Sorry about that. At the very end of the function, if TargetIndex == GridIndex returns false, you should add a return node with Visible set to false. Here is how I personally set up collision to be enabled/disabled in a child blueprint of BP_Unit:

Here is how it looks in game:

[/QUOTE]

Cool! Almost work :slight_smile: Unit which controlled by AI start drive crazy. AI unit run to 0 index tile. Please check it

@Lexx : There is likely still a place in the AI logic that checks for visibility the old way. Search through the nodes in the Assess Ability Value part of BP_Ability for line traces for visibility and modify them as with CheckIfTileIsVisible. If it still does not work, come back to me and I will look into it when I have the time.

Hello Monokkel, I have a problem when adding shields on units, (shields are set up exactly like the health bar etc. ) added shield damage in the advanced map laser ability added a pin on the floats array going to “queue action” added a print string all ok to there…in the BP_Unit at break FAction I get an error (Attempted to access index 1 from array Floats…of length 1) when “get reference” to float array 1 and remains at zero and if “get copy” there is no error and remains at zero. no rush on this not a big problem I think I will try an integer…

Disregard this…my fault, found more that needed modifying…got it to work

Glad to hear you got it working, as it sounded like you did everything right from the description.

I had to set damage from array somewhere else, can’t remember where (and found that just after I posted here…ba ha)…I have been watching your progress on Trello, looks like your cruising along fairly well. I am looking forward to the next update and maybe some news when approx. it might be out…
Having sooo much fun with ATBTT things are coming along here good. I know your busy and thanks for working on this when you have the time.

Hey Monokkel,

I’d like to remove the combat feature completely (the red tiles). How do I do that? In which blueprint is the combat located?
Thank you :slight_smile:

Good to hear you’re having fun! I’m fiddling with the toolkit every now and then to take a break from the thesis work, so you’ll see sporadic changes in the Trello every now and then.

It is defined in the abilities of the units. If you switch out the default abilities of your units from BP_Ability_MoveAttack to BP_Ability_Move you should get the result you want.

Thank you!

Hi Knut,

I bought your toolkit some days ago and it’s working really well so far. I just have a few questions I hope you’ll have an answer (whenever you find some time I know you’re busy! :slight_smile: )

I want to make a turn based game using a hex grid featuring two teams of about 4 units fighting (all good so far) What I need to add is:
-Walking costing only “move points”(the move value of a unit) and not AP, and available at anytime of turn (for example: move -> attack -> move to cover)
-Being able to use multiple abilities in the same turn (I think there is a way already but when I try using an ability costing 1AP with 3AP available, my AP is set to 0 and my turn automatically ends.)
-Using a custom animation for the skeletal mesh for each ability (i guess I have to add a bool ref to an anim bool inside the abilityBP?)

An example of a turn I would like to be possible: [move out of cover(-2 MovePoint); attack1(-2AP); go near ally unit (-4MP); healing on both allies (-3AP); end of turn]

Do you know how I could achieve such features or at least where I should look? Thank you very much for your help and good luck on your work,

Grégoire

No worries :slight_smile:

Hi Monokkel!

This Toolkit is becoming more amazing everyday, that’s great :slight_smile:

However, as you probably remember, we are working with the v1.82 version of the Toolkit and we are going so far with the new ability system, networked multiplayer and so on.
Thanks again for what you did also for a first version customer like us :slight_smile:

Right now we want to add some features to Arcane Legacy:

  1. Tutorial Mode vs AI
    This is like every tutorial you ever seen in your gameplay life: action is suddenly stopped, an UMG overlay with instructions on what you should do next appears and you have to follow that instructions to go ahead, move you character, attack, summon a servant, cast a spell, etc.
    As the creator of the Toolkit, how do you think how to achieve such a thing? Is it possible to create a New Game Mode with different rules without breaking everything?
    Or is it better to achieve this through modifications on the Game State?

  2. Scenario Mode
    We are planning to add single player campaigns to our game based on single scenario templates like XCOM.
    Protect a Priest, Resist 30 turns against an horde of enemies, find an artifact in a dungeon etc.
    So… even in this case from a Toolkit side of view, what is the best option to have multiple scenario rules? The main rule of the game is to defeat the enemy archmage in a duel, but we like to add different winning conditions. In v1.82 version, the winning condition is triggered by BP_Unit. This of course cannot work in scenarios like above. I thought to check a variable (IsDuel) and eventually skip the winning condition on the BP_Unit, but then, where you think is the best point to inject the different winning conditions? Is a good idea to have a different GameMode?

Thanks for the patience and thanks in advance for the help.

Regards,
Helly

Hey, Wisom-HELLy, glad to see you’ve got a demo up on steam :slight_smile: I’ll do my best to answer your questions.

Well, the function of the game mode in ATBTT is currently to handle the order blueprints are set up, as well as players joining, while the game state is just used as a singleton for accessing other singletons. You are free to modify these, of course, but you should keep most of what is there, as the rest of the toolkit is dependent on it. So if you want to create a new mode or state, you should either duplicate the old ones or use child blueprints. I have not done anything like what you describe myself yet, but from a quick search I can see that there are several discussions on pausing the game when within a menu, such as an inventory system etc. So if that is what you’re after you could do something like that. Pause the game, show your custom tutorial UMG and resume when the player gives the appropriate input.

This basically just boils down to checking whether a condition has been met at any point where the relevant variables have been changed, and ending the game if it is true. By default I want to end the game when only one faction remains. Every time a unit dies there is a possibility that only one faction remains, which is why I check this condition within BP_Unit, where unit death is handled. For your other conditions you would do similar checks at whatever point is appropriate. For your 30 turn limit, for instance, you could check the value of current turn whenever it is incremented, and end the game when it reaches thirty. So the question is what is the best way to implement something like this which is easy to work with. One way would be to have multiple child blueprints of the game mode or game state that each implement different overridden versions of an IsGameOver function. Another would be to have all of these options contained within a single function, where the type of condition that is checked is defined by an enum. In both these cases you could then run the generic IsGameOver function in all parts of the toolkit where any of your victory conditions could be met (you should be able to avoid ever using an event tick for this in a turn based game).

Happy to help :slight_smile:

HI Monokkel! I still can’t fix AI behaviour. Can you help pls? My suggestion the problem somewhere in BP_gridManager > Find tiles in move range with sight to target. Thanks!