新規作成
新規ページ作成
新規ページ作成(その他)
このページをコピーして新規ページ作成
このウィキ内の別ページをコピーして新規ページ作成
このページの子ページを作成
新規ウィキ作成
編集
ページ編集
ページ編集(簡易版)
ページ名変更
メニュー非表示でページ編集
ページの閲覧/編集権限変更
ページの編集モード変更
このページにファイルをアップロード
メニューを編集
右メニューを編集
バージョン管理
最新版変更点(差分)
編集履歴(バックアップ)
アップロードファイル履歴
ページ操作履歴
ページ一覧
ページ一覧
このウィキのタグ一覧
このウィキのタグ(更新順)
このページの全コメント一覧
このウィキの全コメント一覧
RSS
このウィキの更新情報RSS
このウィキ新着ページRSS
ヘルプ
ご利用ガイド
Wiki初心者向けガイド(基本操作)
このウィキの管理者に連絡
運営会社に連絡(不具合、障害など)
MUGEN CNS WIKI CHAOS@予定
操作ガイド
新規作成
編集する
全ページ一覧
登録/ログイン
MUGEN CNS WIKI CHAOS@予定
操作ガイド
新規作成
編集する
全ページ一覧
登録/ログイン
MUGEN CNS WIKI CHAOS@予定
現在のページ名(確認用)
T-/Command
▼メニュー
●
トップページ
↓細かい報告はこちらへ
●
暫定会議室
会議室の一覧
●
用語について
●
その他・雑多
フレーム処理
●
参考ページ一覧
▼
ファイルの一覧
Def
/
CMD
/
CNS
/
State
/
Air
●
Commonステート
●
ステートコントローラー
●
トリガー情報
●
ステート技術
●
Helper技術
●
AI技術
※未作成
▼親ページ
SC-
/
テンプレ
T-
/
テンプレ
File-
AI-
※未作成
砂場ページ
表示ページの参照数
今日:
-
昨日:
-
加算が+2~3っぽいんですが…
ここを編集
更新履歴
取得中です。
新規ページ
取得中です。
ここを編集
戻る→
トリガー情報の一覧
■Command【コマンド認識】
▼概要
File-/CMDファイル
で指定したCommandに適合しているかどうかを確認。
全てのコマンド入力を認識するための記述。
Commandの中身や細かい技術については
File-/CMDファイル
のページを参照。
▼情報・書式
Command = "文字列"
;""を確認する条件式、bool型
指定したCommandの入力が成立しているなら1を、それ以外で0を返す。
入力後、成立状態はbuffer.timeの分持続する。
「=」を
「!=」にすると入力がないことを確認できる。
文字列型としては珍しく不等号式が使える。
文字列のCommandが存在しない場合
エラーで落ちる
※なお"文字列"部分は大文字小文字の区別を行う。
誤って存在しない大文字小文字の組み合わせを使用するとエラーで落ちる。
■Lv1-記述例・補足・注意点
記述例
[State -1, p]
Type = ChangeState
TriggerAll = Statetype != A
TriggerAll = Command = "x"
Trigger1 = Ctrl
Trigger2 = MoveContact && StateNo = 200
Value = 200
代表的な弱パンチ用の記述。
補足
なお
SC-/Helper
では設定のKeyCtrlを1にしなければ認識しない。
T-/RoundState
>=3、戦闘終了後はCommandを認識しない。
攻撃によるHitPause中にCommandが成立していた場合
HitPause最中ずっと1+本来のbuffer.Time計測は経過しない。
HitPauseが終わった次のフレームからbuffer.Time分らしい?
SC-/Pause
,
SC-/SuperPause
による停止中のCommandは通常と同じ。
受付は制限されないが、特殊な持続もない、とのこと
MUGEN側のAI補足
MUGEN側のAIはランダムにCommandを成立させる。
MUGEN側のAIでも一応基本コマンドとそれによるCommand判定が行われている。
基本コマンドは単一の方向キー・ボタンキーのこと
KeyCtrl=1設定の
SC-/Helper
のMUGEN側のAI入力は、
Helperと本体で別々の基本コマンドの入力を行う。
基本コマンド以外のコマンドは本体と同期している。
同じ本体を持つHelper同士の基本コマンド自体は全て同一のはず。。
注意点
攻撃によるPauseTime(ヒットポーズ)中はCommandの持続する。
そのため屈み攻撃→立ち攻撃などの連携がしずらくなる。
ヒットまでに放さないとCommand="holddown"がPauseTime中持続してしまい、
キー自体を放しても内部的に↓入れ攻撃と判定されてしまう。
対処法については
File-/CMDファイル
のページを参照。
ステート奪取
されている場合、認識するCommandが変化する。
そのため、不可能なコマンドですら成立することがある。
内容的には適応された相手側のn個目のコマンドに対応する
自分側のn個目のコマンドが入力状態になる
らしい
。
例:自分側3個目に昇龍、相手側3番目に波動の場合
ステートを奪われている最中に
波動を入力で、昇龍を認識してしまう
。
ただ「recovery」は例外的に自分側の通りみたい?
なお
リダイレクト
で相手のCommandを参照する場合も
自分側のn個目のコマンドを記述している場合、
相手のn個目にあるコマンド入力に対して反応する。
同キャラなら同じコマンド。自身の
SC-/Helper
なら問題ない。
上記の理由により、
-2ステート
にCommandを配置してはならない。
同様理由で
HelperからRoot,
リダイレクト
でのCommandを認識もしてはいけない。
また奪ったステートをHitPause最中に返すことも危ない。
あとbuffer.timeは奪った側の基準とのことで
buffertimeを2以上にすると暴発する危険がハネ上がる。
Enemy,Command="holddown"なども不可。
仕組みについての考察は後述。
File-/CMDファイル
のページも参照
なおトリガー情報としては処理がやや重め。
1フレームに数万回レベルで読み込みを行うと処理落ちが発生する。
AI制作時の注意点
AI用にはAI起動時に不可能Command認識でのAI起動をする程度。
起動後はCommandを基本的に無視する。
ステートを奪われている状態
で特定のCommandを要求されても対応できない。
Recoverに限り、AI専用の仕様にすることで確実な最速反応も可能だが。
その場合、止めること・ディレイすることは不可能。
+
■
ステート奪取
・
リダイレクト
に対応しないCommand処理の推測
Command処理の推測
コマンド成立情報は基本
File-/CMDファイル
の記述順でコマンド成立状態のフラグ
を保存している。
つまりそれは基本「××のコマンドが成立しているかどうか」ではなく、
「n番目のコマンドが成立しているかどうか」
でフラグ管理されているということ。
そして情報のCommandでは
対応するn番目のコマンド情報が成立しているかどうか
を確認する。
例えば
10番目に"hadou_a"
というコマンドの定義が記述されている場合、
そのキャラのCommand="hadou_a"で
10番目の情報を確認
する処理を行い、
10番目のコマンド定義(この場合"hadou_a")が成立すると10番目の成立フラグが立つ
わけである。
リダイレクト
で対応するn番目のコマンドを認識するのはそういう理由。
ステート奪取
をされた場合、
コマンド定義自体がほぼ全て相手側の定義に差し替わる
ため、
単純に対応するn番目の情報を確認するCommand条件が暴発してしまうわけである。
なので
-2ステート
にCommand条件を置いたり、
SC-/Helper
から
リダイレクト
でCommandを参照したりしないこと。
例外のrecovery
Command="recovery"(
空中受身用コマンド
)だけは
例外として
定義の記述順に関わらずrecoveryのコマンドで認識を行う
上、
恐らく
常にキャラ側の定義で処理を行う
みたい。多分。
他の必須コマンドは確かめていないが、aやholddownは対応していない模様。
「Command」をウィキ内検索
最終更新:2015年09月28日 22:57
|
ログイン
|