※上記の広告は60日以上更新のないWIKIに表示されています。更新することで広告が下部へ移動します。


※解説修正情報※
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:Target8人制限を編集。HitOnceは特殊なTarget処理を行う。


※編集が中途半端かも。

■Targetについて

基本的な仕様
  • 攻撃を命中させると相手をTargetとして捉え、Target系の処理を行うことができるようになる。
  • Targetを取るにはSC-/HitDefSC-/ProjectileSC-/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スロットについて」を参照。

Target8人制限
Targetは最大で8人までしか取ることができない。
処理はSC-/HitDefSC-/ReversalDefのHitOnceの設定で異なる。ProjはHitonce=0固定?
  • HitOnce=0の攻撃は同時に最大8人まで、Targetを取得できた相手にだけ命中する
    • そのため既にTargetを8人取得している場合Target以外の相手へのHitOnce=0の攻撃は当たらない。
    • 例外的にSC-/HitOverrideが発動する相手には8人制限に関係なく命中する。
      HitOverrideが発動する相手のTargetは取得できないが、当たったことにはなる。
  • HitOnce=1の攻撃は命中する場合Targetを一度全て放棄した上で、単一の相手へ命中する
    • そのため既に8人の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で特別な反応をするキャラAがいるとする
        2. そのキャラAと、ID=2000の攻撃を持った別のキャラBがタッグで戦う。
        3. もしコンボなどでAがTargetをとっている状態でBがID=2000の攻撃を当てた場合…
        4. AのNumTarget(2000)>0が反応してしまうのである。AがID=2000を出していなくても
  • また設定できるID自体単一で、複数の相手へ命中した場合に別々の処理を行うことはできない。
    • Target(xHitIdx),の相手が複数いる場合、誰を参照するかを指定することはできない。
    • タッグで同時にガードとヒット両方であたった場合も、それらの区別はほぼ無理。
      • ガードとヒットで処理が異なる場合も、Targetで区別することは不可

Target系ステートコントローラーを使用する際の注意点
  • 基本、条件の中にT-/NumTargetを入れ相手の確認をとること。
  • Targetの対象に関する処理にも要注意。
    • 相手がガードしていてもTargetは取得する。
  • IDの指定は可能な限り行うこと。ID無指定では全Targetが対象のため
    ステコンを発動する攻撃を当てていない相手まで巻き込むこともある。
    • 非常におかしい状態になってしまうので可能な限りID指定をすること。
  • ID指定している場合は攻撃が重なった場合に、処理が通らない場合がある。
    • TargetIDについては上を参照。
  • なおT-/MoveHit=1などで処理を実行する場合、
    攻撃判定の持続で2人目に命中すると2度実行してしまう。
    • 実行タイミングの調整や実行後の処理の調整には要注意。
    • 調査が難しいため見落とされがち
  • タッグ時にTargetを取った相手を相方が攻撃中に、別の相手へTargetステコンを使う攻撃を当てた時
    可能性は低いがHitIDが重複した場合、Targetを取っていただけの相手も巻き込む事がある。
    • 同キャラタッグの同技なら比較的可能性は高いが、実践で頻発するようでなければ無視していい、はず。
    • Targetの性質とHitIDの性質上、強引な手を使わず完全に防ぐというは基本的に無理なため。

Helperに対するTargetステコンについて
  • Helperに対してのTargetStateは相手Helperがガード以外のくらい状態であるか、ReversalDefを当てている必要がある。
    • 相手本体ユニットに対しては、ガード状態であっても影響を与えられる。

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の上限と同様1~8まで。
  • Targetになると最も若い空きスロットが割り当てられ、入った後は入れ替わらないし、繰り上がりもしない
  • Targetから外れると、割り当てられていたスロットは空きとなる
    • 例:ABCの順にTargetを取った後、1Aと2BがTargetから外れて3Cだけ残り、
      新しくD→再度AをTargetに取った場合、スロットは1D・2A・3Cの順になる。
  • リダイレクトのTarget,は該当する相手の中で最も若いスロット番号の相手を参照する
    • IDを指定している場合、最も若い該当するHitIDを持った相手を参照する。
ターゲット保持バグはそのTarget,で参照する相手がTargetから外れる状態にならないと
次のTargetの状態を確認せずに保持し続けてしまう、という仕様のバグと思われる。


■Lv2-細かいバグ回避

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

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

持続ヒットに対する2人目ヒット時に1人目も影響を受けてしまう点について
  • 状態・命中時にTargetStateをし、特殊なくらい状態にさせるという技で
    • 持続の長い攻撃で1人目にヒットしTargetStateを行った後、
    • 2人目にもヒットした時にTargetStateを行うと1人目にも2回目のTargetStateが働いてしまう
  • ▼対処法1・SC-/TargetDrop
    • ヒット毎にSC-/TargetDropすれば1人目を外すことはできるが、
      Targetを全て失うとヒットカウントがリセットされてしまうため非推奨。
  • ▼対処法2・TargetStateを使わずSC-/HitDefのP2StateNo指定を使う。
  • ▼対処法3・SC-/HitDefをいじり、HitIDを更新し別々にTargetStateする。
    • TargetStateによって相手を確実に攻撃範囲外に飛ばさないと一人の相手に連続ヒットしてしまう。
  • ▼対処法4・HelperやProjで攻撃を追加で当ててTargetStateした相手のHitIDを更新する。
    • ステートを奪う相手に対してHelperやProjで攻撃を追加で当てる。
    • 記述・処理が面倒であるが比較的確実な振り分けができる。
  • ▼対処法5・TargetStaetした後を2段型にし、PrevStateNoで確認しパラメータの初期処理をせず戻す。
    • ガード・ヒット区別のようにPrevStateNoを確認するステートを作ってそこへ飛ばす。
      • PrevStateNoが同系統のステートでなかった場合、ステート変更・速度決定などの初期処理をする。
      • PrevStateNoが同系統のステートだった場合は、PrevStateNoへ戻す。
      • ステートを奪っている最中はTimeを使わないこと。どうしても時間数値が欲しいならAnimを利用。
    • 最中処理の記述が非常に面倒なのと、相方が別キャラだとPrevStateNoでおかしな暴発を見せる可能性がある。
  • ▼対処法6・持続当てでステートを奪わない。
    • TargetStateの処理を1回に限定し、2回目の相手はスルーする。
    • 見かけは悪くなるが、処理的には一番楽。

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];保険2
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

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

ガード可能な技からTargetStateを使いガードした方のTargetのみをふるい落としたい場合・まとめ
以下の処理をしっかり整えれば二段型は不要、かもしれない。
  • ( Target,GetHitVar(Guarded)=0 && MoveGuarded > 0 )の場合はTargetStateの前に、TargetDropを行う。
    • >同時ヒットかつ、ターゲット2人目がガードしている。TargetDropで2人目を放棄する。
  • ( TArget,GetHitVar(Guarded)=1 && numTarget = 1 )の場合はTargetStateを発動せず、TargetDropを行う。
    • >連続ヒット時の処理を調整するため、可能な限り素早く手放したほうが良い。
  • ( NumTarget > 1 && Target,GetHitVar(Guarded) = 1 )の場合は振り分けへTargetStateさせた後、ガードした側の硬直が解けるまで待つ
    • >Target,リダイレクトの相手はくらい状態以外になればTargetから外れる。それ以外に確実な放棄方法は無い。
    • >ガード単体の場合即時放せば『ガード・ヒット同時かつ、ガードが1人目』という状態である。
    • 追加でTargetStateを発動させるタイプの場合、ガード側のTargetは確実に手放したい。
      • 自分がAヒット・Bガードの後に、相方がBヒットさせるとTarget奪い合いが発生してしまう
      • 追加でTargetStateする=自分側が無敵で待機なので「ガード側もガード硬直終了まで無敵にする」か、あるいは「ガード硬直自体を無くしてしまう」とするほうが良い。
        • どちらかと言えば後者推奨。相方のガードに対する超必殺技などを防げるので。


ガード可能な技からTargetStateを使いガードした方のTargetのみをふるい落としたい場合・草案メモ
基本は同じ方法で相手をガードで戻しガードが解けるのを待つ。
ガードがとければTargetは消えるので、それから本来のTargetStateを読みこせればいい。
またTargetStateを繰り返し用いる場合はガード確認ステートのHiiOverでChangeStateする処理は必要はない。
  • ※検証不足※他のTargetがいるとTargetの喪失が上手く行われない可能性がある。
    • この方法では無理…?
  • SC-/TargetDropexcludeIDを利用することで、一人に限り残せる。
NumTarget>1で、Target,GetHitVar(Guarded)=0(Target相手がガード中でない)
Enemy,GetHitVar(Guarded)||Enemy(NumEnemy>1),GetHitVar(Guarded)(相手にガード有り)を条件に、
該当IDのTargetDropをTargetStateの直下に置くと「1ヒット・2ガード」のずっと残るパターンを解除できる。
  • 3人以上に関しては制御しきれない。
  • 「1ガード・2ヒット」は1がmovetype!=Hになれば勝手に解除されるが、硬直が長いと処理に支障がでる。
    • 自分側が放しても相方が相手を固め続けたりすると、解けずにTargetが保持されてしまう。
    • どうしても処理を安定させたいなら、NotHitByをTime=硬直時間分発生させるか、
      ガード硬直そのものをなくしてすぐMoveType=Iに戻すと安定させやすい。
      • ID指定すれば相方のガード固め~による弊害は考えなくていい確率で、
        よほど特殊な状態でなければガード硬直が溶ける時間分待つだけでいいかも。
      • ただし同キャラで同じ技を使った場合TargetStateで奪い合いになってしまうため、TargetStateでのガード振り分けを行うつかみ投げは不向き。
        • 中段・下段の技で先に相手片方のステートを奪い、相方が残りの相手のステートを奪った場合、そのTargetState奪い合いの状態になってしまう。
        • ただその場合、自分側のステートは無敵状態で待機わけなので、ガードしてる側に硬直分のNotHitByを付け加えて放せば、奪い合いにはならない。相方の追撃ができなくなるけど。





■Lv-4-バグ応用

+■混線バグ

■混線バグ

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