Profile

アメリ

Author:アメリ
キャラ紹介

line
カテゴリ
AIR (1)
Pos (1)
Var (1)
FAQ (1)
line
不許カウンター
line
最新記事
line
最新コメント
line
最新トラックバック
line
月別アーカイブ
line
sub_line
カレンダー
04 | 2017/05 | 06
- 1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31 - - -
line
検索フォーム
line
リンク
line
RSSリンクの表示
line
QRコード
QR
line
ブロとも申請フォーム

この人とブロともになる

line
sub_line
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
line
common1.cns、コモンファイルの指定
 ファイル名をご覧の通り共通ファイルでどのキャラクターにも必要なステートが書かれています。
kfmのdefファイルを見るとstcommon=common1.cnsと書かれていますね、これはdefファイルのあるフォルダにあるcommon1.cnsを参照すると言う意味ですが存在しない場合はMUGEN本体のdataフォルダにあるcommon1.cnsを参照します、因ってkfmは本体のcommon1.cnsを参照しています。
 コモンを調べると俺コモンや独自コモンファイルと言う言葉を見かけますが、自分で変更する事も出来ます。ゲーム全体に関わる変更はキャラクターを変更せずにfight.defやcommon1.cnsで一括して行える様になっています。キャラクター独自のコモンを持っていると言うとぱっと思いつくのは浮いているキャラクターでしょうか、それでもphysics=NにしてHitoverrideすれば必要なさそうなので基本的には食らい状態自体が異なったりしない限りはキャラクター独自のコモンにする必要は無いと思います。それに二、三カ所変える程度であればキャラのcnsで上書き可能ですしその方が互換性が高くなるので良いと思います。

common1.cnsの中身はステート定義
 中を開くとわかりますが、移動、ジャンプ、ガード、食らい等のプレイヤーが変更しなくても使えるステート定義が並んでいます。通常は変更する必要がないので見る必要が無いかと言うとそうでもありません、基本的な仕組みを理解しておかないとわからない部分も出てくると思うのでデバッグの際に見る事があると思います。
 単純に考えればそのキャラクターが使うステート定義(statedef)なのでキャラクターのステート、技と同様に理解できる必要はありますね。

common1.cnsの処理
 common1.cnsのステートの処理自体はキャラクターのステートと同様に行われますが、それとは別にMUGEN本体に特別に扱われる物が多いです。例えば着地ステートやガードステート、それに食らいステートや死亡ステート等があり、そのステートにいないと効果が現れない物が多々あります。
 表面的に書かれている事以上に重要な部分なので、使う場合は実際の動作と合わせてそれぞれ何の意味があるステートかと言うのを覚えておく必要があります。

ステート自体に意味がある物
 立ち状態の[statedef 0]、着地の[statedef 52]、ガードの[statedef 120~140]の個別、食らい開始の[statedef 5000]、死亡の[statedef 5150]、勝利や敗北等の[statedef 171,181,191]と大体こんな所です。そのステート番号にいないと効果が無い物が殆どなので、別のステート番号で似たようなことをしても駄目な場合があります。

 実はこの内容についてはmugendocsをちゃんと読んでいる方にとってはCNS formatのSpecial State Numbersに書いてある事ですので、ここで引っかかる方はmugendocs全体を必ず読んでおきましょう。

common1.cnsのステートを上書きする
 何らかのコモンステートを上書きして使いたい場合はcommon1.cnsを変更してキャラクターに付属させるのではなく、キャラクターのcnsファイルの[statedef -2]より手前に定義します。こうするとcommon1.cnsのステート定義はキャラクターのcnsで定義した物で上書きされて無視されます。
 common1.cnsを付属するのは余程互換性がないキャラクターを作るのでない限りは止めましょう。私もやりましたがよくあるガードエフェクトをつけるだけであれば[statedef -3]にtype = Explodを置くだけで大丈夫です。

勝手に処理されるステート
 着地ステートやガードステートはキャラクターのステート定義を処理した後に勝手に処理されます。
その為、意図しない無限ループに陥り画面が止まってESCキーも効かない状況になる事があります。
コモンステートには2500loopの対象外の部分があるので無限ループしてもエラーが出ない事があります。

自動的に変更されるステート
 ラウンドの開始時や終了時の切替で[statedef 0]や[statedef 5900]に自動的に変更されます。[statedef 0]はctrlがついていないと思いますが、[statedef 191]からctrl=0のまま移動してきてラウンド開始時に自動的にChangeState,value=0,ctrl=1が起こります。また、ラウンド終了時も似た様な具合に処理されています。開始時はctrl=1で判断できるのでAIを行動させる場合はここからとなります。[statedef 5900]は最初に実行されるステートでここで初期化をしているので同じように変数の初期化をしたい場合は[statedef 5900]を自分のcnsに写してやると良いでしょう。

画面が止まる、ジャンプ・着地ループ
 着地ループはphysics=Aの場合にpos y > -1やvel y < 0の場合で[statedef -2]でChangeStateしたりphysics, pos, velを再度同じ様な値に変更したりしていると起こります。これは、キャラクターのcnsのステート(技用の[statedef 1000]とか)の後に着地処理[statedef 52]が行われて、その後[statedef -2]の処理でまた同じステートに戻ってしまって着地処理に戻ると言う状態になっている事と思います。
 velocityの頁で書きましたが、そう言った物はphysics=Aで制御するのではなく出来るだけphysics=Nで動かしましょう。
 また、これはChangeState条件を常に満たしていると言う事なので単純に1個のステートでループしている場合も同じです。自分で作ったステートだけでもChangeState一つで簡単にループしてしまうので気をつけましょう。
 一応これを発見する方法としては、common1.cnsをキャラクターのフォルダに入れて着地ステートでvarを+1していきます。100回程着地処理をしたらPauseをかけてvarを見て着地処理とChangeStateをしない様にしてDisplayToClipboardでvarとstatenoの値を見るとわかると思います。このcommon1.cnsがあれば何かあった時にcommon1.cnsでループをしているかどうかすぐわかります。とは言えトリガーを全体につけるのは面倒なのでcommon1.cnsにDisplayToClipboardとPauseをするステートを作って他のコモンステートの先頭で回数とstatenoをvarsetしてChangeStateしてしまう方が良いと思います。主に終了処理の[statedef 52],[statedef 140]でしょうか。

;loop check
[state ,loop check stateno]
type = varset
trigger1 = 1
var(2) = stateno    ;statenoが取得できないステートもありますが普通はループしないので。
ignorehitpause = 1

[state ,loop check prevstateno]
type = varset
trigger1 = 1
var(3) = prevstateno
ignorehitpause = 1

[state ,loop check times]
type = varset
trigger1 = 1
var(4) = var(4)+1
ignorehitpause = 1

[state ,loop check ChangeState at times = 100]
type = ChangeState
trigger1 = var(4) >= 100
value = 999
ignorehitpause = 1

;---------- ---------- ---------- ----------
;loop stop
[statedef 999]

[state 999]
type = DisplayToClipboard
trigger1 = 1
text = "state=%d, prevstateno=%d, times=%d"
params = var(2), var(3), var(4)
ignorehitpause = 1

[state 999]
type = Pause
trigger1 = 1
time = 60*60    ;60sec
ignorehitpause = 1


実行した訳ではないので動くかわかりませんが、1000>52>1000>52の様なループを発見できると思います。


困った時には
 困った時にはkfmのステートをデバッグで確認してどのステートにいるのか調べましょう。そのステート番号が本来の正しい動作の筈です。
 そのステートを通過した事を知りたい場合はそのステートで変数に値を入れておきましょう、若しくはコモンを弄ってそこからChangeStateしないようにしてtime=1800(30秒)位のPauseをしてみましょう。この様にしてステートの移動を追跡出来れば原因はすぐわかると思います。

スポンサーサイト
line
line

line
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。