Announcement

Collapse
No announcement yet.

[SUPPORT] Advanced Turn Based Tile Toolkit

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    @wisdom-HELLy

    Why not just use widgets? Do you want to create a pop-up text or something that is visible all the time?

    Comment


      I know that I can design on the HUD permanently, but I want an HUGE text that needs to be shown when a character hits another one (or if it miss the enemy) like "HIT!" or "MISS!".
      That text should disappear after a couple of seconds.
      Fantasy Turn-Based Tactical Game
      STEAM: https://store.steampowered.com/app/9...Arcane_Legacy/
      IG: https://www.instagram.com/arcanelegacyofficial/
      FB: https://www.facebook.com/ArcaneLegacy/
      WEB: http://www.arcanelegacy.com

      Comment


        Okay so basically a text that is shown as soon as a specific event occures. I have something like that for a character entering the interaction radius for a chest but the condition should be easily changeable.

        I first created a widget which consists only of a horizontal box and a text (deleted the canvas panel). In the blueprint I created 2 variables, 1 for the text (InteractText, text variable) and one for the actor on which the text location depends (InteractActor, actor variable). The content of the text (in the Designer tab) is bound to the text variable (InteractText). Then I created the following to set up text location and so on:
        Click image for larger version

Name:	interacttxt.png
Views:	1
Size:	153.3 KB
ID:	1074916

        After that I used the following to show the text (here on event overlap). To hide it again just use 'removefromparent' as soon as it shall disapear. You can also just add it after a delay. In your case this should be added after the hit/miss event.
        Click image for larger version

Name:	showinteracttxt.png
Views:	1
Size:	123.4 KB
ID:	1074917
        Last edited by Hinato; 04-22-2015, 02:26 PM.

        Comment


          @hinato: You've created your own invisible walls, then? The default hex ones only block one direction and are probably not ideal to your uses, since you always want to block at least three directions in your case. If you're worried about performance, UE4 can handle a huge amount of invisible actors without any performance hit, so it shouldn't be an issue unless you're using massive grids with tons of walls

          @Wisdom: Hinato's method looks good, but if you only need something very simple and basic you can do what I do with the "Player/Enemy turn" stuff in the HUD. I use a simple interface and change the text of the string to what is needed. To make it invisible after a few seconds you can just set visibility after a delay or even just change the text to an empty string if you want to be really lazy. HUD stuff is really not my forte, but I'll be looking into it more in future updates.
          The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

          Comment


            I just copied every premade hex wall and set the meshes of the copies to hidden in game. Then I placed one of them at each way that I want to be impassable and afterwards put a wall mesh right over them. So I can walk on every field but can't cross the directions in which the invisible walls are.

            Right now I have a problem with getting my doors to work with the new version. Up until now I got 'all actors of type' 'grid manager', got position 0 and with that casted to the grid manager to get the 'edge array' and change it. Redoing this with the new grid manager instead of the old one or the grid manager hex child (since i'm using hex tiles) doesn't work. Same when I get all actors of type game mode and cast to the grid manager/hex child via game mode. The cast to the grid manager/hex child just fails and I don't know why Maybe you can help? Thx!

            Comment


              @Hinato: Ok, I would recommend also making some new hex tiles that block all three edges on one side, as it will probably make your work quicker and greatly reduce the number of invisible actors (even though this has low impact on performance). If the amount of invisible actors should ever become a problem you can simply destroy them all on even begin play after they have been added to the edge array.

              For your new question, don't bother with casting. Just get the edge array directly from the Get all Actors of Class node. As long as the default value of the Grid Manager class variable is set to Grid_Manager (Grid_Manager_Child_Hex might also work, but is not necessary) it should work fine. Just tested it out.

              Edit: Quick example of how to print the faction of the pawn on index 1 of the grid from ATBTT_PlayerController:

              Click image for larger version

Name:	0DCpfVj.png
Views:	1
Size:	102.5 KB
ID:	1074925

              If you want to do this kind of stuff often it will save time to save the output of Get All Actors Of Class (Index 0) in a separate variableso you don't have to get all actors each time.
              Last edited by Monokkel; 04-22-2015, 03:10 PM.
              The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

              Comment


                Okay I got that and made changes accordingly.. Unfortunately it still doesn't work, but it did in the old version Here are my changes:
                Click image for larger version

Name:	door.png
Views:	1
Size:	162.1 KB
ID:	1074938

                That's the only part of the blueprint that differs from the old atbtt version. The pawn can walk through the gap in the wall if the door isn't placed and can't walk through if it's there. If the door is opened he could walk through in the old atbtt version but this doesn't work now. Edge cost open is only '1' at each entry, therefore the pawn should be able to pass :/
                Going to look at it again tomorrow.. maybe I'm just missing something obvious.

                Thanks for all the help!

                Edit: Even manually setting all edge costs of the door to 1 doesn't let me pass. Also I added 'Set Collision Enabled' --> 'No collision' as well as 'Set Collision Response To All Channels' --> 'Ignore' to the above function (target is the door mesh). This also won't solve the problem.
                Last edited by Hinato; 04-23-2015, 11:45 AM.

                Comment


                  @Hinato: I'm not entirely sure what you're doing wrong here, so I'll ask some questions to try to narrow it down:
                  • Grid Manager Ref has a default value, right? I know I keep asking, but I've done this mistake so many times myself.
                  • Is the blueprint above contained within your door blueprint? How are you calling it? Have you tried putting a print string in there to make sure it fires when you think it does?
                  • Edge Cost Open is a variable contained within your door blueprints? All edges are set to 1?
                  • Why are you running pathfinding within your door? Why from index 0 with move 0? What are you trying to accomplish by doing this?


                  It might possibly help you to know the order in which I do things:
                  • Edge costs of tiles are stored in their edge cost public variables that can be modified in the viewport.
                  • When the game begins, the "Add viewport terrain to arrays" function is called within the Grid Manager, adding the edge costs of the different tiles to the edge cost structs contained within the edge cost array at the indexes corresponding to the tiles placed in the level.
                  • When pathfinding is called it calculates a path based on the edge costs that are in the level at the moment pathfinding is called. If edge costs are changed after this, it will not be applied until the next time the pathfinding function is run.
                  The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                  Comment


                    Grid Manager has a default value, the above BP is part of the door and get's activated on user input. I already used strings to verify that the function fires and the edge cost open is all set to 1. I just copied pathfinding from further behind to show that it fires afterwards (without setting any entries) but I'm pretty sure that pathfinding function is run correctly since it's almost the same as last version (where everything worked).

                    The main problem seems to be that even if I select the door in the viewport and set all edge costs to 1 by default my pawn still can't pass through the door! But if I remove the door completely he can pass. Afaik the pawn should be allowed to pass as soon as all the edge costs are 1 or is there some other condition I'm missing?
                    Last edited by Hinato; 04-24-2015, 02:33 AM.

                    Comment


                      @Hinato: Something occurred to me. Are you using auto edge cost based on height? If you are and the door has collision and blocks path trace and is taller than height impassable cutoff, the edge costs would be set to 0 at startup. If this is not the reason I'm confused as to what's wrong. Maybe we can figure it out over Skype?
                      The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                      Comment


                        Wow never even thought of that.. Disabeling 'AutoHeight' solved the problem! The door is now working exactly like in the old atbtt version, thanks a lot!

                        Comment


                          @Hinato: Good to know that solved it! I went through my mind off differences between the two versions that could have caused this, and it seemed the only possibility. If you want to keep auto height enabled, just set the collision of the door to ignore PathTrace and it should work.
                          The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                          Comment


                            Monokkel

                            Wanted to get some feedback from you on some alterations I want to do with the tool kit

                            I want to alter the path finding for a hex grid map.
                            The goal is to make it so some units will have to do forward movement before turning one hex side. Examples:
                            Infantry can turn when ever they want so there are no restrictions on their path finding
                            bigger units might have to travel one hex before switching one hex side (Say it is facing north and wants to face south it would need to, 1. Move one hex forward, turn NE, move one hex, turn Se, move one hex, turn south

                            My solution so far includes
                            1. Two different path finding blue prints: the standard one and another that forces the forward movement before turning
                            2. Units will need some C++ code in the background to work along with the blueprints for the special units
                            3. As for the special path finding I was thinking
                            a. give each unit an int value stating how many forward movements they need to do, and a bool to let the system know if they can turn.
                            b. Then in the path finding check to see if a turn is allowed; if not path only in the direction the unit is facing (which I believe is already stored) if true then path find in three direction, the one the unit is facing and one on each side of that

                            NOTE the reason I was going to have a bool in the unit class was to allow movements to carry over. If a unit moves one space this turn it can turn at the start of its next turn

                            Comment


                              @nrm21122: That's some interesting stuff you want to do. I look forward to seeing how it turns out, and I'll try to do my best to help you out.

                              I think your solution makes sense. I agree with your decition to have two different pathfinding blueprints. That way you can be sure that your alterations will not slow down pathfinding in units where they are not needed.

                              As for C++, that I know very little of, and have so far managed to accomplish whatever I want using blueprints. Whether or not using C++ is better for your purposes is your call.

                              I'm unure if you need a bool. If I'm understanding thing correctly you could just use an integer counter that starts at a certain value depending on the unit, reduce it by one every step it takes and allow turning when it reaches 0. This can carry over just like a bool could.

                              The facing of pawns is not currently stored in the system, so you will have to implement that yourself. One way to do this is using the parent integers stored in the move structs in the Can Move To array. Any unit moving along a path found within a certain Can Move To array will always be facing the tile opposite the parent of the tile it is standing on, relative to itself. Another would be to use the yaw of the pawn to see which of the six directions it is facing and take it from there.
                              The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                              Comment


                                Monokkel

                                (Note not sure what happened, I responded yesterday but my post is not here)

                                Thanks for the quick feedback

                                I was thinking C++ because then I can do things in the class that may not be possible with blue prints. Case in point, I was going to use a bool instead of an integer (like you suggested) but after rethinking it I may go with the integer option. This way I could put modifiers in to effect the turn radius if that becomes an option

                                As for storing data I miss read the coding where you had the directions (north south ext) stored with a value of 5 for each. What I am going to have to do is do figure a way limit the directs the Ai will search when doing path finding. While I could do it the old school way where the players had to move the unit one hex at a time this would not be the best option

                                I will look into your suggestions and see what I come up with

                                One other question
                                You hinted a few post back you would be making more up to date videos for the kit. Any idea when you plan to have those available

                                Comment

                                Working...
                                X