Skill Link Conditions

[HimeWorks]

http://www.himeworks.com/2014/03/30/skill-links/
After a skill is executed, any linked skills can then execute.

Naturally, you want to be able to add conditions for whether they can execute or not.
Some things that would be nice to check

1. The user
2. The target
3. The result of the user's action

The user is always available, however the target and result are not so obvious.

Linked skills have the property that they can have their own scopes. This raises several issues.
First, suppose you used a healing spell that targets an ally, but the spell has a linked skill that will damage all enemies.

The action object currently does not store target information, so you don't actually know who you hit (and consequently, you can't look up the results of your action on each target).

In order to provide useful action conditions, it is necessary for the action to keep track of the targets. This is easy and does not pose too many issues...at least I don't think it does since all we need is to store the targets.

Ok, so now we have the targets of the action, but now the problem with scope occurs again: does the link condition apply to SKILL USE and SKILL APPLICATION?

Skill use refers to whether you can actually execute the linked skill.
Skill application refers to whether you can use it on a particular target.

If we have a skill that targets allies, and then a linked skill that targets enemies, the conditions for the linked skill CANNOT use the original action's results in its application condition...because it is a completely different target!

This probably isn't an issue as long as you keep in mind the difference between skill use and skill application for the most part.

[Roguedeus]

Good explanation.

Clearly stating that conditions based on previous results can not flip the enemy/ally dichotomy should be enough as I see.

[HimeWorks]

Here's something that would be a little difficult to write.
Let's say you wanted to create a skill that "bounces off" a target.

For example, you have three enemies lined up like this

 A    B    C

When you hit A, it deals 200 damage.
It then bounces off and hits B for 100 damage.

The condition here is that the skill has hit the previous target, but what is the previous target?
And what happens if an action has multiple targets? Who would be the previous target?

It becomes really involved once you consider the fact that you can have multiple target scopes, and if you need to access another target's results.

[Roguedeus]

I understand. I suppose the question becomes whether you want to add new scopes with the new functionality, or simply utilize the existing ones.

The example you gave would be very similar if the scope for the linked skills were targets X random... Such as three linked up skills, each doing less damage then the previous, and each having 1 random enemy as their scope. Link conditions adding even greater variability.

It wouldn't be as focused an effect, but it would still be reasonably predictable and nearly transparent to the player.

[HimeWorks]

When I first wrote the script, the use case I was focused on was a skill that damages enemies and heals allies.

By simply running two separate skills together, it achieves that effect quite easily.

Having targets would provide a lot more conditions to work with.
But if we have information about the targets, we can use that information for later skill executions as part of the damage formula.

[Roguedeus]

Are you saving the previous targets as class variables? Once they are determined on the first result?

There wouldn't be compatibility issues with something like Yanfly's Target Manager? (I can't look at the code at the moment) I only use it for the control of choosing a primary target and then having 'X' randoms determined. The default of not having random scope including at least the first target is frustrating sometimes.

[HimeWorks]

As long as Game_Action#make_targets returns an array of targets, it's fine.

[Roguedeus]

The issue is that the way the skill links are collected, and processed in order, doesn't lend itself to easily adding a conditional, resembling something like you did with Conditional States.

I am thinking it may be best to create Skill Link objects in the load_notetag_skill_links method and process those objects in the skill_links method.

Each Skill Link will hold its conditional string, and evaluate it when processed.

That way, the separate skill links, can have simple resolve true, or a more complex return ID, or a selection of both, for more complex combos.

[HimeWorks]

The condition I had in mind was to simply return true or false depending on whether the attached skill will be executed or not.

[Roguedeus]

I know it may not be an issue worth addressing, but the way the script works now, all linked scopes fire as independently of any origin target, which can often make for undesired results.

For example, a single enemy scope skill that is linked with a second single enemy scope skill.

If the first skill ends up killing the target, the linked skill fires off at a new target instead of stopping itself because the original target is dead.

Would it be easy to add an option to link tags that specifies if it should be nullified if the original target is gone?

Or visa verse, what if a linked skill can ONLY fire off if the original target dies?

Hmmm.

[HimeWorks]

All the different cases would be handled by the linked skill conditions.
There would need to be a way to reference the "original" data though.

[Roguedeus]

I don't know why but I had one of the hardest coding days I have had in a while...

Sometimes by brain just wont visualize code.

[Roguedeus]

I have a preliminary link condition plugin atm... Making sure all its options function as expected before sharing.

[Roguedeus]

Done: http://www.roguedeus.com/Stuff/RDeus%20-%20Skill%20Links%20Plugin.rb

I don't think I did anything wrong or unnecessarily. Let me know if I did.

[Roguedeus]

I think on line 430 I shouldn't have left the *.uniq call for the arrays... With the way I ended up doing it, there is a risk of having an unequal comparison to the results array for a multi-hit skill.

[HimeWorks]

All battlers should be unique regardless. Where would the issue be?

[Roguedeus]

No issue now, but when I was first looking at making totals, I didn't want repeat targets being in the array. I'm gonna remove that.

[Roguedeus]

Now I remember. I was thinking about having conditions that required a minimum number of different targets being hit before qualifying. Having repeat battlers in the targets array would allow the same battler to be counted multiple times.

[Roguedeus]

Can you look at my solution and tell me if there was a better one?

Essentially I am checking each results target against the array of targets already pushed and then updating u_* versions of applicable variables so its now super easy to condition using unique target counts rather than gross target counts.

Link above is updated.

[HimeWorks]

Better what?

[Roguedeus]

Better solution. More efficient, etc... Or just your opinion. :)

I learn from criticism and rarely take it personally when I request it.

[HimeWorks]

I think as long as it works, looks clean and abstracted, it's fine.
You'll typically know if it's a good solution once you start using it or write extensions on top of it.