MUGEN CNS WIKI CHAOS@予定
MUGEN CNS WIKI CHAOS@予定

「Target」の編集履歴（バックアップ）一覧に戻る

Target - (2014/10/28 (火) 06:29:01) の編集履歴(バックアップ)

※解説修正情報※
●2014-10-28：Target系ステコン処理について、再度修正※差し戻し
●2014-10-28：Target系ステコン処理について・ガードヒット区別処理判明
●2014-10-28：MoveHit,MoveGuardedの対応処理はTarget,を　☓先に→○後に　取った方。
●2014-10-12：Targetスロットの概念を発見した。
●2014-10-11：Targetの喪失について。ガードふるい落としが出来ないかも。
●2014-10-11：Target８人制限を編集。HitOnceは特殊なTarget処理を行う。

※編集が中途半端かも。

■Targetについて

基本的な仕様
  • 攻撃を命中させると相手をTargetとして捉え、Target系の処理を行うことができるようになる。
  • Targetを取るにはSC-/HitDef、SC-/Projectile、SC-/ReversalDefのいずれかを当てなければならない。
    • 攻撃をガードされてもTargetは取ることができる。
    • 攻撃により相手側のSC-/HitOverrideが機能した場合はTargetは取れない。
  • 基本的にTargetを取った相手がMoveType!=Hになった場合、Targetが外れTarget系処理が通らなくなる。
    • StateNo=5150(死亡ステート)になった場合もTargetは外れる。
    • ステートを奪っていても外れる。
    • 例外として永続ターゲットがある。SC-/ReversalDefのLv4を参照。
    • もう一つ例外として、ターゲット保持バグがある。※要追加検証※
      • 複数のTargetがいる場合Targetの中で一番若いTargetスロットの相手が外れない限り、
        それ以外のTargetがMoveType!=HになってもTargetを喪失しない。
        • Targetスロットについては下に記載。
      • しかもそのまま保持し続けていると、
        別の相手に攻撃を何度か当ててると攻撃が当たらなくなるなどのバグが起きる。
  • Targetを取得している自分側が攻撃を受けたり、死亡したりした場合もTargetは外れる。
    • HitDefやProjの攻撃を受けた時点・死んだ時点でTargetが外れるだけで、
      その判定の後に攻撃が命中した場合はTargetは取得・維持できる。
    • 攻撃の命中時点でTargetを放棄するためHitOverrideが発動しても消える。
  • またSC-/TargetDropでTargetは自発的に放棄することができる。
    • TargetDropにてヒットIDを指定すると一人だけ相手を残して他を破棄することもできる。
      • 残す対象の相手が複数いる場合、Target(ヒットID),で参照する相手を残す。みたい。
      • Target,の複数いる場合の参照する相手についてはページ下部「Targetスロットについて」を参照。

Target８人制限
Targetは最大で８人までしか取ることができない。
処理はSC-/HitDefSC-/ReversalDefのHitOnceの設定で異なる。ProjはHitonce=0固定？
  • HitOnce=0の攻撃は同時に最大８人まで、Targetを取得できた相手にだけ命中する。
    • そのため既にTargetを８人取得している場合Target以外の相手へのHitOnce=0の攻撃は当たらない。
    • 例外的にSC-/HitOverrideが発動する相手には８人制限に関係なく命中する。
      HitOverrideが発動する相手のTargetは取得できないが、当たったことにはなる。
  • HitOnce=1の攻撃は命中する場合Targetを一度全て放棄した上で、単一の相手へ命中する。
    • そのため既に８人のTargetを取得していたとしても、再度相手が選ばれて攻撃が命中する。
    • ただし命中しても相手がSC-/HitOverrideが発動した場合Targetは取得できない。
※検証不足※同時命中時の対象選択はTarget,リダイレクトの処理に準じる？

ヒットカウントとTarget
  • 味方側の誰か(Helper含む)がTargetを持っている状態では画面に表示されるヒットカウントがリセットされない。
    • 永続ターゲットを利用している場合、Targetを保持し続けるのでヒットカウントはリセットされない。
    • 反対にTargetを持っているキャラ(Helper含む)が存在しない場合、ヒットカウントはリセットされる。
+ Helper消失によるヒットカウントリセットバグについて
仮にHelperが攻撃を通し本体他がTargetをとっていない状態でそのHelperをDestroySelfで消すと、Targetを持っているキャラ(Helper含む)が一人もいなくなり、相手がMoveType=H状態のままでもヒットカウントがリセットされてしまう。
気になるならDestroySelfのタイミングにroot,NumTargetなどを入れたり、攻撃判定自体をProjectileで処理するようにすると良い。
:|
Target系ステートコントローラー

■Lv1-注意点

Targetエラー
  • Targetが存在しない時にTarget,やTarget系ステートコントローラーを使用するとデバッグ表示でエラーが流れる。
    • 致命的ではありませんが、NumTargetでTargetがいるかどうかを確認した上で使おう。

TargetとHitIDの関係
  • HitIDとは、攻撃定義のオプションとして設定されたIDのこと。
    • Target(xHitIDx),と指定することで特定のHitIDの相手にのみ処理することができる。
    • ChainIDやNoChainIDなどにも利用できる。
  • しかしTargetの相手が誰であるか自体は攻撃した側で管理されているが
    Target(xx),などで利用するHitIDは攻撃をくらった側で管理されている
    • そのため保持されるHitIDは単一で複数の攻撃があたった場合もHitIDはどれか1つになる。
    • この仕様の厄介な点は目的のIDを出していないのに反応してしまうことがある点。
      • 具体例
        1. 常時監視ステートでNumTarget(2000)>0で特別な反応をするキャラＡがいるとする
        2. そのキャラＡと、ID=2000の攻撃を持った別のキャラＢがタッグで戦う。
        3. もしコンボなどでＡがTargetをとっている状態でＢがID=2000の攻撃を当てた場合…
        4. ＡのNumTarget(2000)>0が反応してしまうのである。ＡがID=2000を出していなくても
  • また設定できるID自体単一で、複数の相手へ命中した場合に別々の処理を行うことはできない。
    • Target(xHitIdx),の相手が複数いる場合、誰を参照するかを指定することはできない。
    • タッグで同時にガードとヒット両方であたった場合も、それらの区別はほぼ無理。
      • ガードとヒットで処理が異なる場合も、Targetで区別することは不可

Target系ステートコントローラーを使用する際の注意点
  • 基本、条件の中にT-/NumTargetを入れ相手の確認をとること。
  • Targetの対象に関する処理にも要注意。
    • 相手がガードしていてもTargetは取得する。
  • IDの指定は可能な限り行うこと。ID無指定では全Targetが対象のため
    ステコンを発動する攻撃を当てていない相手まで巻き込むこともある。
    • 非常におかしい状態になってしまうので可能な限りID指定をすること。
  • ID指定している場合は攻撃が重なった場合に、処理が通らない場合がある。
    • TargetIDについては上を参照。
  • なおT-/MoveHit=1などで処理を実行する場合、
    攻撃判定の持続で２人目に命中すると２度実行してしまう。
    • 実行タイミングの調整や実行後の処理の調整には要注意。
    • 調査が難しいため見落とされがち。

Target(),リダイレクトとTarget系ステコンのバグ
  • Target系ステコンのパラメーター内でTarget,リダイレクトを直接使用してはならない。
    • 使用すると最悪MUGENがフリーズしたり、エラーで落ちたりする。
    • Target情報を使用したい場合、一度Varへ入れてから使えば問題ない。
    • Trigger内で「:=演算子」で処理すると処理が楽。

MoveHit or MoveGuarded
同時ヒットした場合の処理はリダイレクトのページを参照して欲しいが、
ヒットとガードへ同時に命中した場合どうなるか
  • Hit系・Guard系のどちらか片方のみが処理される
    • 処理としては後側に処理した方をHit,Guardの基準とする。
      • 新規Targetへの同時ヒットはTarget,リダイレクトで参照する側参照しない側を基準とする。
これはT-/MoveHit/T-/MoveGuardedだけでなく、T-/HitCountや
攻撃の自分側の硬直なども、それを基準として行う。

Targetスロットについての仮説
TargetはスロットIDと同様、独自のスロット型で管理されている模様。
  • スロットはTargetの上限と同様１～８まで。
  • Targetになると最も若い空きスロットが割り当てられ、入った後は入れ替わらないし、繰り上がりもしない。
  • Targetから外れると、割り当てられていたスロットは空きとなる。
    • 例：ＡＢＣの順にTargetを取った後、１Ａと２ＢがTargetから外れて３Ｃだけ残り、
      新しくＤ→再度ＡをTargetに取った場合、スロットは１Ｄ・２Ａ・３Ｃの順になる。
  • リダイレクトのTarget,は該当する相手の中で最も若いスロット番号の相手を参照する。
    • IDを指定している場合、最も若い該当するHitIDを持った相手を参照する。
ターゲット保持バグはそのTarget,で参照する相手がTargetから外れる状態にならないと
次のTargetの状態を確認せずに保持し続けてしまう、という仕様のバグと思われる。

■Lv2-細かいバグ回避

味方他とのHitIDの混同について
  • NumTarget()だけで判定するのは不可。
    • StateNoやMoveHit、HelperならNumHelper+Helper,MoveHitなどと併用して判別しよう。

ガードとヒットが同時に起こった場合のTargetState関係について
  • 面倒であれば諦める。
    • 処理が安定しなくてもTargetStateを使いたいならTargetStateを。
    • ただTargetStateよりHitDefにP2StateNoを仕込むほうが安全。HitOverrideに命中しなくなるが。
  • 対応策はあるが、非常に細かいため、Lv3に記述。

Target,リダイレクト情報をTargetのステコンで使用する方法
  • 情報をVarに代入して、Varをパラメーターに記述するだけ。
    • 「:=」での代入を併用すれば非常に楽。

■Lv3-細かい応用


+ ■ガードとヒットが同時に起こった場合のTargetState制御

■ガードとヒットが同時に起こった場合のTargetState制御

:|
  • 情報提供DLS氏・調整アレンジADI氏
+ 最中に細かくTargetStateしない＋単発用
※完全ではなく、あくまでそれらしく制御できる記述です。
※TargetStateで壁バウンドをさせる技など用。
※長く持続する技だとうまくいかないことがある。
飛ばすステートの調整
相手を制御するステートの前に【ガード確認ステート】を作りそちらへ飛ばす

[StateDef XXX];ガード確認ステート
Type = U ;変更しない
MoveType = U ;変更しない
Physics = U ;変更しない
sprpriority = -1
Ctrl = 0

[State XXX, PosFreeze];保険
Type = PosFreeze
Trigger1 = 1
IgnorehitPause = 1

[State XXX, nothitby];保険２
Type = NotHitBy
Trigger1 = 1
value = SCA
IgnorehitPause = 1

[State XXX, SelfState];相手をガードステートへ戻す
type = SelfState
Trigger1 = PrevSTateNo = [120,159] ;ガード最中からTargetStateされたか
value = 150 + 2*(StateType=C) + 4*(StateType=A)
IgnorehitPause = 1

[State XXX, ChangeAnim];相手に専用Animを表示させる場合は、ChangeAnim2で
type = ChangeAnim; 2
Trigger1 = 1
value = 5000
IgnorehitPause = 1

[State XXX, ChangeState];相手を制御するステートへ飛ばす
Type = ChangeSTate
Trigger1 = HitShakeOver
value = XXXX ;■←相手を制御するステート番号に
IgnorehitPause = 1

上記のステートを介することで、ガードしていた場合にガードステートへ戻してしまう。
TargetStateの記述を調整する
上記のガード確認ステートへ飛ばすためのTargetステートも調整する。

[State XXXX, TargetSTate]
Type = targetState
Trigger1 = Numtarget(XXXX)
Trigger1 = MoveContact = 1
Trigger1 =(Target(XXXX),StateNo!=[150,159])||NumTarget(XXXX) > 1 ;相手ガードでないor相手二人以上
ID = XXXX
value = XXXX ;■ガード確認ステートへ
Persistent = 0 ;処理一度のみ
Ignorehitpause = 1

これだけだと時間差を置いてヒットした場合うまく制御できないので、
HitDefをNumTarget(XXXX)&&NumTarget(XXXX+1)=0で更新するようにし、
HitDefのID=XXXX+(NumTarget(XXXX)>0)、NoChainID=XXXXという風に調整を行い。

[State XXXX, TargetSTate 2];2回目用
Type = targetState
Trigger1 = Numtarget(XXXX+1)
Trigger1 = MoveContact = 1
Trigger1 =(Target(XXXX+1),StateNo!=[150,159])||NumTarget(XXXX+1) > 1 ;相手ガードでないor相手二人以上
ID = XXXX+1
value = XXXX ;■ガード確認ステートへ
Persistent = 0 ;処理一度のみ
Ignorehitpause = 1

２回目用のTargetStateを追記する。
  • 性能との上手い兼ね合いができない場合は諦めよう。
  • 例えば攻撃判定がガード硬直より長い場合、ガードへ戻した相手のガードが解けた後にもヒットしてしまう。

ガード可能な技からTargetStateを使いガードした方のTargetのみをふるい落としたい場合
基本は同じ方法で相手をガードで戻しガードが解けるのを待つ。
ガードがとければTargetは消えるので、それから本来のTargetStateを読みこせればいい。
またTargetStateを繰り返し用いる場合はガード確認ステートのHiiOverでChangeStateする処理は必要はない。
  • ※検証不足※他のTargetがいるとTargetの喪失が上手く行われない可能性がある。
    • この方法では無理…？
  • SC-/TargetDropのexcludeIDを利用することで、一人に限り残せるかもしれない。
    • ※検証求む※




■Lv-4-バグ応用

+ ■混線バグ

■混線バグ

:|
※凶悪系技術※　通常のキャラでは絶対に使いません。
筆者は詳しくは知らないので多分の推測混じり。
凶悪系のキャラにおいてはお馴染みの技術、らしい。
以下原理の推測。
  • Targetは実はスロットIDで管理されている
    • SC-/ReversalDefの発生中だと、永続タゲバグによりHelperが消えた際もTargetだけは残る。
    • そのスロットIDへ他のHelperが入ると、そのHelperを対象としたTargetが使用可能になる。
  • それらを応用して
    • 自分でHelperを射出しそのHelperを（基本別のHelperで）味方攻撃を使いTargetをとる。
    • 攻撃をしたキャラがReversalDefを出して永続タゲを起こしている状態で、被TargetのHelperを消す。
    • 待つ。
    • 相手のHelperを感知したらTargetStateなどで料理する。
という流れと思われる。
この手法の凶悪さは「相手へ直接攻撃を与えなくてもTargetを取得できる」という点。
演出用のカットイン用のHelperすらTargetを取れるのである。