[SUPPORT] Advanced Turn Based Tile Toolkit

[Monokkel]

@leo_bar

hi

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.

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.

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.