Untargettable State

[RaythalosM]

There seems to be a problem with untargettable states; It seems to break auto-attack whenever there's an untargettable enemy and you killed a different enemy. The other party members would try to attack the untargettable enemy and the game would cancel their action, causing attacks that would have been aimed at another targettable enemy to be wasted.

Example: Slime A, B, C was encountered. Slime A was applied the untargettable state. Slime B was attacked and killed by Eric. The other 3 party members tried to attack Slime A instead of C, and their actions get cancelled.

Demo Attached: https://mega.nz/#!TM1HXRLS!qMojh8c6StQLVqppPueRE8dNU31BuP9sDjNw4oCf214

[RaythalosM]

I got around it by modifying smooth_target(index)'s alive_members in game_unit into targetable_members, is this a perfectly valid workaround for now?

[HimeWorks]

I think that should be fine. The purpose of smooth_target is to find another valid target in case the original one is no longer valid.

targetable_members is meant to be a list of valid members (except it only filters out "untargetable" members)

[RaythalosM]

Oh, so that's what it did. I see. On another note, it seems enemies will still try to attack untargettable actors even with smooth_target modified. Is there any way to stop them from trying to attack untargettable actors?

EDIT: Actually, scratch that. Setting TGR to 0% for that state seems to work...?

[HimeWorks]

Enemies don't actually try to target anyone. They literally use "random target" all the time. TGR simply makes it so that an actor is more or less likely to be randomly selected, so TGR of 0 would work.

However if the actor is the only one left...it would still try to be targeted.

[RaythalosM]

Hmm. Well, the actor being the only one left wouldn't be a problem, since I'm using a incapacitate state for actors combined with the untargettable state so it wouldn't matter (sort of like Petrify)

I found an (apparently unresolved) issue with actor targetting however, as actors who are untargettable even though they don't have an icon will still have their selection slots treating them as if they are still there and you will still target them (and failing) Screenshot attached: http://puu.sh/knClf/18a915e034.jpg

I've been messing around with the scripts through trial and error due to my lack of scripting skills switching alive_member or battle_member with targettable_member but it doesn't seem to work properly.

[HimeWorks]

Does this occur in a new project? Without the battle system?

On Fri, Sep 25, 2015 at 9:33 AM, RaythalosM notifications@github.com wrote:

Hmm. Well, the actor being the only one left wouldn't be a problem, since I'm using a incapacitate state for actors combined with the untargettable state so it wouldn't matter (sort of like Petrify)

I found an (apparently unresolved) issue with actor targetting however, as actors who are untargettable even though they don't have an icon will still have their selection slots treating them as if they are still there and you will still target them (and failing) Screenshot attached: http://puu.sh/knClf/18a915e034.jpg

— Reply to this email directly or view it on GitHub https://github.com/Hime-Works/Requests/issues/298#issuecomment-143224533 .

[RaythalosM]

Apparently, yes. I tried it earlier on the demo I linked but I modified it to give the untargettable state to the first actor instead of the enemy, and ordered everyone used a potion on the second actor, (which is the first selection in the window because the first actor is unselectable) but everyone tried to use the potion on the first actor instead, cancelling all the orders.

That demo is also clean, other than that script and a message script that would most likely not have anything to do with it.

[HimeWorks]

This one's a bit strange. The way the target selection works is that when you pick an actor in the window, the index that is returned, will be the target index of the action.

So for example, if you select index 1, then your target will be the second actor in battle. In this case, if the second actor is not targetable, it would still be set as the target. Now, target smoothing would come in to play and select a different target, but that's not really what "targeting" means.

Changes would need to be made for each battle system, since you would need to grab the index of the actor that the player selects, rather than the index of the window.

[RaythalosM]

So it's a lot more complicated than I thought-

Is there a way for me to modify it for Yanfly's Battle System? Which classes do I need to tweak around?

[HimeWorks]

Here is an example from the default battle system.

Scene_Battle

def on_actor_ok
    BattleManager.actor.input.target_index = @actor_window.index
    @actor_window.hide
    @skill_window.hide
    @item_window.hide
    next_command
end

You can see that it uses the actor window's index. You might need something like

class Window_BattleActor < Window_BattleStatus
  def actor_index
    $game_party.targetable_members[index]
  end
end

This one returns the index based on targetable members

And now you need your battle scene to know this

def on_actor_ok
    BattleManager.actor.input.target_index = @actor_window.actor_index
    @actor_window.hide
    @skill_window.hide
    @item_window.hide
    next_command
end

[RaythalosM]

Hmm, using your example, making on_actor_ok take the actor_index causes the default battle system to crash- "Can't convert Game_Actor into integer"

Either that or I completely missed the point since it's 6:30 AM right now. I'll try to work around this tomorrow- Thanks for taking the time to help

[RaythalosM]

I give up. I couldn't think of anything, so I just remodified my battleactor to draw the untargettable actors, but you couldn't select them regardless. (a buzzer will sound since i modified current_item_enabled to return false if !battle_members[index].can_target?)

It's a brash solution, but it does the job at least.

On another note, does targetable_members pick all members whether they are dead or alive? I modified members.select into alive_members.select in def targetable_members as a solution since the enemies now started futilely attacking dead members.