「Target」の編集履歴（バックアップ）一覧はこちら
「Target」(2014/11/04 (火) 12:18:58) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
----
:※解説修正情報※|
//●&font(12,b){日付：修正部分の概要}
●&font(18,b){2014-10-28：Target系ステコン処理について、再度修正※差し戻し}
●&font(18,b){2014-10-28：%%Target系ステコン処理について・ガードヒット区別処理判明%%}
●&font(12,b){2014-10-28：MoveHit,MoveGuardedの対応処理はTarget,を ☓先に→○後に 取った方。}
●&font(12,b){2014-10-12：Targetスロットの概念を発見した。}
●&font(12,b){2014-10-11：Targetの喪失について。ガードふるい落としが出来ないかも。}
●&font(12,b){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は外れる。
--&b(){[[ステートを奪っていても>ステート奪取]]外れる。}
--例外として''永続ターゲット''がある。[[SC-/ReversalDef]]のLv4を参照。
--もう一つ例外として、''ターゲット保持バグ''がある。''※要追加検証※''
---複数のTargetがいる場合''Targetの中で一番若いTargetスロットの相手が外れない限り''、&br()それ以外のTargetがMoveType!=HになってもTargetを喪失しない。
----Targetスロットについては下に記載。
---しかもそのまま保持し続けていると、&br()別の相手に攻撃を何度か当ててると攻撃が当たらなくなるなどのバグが起きる。
-Targetを取得している自分側が攻撃を受けたり、死亡したりした場合もTargetは外れる。
--HitDefやProjの攻撃を受けた時点・死んだ時点でTargetが外れるだけで、&br()その判定の後に攻撃が命中した場合はTargetは取得・維持できる。
--攻撃の命中時点でTargetを放棄するためHitOverrideが発動しても消える。
-また[[SC-/TargetDrop]]でTargetは自発的に放棄することができる。
--TargetDropにてヒットIDを指定すると一人だけ相手を残して他を破棄することもできる。
---残す対象の相手が複数いる場合、Target(ヒットID),で参照する相手を残す。みたい。
---Target,の複数いる場合の参照する相手についてはページ下部「Targetスロットについて」を参照。
:Target８人制限|
Targetは最大で８人までしか取ることができない。
処理は[[SC-/HitDef]][[SC-/ReversalDef]]のHitOnceの設定で異なる。ProjはHitonce=0固定？
-HitOnce=0の攻撃は''同時に最大８人まで、Targetを取得できた相手にだけ命中する''。
--そのため既にTargetを８人取得している場合Target以外の相手へのHitOnce=0の攻撃は当たらない。
--例外的に&b(){[[SC-/HitOverride]]が発動する相手には８人制限に関係なく命中する。}&br()HitOverrideが発動する相手のTargetは取得できないが、当たったことにはなる。
-HitOnce=1の攻撃は''命中する場合Targetを一度全て放棄した上で、単一の相手へ命中する''。
--そのため既に８人のTargetを取得していたとしても、''再度相手が選ばれて攻撃が命中する''。
--ただし命中しても相手が[[SC-/HitOverride]]が発動した場合Targetは取得できない。
''※検証不足※''同時命中時の対象選択はTarget,[[リダイレクト]]の処理に準じる？
:ヒットカウントとTarget|
-味方側の誰か(Helper含む)がTargetを持っている状態では画面に表示されるヒットカウントがリセットされない。
--''永続ターゲット''を利用している場合、Targetを保持し続けるのでヒットカウントはリセットされない。
--反対にTargetを持っているキャラ(Helper含む)が存在しない場合、ヒットカウントはリセットされる。
#region(Helper消失によるヒットカウントリセットバグについて)
仮にHelperが攻撃を通し本体他がTargetをとっていない状態でそのHelperをDestroySelfで消すと、Targetを持っているキャラ(Helper含む)が一人もいなくなり、相手がMoveType=H状態のままでもヒットカウントがリセットされてしまう。
気になるならDestroySelfのタイミングにroot,NumTargetなどを入れたり、攻撃判定自体をProjectileで処理するようにすると良い。
#endregion
:|
//↑の単体の「:|」は不具合解消用です、消さないで下さい。
:Target系ステートコントローラー|
-[[SC-/TargetDrop]]
-[[SC-/TargetState]]
-[[SC-/TargetFacing]]
-[[SC-/TargetLifeAdd]]・[[SC-/TargetPowerAdd]]
-[[SC-/TargetVelAdd]]・[[SC-/TargetVelSet]]
-[[SC-/BindToTarget]]・[[SC-/TargetBind]]
----
**■Lv1-注意点
:Targetエラー|
-Targetが存在しない時にTarget,やTarget系ステートコントローラーを使用すると[[デバッグ]]表示でエラーが流れる。
--致命的ではありませんが、NumTargetでTargetがいるかどうかを確認した上で使おう。
:TargetとHitIDの関係|
-HitIDとは、攻撃定義のオプションとして設定されたIDのこと。
--Target(xHitIDx),と指定することで特定のHitIDの相手にのみ処理することができる。
--ChainIDやNoChainIDなどにも利用できる。
-しかしTargetの相手が誰であるか自体は攻撃した側で管理されているが&br()''Target(xx),などで利用するHitIDは攻撃をくらった側で管理されている''
--そのため保持されるHitIDは単一で複数の攻撃があたった場合もHitIDはどれか1つになる。
--この仕様の厄介な点は目的のIDを出していないのに反応してしまうことがある点。
---具体例
---+常時監視ステートでNumTarget(2000)>0で特別な反応をするキャラＡがいるとする
---+そのキャラＡと、ID=2000の攻撃を持った別のキャラＢがタッグで戦う。
---+もし''コンボなどでＡがTargetをとっている状態でＢがID=2000の攻撃を当てた''場合…
---+''ＡのNumTarget(2000)>0が反応してしまう''のである。ＡがID=2000を出していなくても
-また設定できるID自体単一で、複数の相手へ命中した場合に別々の処理を行うことはできない。
--Target(xHitIdx),の相手が複数いる場合、誰を参照するかを指定することはできない。
--タッグで同時にガードとヒット両方であたった場合も、それらの区別はほぼ無理。
---ガードとヒットで処理が異なる場合も、Targetで区別することは不可
:Target系ステートコントローラーを使用する際の注意点|
-基本、条件の中に[[T-/NumTarget]]を入れ相手の確認をとること。
-Targetの対象に関する処理にも要注意。
--相手がガードしていてもTargetは取得する。
-IDの指定は可能な限り行うこと。ID無指定では全Targetが対象のため&br()ステコンを発動する攻撃を当てていない相手まで巻き込むこともある。
--非常におかしい状態になってしまうので可能な限りID指定をすること。
-ID指定している場合は攻撃が重なった場合に、処理が通らない場合がある。
--TargetIDについては上を参照。
-なお[[T-/MoveHit]]=1などで処理を実行する場合、&br()攻撃判定の持続で２人目に命中すると２度実行してしまう。
--実行タイミングの調整や実行後の処理の調整には要注意。
--調査が難しいため''見落とされがち''。
-タッグ時にTargetを取った相手を相方が攻撃中に、別の相手へTargetステコンを使う攻撃を当てた時&br()可能性は低いがHitIDが重複した場合、Targetを撮っていただけの相手も巻き込む事がある。
--同キャラタッグの同技なら比較的可能性は高いが、実践で頻発するようでなければ無視していい、はず。
--Targetの性質とHitIDの性質上、強引な手を使わず完全に防ぐというは基本的に無理なため。
:Helperに対するTargetステコンについて|
-Helperに対してのTargetStateは相手Helperがガード以外のくらい状態であるか、ReversalDefを当てている必要がある。
--相手本体ユニットに対しては、ガード状態であっても影響を与えられる。
:Target(),リダイレクトとTarget系ステコンのバグ|
-&b(){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から外れて３Ｃだけ残り、&br()新しくＤ→再度ＡをTargetに取った場合、スロットは１Ｄ・２Ａ・３Ｃの順になる。
-[[リダイレクト]]のTarget,は該当する相手の中で''最も若いスロット番号の相手を参照する''。
--IDを指定している場合、最も若い該当するHitIDを持った相手を参照する。
''ターゲット保持バグ''はそのTarget,で参照する相手がTargetから外れる状態にならないと&br()次のTargetの状態を確認せずに保持し続けてしまう、という仕様のバグと思われる。
----
**■Lv2-細かいバグ回避
:味方他とのHitIDの混同について|
-NumTarget()だけで判定するのは不可。
--StateNoやMoveHit、HelperならNumHelper+Helper,MoveHitなどと併用して判別しよう。
:ガードとヒットが同時に起こった場合のTargetState関係について|
-面倒であれば諦める。
--処理が安定しなくてもTargetStateを使いたいならTargetStateを。
--ただTargetStateよりHitDefにP2StateNoを仕込むほうが安全。HitOverrideに命中しなくなるが。
-対応策はあるが、非常に細かいため、Lv3に記述。
:持続ヒットに対する２人目ヒット時に１人目も影響を受けてしまう点について|
-状態・命中時にTargetStateをし、特殊なくらい状態にさせるという技で
--持続の長い攻撃で１人目にヒットしTargetStateを行った後、
--２人目にもヒットした時にTargetStateを行うと''１人目にも２回目のTargetStateが働いてしまう''。
-▼対処法１・[[SC-/TargetDrop]]
--ヒット毎に[[SC-/TargetDrop]]すれば１人目を外すことはできるが、&br()Targetを全て失うとヒットカウントがリセットされてしまうため非推奨。
-▼対処法２・TargetStateを使わず[[SC-/HitDef]]のP2StateNo指定を使う。
--区別できるようになるが[[SC-/HitOverride]]に対して命中しなくなる。
--＋[[SC-/Projectile]]によってダメージを与える。→相手の[[SC-/ReversalDef]]が効かなくなるかも。
-▼対処法３・[[SC-/HitDef]]をいじり、HitIDを更新し別々にTargetStateする。
--TargetStateによって相手を確実に攻撃範囲外に飛ばさないと一人の相手に連続ヒットしてしまう。
-▼対処法４・HelperやProjで攻撃を追加で当ててTargetStateした相手のHitIDを更新する。
--ステートを奪う相手に対してHelperやProjで攻撃を追加で当てる。
--記述・処理が面倒であるが比較的確実な振り分けができる。
-▼対処法５・TargetStaetした後を２段型にし、PrevStateNoで確認しパラメータの初期処理をせず戻す。
--ガード・ヒット区別のようにPrevStateNoを確認するステートを作ってそこへ飛ばす。
---PrevStateNoが同系統のステートでなかった場合、ステート変更・速度決定などの初期処理をする。
---PrevStateNoが同系統のステートだった場合は、PrevStateNoへ戻す。
---ステートを奪っている最中はTimeを使わないこと。どうしても時間数値が欲しいならAnimを利用。
--最中処理の記述が非常に面倒なのと、相方が別キャラだとPrevStateNoでおかしな暴発を見せる可能性がある。
-▼対処法６・持続当てでステートを奪わない。
--ステート奪取の制御に、
--見かけは悪くなるが、処理的には一番楽。
:Target,リダイレクト情報をTargetのステコンで使用する方法|
-情報をVarに代入して、Varをパラメーターに記述するだけ。
--「:=」での代入を併用すれば非常に楽。
----
**■Lv3-細かい応用
#region(''■ガードとヒットが同時に起こった場合のTargetState制御'')
**■ガードとヒットが同時に起こった場合のTargetState制御
-情報提供DLS氏・調整アレンジADI氏
**最中に細かくTargetStateしない＋単発用
※完全ではなく、あくまでそれらしく制御できる記述です。
※TargetStateで壁バウンドをさせる技など用。
※長く持続する技だとうまくいかないことがある。
:飛ばすステートの調整|
相手を制御するステートの前に【''ガード確認ステート''】を作りそちらへ飛ばす
#aa(){{{
[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ステートも調整する。
#aa(){{{
[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という風に調整を行い。
#aa(){{{
[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のみをふるい落としたい場合・まとめ|
以下の処理をしっかり整えれば二段型は不要、かもしれない。
-&b(){( Target,GetHitVar(Guarded)=0 && MoveGuarded > 0 )}の場合はTargetStateの前に、TargetDropを行う。
--＞同時ヒットかつ、ターゲット２人目がガードしている。TargetDropで２人目を放棄する。
-&b(){( TArget,GetHitVar(Guarded)=1 && numTarget = 1 )}の場合はTargetStateを発動せず、TargetDropを行う。
--＞連続ヒット時の処理を調整するため、可能な限り素早く手放したほうが良い。
-&b(){( NumTarget > 1 && Target,GetHitVar(Guarded) = 1 )}の場合は振り分けへTargetStateさせた後、''ガードした側の硬直が解けるまで待つ''。
--＞Target,リダイレクトの相手はくらい状態以外になればTargetから外れる。それ以外に確実な放棄方法は無い。
--＞ガード単体の場合即時放せば『ガード・ヒット同時かつ、ガードが１人目』という状態である。
--追加でTargetStateを発動させるタイプの場合、ガード側のTargetは確実に手放したい。
---自分がＡヒット・Ｂガードの後に、相方がＢヒットさせると''Target奪い合いが発生してしまう''。
---追加でTargetStateする＝自分側が無敵で待機なので「''ガード側もガード硬直終了まで無敵にする''」か、あるいは「''ガード硬直自体を無くしてしまう''」とするほうが良い。
----どちらかと言えば後者推奨。相方のガードに対する超必殺技などを防げるので。
:ガード可能な技からTargetStateを使いガードした方のTargetのみをふるい落としたい場合・草案メモ|
%%基本は同じ方法で相手をガードで戻しガードが解けるのを待つ。%%
%%ガードがとければTargetは消えるので、それから本来のTargetStateを読みこせればいい。%%
%%またTargetStateを繰り返し用いる場合はガード確認ステートのHiiOverでChangeStateする処理は必要はない。%%
-''※検証不足※''他のTargetがいるとTargetの喪失が上手く行われない可能性がある。
--この方法では無理…？
-[[SC-/TargetDrop]]の''excludeID''を利用することで、一人に限り残せる。
NumTarget>1で、''Target,GetHitVar(Guarded)=0（Target相手がガード中でない）''と
''Enemy,GetHitVar(Guarded)||Enemy(NumEnemy>1),GetHitVar(Guarded)（相手にガード有り）''を条件に、
該当IDのTargetDropをTargetStateの直下に置くと「１ヒット・２ガード」のずっと残るパターンを解除できる。
-３人以上に関しては制御しきれない。
-「１ガード・２ヒット」は１がmovetype!=Hになれば勝手に解除されるが、硬直が長いと処理に支障がでる。
--自分側が放しても相方が相手を固め続けたりすると、解けずにTargetが保持されてしまう。
--どうしても処理を安定させたいなら、NotHitByをTime=硬直時間分発生させるか、&bR()ガード硬直そのものをなくしてすぐMoveType=Iに戻すと安定させやすい。
---ID指定すれば相方のガード固め～による弊害は考えなくていい確率で、&br()よほど特殊な状態でなければガード硬直が溶ける時間分待つだけでいいかも。
---ただし同キャラで同じ技を使った場合TargetStateで奪い合いになってしまうため、TargetStateでのガード振り分けを行うつかみ投げは不向き。
----中段・下段の技で先に相手片方のステートを奪い、相方が残りの相手のステートを奪った場合、そのTargetState奪い合いの状態になってしまう。
----ただその場合、自分側のステートは無敵状態で待機わけなので、ガードしてる側に硬直分のNotHitByを付け加えて放せば、奪い合いにはならない。相方の追撃ができなくなるけど。
#endregion
----
**■Lv-4-バグ応用
#region(''■混線バグ'')
**■混線バグ
:|
''※凶悪系技術※'' 通常のキャラでは絶対に使いません。
筆者は詳しくは知らないので多分の推測混じり。
凶悪系のキャラにおいてはお馴染みの技術、らしい。
以下原理の推測。
-Targetは実は[[スロットID]]で管理されている
--[[SC-/ReversalDef]]の発生中だと、永続タゲバグによりHelperが消えた際もTargetだけは''残る''。
--そのスロットIDへ他のHelperが入ると、そのHelperを対象としたTargetが使用可能になる。
-それらを応用して
--自分でHelperを射出しそのHelperを（基本別のHelperで）味方攻撃を使いTargetをとる。
--攻撃をしたキャラがReversalDefを出して永続タゲを起こしている状態で、被TargetのHelperを消す。
--待つ。
--相手のHelperを感知したらTargetStateなどで料理する。
という流れと思われる。
この手法の凶悪さは「相手へ直接攻撃を与えなくてもTargetを取得できる」という点。
''演出用のカットイン用のHelperすらTargetを取れる''のである。
#endregion
----
----
:※解説修正情報※|
//●&font(12,b){日付：修正部分の概要}
●&font(18,b){2014-10-28：Target系ステコン処理について、再度修正※差し戻し}
●&font(18,b){2014-10-28：%%Target系ステコン処理について・ガードヒット区別処理判明%%}
●&font(12,b){2014-10-28：MoveHit,MoveGuardedの対応処理はTarget,を ☓先に→○後に 取った方。}
●&font(12,b){2014-10-12：Targetスロットの概念を発見した。}
●&font(12,b){2014-10-11：Targetの喪失について。ガードふるい落としが出来ないかも。}
●&font(12,b){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は外れる。
--&b(){[[ステートを奪っていても>ステート奪取]]外れる。}
--例外として''永続ターゲット''がある。[[SC-/ReversalDef]]のLv4を参照。
--もう一つ例外として、''ターゲット保持バグ''がある。''※要追加検証※''
---複数のTargetがいる場合''Targetの中で一番若いTargetスロットの相手が外れない限り''、&br()それ以外のTargetがMoveType!=HになってもTargetを喪失しない。
----Targetスロットについては下に記載。
---しかもそのまま保持し続けていると、&br()別の相手に攻撃を何度か当ててると攻撃が当たらなくなるなどのバグが起きる。
-Targetを取得している自分側が攻撃を受けたり、死亡したりした場合もTargetは外れる。
--HitDefやProjの攻撃を受けた時点・死んだ時点でTargetが外れるだけで、&br()その判定の後に攻撃が命中した場合はTargetは取得・維持できる。
--攻撃の命中時点でTargetを放棄するためHitOverrideが発動しても消える。
-また[[SC-/TargetDrop]]でTargetは自発的に放棄することができる。
--TargetDropにてヒットIDを指定すると一人だけ相手を残して他を破棄することもできる。
---残す対象の相手が複数いる場合、Target(ヒットID),で参照する相手を残す。みたい。
---Target,の複数いる場合の参照する相手についてはページ下部「Targetスロットについて」を参照。
:Target８人制限|
Targetは最大で８人までしか取ることができない。
処理は[[SC-/HitDef]][[SC-/ReversalDef]]のHitOnceの設定で異なる。ProjはHitonce=0固定？
-HitOnce=0の攻撃は''同時に最大８人まで、Targetを取得できた相手にだけ命中する''。
--そのため既にTargetを８人取得している場合Target以外の相手へのHitOnce=0の攻撃は当たらない。
--例外的に&b(){[[SC-/HitOverride]]が発動する相手には８人制限に関係なく命中する。}&br()HitOverrideが発動する相手のTargetは取得できないが、当たったことにはなる。
-HitOnce=1の攻撃は''命中する場合Targetを一度全て放棄した上で、単一の相手へ命中する''。
--そのため既に８人のTargetを取得していたとしても、''再度相手が選ばれて攻撃が命中する''。
--ただし命中しても相手が[[SC-/HitOverride]]が発動した場合Targetは取得できない。
''※検証不足※''同時命中時の対象選択はTarget,[[リダイレクト]]の処理に準じる？
:ヒットカウントとTarget|
-味方側の誰か(Helper含む)がTargetを持っている状態では画面に表示されるヒットカウントがリセットされない。
--''永続ターゲット''を利用している場合、Targetを保持し続けるのでヒットカウントはリセットされない。
--反対にTargetを持っているキャラ(Helper含む)が存在しない場合、ヒットカウントはリセットされる。
#region(Helper消失によるヒットカウントリセットバグについて)
仮にHelperが攻撃を通し本体他がTargetをとっていない状態でそのHelperをDestroySelfで消すと、Targetを持っているキャラ(Helper含む)が一人もいなくなり、相手がMoveType=H状態のままでもヒットカウントがリセットされてしまう。
気になるならDestroySelfのタイミングにroot,NumTargetなどを入れたり、攻撃判定自体をProjectileで処理するようにすると良い。
#endregion
:|
//↑の単体の「:|」は不具合解消用です、消さないで下さい。
:Target系ステートコントローラー|
-[[SC-/TargetDrop]]
-[[SC-/TargetState]]
-[[SC-/TargetFacing]]
-[[SC-/TargetLifeAdd]]・[[SC-/TargetPowerAdd]]
-[[SC-/TargetVelAdd]]・[[SC-/TargetVelSet]]
-[[SC-/BindToTarget]]・[[SC-/TargetBind]]
----
**■Lv1-注意点
:Targetエラー|
-Targetが存在しない時にTarget,やTarget系ステートコントローラーを使用すると[[デバッグ]]表示でエラーが流れる。
--致命的ではありませんが、NumTargetでTargetがいるかどうかを確認した上で使おう。
:TargetとHitIDの関係|
-HitIDとは、攻撃定義のオプションとして設定されたIDのこと。
--Target(xHitIDx),と指定することで特定のHitIDの相手にのみ処理することができる。
--ChainIDやNoChainIDなどにも利用できる。
-しかしTargetの相手が誰であるか自体は攻撃した側で管理されているが&br()''Target(xx),などで利用するHitIDは攻撃をくらった側で管理されている''
--そのため保持されるHitIDは単一で複数の攻撃があたった場合もHitIDはどれか1つになる。
--この仕様の厄介な点は目的のIDを出していないのに反応してしまうことがある点。
---具体例
---+常時監視ステートでNumTarget(2000)>0で特別な反応をするキャラＡがいるとする
---+そのキャラＡと、ID=2000の攻撃を持った別のキャラＢがタッグで戦う。
---+もし''コンボなどでＡがTargetをとっている状態でＢがID=2000の攻撃を当てた''場合…
---+''ＡのNumTarget(2000)>0が反応してしまう''のである。ＡがID=2000を出していなくても
-また設定できるID自体単一で、複数の相手へ命中した場合に別々の処理を行うことはできない。
--Target(xHitIdx),の相手が複数いる場合、誰を参照するかを指定することはできない。
--タッグで同時にガードとヒット両方であたった場合も、それらの区別はほぼ無理。
---ガードとヒットで処理が異なる場合も、Targetで区別することは不可
:Target系ステートコントローラーを使用する際の注意点|
-基本、条件の中に[[T-/NumTarget]]を入れ相手の確認をとること。
-Targetの対象に関する処理にも要注意。
--相手がガードしていてもTargetは取得する。
-IDの指定は可能な限り行うこと。ID無指定では全Targetが対象のため&br()ステコンを発動する攻撃を当てていない相手まで巻き込むこともある。
--非常におかしい状態になってしまうので可能な限りID指定をすること。
-ID指定している場合は攻撃が重なった場合に、処理が通らない場合がある。
--TargetIDについては上を参照。
-なお[[T-/MoveHit]]=1などで処理を実行する場合、&br()攻撃判定の持続で２人目に命中すると２度実行してしまう。
--実行タイミングの調整や実行後の処理の調整には要注意。
--調査が難しいため''見落とされがち''。
-タッグ時にTargetを取った相手を相方が攻撃中に、別の相手へTargetステコンを使う攻撃を当てた時&br()可能性は低いがHitIDが重複した場合、Targetを取っていただけの相手も巻き込む事がある。
--同キャラタッグの同技なら比較的可能性は高いが、実践で頻発するようでなければ無視していい、はず。
--Targetの性質とHitIDの性質上、強引な手を使わず完全に防ぐというは基本的に無理なため。
:Helperに対するTargetステコンについて|
-Helperに対してのTargetStateは相手Helperがガード以外のくらい状態であるか、ReversalDefを当てている必要がある。
--相手本体ユニットに対しては、ガード状態であっても影響を与えられる。
:Target(),リダイレクトとTarget系ステコンのバグ|
-&b(){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から外れて３Ｃだけ残り、&br()新しくＤ→再度ＡをTargetに取った場合、スロットは１Ｄ・２Ａ・３Ｃの順になる。
-[[リダイレクト]]のTarget,は該当する相手の中で''最も若いスロット番号の相手を参照する''。
--IDを指定している場合、最も若い該当するHitIDを持った相手を参照する。
''ターゲット保持バグ''はそのTarget,で参照する相手がTargetから外れる状態にならないと&br()次のTargetの状態を確認せずに保持し続けてしまう、という仕様のバグと思われる。
----
**■Lv2-細かいバグ回避
:味方他とのHitIDの混同について|
-NumTarget()だけで判定するのは不可。
--StateNoやMoveHit、HelperならNumHelper+Helper,MoveHitなどと併用して判別しよう。
:ガードとヒットが同時に起こった場合のTargetState関係について|
-面倒であれば諦める。
--処理が安定しなくてもTargetStateを使いたいならTargetStateを。
--ただTargetStateよりHitDefにP2StateNoを仕込むほうが安全。HitOverrideに命中しなくなるが。
-対応策はあるが、非常に細かいため、Lv3に記述。
:持続ヒットに対する２人目ヒット時に１人目も影響を受けてしまう点について|
-状態・命中時にTargetStateをし、特殊なくらい状態にさせるという技で
--持続の長い攻撃で１人目にヒットしTargetStateを行った後、
--２人目にもヒットした時にTargetStateを行うと''１人目にも２回目のTargetStateが働いてしまう''。
-▼対処法１・[[SC-/TargetDrop]]
--ヒット毎に[[SC-/TargetDrop]]すれば１人目を外すことはできるが、&br()Targetを全て失うとヒットカウントがリセットされてしまうため非推奨。
-▼対処法２・TargetStateを使わず[[SC-/HitDef]]のP2StateNo指定を使う。
--区別できるようになるが[[SC-/HitOverride]]に対して命中しなくなる。
--＋[[SC-/Projectile]]によってダメージを与える。→相手の[[SC-/ReversalDef]]が効かなくなるかも。
-▼対処法３・[[SC-/HitDef]]をいじり、HitIDを更新し別々にTargetStateする。
--TargetStateによって相手を確実に攻撃範囲外に飛ばさないと一人の相手に連続ヒットしてしまう。
-▼対処法４・HelperやProjで攻撃を追加で当ててTargetStateした相手のHitIDを更新する。
--ステートを奪う相手に対してHelperやProjで攻撃を追加で当てる。
--記述・処理が面倒であるが比較的確実な振り分けができる。
-▼対処法５・TargetStaetした後を２段型にし、PrevStateNoで確認しパラメータの初期処理をせず戻す。
--ガード・ヒット区別のようにPrevStateNoを確認するステートを作ってそこへ飛ばす。
---PrevStateNoが同系統のステートでなかった場合、ステート変更・速度決定などの初期処理をする。
---PrevStateNoが同系統のステートだった場合は、PrevStateNoへ戻す。
---ステートを奪っている最中はTimeを使わないこと。どうしても時間数値が欲しいならAnimを利用。
--最中処理の記述が非常に面倒なのと、相方が別キャラだとPrevStateNoでおかしな暴発を見せる可能性がある。
-▼対処法６・持続当てでステートを奪わない。
--TargetStateの処理を１回に限定し、２回目の相手はスルーする。
--見かけは悪くなるが、処理的には一番楽。
:Target,リダイレクト情報をTargetのステコンで使用する方法|
-情報をVarに代入して、Varをパラメーターに記述するだけ。
--「:=」での代入を併用すれば非常に楽。
----
**■Lv3-細かい応用
#region(''■ガードとヒットが同時に起こった場合のTargetState制御'')
**■ガードとヒットが同時に起こった場合のTargetState制御
-情報提供DLS氏・調整アレンジADI氏
**最中に細かくTargetStateしない＋単発用
※完全ではなく、あくまでそれらしく制御できる記述です。
※TargetStateで壁バウンドをさせる技など用。
※長く持続する技だとうまくいかないことがある。
:飛ばすステートの調整|
相手を制御するステートの前に【''ガード確認ステート''】を作りそちらへ飛ばす
#aa(){{{
[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ステートも調整する。
#aa(){{{
[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という風に調整を行い。
#aa(){{{
[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のみをふるい落としたい場合・まとめ|
以下の処理をしっかり整えれば二段型は不要、かもしれない。
-&b(){( Target,GetHitVar(Guarded)=0 && MoveGuarded > 0 )}の場合はTargetStateの前に、TargetDropを行う。
--＞同時ヒットかつ、ターゲット２人目がガードしている。TargetDropで２人目を放棄する。
-&b(){( TArget,GetHitVar(Guarded)=1 && numTarget = 1 )}の場合はTargetStateを発動せず、TargetDropを行う。
--＞連続ヒット時の処理を調整するため、可能な限り素早く手放したほうが良い。
-&b(){( NumTarget > 1 && Target,GetHitVar(Guarded) = 1 )}の場合は振り分けへTargetStateさせた後、''ガードした側の硬直が解けるまで待つ''。
--＞Target,リダイレクトの相手はくらい状態以外になればTargetから外れる。それ以外に確実な放棄方法は無い。
--＞ガード単体の場合即時放せば『ガード・ヒット同時かつ、ガードが１人目』という状態である。
--追加でTargetStateを発動させるタイプの場合、ガード側のTargetは確実に手放したい。
---自分がＡヒット・Ｂガードの後に、相方がＢヒットさせると''Target奪い合いが発生してしまう''。
---追加でTargetStateする＝自分側が無敵で待機なので「''ガード側もガード硬直終了まで無敵にする''」か、あるいは「''ガード硬直自体を無くしてしまう''」とするほうが良い。
----どちらかと言えば後者推奨。相方のガードに対する超必殺技などを防げるので。
:ガード可能な技からTargetStateを使いガードした方のTargetのみをふるい落としたい場合・草案メモ|
%%基本は同じ方法で相手をガードで戻しガードが解けるのを待つ。%%
%%ガードがとければTargetは消えるので、それから本来のTargetStateを読みこせればいい。%%
%%またTargetStateを繰り返し用いる場合はガード確認ステートのHiiOverでChangeStateする処理は必要はない。%%
-''※検証不足※''他のTargetがいるとTargetの喪失が上手く行われない可能性がある。
--この方法では無理…？
-[[SC-/TargetDrop]]の''excludeID''を利用することで、一人に限り残せる。
NumTarget>1で、''Target,GetHitVar(Guarded)=0（Target相手がガード中でない）''と
''Enemy,GetHitVar(Guarded)||Enemy(NumEnemy>1),GetHitVar(Guarded)（相手にガード有り）''を条件に、
該当IDのTargetDropをTargetStateの直下に置くと「１ヒット・２ガード」のずっと残るパターンを解除できる。
-３人以上に関しては制御しきれない。
-「１ガード・２ヒット」は１がmovetype!=Hになれば勝手に解除されるが、硬直が長いと処理に支障がでる。
--自分側が放しても相方が相手を固め続けたりすると、解けずにTargetが保持されてしまう。
--どうしても処理を安定させたいなら、NotHitByをTime=硬直時間分発生させるか、&bR()ガード硬直そのものをなくしてすぐMoveType=Iに戻すと安定させやすい。
---ID指定すれば相方のガード固め～による弊害は考えなくていい確率で、&br()よほど特殊な状態でなければガード硬直が溶ける時間分待つだけでいいかも。
---ただし同キャラで同じ技を使った場合TargetStateで奪い合いになってしまうため、TargetStateでのガード振り分けを行うつかみ投げは不向き。
----中段・下段の技で先に相手片方のステートを奪い、相方が残りの相手のステートを奪った場合、そのTargetState奪い合いの状態になってしまう。
----ただその場合、自分側のステートは無敵状態で待機わけなので、ガードしてる側に硬直分のNotHitByを付け加えて放せば、奪い合いにはならない。相方の追撃ができなくなるけど。
#endregion
----
**■Lv-4-バグ応用
#region(''■混線バグ'')
**■混線バグ
:|
''※凶悪系技術※'' 通常のキャラでは絶対に使いません。
筆者は詳しくは知らないので多分の推測混じり。
凶悪系のキャラにおいてはお馴染みの技術、らしい。
以下原理の推測。
-Targetは実は[[スロットID]]で管理されている
--[[SC-/ReversalDef]]の発生中だと、永続タゲバグによりHelperが消えた際もTargetだけは''残る''。
--そのスロットIDへ他のHelperが入ると、そのHelperを対象としたTargetが使用可能になる。
-それらを応用して
--自分でHelperを射出しそのHelperを（基本別のHelperで）味方攻撃を使いTargetをとる。
--攻撃をしたキャラがReversalDefを出して永続タゲを起こしている状態で、被TargetのHelperを消す。
--待つ。
--相手のHelperを感知したらTargetStateなどで料理する。
という流れと思われる。
この手法の凶悪さは「相手へ直接攻撃を与えなくてもTargetを取得できる」という点。
''演出用のカットイン用のHelperすらTargetを取れる''のである。
#endregion
----
