Announcement

Collapse
No announcement yet.

[SUPPORT] Advanced Turn Based Tile Toolkit

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

    Me again, just to say that I've solved the issue and it was me missing something obvious. I was casting to ABP_Unit instead of the ABP for the new character/skeletal mesh, although not 100% sure how thats happened as I don't think it was covered in your video. Probably my fault again! Still very new to all this.

    Comment


      Originally posted by Loadout View Post
      Hey, first off fantastic package. As someone very new to blueprints its a brilliant resource to look through and learn from. I was following along with your Custom Units - Custom Rigs tutorial on youtube, but am having an issue. I'm getting this error with AbpRef. The idle is playing, but nothing else is working with movement or attack etc, as it is failing to cast to ABP_Unit. Guessing its something very basic I've missed, but felt I had followed the tutorial along correctly.
      Click image for larger version

Name:	Screenshot_68.png
Views:	22
Size:	65.2 KB
ID:	1625332
      Thanks!
      Originally posted by Loadout View Post
      Me again, just to say that I've solved the issue and it was me missing something obvious. I was casting to ABP_Unit instead of the ABP for the new character/skeletal mesh, although not 100% sure how thats happened as I don't think it was covered in your video. Probably my fault again! Still very new to all this.
      Glad you figured it out. Simple mistake to make. Hopefully it was not caused by something incorrect I said in the video.

      Originally posted by Zennisin View Post

      this sounds great! For what it's worth, in my game it's perfectly acceptable for a unit to die on it's own turn depending on the decision they make. They could even die in the middle of their run from tile A to tile B.
      Yeah, that is probably the case for many games, which is why I'm trying to find a generic solution for this.
      The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

      Comment


        hi knut

        If possible I would like to know when another major update is planned (roughly)
        I just want to plan my continued work with regard to the updates you are working on (if possible of course)
        Every major update requires me to start a new project, although some of the blueprints are only mine and then I just switch, but some are actually based on your orginal blueprint which I have to change according to my changes.

        In any case, it is not very important and only if you have a rough estimate

        cheers

        leo

        Comment


          Originally posted by Monokkel View Post
          I think there might be a naming conflict here that is causing trouble. There are two TargetIndex variables here. One is the one stored in the ability itself. Another is the one stored as a local variable in the function (blueprint functions automatically converts input variables to local variables). I think you're using the TargetIndex variable of the main blueprint instead of the local one of the function. As the AI and player store the target index differently, I'm guessing this fails in one of the cases. This is my bad for not naming them differently. If you right click the graph and search for the TargetIndex variable select the lowest one that is least indented. That should be the local variant.
          Yep, that was totally it! For what it's worth I think it'd be a good idea to keep those variables named differently, in case you could do that in later updates, unless it's smarter to work like this (in which case, I'd love to know why).


          Now, next experiment. For the way these counterattacks have been set up, they are bound to the attacking unit, meaning no matter who this unit attacks, it would always receive counter damage, since it's something hardcoded in the ability. Now, I wanted to flip this around, and make the counter be bound to the attacked unit, meaning no matter who attacks this unit, they should receive some counter damage.

          So my though process was this, and please tell me if I'm on the right track during all this or I'm missing important ATBTT rules here.

          -Normally I'd like to just paste the extra branch we added in ExecuteAbility() simply after the unit takes damage instead, but this is: A) not very modular, and B) not really possible, because the TakeDamage() function is in BP_Unit, which has no easy access to all that information like TargetIndexes/GridManagerVariables that abilities have...

          -So, to solve A), I would create a BPI, let's say BPI_CounterAttack, and add it to the unit I want to have this status effect. This should be a very modular solution to the problem, since I can attach or detach during gameplay these BPIs to various units (dont really know how to yet but I assume this is easily doable).

          -To solve B), now in BP_Unit's TakeDamage(), after the Hurt Queue Action I simply check if the object/unit has the BPI_CounterAttack, and if so I send through the Return Node a HasCounterAttack boolean as true. With this, back in the ability's ExecuteAbility() I can specify what happens when this occurs after I call TakeDamage(), saying for example if HasCounterAttack is true, take damage. I even win some control in specifying whether some abilities are immune to this status effect or not.

          What do you think? Can you think of easier & better ways of implementing this?
          Last edited by Justo; 06-04-2019, 06:42 AM.
          Artstation | 3D Artist | Krakow

          Comment


            Originally posted by leo bar View Post
            hi knut

            If possible I would like to know when another major update is planned (roughly)
            I just want to plan my continued work with regard to the updates you are working on (if possible of course)
            Every major update requires me to start a new project, although some of the blueprints are only mine and then I just switch, but some are actually based on your orginal blueprint which I have to change according to my changes.

            In any case, it is not very important and only if you have a rough estimate

            cheers

            leo
            It is a bit difficult to estimate, and depends a bit what you mean by major update. The next planned update is the one that includes a system for inserting actions into the ongoing action queue. This could potentially be done in a week or in two months. It depends on how thoroughly I'll need to modify the turn order code to get a satisfactory solution for units dying during their own turn. I guess my rough estimate is three weeks, but it is a pretty wild guess. This update will in any case be quite small compared to my major revisions, and I imagine it should be possible to just implement just the relevant changes.

            Originally posted by Justo View Post

            Yep, that was totally it! For what it's worth I think it'd be a good idea to keep those variables named differently, in case you could do that in later updates, unless it's smarter to work like this (in which case, I'd love to know why).
            Ok, glad to hear that was the reason. I agree that it is not ideal to have variable name conflicts like this. I've had it on my list of things to fix for a while, but other things have taken priority.

            Originally posted by Justo View Post
            Now, next experiment. For the way these counterattacks have been set up, they are bound to the attacking unit, meaning no matter who this unit attacks, it would always receive counter damage, since it's something hardcoded in the ability. Now, I wanted to flip this around, and make the counter be bound to the attacked unit, meaning no matter who attacks this unit, they should receive some counter damage.

            So my though process was this, and please tell me if I'm on the right track during all this or I'm missing important ATBTT rules here.

            -Normally I'd like to just paste the extra branch we added in ExecuteAbility() simply after the unit takes damage instead, but this is: A) not very modular, and B) not really possible, because the TakeDamage() function is in BP_Unit, which has no easy access to all that information like TargetIndexes/GridManagerVariables that abilities have...

            -So, to solve A), I would create a BPI, let's say BPI_CounterAttack, and add it to the unit I want to have this status effect. This should be a very modular solution to the problem, since I can attach or detach during gameplay these BPIs to various units (dont really know how to yet but I assume this is easily doable).

            -To solve B), now in BP_Unit's TakeDamage(), after the Hurt Queue Action I simply check if the object/unit has the BPI_CounterAttack, and if so I send through the Return Node a HasCounterAttack boolean as true. With this, back in the ability's ExecuteAbility() I can specify what happens when this occurs after I call TakeDamage(), saying for example if HasCounterAttack is true, take damage. I even win some control in specifying whether some abilities are immune to this status effect or not.

            What do you think? Can you think of easier & better ways of implementing this?
            I think this sounds like a very reasonable approach. The solution that might come to mind immediately is to include the code in the TakeDamage event, but it would be unnecessarily called several times, and you'd have to pass over a lot of relevant information. Having the ability call an interface event on the unit as part of the execution seems like a flexible and clean way to solve it.
            The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

            Comment


              Oh, I just realized my mistake. A BPI can only be added to blueprints and not in-game actors, meaning if I added the BPI_Counterattack to a certain unit's BP, all of the other units sharing the same BP would acquire counterattack too. Someone tell me if I'm wrong though, obviously.

              1) Knut, have you made any videos going in-detail about status effects in the ability system, or maybe have some sample code somewhere in a specific map example? Maybe I could create a status effect for this Counterattack, which BP_Unit's TakeDamage() could verify if it exists in its unit, to know whether to send back the OK signal for counterattack damage to be applied.

              2) Smaller curiosity Q: I am not aware what's the purpose of leaving Branch nodes empty after a True/False pin, and why you seem to never do this in certain places. Say, for example, in many Event Graphs, like BP_Ability_MoveAttack or BP_TurnManager, after you do a "check if..." it's common to see you leave the False pin empty, and continue the code only when the Branch node comes out as True/Valid.
              Shouldn't such an action freeze the game? It obviously isn't freezing when I run it so it's not a problem, but I do not understand why it isn't doing so. If the code is running each tick, and comes across one of these checks and is invalid, it has nowhere else to go! No return nodes, no exits, nada! However, you never seem to do this (AFAIK) inside functions, since in those you always put in a return node no matter where the code ends. I suppose what I am saying about freezups do apply here, and that's why you do this, but just in case, I wanted to hear your words on this, if possible.

              Cheers, and have a nice day Knut & everyone.
              Last edited by Justo; 06-05-2019, 05:54 AM.
              Artstation | 3D Artist | Krakow

              Comment


                Originally posted by Justo View Post
                Oh, I just realized my mistake. A BPI can only be added to blueprints and not in-game actors, meaning if I added the BPI_Counterattack to a certain unit's BP, all of the other units sharing the same BP would acquire counterattack too. Someone tell me if I'm wrong though, obviously.
                I still think your idea is solid. I generally recommend making a duplicate of BP_Unit_anim as the starting point for your own units (unless you are not making units with skeletal meshes, and if so check my recent animation videos). You could implement the interface for this unit. Then you could tie the interface event in the event graph to a branch that checks if this particular unit can counterattack before proceeding with this.

                Originally posted by Justo View Post
                1) Knut, have you made any videos going in-detail about status effects in the ability system, or maybe have some sample code somewhere in a specific map example? Maybe I could create a status effect for this Counterattack, which BP_Unit's TakeDamage() could verify if it exists in its unit, to know whether to send back the OK signal for counterattack damage to be applied.
                There are currently two status effects demonstrated in the toolkit, which is the mind control and woke status effects. Check them out in JungleRaid. I cannot remember to what degree I've covered these in my tutorials. Probably not enough. They are fairly straightforward, though. If you add a status effect (generally done through a function in BP_Ability) the effect is added to an array of status effect (provided the unit has the ability system component). Then on the start and end of a unit's turn it loops through all its status effects and run any events specified in the status effect to run at this time.

                Originally posted by Justo View Post
                2) Smaller curiosity Q: I am not aware what's the purpose of leaving Branch nodes empty after a True/False pin, and why you seem to never do this in certain places. Say, for example, in many Event Graphs, like BP_Ability_MoveAttack or BP_TurnManager, after you do a "check if..." it's common to see you leave the False pin empty, and continue the code only when the Branch node comes out as True/Valid.
                Shouldn't such an action freeze the game? It obviously isn't freezing when I run it so it's not a problem, but I do not understand why it isn't doing so. If the code is running each tick, and comes across one of these checks and is invalid, it has nowhere else to go! No return nodes, no exits, nada! However, you never seem to do this (AFAIK) inside functions, since in those you always put in a return node no matter where the code ends. I suppose what I am saying about freezups do apply here, and that's why you do this, but just in case, I wanted to hear your words on this, if possible.

                Cheers, and have a nice day Knut & everyone.
                You do not actually need to have return nodes for everything in blueprint functions, as the compiler takes care of this. It is best practice, though, as it keeps your intentions more clear. Also, using a return node can exit a function even if it is, say, in the middle of a loop.

                As for the empty nodes in various event graphs, I think I've generally set these up so that if they fail they are called again, or alternately send an error message. I'm sure I've forgotten it in some places, though. Could you mention some specific ones?
                The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                Comment


                  Originally posted by Monokkel View Post

                  I still think your idea is solid. I generally recommend making a duplicate of BP_Unit_anim as the starting point for your own units (unless you are not making units with skeletal meshes, and if so check my recent animation videos). You could implement the interface for this unit. Then you could tie the interface event in the event graph to a branch that checks if this particular unit can counterattack before proceeding with this.
                  But regardless of whether I create a duplicate/new BP for my units, if I attached the BPI during gameplay to any unit's BP, all the other units sharing/inheriting from this BP woud acquire counterattack too, no? This would be a no-go. That was why I asked about status effects - maybe this counterattack should use the same setup that those use, so that units sharing the same BP_Unit can be affected by different effects.

                  Originally posted by Monokkel View Post
                  You do not actually need to have return nodes for everything in blueprint functions, as the compiler takes care of this. It is best practice, though, as it keeps your intentions more clear. Also, using a return node can exit a function even if it is, say, in the middle of a loop.
                  Nice, I didn't know that about the return nodes - thanks for explaining that!

                  Originally posted by Monokkel View Post
                  As for the empty nodes in various event graphs, I think I've generally set these up so that if they fail they are called again, or alternately send an error message. I'm sure I've forgotten it in some places, though. Could you mention some specific ones?
                  Well, in BP_TurnManager I can see an empty IsNotValid pin right after the BeginActorTurn event is called, in the Begin Actor Turn colored comment chart. Or an empty False branch in the same chart at the end, after ServerUpdateInitiativeBar is called. In BP_Ability_MoveAttack's event graph, right after the Event Server Interact, inside the Click chart, we have tthree branch nodes, two of which have empty False pins.

                  Again though, just to be clear, I am not saying this is wrong - obviously the kit works like a charm as is from my POV. I simply wonder how it is these BPs can leave open ends like this and not simply freeze up.
                  Artstation | 3D Artist | Krakow

                  Comment


                    Hello! I had question about using 2D sprites with the 'Advanced' portion of the turn based tool kit.

                    You see, I'm trying to create a game like Final Fantasy Tactics, and I wanted to emulate the art style while retaining the 3D gameplay (complete with extra abilities and such)

                    I have seen the 2D portion of the toolkit, and while its mindblowing, I don't think I can create the game I'd like with it. To be sure, here's an image of what I'm trying to do: Click image for larger version  Name:	finalfantasytacticsthewarofthelions20070708081504429000.jpg Views:	1 Size:	43.0 KB ID:	1628452

                    It plays exactly like your toolkit, but uses 2D images instead.

                    Does anybody know how I could implement 2D sprites with the 3D version of your toolkit?

                    Comment


                      LuckyDuck12 I don't know how to achieve this, but if you really want 2D graphics for the characters, I would imagine they would be planes with the sprite animation textures, that would always be looking straight at the camera, no matter the rotation. So, I would A) look up Unreal's 2D tools, and B) work this rotation functionality for my sprites to always rotate to face the camera.
                      Artstation | 3D Artist | Krakow

                      Comment


                        Originally posted by Justo View Post

                        But regardless of whether I create a duplicate/new BP for my units, if I attached the BPI during gameplay to any unit's BP, all the other units sharing/inheriting from this BP woud acquire counterattack too, no? This would be a no-go. That was why I asked about status effects - maybe this counterattack should use the same setup that those use, so that units sharing the same BP_Unit can be affected by different effects.
                        It is no more difficult than having the interface event tied to a branch that checks if a bCanCounterAttack variable is true or not. I don't think you would gain much by having status effects, unless you want to turn on and off counter attack capability for the same unit during a game as well as modify the effect on turn start or turn end.

                        Originally posted by Justo View Post
                        Nice, I didn't know that about the return nodes - thanks for explaining that!
                        You're welcome

                        Originally posted by Justo View Post
                        Well, in BP_TurnManager I can see an empty IsNotValid pin right after the BeginActorTurn event is called, in the Begin Actor Turn colored comment chart. Or an empty False branch in the same chart at the end, after ServerUpdateInitiativeBar is called. In BP_Ability_MoveAttack's event graph, right after the Event Server Interact, inside the Click chart, we have tthree branch nodes, two of which have empty False pins.

                        Again though, just to be clear, I am not saying this is wrong - obviously the kit works like a charm as is from my POV. I simply wonder how it is these BPs can leave open ends like this and not simply freeze up.
                        To take the BeginActorTurn event as an example I'm preventing the toolkit from activating a nonexistent actor, as this could lead to some weird behavior. There validity checks are done in some cases where I always expect it to be valid. If it fails it will now do so in a way that is less confusing when I'm debugging. Ideally I should connect the invalid output to a print node to make the developer aware of exactly what failed. I do this in some instances, but I've missed a few spots. Some are remnants of bug-testing that should perhaps have been removed.

                        Originally posted by LuckyDuck12 View Post
                        Hello! I had question about using 2D sprites with the 'Advanced' portion of the turn based tool kit.

                        You see, I'm trying to create a game like Final Fantasy Tactics, and I wanted to emulate the art style while retaining the 3D gameplay (complete with extra abilities and such)

                        I have seen the 2D portion of the toolkit, and while its mindblowing, I don't think I can create the game I'd like with it. To be sure, here's an image of what I'm trying to do: Click image for larger version Name:	finalfantasytacticsthewarofthelions20070708081504429000.jpg Views:	1 Size:	43.0 KB ID:	1628452

                        It plays exactly like your toolkit, but uses 2D images instead.

                        Does anybody know how I could implement 2D sprites with the 3D version of your toolkit?
                        Like Justo said, you can just place a sprite or flipbook component on your unit and it should work fine. If you have a game with a set camera than cannot rotate you can just have them face in that direction to begin with and refrain from rotating them during movement. If you have camera rotation you can rotate them to face the camera on tick. Here is the first AnswerHub thread I found on how to do this.
                        The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                        Comment


                          Hello Dr. Monokkel, First off congrats on the completion of your phd. that is a lot of hard work you have done in the past few years doing that and keeping up with this. Again it looks like I have some new vids to look at and updates to check out, thank you for those.
                          I have been thinking about level steaming and figuring it may be difficult, any thoughts on this ?
                          Also, I have been testing out the imposter system from Fortnite, managed to double the frame rate of the example map(Hex) so that made me happy. I see on you trello you might be working on a procedural map system, I have found something I am trying to implement here.. https://forums.unrealengine.com/deve...=map+generator
                          I will let you know how that works out, but it might take some time..

                          Comment


                            Originally posted by Monokkel View Post

                            It is no more difficult than having the interface event tied to a branch that checks if a bCanCounterAttack variable is true or not. I don't think you would gain much by having status effects, unless you want to turn on and off counter attack capability for the same unit during a game as well as modify the effect on turn start or turn end.
                            So then, if the unit is going to have a public boolean that specifies whether this single entity can do the effect or not, do you not agree the BPI_CounterAttack serves no purpose anymore and could be taken out of the equation? After all, the branch will just check if the boolean within the unit is true or not, and the entire exchange will be communicated between the ability's ExecuteAbility() and the unit's TakeDamage() - I see no need to add in a BPI, no?

                            Originally posted by Monokkel View Post
                            To take the BeginActorTurn event as an example I'm preventing the toolkit from activating a nonexistent actor, as this could lead to some weird behavior. There validity checks are done in some cases where I always expect it to be valid. If it fails it will now do so in a way that is less confusing when I'm debugging. Ideally I should connect the invalid output to a print node to make the developer aware of exactly what failed. I do this in some instances, but I've missed a few spots. Some are remnants of bug-testing that should perhaps have been removed.
                            If I am understanding you correctly, you don't deny that if those validity checks end up as false, they really can freeze the game, right? I was under the assumption that this could happen and the game would flow normally.

                            It just so happens to be that you have already accounted for all possible failure scenarios, or at least to the best of your knowledge, so all those validity checks are there mostly as a debug tool for us.
                            Artstation | 3D Artist | Krakow

                            Comment


                              Originally posted by Justo View Post

                              So then, if the unit is going to have a public boolean that specifies whether this single entity can do the effect or not, do you not agree the BPI_CounterAttack serves no purpose anymore and could be taken out of the equation? After all, the branch will just check if the boolean within the unit is true or not, and the entire exchange will be communicated between the ability's ExecuteAbility() and the unit's TakeDamage() - I see no need to add in a BPI, no?
                              Well, partly. If you add the interface to BP_Unit you can just use a regular event or function. However, if you make these additions to a child actor such as BP_Unit_Anim in order to keep BP_Unit simple, using an interface means you do not have to cast to that unit. This could become cumbersome if you have many different types of unit classes. Casting is also a slow operation and creates dependencies, though that is unlikely to have any significant impact.

                              Originally posted by Justo View Post
                              If I am understanding you correctly, you don't deny that if those validity checks end up as false, they really can freeze the game, right? I was under the assumption that this could happen and the game would flow normally.

                              It just so happens to be that you have already accounted for all possible failure scenarios, or at least to the best of your knowledge, so all those validity checks are there mostly as a debug tool for us.
                              Yes, they are basically there for debugging, as they should never return false in a regular game.
                              The Advanced Turn Based Tile Toolkit (Marketplace page - Feedback thread)

                              Comment


                                I see the light now. Thanks Knut, and thx for the comment about casting too - since I don't have much of a background programming in Unreal, general guidelines like that is always useful to keep in mind. I believe I should't need to cast for this, but I will first try and experiment with this new info before rambling more here.
                                Artstation | 3D Artist | Krakow

                                Comment

                                Working...
                                X