MUGEN豆知識

MUGENにおいてあまり知られていない物事について。

以上の10項目はそれぞれリンク先の独立記事を参照。



MUGENにおける1P側と2P側の差

一般的な格闘ゲームにおいては1P側と2P側でなんらかの差(特定の攻撃がつながるなど)があることも多いが、
MUGENにおいてもやはり存在する。
MUGENではフレームの開始時点でmoevtypeがAになっているキャラクターやヘルパーが存在しない場合、
1P側のキャラクター本体のステコンが処理された後で、
2P側のキャラクターで同様の処理が行われ、その後ヘルパーの処理がなされた後、攻撃の成功判定などが最後に行われる。
movetypeがAのときは基本的にctrlが無効になるので、
お互いが行動を起こせる状態では2P側は1P側の出方を見てステートを処理しており、
この処理順が勝敗に多大な影響を及ぼす局面が頻繁に起こっている。
特に顕著なのが1F技で、ほとんどのAIでは投げ攻撃に対してhitdefattrを利用して回避行動を取るようになっているが、
発生1Fの攻撃に限り、2P側では相手の攻撃に対して回避行動やガードを行うことができる。
だが1P側のキャラクターはそれができず、2P側で選択されていれば対処できたはずの攻撃をくらってしまうことになる。
またキャラクターの移動も1P側が先に行われるため、原理的には一般的な格闘ゲームに見られる1P側、2P側限定裏回りも成立し得る。
他にも1F技のように目立つことは無いものの、全てのトリガーの反応が実質1フレーム遅れて後出しで行動できるので、
色々な局面で2P側が有利になりやすい。

ちなみにmovetypeがAになっているプレイヤーまたはヘルパーが存在する場合、それらの処理が優先して行われる。
発生が1Fでなければ1P側でもhitdefattrを使用してガードなどができるのはこのため。
尤もAI対AIの場合、2P側の方が打撃技に対するガード移行や超反応迎撃の試行回数が1回多いので、やはり2P側有利は変わらない。

AIに限った話ではなく、相手の挙動に即座に反応するステコン全般でこのような問題が発生する可能性がある。
キャラクターやAIの製作中には、たまには自分のキャラクターを2P側にして動かしてみよう。


MUGENの処理フレーム

MUGENでは1フレーム経過した時点で処理が完了するケースが多い。
例えばhitdefやprojectileはヒットまたはガード判定が出た次のフレームでダメージが入るため、
ヒット判定が出た次のフレーム(このときのstatenoは5000、5010、5020、150、152、154)で、
hitoverride、changestateで他のステートに飛ばしたり、statetypesetを実行したりして、
キャラクターのmovetypeをH以外にするとダメージが入らない。
またmugenの内部処理ではないものの、p2statenoのかわりにtargetstateを使用している攻撃も、
ヒット判定は出るがtargetstateは無効化される。



MUGENのステートの処理順序

MUGENでは毎フレームごとに-3ステート→-2ステート→-1ステート→0番以降の自分が今いるステートの順番で処理が進む。
-3ステートおよび-1ステートは、ステートを奪われていない限り1フレームにつき必ず1回実行され、
-2ステートはステートを奪われていても1フレームにつき1回実行される。
これらのマイナスの番号がついたステートは常時監視ステートと呼ばれ、どのステートも同一フレームで2回以上実行されることは無い。
なお0番以降のステートはchangestateを繰り返すことで何度でも(2500回という上限は一応存在する)実行可能である。

MUGENのシステムに組み込まれているAI(デバッグキーのCtrl+1および+2で起動するもの)が起動している場合、
ctrlが有効になっていると-3ステートの前にMUGEN内部のコマンド処理が割り込むことがある。
一般的なchangestateは常時監視ステートで行われるので問題にならないが、
例外的にMUGENの内部処理に組み込まれているchangestate
(hitdefを受けたことによるくらいモーションへの移行、MUGEN内部のコマンド処理による前進、後退(ガード)、しゃがみ、
ジャンプ移行。ただし前進と後退、ガードはassertspecialで無効化できる。)は、
-3ステートが実行される前に実行される。
これらの処理は-3ステートにおいてtime=0が成立する数少ないchangestateになっているので、
ジャンプ移行などを完全に排除したいときは-3ステートの末尾でそれぞれのステート番号とtime=0をトリガーにして、
ctrlを有効にしつつニュートラル(一般的には0番ステート)に引き戻すようにすればよい。
ただし下手に条件を設定するとくらい抜けや空中で立つなどということになりかねないので、
トリガーは慎重に設定すること。

ちなみに常時監視ステート内でselfstateおよびchangestateが実行されると、
それ以降のそのステートにあるステートコントローラが全て無視される。
必殺技へのchangestateをcmdファイルの上の方に記述しなければならないのはこれが理由なのだが、
内部処理用のステコンの前に置いてしまうと本来毎フレーム処理されるはずの処理がスキップされてしまうことにある。
場合によっては致命的な問題を引き起こすので、changestateはそれぞれのステートの末尾にまとめて並べるようにした方がよい。
上記したtime=0のchangestateをわざわざ末尾で実行するよう明記したのはそのためである。
なお実行されないのではなく完全に無視されてしまうので、nullと:=を用いた変数代入もスキップされる。
裏を返せば、type=nullとしてもトリガー自体は実行されているということである。
完全に処理を排除してしまいたければ、セミコロンを使ってコメントアウトしなければならない。

以下、AI製作者向け
-3ステートで内部処理に加えてAIのchangestateが行われていることがあるが、
-3ステートではAIのchangestateを行わない方がよい。
それどころか、AI関係のステコンはごく一部の例外を除き、全て-1ステートで処理した方がよかったりする。
というのも、たとえ同一フレームであっても、-2ステートの内部処理を経由することで、
キャラクターの状態が全く異なることが有り得るからである。
オリコンやMAX発動の最後の1フレームなどが分かりやすい例で、
-3ステートの時点では最後の1フレームが残っている→
-2ステートでカウントが進み、オリコンorMAX状態解除→-1ステートの時点では解除済み、となる。
実際の対戦では両者の最後の1フレームは技の硬直中であったり
持続時間を十分残した状態で超必殺技を使って強制解除となることが大半でほとんど問題にならないのだが、
キャラクターのシステムによっては1フレームの差がきいてくることもある。
フレーム単位で自分のおかれている状況を判断しているAIならば、なおさら差が生じやすい。
こうした問題があるので、-3ステートには「相手にステートを奪われている時は実行したくない内部処理」のみを置き、
-2ステートに「相手にステートを奪われているときも実行したい内部処理」
-1ステートに「-3、-2ステートの処理の結果を見て実行したい内部処理とchangestate」を記述するのが無難である。


スケール関連

飛び道具の倍率

CNSのSIZE内「xscale」、「yscale」を任意の数値に変更するとキャラクターの表示倍率が変化する。
ここでproj.doscaleが1になっていると、projectileのスケールも上記の倍率通りになる。

しかし、projectileの代わりにhelperを用いた飛び道具の場合は一括して変更することは出来ない。
CNS内を「type = helper」(=の前後の空白は有ったり無かったりなので気を付けること)で検索し、
size.xscale = const(size.xscale)
size.yscale = const(size.yscale)
スケールの値をこのように設定すれば本体の倍率が適用されるようになる。
ただしもともとスケールを変更してあるhelperの場合はまた別。

飛び道具の出現位置がずれる場合が多いので、
その時は「type = helper」、「type = projectile」で検索し、
直下の「pos」を倍率及び基準位置(postype)に従って全て変更。
さらにキャラ本体の移動速度や弾速もスケールに合わせ全て調整しなくてはならない。
本体およびhelper用の全てのステート内のVel系全命令、
それともしもGravityが使われているならConstのMovement>yaccelもチェックしよう。
projectileの場合「velocity」「remvelocity」がチェックの対象である。

大雑把でいいと割り切っているなら上記の作業全てをやる必要は無いが、きちんとしたものにしようとすると、
作業量はかなり多いので気を付けよう。
作業に入る前に、変更前のキャラをどこかに保存しておこう。
また、一時的に変更前のキャラと作業中のキャラを両方登録しておき挙動を比べてみると良い。
特に、もしそのキャラを動画に使用するつもりならば、
技の当たり具合やコンボの繋がりにおかしな影響が出ていないかのチェックには充分に念を入れよう。

なお、Win版MUGENを使っているなら(多分使っているだろうが)次の節も参照しておいた方が良い。


Size>scaleの問題点

キャラの倍率を自由に変更できるConst>Size>xscaleおよびyscaleだが、
実はWin版MUGENでは「yscaleを1以外にすると影や床の反射像の表示位置が狂う」という問題がある
(xscaleの方は1以外を使用しても特に問題は無い)。
解決方法は無いらしく、強いて言えばyscaleを1から変更しないことが対策である。
後からscaleなど使わずに済むように、なるべくSFF構築の時点で画像に拡大縮小をかけておくのが望ましい。

……と言われても、所謂D4専用キャラでは無理な話だろうが、
正規のバージョンではない流出品の本体を正しくない設定で使用していることを考えれば、この程度の問題はやむを得ない所だろう。
一応D4キャラのためには、constではなくAngleDrawを-2ステートから用いて常時縮小表示するという手段があり、
このやり方ならば影が正しい位置に表示される。
キャラによっては投げ技などの最中にP2用のステイトでAngleDrawを使う場合もあるが、
その場合でもちゃんと双方のAngleDrawの効果が反映された表示になってくれる。
後からサイズを変更するのには向かないが、それをしないならばConstのxscale、yscaleを変更するよりも、
AngleDrawを使う方がより良い処理と言えそうだ。


attrの仕様

attrとは、HitDefとProjectileの中にある攻撃の属性を指定する項目である。
「特性」や「属性」といった意味のAttributeの略。

一個のattrはarg1、arg2と呼ばれる二つの部分をもち、さらにarg2は前後2文字でできている。
例えば「S,NA」というattr、コンマの前の「S」がarg1、後の「NA」がarg2である。
arg1はS、C、Aで、それぞれ立ち、しゃがみ、空中を意味する。
arg2は1文字目がN、S、Hでそれぞれ通常技、必殺技、超必殺技、2文字目がA、T、Pで打撃、投げ、飛び道具、を意味する。

arg1、arg2の1文字目、arg2の2文字目それぞれ3通りなので、3×3×3で前27種。この27種類のattrを表のようにするとこのようになる。
打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) S,NA S,NT S,NP
必殺技 (S) S,SA S,ST S,SP
超必殺技 (H) S,HA S,HT S,HP
しゃがみ (C) 通常技 (N) C,NA C,NT C,NP
必殺技 (S) C,SA C,ST C,SP
超必殺技 (H) C,HA C,HT C,HP
空中 (A) 通常技 (N) A,NA A,NT A,NP
必殺技 (S) A,SA A,ST A,SP
超必殺技 (H) A,HA A,HT A,HP

arg2は必須パラメータだが、キャラ本体やヘルパーのHitDefではarg1は必須でなく省略可能。
Projectileにはarg1も必須パラメータである。


NotHitByの仕様

NotHitByとは、キャラクターを無敵状態にするステートコマンドである。
敵の攻撃判定のattrを指定し、どの攻撃を無効化しどの攻撃を有効なままにするかを決定するが、指定の自由度はあまり高くない。

NotHitByの記述は以下のようなもの。
[State XX, XX]
type = NotHitBy
trigger1 = (任意のトリガー)
value = (任意のarg1要素),(任意のarg2要素),(任意のarg2要素),(任意のarg2…略
このvalueにattrを書きこむことで、どの属性の攻撃判定を無効化するか指定するのだが、
この時の記述の形式はけっこう独特で分かりづらいため、しっかりと理解することが必要である。

「value =」の直後に記述するのはarg1要素。
value = S
例えばこうしてSと指定しただけでStateTypeがSの状態での判定全てが無効化される。
注意すべきは参照しているのは敵のHitDef内のattrの記述ではなく、敵の実際のStateTypeだという点。
記述上でagr1がCやAになっていてもStateTypeがSなら無効化対象であり、
もし敵がそのHitDefを維持したままStateTypeをCやAに変更すればその時点から無効化対象外になる。
ちなみにPrijectileは本体のStateTypeの影響を受けず常に記述通りの属性なのでこういうことは無い。
value = SCA
こうするとStateTypeがCとAの攻撃も無効化対象に入る。完全無敵を作りたい場合この記述が一番簡単である。

arg1要素を省きarg2要素だけ指定したい場合は「value =」の直後にコンマを打ってから記述を始める。
value = ,NA
このようにすれば通常技で打撃属性の判定(arg2がNAのattr全て)を無効化する。
さらにNAの後にまたコンマを打てば他のarg2要素を書き加えていくことが出来る。

なおarg2要素1文字目には、N、S、Hの他にAが存在する。Allの略のAである。
value = ,NA,SA,HA
「N、S、Hの全ての打撃」を対象にしたい場合普通に書けば上のようになるが、
value = ,AA
Aを使うとこのように短縮できる。ちなみに下のようにすると、「全ての打撃と投げと飛び道具」が対象となってSCAと同じく完全無敵になる。
value = ,AA,AT,AP

指定対象は書き足せば足した分だけそのまま範囲が広がり、例外枠を作ることはできない。
value = S,NA,NP
などとすると、全ての立属性の判定通常技で打撃属性の判定通常技の飛び道具属性の判定に対して無敵になる。
例としてvalue = S、value = SCA、value = ,NA、value = S,NA,NPの無効化範囲を表で見るとこうなる。
+ ...
value = S 打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) 無効 無効 無効
必殺技 (S) 無効 無効 無効
超必殺技 (H) 無効 無効 無効
しゃがみ (C) 通常技 (N) 有効 有効 有効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効
空中 (A) 通常技 (N) 有効 有効 有効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効

value = SCA 打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) 無効 無効 無効
必殺技 (S) 無効 無効 無効
超必殺技 (H) 無効 無効 無効
しゃがみ (C) 通常技 (N) 無効 無効 無効
必殺技 (S) 無効 無効 無効
超必殺技 (H) 無効 無効 無効
空中 (A) 通常技 (N) 無効 無効 無効
必殺技 (S) 無効 無効 無効
超必殺技 (H) 無効 無効 無効

value = ,NA 打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) 無効 有効 有効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効
しゃがみ (C) 通常技 (N) 無効 有効 有効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効
空中 (A) 通常技 (N) 無効 有効 有効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効

value = S,NA,NP 打撃 (A) 投げ (T) 飛び道具 (P)
立ち (S) 通常技 (N) 無効 無効 無効
必殺技 (S) 無効 無効 無効
超必殺技 (H) 無効 無効 無効
しゃがみ (C) 通常技 (N) 無効 有効 無効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効
空中 (A) 通常技 (N) 無効 有効 無効
必殺技 (S) 有効 有効 有効
超必殺技 (H) 有効 有効 有効

上記のようにarg1、arg2の要素はそれぞれ独立しているのだが、KOFの前転の様に「SCA全属性の打撃および飛び道具に無敵」としたい時に、
「SCA全属性の」を意識するあまりつい「value = SCA,AA,AP」としてしまうような事も有るが、これだと完全無敵になってしまう。
この場合arg1を省き「value = ,NA,SA,HA,NP,SP,HP」か「value = ,AA,AP」とするのが適切である。

キャラ作成をしていれば「立属性かつ打撃属性である攻撃に対してだけ無敵」という状態を作りたい場合なども、
あるかもしれないが、NotHitByの仕様上それは不可能である。
value = ,AA とarg2要素だけを指定しトリガーにP2StateType = Sを加えるなどすれば、
意図に近い状態を作れないでもないが、トリガー成立中にはあくまでも全ての打撃に対し無敵となっているため、
タッグモードや、相手がヘルパーを多用するキャラだった場合など、
P2のHitDef以外の攻撃がある状況ではどうしても安定した結果にならない。


投げ技の最中にしてはいけないこと

正確には投げ技だけでなく、HitdefでP2StateNoを指定する技と、
targetstateを使用する技全般である。これらをさしてステートを奪う、などと呼ばれる。
ステートを奪われていると、デバッグを起動した時に画面左下に表示されるキャラクター情報の文字が黄色になる。
このとき、技を仕掛けた側、仕掛けられた側双方にしてはいけないことがある。

まず技を仕掛けた方。
:相手のVarを変更してはいけない
|本当をいうとこれは豆知識だとかではない。なんでかと言うと公式のドキュメントに書いてあることだからである。
sctrls.rtfかsctrls.htmlを開いて「rude」という単語を検索すれば当該の箇所が見付かる
(大体を意訳すると、
 「貴方のカスタムしたステートでP2を処理している間には使わないでください、P2の変数を上書きしてしまいます。とても失礼です」
 というような内容)。
:Helper、Projectile、Explod等を発生させてはいけない
|こちらは別にドキュメントに書かれているわけではないが、理由は大体上と同じである。
HelperとProjectileはともかくExplodまで?と思うかもしれないが、
NumExplodというトリガーもあるので念の為に使用を避けた方が安全。
:相手のPowerをトリガーにした記述を考え無しに使用してはならない
|これはPowerはそのキャラ固有のものではない(タッグパートナーやヘルパーも共有している)ためで、
例えば「徐々に相手のPowerを減少させていき、やがてある数値を下回ったらSelfStateでコントロールを返す」というような、
技を作ると、場合によってはその技は延々終わらなくなってしまう。
ただしあくまでこれは考え無しに使うのが問題なので、きちんと考えて使う分には問題はいくらでも避けられる。
:技の演出中にtargetstateやtargetbindなどを使う時は考え無しにくらい判定を付けてはいけない
|ワイヤーダメージや特殊ダウン(ダウン追い討ちをかけるためのダウン)など、
かけられた側が一定時間後にselfstateを実行する場合は構わないが、
投げ技などでは技をかけている最中に攻撃側が攻撃を受けて技のステートから抜けてしまうと、
技をかけられた側がそのステートから抜け出せなくなってしまうことがある。
また技をかけられた側のくらい判定を残したままにすると、攻撃をくらってステートから抜けた際に、
かけた側が何もない場所で投げモーションを取ったりと妙なことになる。
これもきちんと考えて使う分には問題はいくらでも避けられるし、見栄えも良い。
と言うか、何らかの要因で相手が想定外の位置やステートに行った場合の挙動は普通に想定しておくべき事柄である。
なお、くらい判定が無ければそれで安心かというと案外そんな事も無い。
例えば!GetHitVar(IsBound)でSelfStateするなど、予定外の状態になった場合に相手が抜けれるように例外処理はきっちりと書いておくべきである。

つぎに技を仕掛けられた方。
こちらはしてはいけないことが多いのでやや大雑把になるが一個一個を上げずにまとめて説明する。
:勝手に状態を変えてはいけない
|勝手に-2ステートでChangestateやSelfState等をするな、ということ。
当たり前に思えるが、原作で投げや当て身投げが通じないような特殊なキャラ(これとかこれとか)で、
その再現のためかこれをやってしまっているキャラは案外いる。
しかし、投げを食らわないようにするのと、投げ成立後に相手の記述から勝手に抜けるのは別である。
最悪本体が落ちることもあるのでこれらのキャラと当て身投げ技を持つキャラの対戦時は注意がいる。
:相手がトリガーにしそうなものは全て変更してはいけない
|例えばVelSet、VelAdd、PosSet、PosAdd、LifeSet、LifeAdd、ChangeAnim…etcである。
これらを変更する記述を-2ステート内に持っているキャラは、-3に記述の場所を移した方が良いだろう。
ちなみにこれらを意図的にやって、相手の投げ技などを正常に機能しなくさせているのが神キャラらの即死攻撃対策である。
特にselfstateで投げなどから抜ける行動はステート抜けと呼ばれ、
GUILTY GEAR』のサイクバーストのようなくらい抜けとは明確に区別されており、
後者はコモンステートで定義された共通くらいステートでのみ使用可能になっている。
裏を返せばステートを奪われるとこれらのシステムが使用できなくなってしまうため、
むやみやたらとステートを奪うのは考え物である。
もっとも、技の性質上こういったシステムを使用させたくない時に、わざとステートを奪うケースもあるのだが。
:commandトリガーを使ってはいけない
|ステートを奪った側で実行されたコマンドに対応するコマンド(コマンドの内容ではなく、cmdファイルに記述されている順番が同じコマンド)が、
なぜかステートを奪われた側でも実行されるという仕様が存在する。
そのためcommand以外の条件が甘いステコンを-2ステートに記述すると、
投げ技や当身を受けた時に暴発してしまう可能性がある。
またhelperは本体とは独立して処理を行っているので、
helper側のroot,commandトリガーが反応してしまいステコンの暴発につながることも有り得る。
:stateno=○というトリガーを使ってはいけない
|相手がtargetstateなどで指定したstatenoの番号と、
-2ステートやhelperに記述されたstatenoトリガーの番号が重なってしまった場合、何が起こるか分からない。
stateno!=○というトリガーであれば問題は起こりにくいが根本的には同じである。
例えば本体のステートを参照してhelperからexplodなどを射出している場合、
本体が投げられた途端にエフェクトが表示されるなどということがある。
それだけならまだいいが、varsetなどが実行されていると非常に危険。
-2ステートにあるものついては、statenoトリガーを使うのではなく、
ステートコントローラごとそれぞれのステートに移した方がよい。
また、stateno!=○というトリガーであっても、statenoが重なってしまった時の対応を考えておく必要がある。
commandトリガーと同様、helperでroot,statenoやparent,statenoトリガーを使用している時も注意しなければならない。

これらはステートコントローラーをState -2内に置いている事で起こる
(と言うか「投げ技を喰らっている最中でも実行したい事がある場合のために有るのがState -2」だと捉える方が合っているだろう)。
記述をState -1か-3に移動させれば実効されなくなる。
どうしても-2から記述を動かすわけにいかない場合、トリガーの条件を厳密にするしかない。
例えばステートを奪われている時はmovetypeがHとなっていることが多い(ReversalDefからだとそうでない場合もある)ので、
movetype!=H、またはroot,movetype!=Hを加えるだけでもほとんどの暴発を防止できる。


p2statenoおよびtargetstateをかけた攻撃の仕様について

p2stateno

相手に攻撃がヒットしたフレームでステートが変更されるため、
デバッグのコマ送りで5000番台のステートに飛んでいるのは確認できない(prevstatenoでは確認可能)。
hitdefのattrが相手がhitoverrideで指定しているattrと重複した場合強制的にスカり、
ヒット判定やガード判定、エフェクトは一切出ない。
そのため、一見すると無敵状態になっているように見える。

hitonceが無効になっている攻撃で複数の相手を同一フレームで巻き込み、
一方が直撃、一方がガードした場合、直撃した方のみp2statenoで指定したステートに飛び、
両方とも直撃していれば、両方が飛ぶ。
p1statenoがある場合、1体でも直撃していれば指定したステートに飛び、
全てガードされていれば飛ばない。
hitonceが有効になっている攻撃で複数の相手を巻き込んだ場合、
ランダムでどちらか一方のみp2statenoで指定した飛ばす。
また、自分はp1statenoで指定していたステートに飛ぶ。
なおhitonceを明記しなかった場合、attrが投げ以外なら無効、投げなら有効になる。

p2statenoを仕込んだ攻撃と相手の攻撃が相打ちになった場合、
p1statenoに関係なく食らいステートに飛ばされるが、p2statenoだけは実行される。
selfstateで強引に戻すにしても自分以外のステートをトリガーにせざるを得ないため、
タッグできちんと動作する保障は無い。
そのためp2statenoを仕込んだ攻撃のpriorityはmissにしておいた方が無難。

p2statenoを仕込んだ攻撃と仕込んでいない攻撃が同じフレームで相手に当たった際に
(以下便宜のため、p2statenoを仕込んだ攻撃を投げ、仕込んでいない攻撃を打撃と呼ぶ)
idの若い方が投げを実行していた場合、
攻撃を受けた側は投げで指定されたステートに飛ばされ攻撃側もp1statenoで指定されたステートに飛ぶが、
同時に打撃によるダメージも入る。
また、targetは投げを使ったキャラクターのみ保持され、
打撃を当てたキャラクターのtargetは無効となる。
idの若い方が打撃を実行していた場合、
1Fだけ投げで指定されたステートに飛ばされるが、その次のフレームで打撃によるダメージを受け、
5050番ステートに飛ばされ、その場でダウンする。

targetstate

投げ技などの過程でtargetstateを使用する場合もあるが、
ここではロック技やワイヤーダメージなどを想定し、
numtarget&&movehitをトリガーにしてignorehitpauseを有効にして作動するものとする。
targetstateはキャラクターの個別処理なので、最速でもヒット判定が出た次のフレームで、
常時監視ステートが実行できる状態にならないと作動させられない。
一方hitoverrideによるステート変更はmugenの内部処理にあたり、
ヒット判定が出た次のフレームの冒頭で実行されるので、
相手がhitoverrideでmovetypeがH以外に指定されているステートに飛ぶとtargetが無効になり、作動しなくなる。

targetstateを仕込んだ攻撃で複数の相手を同一フレームで巻き込み、
一方が直撃、一方がガードした場合、ガードした方の相手もtargetstateで指定したステートに飛ぶ。
これはガードされたときもtargetは有効であり、movehitとmoveguardedが同一フレームで成立すると、
movehitだけが有効になるためで、targetstateのトリガーだけで完璧に回避することはできない。
また、p2statenoのhitonceのように相手を1体に限定することも不可能。
一応、targetstateで飛んだ先でgethitvar(guarded)などをトリガーにしてselfstateで戻すことは可能。
このとき戻すステートは120、130~132番ステートが妥当だが、
技の演出の関係上、どうやっても見た目が不自然になってしまうこともある。
また攻撃側の挙動が安定しないケースもあるので、
タッグ限定のバグであることから、実際には特に対処されていないことがほとんど。

targetstateを仕込んだ攻撃と相手の攻撃が相打ちになった場合、
食らいステートに飛ばされるためtargetstateが実行されることは無い。
そのため、hitdefのpriorityをhitにしても基本的に問題は無い。
ただし常時監視ステートにtargetstateを置く場合は、
相打ちした時に誤作動することがあるので、movetype!=Hなどが必要になる。

targetstateを仕込んだ攻撃と仕込んでいない攻撃が同じフレームで相手に当たった場合、
targetstate自体はidを問わず問題なく作動し、同時にchangestateを作動させても問題無い。
またtargetはtargetstateをかけた側のみ有効になる。
逆にtargetstateが乗っていない攻撃は、攻撃が重なったフレームに関しては、
相手のくらい判定や無敵状態に関係なく強制的にスカる。


技が途中で止まるorいつまで経っても止まらないorキャンセルの猶予が異常に短い

真田小次郎(ホタリュソ氏)の「無明剣・贄」、ジャック・ターナー(Andre Lopes氏)の「ストライカーテムジン」、グラント(M.M.R氏)の「魔神円月輪」などで起こる現象。
最後1つは少し毛色が違うが、原因は同じだったりする。

これはMUGENの、DOS版とWIN版の仕様の違いによるもので、簡単に修正する事が出来る。
下記の左側の記述を右側のように変更すれば良い。

movecontact = 1 ⇒ movecontact
movecontact = 0 ⇒ !movecontact
movehit = 1   ⇒ movehit
movehit = 0   ⇒ !movehit
moveguarded = 1 ⇒ moveguarded
moveguarded = 0 ⇒ !moveguarded

置換機能のあるテキストエディタを使えば楽、と言うか使わないとかなり面倒なので、大人しく使おう。
ちなみにこの項の内容は無限小学校のMUGEN説明書にも載っているのだが、意外と気付いていない人も多いのではないだろうか。
「何かおかしいな?」と思ったらまず試してみるのをお勧めする。

立ち・しゃがみニュートラルで出せる技とstatetypeトリガー

ctrlが有効な時にキー入力により起こる立ち・しゃがみへのchangestateは常時監視ステートの前に処理される。
しかしchangestateが起こった時点でstatenoは変化するが、
実際にstatetypeやphysicsが変化するのは常時監視ステートの処理が終わった後なので、
常時監視ステートでstatetype=Cが成立するのは、
ニュートラル状態でcommand="down"が成立したフレーム(キーの↓を押したフレームと考えていい。
このとき同時にcommand="holdown"も成立する)ではなく、その次のフレームになる。
このため、kfmのようにstatetype=Cがしゃがみ通常技のトリガーに入っている場合、
↓キーとボタンを同時押しするとしゃがみ通常技が出ない。
また、立ちへの移行でも同様の現象が原因で、
しゃがみニュートラル状態から↓キーを離すと同時にボタンを押しても立ち通常技が出せない。
わずか1Fではあるが、立ち通常技>しゃがみ通常技、
またはしゃがみ通常技>立ち通常技の目押しが重要となるキャラでは致命的。
特に猶予0Fの目押しは、絶対につながらなくなってしまう。
技の条件に入っているstatetype=Sやstatetype=Cを全てstatetype!=Aに書き換えれば、この問題は解決される。

なお立ちガードとしゃがみガードの切り替えに関しては、ガードステート内に立ち、しゃがみの切り替え記述があり、
ガードの正否判定がキャラクターの処理が全て終わった後に行われるので問題無い。

ちなみにキー入力によるジャンプ移行でもctrlが無効化されるのは常時監視ステートの処理が終わった後なので、
ニュートラルからキー↑要素を入れた1F目では、stateno=40&&ctrlが成立する。
この仕様があるので、サマーソルトキックのようなキー↑要素のある技のトリガーにはstateno=40を加えなくても一応出せるのだが、
出しにくいことに変わりはないので、stateno=40でも出せるようにしておいた方がいいだろう。


AIパッチを当てる際の小技

単にパッチファイルを丸ごと上書きする前に少し手を加えてやると、
1キャラ分の容量で複数のAIを使い分けることができ、またバックアップや整理も容易になる。
  1. キャラフォルダ内に新規フォルダを作る。フォルダ名はAIの製作者名などにしておくと整理する際に分かりやすい。
  2. そのフォルダにAIパッチの中身を全て入れる。
  3. AIパッチの中に新しいdefファイルがあればそれを、なければ元キャラのdefファイルをコピーし、元キャラのdefと同じ場所に置く。
    ファイル名は先ほど作ったフォルダ名と同じにしておくと良い。
  4. コピーしたdefファイルを開き、AIパッチの内容に基づいて記述を変更する。
    (例) 新しいchara.cmdとchara.cnsファイルが「AI」フォルダに入っている場合、
    chara.cmd → AI/chara.cmd
    chara.cns → AI/chara.cns
    に全て変更
  5. このdefファイルをMUGENのdataフォルダ、もしくは使用アドオン内のselect.defに登録する。
AI製作者の中には最初からこの形式で製作されている方もいるので、その場合はこの手順を踏む必要は無い。
select.defを参照すればどれが誰のAIなのか一目瞭然なので、後々非常に便利。
ただし、新しく作ったdefファイルの記述が間違っていてもエラーが出ないことが多いので、確認はしっかり。
何か動きがおかしいなと思ったらここをチェックしてみよう。

また、この作業を自動化するツールも公開されている。
簡単なので一度使ってみるとよいだろう。
ただし動画中にも書かれているが、くれぐれも適用後の確認を怠らないように。


チーム戦(Turns)で2番手以降のキャラのイントロを発生させる方法

最初から対応しているキャラもいるが、MUGENのデフォルト設定では発生しないようになっている。
そこでまずMUGENのdataフォルダ内のcommon1.cnsを開き、一番下にある [State 5900, 3] ;Intro for round 1 の記述を
[State 5900, 3] ;Intro for round 1
type = ChangeState
trigger1 = RoundNo = 1
trigger2 = RoundsExisted = 0
trigger2 = TeamMode = Turns
trigger2 = RoundNo > 0
value = 190
に書き換えてやる。
これで備え付けのcommonを使っているキャラはOKだが、
独自にcommonファイルを持っているキャラやcns内にvar持ち越し、イントロの設定などが含まれているキャラの場合
それぞれ [State 5900, 3] に相当する記述を探し出して同じように書き換える必要がある。
この場合間違った場所に上書きしたりすると最悪そのキャラが動かなくなるので、バックアップを忘れずに。
場所はキャラによってまちまちだが、片っ端からファイルを開いて 「5900」 などで検索をかけていけば大抵は見付かる。
稀に [State 5900] 以外に記述しているキャラもいるので、どうしても見つからなければ検索ワードを 「190」 などに変えてみよう。
2箇所に記述があることもあり、その場合は優先順位の高い方を修正しないと反映されないので注意。
イントロがあるかないかで動画の見栄えもかなり変わってくるので、チーム戦の動画を作る際にはこの作業をやっておくと良いだろう。

ただしこの記述は単にそのキャラが登場したラウンドのみイントロに移行するというものなので、
KOFのような特定の対戦カードになったときの掛け合いが成立しない。
trigger3 = TeamMode = Turns
trigger3 = P2Name = "kfm" || P2Name = "ryu" || P2Name = "kyo" ;(以下略)
という具合に書き加えて対応キャラを個別に登録していけば可能だが、これをいちいちやっていくのは凄まじく骨が折れる。
一応毎試合無条件で両者のイントロを発生させるようにすれば一括で成立するので、
それでもいいから掛け合いが欲しいという人は上の記述5行目行頭に「;」(半角セミコロン)を挿入しよう。

また別の方法としてはイントロ分岐用のステートを別に準備した上で5900ステートからへは毎ラウンドそのステートへ飛ばすようにし、
特殊イントロがあり、自分か相手のどちらかが初登場のラウンドなら特殊イントロへ、
(triggerall = RoundsExisted = 0 || enemy,RoundsExisted = 0 という記述を条件に追加する)
特殊イントロがなくて自分が最初のラウンドなら汎用イントロへ、
どちらでもないなら立ちステートへ飛ばすように分岐をかければ、これらの問題はすべて解決する。
ただし、対戦する両方に記述をしておかないと、片方が呼びかけているのに相手が無反応という悲しい事態も起きる。
必ず両方を対戦させてチェックしよう。


勝利ポーズ表示時間を変更する方法

独眼ちゃんやアリ氏の斬紅郎(2008年5月以前版)などで、
勝利ポーズの途中で画面が切り替わってしまう現象が時折見られる。
逆に、キャラによっては勝利ポーズが終わったのにいつまでも切り替わらないこともある。
斬紅郎の「無限流こそ海内無双の剣技よ」という台詞の「海内」の辺りで画面が切り替わってしまう現象に空耳も合わさって、
一部では「無限流こそ曖昧現象」と呼ばれることもある。
それを解決するには、勝利ポーズのステートから
[State 181, 1]
type = AssertSpecial
Trigger1 = Time = [0,200]
flag = RoundNotOver
というような記述を探し、無い場合は付け加える。

もちろん勝利ポーズによって掛かる時間は違うため、Time = [0,200]の部分はそれに合わせて書き替える必要があるが、
そこは実際にMUGEN上で動かして調整すればいいだろう。
またライフバー側の設定がまずい場合も似たような現象が起こる。代表的なのはVF5LBだろう。
fight.defの中のover.timeの数値を250ぐらいに変更すれば解決するはずだ。


常時ステートの専用記述で対応する攻撃一覧

毒などの特殊な技は、攻撃側の記述だけでは再現しにくいことがある。
そのため相手側の常時ステートに専用の記述を組み込む必要があるが、
もちろん全てのキャラがその種の技全てに対応しているわけではない。
キャラや動画を製作する時は、こういった点にも留意するべきだろう。

製作者名 キャラクター名 対応する攻撃 備考
ドロウィン氏 廿楽冴姫 アンプゾワネ
アバトワール
朱鷺宮神依
フィオナ・メイフィールド
SAIKEI氏 ユダ イチコロ
ゆ~とはる氏 マミヤ バイク 七星ゲージのあるキャラ限定
マミヤ 挑発
愛原奈都美
アル・アジフ
586氏 神尾観鈴 不幸の塊
観鈴ちんピンチ!
HAL氏 遠野秋葉 獣を焦がす
疾駆する獣を焦がす
⑨氏 赤朱秋葉
翡翠 じょうろ MBAA仕様
琥珀 現代医学の犠牲者です MBAA仕様
レン パウダースノウ MBAA仕様
ワラキアの夜 ブラック・クラック MBAA仕様
祇園城奏貴氏 西行寺幽々子 霊符「无寿の夢」
寿命「无寿国への約束手形」
水影氏 伊吹萃香 酔符「鬼縛りの術」
酔夢「施餓鬼縛りの術」
霊力ゲージのあるキャラ限定
小野塚小町 脱魂の儀
鈴仙・優曇華院・イナバ 毒煙幕「瓦斯織物の玉」
洩矢諏訪子 土着神の祟り
ミシャグジさまの祟り
IF氏 永峰希美 ウィッシュプライヤー

具体的な対応方法や記述の内容は、各々の付属txtなどを参照のこと。


MUGENデバッグキーの一覧

大会・ストーリー動画の作成や、キャラ・AIの作成などあらゆる場面で知っていると便利なMUGENショートカットキーの一覧を掲載。
F1 2P側のライフを0に
CTRL+F1 1P側のライフを0に
F2 両側のライフを1に
CTRL+F2 1P側のライフを1に
SHIFT+F2 2P側のライフを1に
F3 両側のパワーをMAXに。ゲジマユでお馴染み
F4 ラウンドリセット
SHIFT+F4 データのリロード(mugen起動中にcnsを更新して、そのまま更新データを読み込ませる事も可能)
F5 タイムオーバー
F8 デバッグデータ表示中、エラーメッセージをリセット
F12 スクリーンショット
CTRL+C 判定枠の表示の切り替え
CTRL+D デバッグデータ表示の切り替え
CTRL+I 両側のプレイヤーを強制ニュートラルステート(StateNo=0)に(はまり状態の回避に使える)
CTRL+L アドオンのライフ、パワーバー等を消去(キャラ固有のパワーバーは消せない)、用途はキャラ作成時に見やすくすることなど
CTRL+S ゲームスピードアップ(デバッグのFPSとSPEEDで確認可能)
CTRL+数字 数字には1~4の数値が入る。指定した数値のキャラをAIモードに(1なら1P、2なら2P)
CTRL+ALT+数字 キャラの消去。もう一度押すと元に戻る
SPACE 両側のライフとパワーをMAXに、時間もリセット
PAUSE ポーズ画面の表示、トレーニングモードならサンドバッグの状態の指定も可能
SCROLLLOCK PAUSE中にSCROLLLOCKを押すたびに1Fだけ時間を進める、製作中キャラの動きの確認等で使える。
ESC mugenの終了や画面を戻すのに使用


batで色々

[(mugen名) -r (アドオン名) -p2.ai 1]とやるとアドオン実行&2pAIonの効果
-h ヘルプを表示。上の画像
-r アドオン
-p2.ai 1で2pのAIon。-p1.ai 0ならwatchモードで1pが操作可能に。-p3.ai 0で3pのAIも無効化できるのでタッグの動作確認などに。
-p2.color カラー指定。12P色を選ぶ時とかに
-s ステージを指定。select.defに登録する時の「stages/aaaaa.def」という書式ではなく「aaaaa」で記載
-nomusic BGMを流さない。
-nosound BGMと効果音を流さない。
-rounds ラウンド回数を指定。0で1ラウンドだけ戦う。10ラウンド戦わせる時は、9にする。
-log 試合結果をテキストに保存する。

例.
winmugen -r MBC -p1 ryu -p2 terry -p1.color 1 -p2.color 4 -p1.ai 1 -p2.ai 1 -s geese_stage -rounds 2 -nomusic -log ryuvsterry.txt
という内容のバッチファイルを作ると、
アドオンは「MBC」で、1P側のキャラはryu、2P側のキャラはterry、1P側のカラーは1、2P側のカラーは4、1P側はAI操作、2P側はAI操作、
ステージはgeese_stage、3ラウンド戦ったら終了、「ryuvsterry.txt」というファイルを作ってログを保存する……という事ができる。
AI戦闘の勝率チェックで200ラウンドほど戦わせて結果だけ表示させたいという時に便利。
各ラウンド終了時の体力やゲージ残量も記録してくれる。通算成績を自動計算してくれないのが難点か。


起き上がり短縮

MUGENでは自分が操作しているキャラクターがダウンした時(StateNo5100、5101、5110の時)、
ボタン(FBUDabcxyzsどれでもOK)を連打するとダウン時間を短縮出来る(=起き上がりステートへ移行できる)仕様になっている。
ダウン短縮自体は実装されているゲームも多いのだが、MUGENの場合起き上がりタイミングを任意に変えられる上に、
連打の速さによってはダウン直後に起き上がれる場合すらある
このためMUGENではダウン追い討ちがしづらいばかりでなく、
起き攻めリバーサルのコマンド入力もタイミングが取りづらい上、
場合によってはダウンさせたのに反確という事態もしばしば起こる。
これを防ぎたい場合は攻撃側であればダウン中相手のステートを奪う、
防御側であればStateNo5110に飛んだ瞬間に別のダウン専用ステートに飛ばすといった処理を行うしかない。
一部のキャラはこのような処理を行なっているので、気になる場合は参考にするといいかもしれない。


Helpermaxについて

一部のキャラクターは、製作者が付属のテキストで「Mugen.cfgのHelermaxを56に書き換えてください」と指示していることがあるが、
実はこの修正、MUGENで遊ぶ際の必須事項と言ってもいい。
Helperが大量に発生するのは何も弾幕を張った時だけではなく、
演出やエフェクトにも使用されており、GM氏の3rd仕様リュウがダウン時に10個以上の視覚的に見えないHelperを管理していたりと、
意外なキャラクターがそこそこの数のHelperを発生させている。
Helperの個数がHelpermaxに到達してしまうと、飛び道具が出ないぐらいならまだいい方で、
ロック技の判定にHelperが使用されていると試合が続行不能になることもある。
こうした事故を未然に防ぐために、面倒くさがらずに上限値である56に設定しておこう。
また、Helperを使ったキャラを製作する時は、2対2の試合の時でもHelpermaxを超えない様に、
一度に使用するHelperは14個までにしておくことが本来望ましいという意見もある
弾幕キャラの場合そうはいかない事もあるが)。


製作者特有のMUGENキャラクターの仕様について

Luchini氏製作キャラのAIを起動する方法

該当するキャラは
の9キャラです。

氏の製作したキャラクターにはAIが搭載されているものの、アーケードモードでしか起動しません。
これをウォッチモードでも起動できるようにします。

まず、それぞれのキャラのcmdファイルを開き[state -1, AI]となっているStateを探しましょう。
幾つか見つかると思います。
その全てに

triggerall = ishometeam = 1
triggerall = matchno > 1

というトリガーがあるので、この二つが機能しないようにそれぞれの頭に「;」を付けます。

;triggerall = ishometeam = 1
;triggerall = matchno > 1

これでウォッチモードでもAIが起動するようになります。
が、このままでは自分がそのキャラでプレイする時にまで起動してしまうので、
知識のある方は簡易的にでもAIスイッチを付けた方が良いです。


水影氏製作の東方キャラについて

キャラのバージョンについて

氏のキャラはいずれも動画使用時は最新版を使用するように義務付けられている。
動画撮影時には更新日時をきっちり確認するようにしよう

受身不能時の無敵について

氏のキャラは受身可能になると全身無敵になる仕様がある。
これ自体は元ゲーの仕様の再現であるのだが、氏のキャラの場合受身不能状態であっても無敵状態になることがしばしば起こる。
これは一部のキャラがfall.recoverで受身不能にしつつもfall.recovertimeを設定している、
もしくは攻撃ヒット時にHitDefのパラメーターを使わずにステートを奪って受身可能になるまで受身動作を取れないようにすることで、
擬似的に受身不能時間を設定するといった処理を行っているのに対し、
水影氏のキャラは受身不能時間が0になったら無敵になるという処理を施しているために、
受身不能時間が0になると例えステートを奪われていようと問答無用で無敵になってしまうため。
これを防止するには水影氏のキャラのフォルダ内のstate-2.cnsにある。
[State 3200, 1]
type = Nothitby
trigger1 = (statetype = A)*(CanRecover+(gethitvar(fall.recovertime)=0)>0)*(movetype = H)*(stateno != [150,159])
value = SCA
という記述を無効にするか-3ステートに移すかすればよい。
ただし前者の場合は受身可能時無敵という仕様そのものがなくなり、後者ではHitDefでfall.Recovertime=0としている場合には効果が無い。
いずれにせよこの改変を行う際にはよく考えた上で自己責任で行うように。

総体力について

氏のキャラはいずれもLIFE10000・DEF10に設定されている。
このためLifeAddでのダメージや相手体力の最大値を参照したダメージを与えるとダメージ量がおかしなことになることがある。
後述するKong氏のキャラ相手の異常なダメージもこれの一種であるため、動画で使用する際にはきちんと確認しておこう。


Kong氏製作のキャラについて

ダメージ設定について

Kong氏のキャラはいずれも相手のLifeMaxに応じてダメージが変化する仕様がとられている。
が、LifeMaxしか監視していないため、水影氏制作の東方キャラと対戦させた場合、Kong氏のキャラの火力が異常なまでに上昇し、
水影氏のキャラがほんの数ヒットで即死するという事態が起こる。
これは水影氏のキャラがLIFE10000・DEF10という特殊な仕様になっているため。
これを防止する方法はkong氏のキャラフォルダ内にある(〇〇キャラ名)_-2.cns を開き、
その中から「;Life」で検索してその直下にある、
[State -2]
type = varset
trigger1 = !var(30)
trigger1 = numenemy > 1
var(30) = floor((enemy(0),LifeMax/(100)+enemy(1),LifeMax/(100)/2))

[State -2]
type = varset
trigger1 = !var(30)
trigger1 = numenemy < 2
var(30) = floor(enemy(0),LifeMax/(100))
という記述のうちvar(30)= の部分をいずれも
var(30) = 10
と書き換える。
こうすることで相手のLifemaxに左右されないダメージが算出される。

なお、氏のキャラは『MVC2』仕様にもかかわらず&b{コンボ補正というものが一切無い。}
Var(10)がダメージにかかる係数であるので、気になる人はここにヒット数依存のコンボ補正を付けるといいだろう。
ただし多段技のダメージが補正無し前提の調整であるため、ここも弄らないと非常に安くなるので注意。

AIの空中要塞化自重方法

氏の製作したキャラにはAIがデフォルトで搭載されているが、
一部のキャラ(アイアンマンセンチネルベガMVCジェダ等)はライフが減ると空中高くに舞い上がり、
そこから遠距離攻撃ばかり仕掛けてくるという戦法を取ってくる。
MvCでは立派な戦術の一つなのだが、MUGENにおいてはその高度の敵への何らかの攻撃法を持たないキャラでは手も足も出ず、
詰み状態になってしまうことが多い。そこで、自重させる方法を紹介する。
  1. 使っているAIのcmdファイルを開く
  2. 「[State -1, testing flight atk mode]」を検索
  3. そのすぐ下の「type = ChangeState」を「type = null;ChangeState」に書き換える。
以上で完了。手順はたったこれだけなので、大会等に出したいけど強すぎて……という場合には是非試してみよう。
ちなみにこれをやってもハイジャンプ→急降下攻撃ばかりしてくるキャラもいるが、
空爆に比べればAIでも付け入る隙は大きいのであまり問題は無いだろう。

サイバーボッツキャラの勝利自爆修正方法

kong氏作の『サイバーボッツ』キャラには、本来敗北時に起こる爆発&コックピット離脱演出が敗北時に起こらず、
逆に勝利時に起こる(しかも2回)という不具合がある。
それを制御する、全キャラ共通の記述が下記。
+ 修正前
[State -2]
type = null;SelfState
triggerall = lose
triggerall = stateno != 30000 && stateno != 171
triggerall = HitShakeOver
trigger1 = Pos Y < -50
value = 30000

[State -2]
type = SelfState
trigger1 = lose
triggerall = stateno != 30000 && stateno != 171
;triggerall = HitShakeOver
;trigger1 = StateType != A
value = 171

[State -2]
type = SelfState
trigger1 = matchover
triggerall = stateno != 30000 && stateno != 171
;triggerall = HitShakeOver
;trigger1 = StateType != A
value = 30000

細かい所は省くが、大まかに言えば「試合終了時、時間切れ負け状態になっていなければ爆発する」ということなのだが、
その条件に勝利時が含まれているのが主な原因。
該当部分を下記のように修正すれば、敗北時にのみ爆発するようにすることが可能。
+ 修正後
[State -2]
type = SelfState
triggerall = stateno != 30000 && stateno != 171
trigger1 = Lose
trigger1 = var(50) = 1
trigger2 = Lose
trigger2 = TeamMode = Turns
value = 30000

[State -2]
type = SelfState
triggerall = stateno != 30000 && stateno != 171
trigger1 = TeamMode = Single || TeamMode = Simul
trigger1 = Lose
trigger1 = var(50) <= 0
value = 171

[State -2,負けフラグ]
Type = VarSet
Trigger1 = Lose
Trigger1 = Var(50) = 0
V = 50
Value = -1

[State -2, 2ラウンド以降セット]
Type = VarSet
TriggerAll = Var(50) <= -1
Trigger1 = RoundState = 2
V = 50
Value = -Var(50)


最終更新:2021年12月10日 14:28
添付ファイル