MUGEN CNS WIKI CHAOS@予定
http://w.atwiki.jp/mugencns/
MUGEN CNS WIKI CHAOS@予定
ja
2023-03-11T04:10:17+09:00
1678475417
-
トップページ
https://w.atwiki.jp/mugencns/pages/1.html
&font(20,b){『mugenの謎仕様は仕様の数だけあるみたいです…』}
----
MUGENのCNS仕様をまとめたいWIKIです。
主な目的はステートコントローラー一覧・トリガー一覧とかに載っていない
ステート内の細かい仕様・注意点などをまとめるためのwikiです。基本的なこともまとめたいです。
なお、凶悪系については専門外です。専門のwikiへどうぞ。
CNS以外のことについてはまとめない方向です。AIについては微妙。
SFF,SND,AIR系については補足程度。
----
-※''現在、編集はメンバー限定です''※
-(2019-04-22)※積極的な更新は停止状態ですが、何か報告があれば対応しています。
-(2023-03-11)※広告消し用の更新です
***何かありましたら[[暫定会議室]]の方へどうぞ。
***■2019-09-07 遅いですが一応の報告
アットウィキサービスが2019年7月19日からサービス全体のURLの変更処理を行ったとのことです。
以前はwww49.atwiki~から始まっていたのが、w.atwikiとなっています。
旧URLからでもリダイレクトによって閲覧可能ですが、リンク・ブックマークの変更等をお願いしますとのこと。
----
#region(■2015-05-02 メモ:HelperのGetPowerバグの対応策案・※実用性低め)
***■2015-05-02 メモ:HelperのGetPowerバグの対応策案・※実用性低め
同じスロットIDに一個前にいたHelperのチームサイドが自分側である、というのを確定させる方法。
-基本処理:ABを同時射出して、Aを消した直後にBからCを出してAのスロットに差し込む。
--処理対応1:全体のHelperの数を数えて、Aで確認させ処理を調整する。
--処理対応2:総数確認後、AからDを射出して[[T-/ID]]を確認しHelperの射出状況を監視する。
--処理対応3:Helperの数が変わっていたりIDが変動してたりする場合はEを射出し推定空白を埋める。
以下詳しい内容
+ヘルパーA・ヘルパーBを記述を連ねて同時に射出する。
+[[T-/NumHelper]]と[[リダイレクト]]を用いて、本体全員のHelperの数を数える。
+ヘルパーAでも本体全員のNumHelperの数を数える。もし異なる場合はそれに対応する。
+その前にヘルパーAからヘルパーDを射出し、ヘルパーDの[[T-/ID]]を確認する。
+ヘルパーAとDの[[T-/ID]]の差がA+2=Dである場合とそうでない場合で分けて考える。
++[[T-/ID]]の差がA+2=Dである。
+++総ヘルパー数が減っていた場合、ヘルパーEを減少分射出して埋める。
+++総ヘルパー数が同数だった場合は射出しない。増えている場合は無い。
++[[T-/ID]]の差がA+2<Dである。
+++総ヘルパー数が減っていた場合、D-(A+2)にヘルパー減少分を足した数のヘルパーEを出す。
+++総ヘルパー数が同数だった場合はD-(A+2)の数値分ヘルパーEを出す。
+++総ヘルパー数が増えていた場合、D-(A+2)にヘルパー増加分を引いた数のヘルパーEを出す。
++ヘルパーEを出さなければいけない数が膨大な場合は射出を控えたほうが良い。失敗と考えても良い。
+ヘルパーAからヘルパーEを上記の数射出した後、ヘルパーAを[[SC-/DestroySelf]]で消す。
+ヘルパーBからヘルパーCを射出した後[[SC-/DestroySelf]]で消す。
+ヘルパーD・ヘルパーEは残す必要が無いので[[SC-/DestroySelf]]で消す。
+ヘルパーCで処理を扱う。
実際に確認したわけではないので不備あるかもしれません。
かなりヘルパーを大漁に出し入れする関係上ヘルパー総数上限に達する危険があります。
同一の処理が重なってしまった場合は特にその状態が発生しやすく、他のバグを引き起こす可能性があります。
そのため、途中ヘルパーEの数が膨大になる場合は失敗とみなしてしまっても良い。
中断する可能性がある以上1F刻みに精確な処理を行わなければいけない処理には実用性に欠けます。
-E射出数の内容
--ヘルパーが減っている=その分空白が生まれている可能性がある。
--ヘルパーが同数だがIDは増えている=ヘルパーが増えた後に減っていた場合、空白が生まれている可能性はある。
--ヘルパーが増えている+IDが増えている=↑の方式で生まれる空白の数がヘルパーの増加分だけ減る。
+■■■■ABD > A+2=D = 射出不要
+■□□□ABD > A+2=D&ヘルパー減少 = ヘルパー減少と同数射出が必要。
+-※消えたのがABよりも後ろ側のスロットIDのヘルパーで穴埋めが必要無い可能性も一応あるが確認はできない。
+■■■■■AB■■■D > A+2<D&ヘルパー増加 = D-(A+2)-ヘルパー増加数が0なら不要。
+■■□□■AB■■■D > A+2<D&ヘルパー増加 = D-(A+2)-ヘルパー増加数の数だけ射出が必要。
+■□□□■AB■■■D > A+2<D%ヘルパー同数 = 同上=D-(A+2)の数射出が必要。
+□□□□■AB■■■D > A+2<D%ヘルパー減少 = D-(A+2)+ヘルパー減少分の数だけ射出が必要。
+-※こちらも後ろのスロットIDが消えただけなら不要だが、確認はできない。
-&s(){要は&b(){「 D-(A+2)-(本体確認Helper数-A確認Helper数) 」}の計算式でEを射出する。}
-要は&b(){「 (本体確認Helper数-A確認Helper数)+(D-A-2) 」}の数、Eを射出する。
--ただし計算した数値が本体確認Helper数を上回っている場合は、本体確認Helper数を上限して引き下げる。
--あ、D射出してる分があるからE射出は1個少なくていいのか。と言うよりA確認Helper数はD射出後でいいか。
#endregion
**■2015-04-30 重大な解説修正・Helperが受けた時のGivePowerバグ
''Helperのゲージの紐付けの不具合による、攻撃のGetPower,GivePower、TargetPoweAddの対象異常バグ''と判明
&font(20,b){[[SC-/Helper]]での[[SC-/HitDef]][[SC-/ReversalDef]]のGivePowerについて}
&font(20,b){再検証の結果、HelperのHelperTypeがPlayerであれば機能する場合があると判明。}
&font(20,b){ただしこちらもGetPowerの対象バグ同様に、GivePowerの対象は攻撃を受けたHelprの&br()「一個前に同じ[[スロットID]]にいたHelperのチームサイド側になる」というバグがあります。}
&font(20,b){下記(2年前)の検証での「受けれない」というのは上記仕様による勘違いでした。}
&font(20,b){また、どうやら[[SC-/TargetPowerAdd]]も上記バグが存在している模様。}
&font(20,b){バグをどうしても回避するとなったらGivePowerを=0,0にし、TargetPowerAddで管理、&br()TargetPowerAddにTarget,Ishelper=0を入れヘルパー相手には発動しないようにする。}
&font(20){※ReversalDefによる判定は未調査です。}
なお自身のゲージを変更する[[SC-/PowerAdd]][[SC-/PowerSet]]や、
StateDefのオプションPowerAdd、[[SC-/SuperPause]]のPowerAddはHeleprであっても問題なく機能する模様。
**■2013-04-25 報告
-Winまでの''基本的なステコン・トリガーのページを埋め終わりました''。
--が、Helper技術やAI技術など''細かいページはまだ未作成・作成中''です。
--現在もまだ編集はメンバー限定(単独)です。
-突貫で埋めただけなので足りない情報や間違いなどは[[暫定会議室]]へお願いします。
**方針メモ
-とりあえず(Win版までの)ステコン・トリガーのページを埋めました。
--新規は[[SC-]]と[[T-]]とかを参照。それぞれの下層ページとして作成する。
--なお使用例は「実際に使われそうな記述例」で。通常使わないパラメーターは省略する。
--あとページ右側の下部に新規ページの欄があります。
-作成途中のため、存在しないページへのリンクが多々あります。
-現状、Win版を基本として書いています。1.0(新mugen)やDos版は不十分かと。
-CNSのことがメイン。キャラそのものの解説は不可の方向で。
-引用は最小限に。CNSシステム系の引用は参考元を明確にする。
//可能な限り許可を取る。
-細かいことは[[暫定会議室]]へ。
-方針がガチガチっぽく見えるかもしれませんが、わりとゆるめです。ゆるくのんびりいきましょう。
--早いと確認しきれなくて困る。
:■重要|
-書かれている仕様の解説と実際の仕様が異なる疑いがある場合
--話し合ってしっかり検証しましょう。検証した上で説明を正す必要がある場合は正します。
--正すときにページの最上部に修正した日付と修正した箇所を明記しましょう。
-細かい情報の修正でも確認をとった上で修正したほうがいいです。意思疎通大事。
--特に他の場所でこう書かれていた~というのは怪しいです。検証しないと確定しません。
--可能な限り検証した上で情報を修正しましょう。
#region(情報修正の書式@予定)
----
:※解説修正情報※|
●&font(12,b){日付:修正部分の概要}
●&font(12,b){日付:修正部分の概要}
----
何個か溜まってきた場合は、古い情報をページ下部へ移動しましょう。
----
:※解説修正情報※古い履歴|
●&font(12,b){日付:修正部分の概要}
----
#endregion
:regionと押し出しについて|
-「region」の格納と「:|」の押し出しは少し相性が悪いみたい。上手く折り合い付ける。
--Regionの直後の行に:|を入れない。(1行以上開ける)
--EndRegionは:|範囲に入れない。(1行以上、空白行で開ける。)
:■基本の形式|
-ページの作成は「アットウィキモード」にすること。
-「**」見出し・「*」大見出し、「:|」のまとめ、「-」リストを駆使する。
--使い過ぎて見づらくならないように注意。
-情報に関してはLvを想定し、Lvごとに分けて記述する。
--■Lv0-基本的な使用に関する情報
--■Lv1-基本的な記述例・補足・注意点
--■Lv2-バグなどへの基本的な対処法。(Lv1~3とややごっちゃ)
--■Lv3-細かい複合応用について。(バグ回避とごっちゃになることも。)
--■Lv4-バグ応用(基本的なキャラでは利用しない技術)
---Lv3~4についてはregionで情報を格納する。記述が長いならページ独立もあり。
---なお凶悪系技術については通常のキャラで使い様がなければ概要だけの説明にとどめること。
-Lv2-バグ回避について
--簡単なことならLv1の注意点に記述しても良い。
--煩雑になる回避法の場合はLv3で格納して管理する。Lv2には誘導を。
--一個のCNSシステムとして長くなりそうなら別にページを作るのもあり。
-細かくはすでにあるページを参考に、それらしく調整してください。
:■基本の文体|
-長い文章は避ける。
-無理そうなら長い文章でも構わない。改行についても環境に左右されることも踏まえて無理に改行せずキリがよさそうな改行を心がける。
-このようにリストを駆使してある程度細かく分けていく。
-「:|」による文章の押し出しを活用し、わかりやすくまとめる。
--ただし「:|」はプレビュー表示がうまくいかないので、確認はページを保存して確認する。&br()なんなら[[砂場ページ]]を利用する。
-Cnsの記述は&font(b){&nowiki(){ #aa() }}AA用のプラグインを使う。
-まとめた条件式などがプラグイン感知でうまく表示されない場合は&br()&font(b){&nowiki(){ &nowiki() }}NoWiki(プラグイン処理抑制プラグイン)を使う。
-編集をしたら変更点を差分で再度確認。変なところをいじってないか確かめる。
----
&font(20,b){『mugenの内部処理はカオスを煮詰めて圧縮して発酵させたような地獄だ。』}
----
//コメントアウト保存
//
//**■2014-12-04 重要な検証・DefenceMulなどの補正値について
//処理を[[SC-/DefenceMulSet]]にまとめました。
//重要な点の要約は[[ダメージ]]のページを参照してください。
//
//**■2013-06-02 重大な解説修正・GetPowerバグ
//&font(20,b){[[SC-/Helper]]での[[SC-/HitDef]][[SC-/ReversalDef]]のGetPower,GivePowerのバグについて}
//&font(20,b){再検証の結果、Helperでの攻撃判定のGetPowerの対象が常に&br()「一個前に同じ[[スロットID]]にいたHelperのチームサイド側になる」というバグと判明。}
//&font(20,b){Get,GiveバグのHelperの[[SC-/DestroySelf]]での解決は上記仕様による勘違い。}
//&font(20,b){解決法は無くGetPower=0,0指定にし、[[SC-/PowerAdd]]で増加分を管理して対処すること。}
//&font(20,b){可能であれば本体管理になる[[SC-/Projectile]]置き換えでも良い。}
//&s(){&font(20){GivePowerについて上記に関するバグはないが、[[SC-/Helper]]が受けた分は得られない。}}
//&font(30,b){※バグがありました。上記参照}
//
/////
//
//**■2014-10-28 重大な話・Targetステコンの制御について
//&font(30,b){ステートを奪えるみたいです。}記事再度直します。
//↓の検証は、「''Helperに対して''」での検証であり、''Helper相手の場合はステートを奪わない''ようです。
//
//**■2014-10-28 重大な解説修正・Targetステコンの制御
//&font(b){[[Target]]系ステートコントローラーの制御}について
//&s(){検証により、[[SC-/TargetFacing]]と[[SC-/TargetDrop]]以外のTargetステコンの発動は}
//&font(16,b){%%相手の状態によっては影響を与えられなくなると判明%%}
//%%具体的にはfacingを除くTargetステコンは%%
//&font(18,b){%%1.『ガード以外のやられ状態のTarget』と%%}
//&font(18,b){%%2.『ReversalDefを当てたTarget』だけに影響する。%%}
//%%タッグ時など用に&font(16,b){「ガードした相手を弾く」といった処理は必要ない}と判明。%%
//&font(16,b){%%ただし、ガード・ヒットの区別が不要なだけで、%%TargetStateの扱いには要注意。}
//%%なんで今の今まで気づかなかったんだろう…。%%
//:管理人|
//ADI
2023-03-11T04:10:17+09:00
1678475417
-
コメント/暫定会議室
https://w.atwiki.jp/mugencns/pages/40.html
-とりあえずSC,TをSC-,T-に変更する。 -- 名無しさん (2013-01-10 21:12:14)
-文字が小さい上に、白背景で目が痛いなぁ…。丁度いいデザインもないし・・ -- ADI (2013-01-11 04:21:12)
-デザインを調整して、光度を抑える。不満としてはコメント欄とかの調整項目がわからないこと。 -- ADI (2013-01-11 04:39:57)
-会議室のコメントの形式を変更ー - ADI 2013-01-13 00:48:57
-ここの編集権限を誰でもに変更しておく。 - ADI 2013-01-16 23:27:54
-いや、誰でもにする必要はないかな - ADI 2013-01-17 00:19:05
-一通りページが揃ってきたので、メンバーを募集しようかと思いつつ、踏み切れない。 - ADI 2013-01-18 23:11:49
-このペ^ースでいくと、粗方のページが揃うまで1~2ヶ月はかかりそう。 - ADI 2013-01-21 20:03:01
-細かい情報提供についてもここにコメントを入れてもらってもいいかな。とりあえずは - ADI 2013-01-25 00:17:56
-メニューをちょい編集。 - ADI 2013-02-02 12:25:02
-細かい技術の話も適当にまとめたいかもなぁ - ADI 2013-02-03 12:56:03
-Win版までのトリガー情報を一通り揃え終える。wiki作成から一ヶ月です。 - ADI 2013-02-08 16:50:33
-最近全然手付かずですね。忙しいわけでもないのですが…。 - ADI 2013-02-26 22:26:56
-Explodの項のPauseTimeの影響についてですが、Ignorehitpauseを省略ではなく=0を記述するとPauseTime中animの再生が停止したはずです。 - BK 2013-03-31 17:38:29
--なるほどー - ADI 2013-04-03 01:32:18
-とりあえずですが、ページ作成は終わりましたー。ミス報告などあれば、ここにお願いします。 - ADI 2013-04-25 20:01:11
-hitdefのpalfx系、sinaddとcolorとinvertallも使えるみたいです - ワープスター 2013-05-14 23:09:12
--と言うことはPalFXのパラメーター全て使えるってことかな? - ADI 2013-05-16 00:22:00
---確認して追記しました~。 - ADI 2013-05-16 00:38:31
-Projectileですが、AfterImage.Time=XXXといった風にAfterImageのパラメータを記述するとProjectileに残像が付けられるようです。 - BK 2013-05-16 17:57:44
--はい情報ありがとうございます~。AfterImage.XXXで、AfterImageパラメーター全て使えるのかな調べないと - ADI 2013-05-16 22:42:35
-編集の事情とかわからないんでとりあえずここに。OwnPalを省略したヘルパーでPalFXを読んでも効果がなく、OwnPal = 1をつけると効果が現れることを確認しました。 - スケルトン 2013-06-23 21:43:24
--ご報告どうもありがとうございます~。その辺り検証的な確認はしてなかったけど、製作途中でそれらしいとは分かってたので書き忘れて放置してたかんjぢえすけど。 - ADI 2013-06-24 01:58:30
---今確認したら既に[[SC-/Helper]]のページではそのことが書いてありましたね… - ADI 2013-06-24 02:04:33
-sysvarのページで記述例がsysvar(23)となっています。 - 名無しさん 2013-12-13 01:52:39
--ご報告有り難うございます~ - ADI 2013-12-16 20:55:12
-ProjectileのPausetime(Hitdefで使える物と同様の物)はPausetimeで、自分側にPauseをかけた場合以下の仕様を確認しました。■ProjHitsが複数である場合、ProjHitmissTimeが1でもPauseTime分次の攻撃が当たらなくなる。細かい仕様は検証してみないと分かりませんが、とにかくProjMissTimeが使いにくくなる。■ProjRemove=0で、かつProjRemoveTimeが設定してある場合PauseTime分消失が遅れてしまう。現状見つけた仕様はこれだけですが、他に何か変な仕様があるかもしれませんので、Projectileを使う場合PauseTimeを自分側に(相手側は平気)設定しないように(0にするように)書いたほうが良いかと存じ上げます。なお、Guard.PauseTimeは確認しておりませんが恐らく同様の仕様がある物と予測されます。 - ワーキペレウ 2014-10-10 18:24:48
--訂正:ProjHitmissTime⇒ProjmissTime - 名無しさん 2014-10-10 18:25:47
---検証情報ありがとうございます~。状態としては【Proj自体にPauseTimeの停止処理が発生する】と思って良いみたいですねぇ。 - ADI 2014-10-11 17:31:45
-いまさらガード・ヒット同時に対するTargetState処理を再検証し、ガード相手にTarget系ステコンが機能しないということが本当に今さら判明。 なんで詳しく検証しなかったんだ私。 - ADI 2014-10-28 06:12:42
-- あるえー?!!!?!!?!?!?! ガード相手に機能するケースあるやん!!! 要再検証! - ADI 2014-10-28 06:15:29
--検証の結果Helperの場合、ガードした相手にTargetステコンが機能しない、という状態だった - ADI 2014-10-28 07:26:56
-fall.defense_upについて、ここに書いていなかった仕様があります。それは「DefenseMulSetを実行中のキャラクターには適用されない」という、非常に困ったもの。Elecbyteは何故こんな仕様を作ってしまったのか。 - 京太郎 2014-12-02 20:40:49
--細かい事だけどもう少しありました。5070に来た場合でも1fも留まらなければ防御力は上がりません。ステート奪取によって5070にされた場合は上がります。 - 京太郎 2014-12-02 21:08:26
---5070でしか検証していませんが5100も同様かと。 - 京太郎 2014-12-02 21:10:28
---「ステート奪取によって〜」が紛らわしい書き方になってしまいました。この場合でも1fは必要です。自分のステートでなくても適用される、ということを書きたかったのです。 - 京太郎 2014-12-02 21:15:32
--DefenceMulの仕様について>そういえば思い出したので調査した所、 ''【DefenceMulの設定値はMoveType=HとPauseTime中(攻撃当てた側含む)の時だけ保持・適応される】''というもので、反対に言うと''【MoveType=HとPauseTimeの間はほぼずっと(リカバリー(?)・起き上がり除く)、DefenceMulSetで一度設定した値が適応され続ける】''ようです。 また、この仕様から推測できますが、ダウン時の処理は「現在のMul設定値に対して倍率による変更を行う」であり、Mulsetで1.5に設定されていれば、defence_up設定50で、1倍に戻るという処理。もちろんdefence_upの後にMulSetをすれば完全に上書きされ、そのあとdefence_upしても累積値ではなく現在のMulSetに対する変更となります。- ADI 2014-12-04 06:25:44
---自分が検証した相手は常時監視ステートで毎フレームDefenseMulSetを実行していたので、それでfall.defense_upが効いていないように見えたという事ですね。とりあえず言いたかった事は、こちらの攻撃力を上げてfall.defense_upに対抗しようという方法が取れないという事です。根性値とかいって常時監視ステートで扱っているキャラクターが多いので。 - 京太郎 2014-12-04 08:10:16
----色々書き直します~ - ADI 2014-12-04 08:22:18
-Explodについて。ステージ拡大縮小に伴う拡大縮小はpostypeがp1p2(プレイヤー基準)とそれ以外(画面基準)で異なります。 - 京太郎 2014-12-02 21:31:31
--win版だと変わらないようですね。1.1での話でした。 - 京太郎 2014-12-03 05:47:18
-誤解がありそうなので補足。二番目のコメントは「プレイヤーのz座標を0以外にした場合」の事です。win版にはアクティブな拡大縮小機能がありませんからね。 - 京太郎 2014-12-03 06:06:47
--書き込み位置間違えました。「二番目」とはExplodについての二番目のコメントです。 - 京太郎 2014-12-03 06:10:34
---1.0以降については持っていないので検証できません~。ひとまず適当に書いておきます - ADI 2014-12-04 09:38:49
-HitDefの小ネタ。attrが投げ(T)属性の場合はguardflagを省略するとガード不能になります。和訳kfmでguard.dist=0が原因と解説されているのは誤りのようです(InGuardDistでなくてもガードコマンドが入っていればガードは可能です)。 - 京太郎 2014-12-03 19:43:07
--投げ属性についてもう一つ。投げ属性をHitさせた側のpausetime中は食らい側が無敵になるようです。タッグでは未検証なので相方の攻撃は当たるかもしれません。 - 京太郎 2014-12-03 19:55:55
---相手が無敵になるというよりはこちらの攻撃が当たらなくなるといった方がいいかもしれません。 - 京太郎 2014-12-04 08:26:38
----投げ属性についてちらの検証ではAttr属性に関わらず【GuardFlag省略=ガード不可】でした。また投げ属性によるPauseTime適応中でも、その他の攻撃が命中しました。 検証環境はwinで、素KFMの200番書き換えです。 - ADI 2014-12-04 09:36:14
-----「Hitさせた側の」pausetime中です。例えばパンチを当てた硬直中には当てた側の飛び道具やストライカー が当たらなくなるという意味です。前者については後で調べてみます。 - 京太郎 2014-12-04 12:15:54
------ああ、読み間違えてました。確認した所、T属性の攻撃を当てると【'当てた側のPauseTime適応中は、当てた方・くらった方の両方が判定枠のデバッグ表示の無敵標記がMUTEKI=完全無敵''】になってますね。 - ADI 2014-12-04 16:18:47
-----確かにguardflagを省略するとガード不能になるようです(どこかでコピーしてきたステートコントローラ一覧にある記述が誤りだったようです)。 - 京太郎 2014-12-04 18:43:41
-----投げ属性の攻撃について新発見をしました(まだ詳しく調べてはいませんが)。HitDefのトリガーをtrigger1=1の単一トリガーにすると攻撃判定が出ている全フレームがヒットするのはご存知でしょうが、投げ属性の場合はヒットした次のフレームの攻撃がスカり、そのまた次のフレームの攻撃は当たる…つまり「hit,miss,hit,miss....」という結果になりました。 - 名無しさん 2014-12-04 18:51:46
------次のフレームには無敵が持続していた、ということのようです。特に新発見というほどのものでは無かったようですね。 - 京太郎 2014-12-04 18:59:09
-HitdefのページのGuard.distの項目にて「SC-/AttackDistで調整する場合、Hitdefの後ろの行に入れるべき?」とありますが、InGuardDistは相手のMoveType=Aに反応するのであってHitdefが定義された事に反応する訳ではないので気にする必要は無いようです。 - 京太郎 2014-12-04 19:20:59
--ただし、SC-/AttackDistとHitDefのGuard.distを両方設定すると後に定義された方が前の定義を上書きします。無論、SC-/HitdefのGuard.distもSC-/AttackDistも無い場合にはT-/Const(size.attack.dist)が参照されます。 - 京太郎 2014-12-04 19:52:20
---SC-/HitdefのGuard.distが省略されるとまずSC-/AttackDistの定義が参照され、それも無い場合にはT-/Const(size.attack.dist)が参照されます。SC-/AttackDistは実行されたステート内に限り、T-/Const(size.attack.dist)に取って代わる、と言えるかもしれません。 - 京太郎 2014-12-04 20:00:08
----説明下手ですいません。SC-/HitdefのGuard.distによる定義とSC-/AttackDistによる定義は等価であり、最後に定義された値がT-/Const(size.attack.dist)に代わって使用される、というのが適切な表現かもしれません。 - 京太郎 2014-12-04 21:10:06
--【''初期値としてCNS設定値が入っており、HitDefでのGuard.dist省略時は変更しない。HitDefのGuard.DistやAttackDist命令で変更した場合ステート変更まで維持される(?)''】という感じかな。 - ADI 2014-12-04 22:20:11
-攻撃側のMoveTypeがAになるのと同じフレームにヒットする攻撃はガード不能になります。例えば1F目で発生する攻撃は1F目がガード不能。ただし1F目発生の攻撃でも攻撃側のそのステートに移る1F前がMoveType=Aになっていれば防御側が一度もInGuardDistにならなくともガード可能になります(InGuardDistでガードさせるAIはガードしませんが)。 - 京太郎 2014-12-04 19:37:15
--相方no - 京太郎 2014-12-04 20:05:19
--ミス。タッグで1F前に相方がMoveType=Aになっている場合も1F目発生攻撃がガードされるようになるようです。シングルで1F目発生攻撃をガードさせたい場合、Attack.distが0でMoveType=Aのヘルパーを常駐させると良いかもしれません。 - 京太郎 2014-12-04 20:09:27
---ただしやっぱりInGuardDistを用いてガードするAIにとってはガード不能も同然です。1F目発生攻撃は投げ限定にするのが良いでしょうね。 - 京太郎 2014-12-04 20:14:22
---あと、1F目からヒットする飛び道具を発射する場合、発射フレーム以前に発射元のMoveTypeをAにしておくべきです(そもそも本体をMoveType=Iにして飛び道具を出していたら見つかった現象なのでした)。 - 京太郎 2014-12-04 20:50:52
--その辺りについては[[発生1F目攻撃の弊害 ]]にまとめてあります。もうちょい他からのリンク追加したほうがよかったか。 - ADI 2014-12-04 22:27:45
-StatedefのオプションにおいてPhysicsを省略した場合、Physics=Nになるというのが自分の結論ですが、省略しない方が良いと書かれているのは何故でしょうか? - 京太郎 2014-12-04 21:00:50
--Physics自体が重大なパラメータで、通常のキャラのステートとしてSCA以外を用いるということが特殊な処理であるためです。まあ、「省略しない方がよい」は記述管理するときに失念しにくいように、という意味合いですけど。 - ADI 2014-12-04 22:41:38
-ステートの書き方について。各ステートコントローラの先頭に書く[State XX]はXXの部分は何でも良いようです(日本語だろうと何も書かなかろうと)。それで[State(半角スペース)だけでも行けるか?と思って試した所、エラーは吐かずMUGENも落ちないけれど挙動がおかしくなりました。つまり最低でも[State ]が必要なようです。 - 京太郎 2014-12-04 21:24:49
--[State XX]のXXに日本語が使えるのはWin版以降という記述をどこかで見たような…というわけでDOS版はまた違うかもしれません。 - 京太郎 2014-12-04 21:28:28
--そうですね。 - ADI 2014-12-04 22:50:44
-File-/CNSファイルのページのfall.defence_upについて「上昇のタイミングは5070,5100ステートの!Timeでそのキャラ処理終了時点。 キャラの処理終了時点なので、その後のキャラがすぐSC-/TargetStateをしても上昇している。」と書いてありますが、Hit時に即座に相手のステートを奪う処理(トリガーはignorehitpause=1,trigger1=target,stateno=x←本来の硬直中ステート番号)をさせてfall.defence_upを無視しようとした場合、こちらが1P側でも2P側でも同じダメージになりました。原因としては「fall.defence_upはキャラクター全員の処理が終わってから適用」か「食らい側(MoveType=H?)の処理はプレイヤーIDが小さくても後回しにされる」か「攻撃側(MoveType=A?)はプレイヤーIDが大きくても先に処理される」が考えられます。 - 京太郎 2014-12-04 22:03:37
--検証の為にSC-/TargetStateを攻撃側射出のヘルパーに実行させた場合でも同じダメージが得られました。 - 京太郎 2014-12-04 22:14:52
---「SC-/TargetStateを攻撃側射出のヘルパーに実行させた」というのは本体でやっていた攻撃をヘルパー分身にさせた上でです。 - 京太郎 2014-12-04 22:33:32
---処理順についてはスロットIDのページに記述がありましたね(MoveType=Aが先)。それならMoveTypeを変えない限りは1F目でTargetStateすれば間に合いますね。 - 京太郎 2014-12-04 22:53:43
----というかそもそもMoveTypeを変えてもヒット1F目の初期状態はMovetype=Aなのだから意味が無いか。 - 京太郎 2014-12-04 22:58:32
--キャラの処理順については[[スロットID ]]に書いてある通り、 MoveType=Aga - ADI 2014-12-04 22:54:26
---ミス。 【Movetype=Aは処理が優先される】>です。 - ADI 2014-12-04 22:55:25
-詳しい事は不明ですが、SC-/HitOverride中の相手にHitOverride対象属性の攻撃をヒットさせた場合、T-/MoveContact(とMoveHit)は一瞬(1F?)だけ1になりますがT-/NumTargetは0のままのようです。 - 京太郎 2014-12-04 22:42:38
--HitOverrideに対して攻撃を当てた場合はMoveHit等は''通常のヒット同様にカウントされる''はずです。特に明記してませんでしたが。 ただ''HitOverrideが発動した場合はTargetを取得することが出来ないのでNumTargetは0のままです''>[[Target]] - ADI 2014-12-04 23:02:47
-とりあえず一段落。京太郎さん色々とありがとうございました。 - ADI 2014-12-04 23:56:51
--どういたしまして。それにしても仕事速いですね。恐れ入りました。 - 京太郎 2014-12-04 23:59:55
-ConstantsやPlaySndにおけるvolumeの上限下限は分かりますか? - 京太郎 2014-12-06 21:05:27
--それらの上限下限は分かりませんね。mugenの説明書にも無いです。 ただ、同系統の情報として、mugen.cfgのVolume(基本ボリューム?)は0~255、ステージ用のVolumeは-255~255とされてますので、もしかしたらその辺りかもしれません。 - ADI 2014-12-06 22:29:59
-ありがとうございました。 - 京太郎 2014-12-07 00:06:11
--playSndでちょっと調べてみましたが、多分-255~255であってるようです。 - ADI 2014-12-07 00:26:07
-普通は割とどうでもよい事かもしれませんが、Ctrl=1の場合のmugen側の処理はStateTypeだけではなくMoveTypeも関係あるようです。例えばガード待ちステート(130&131)はMoveType=Iでなければ具合が悪いようです。また、Ctrl=0でも着地(52)はデフォルトでは立ガードが可能ですがMoveTypeがI以外だとガード不能になります。 - 京太郎 2014-12-14 13:52:45
--StateNo=52でのMoveType=I,Aでのガード不能については確認しましたが、ガード130,131での不具合については分かりませんでした。 - ADI 2014-12-16 22:51:42
---普通のキャラクターで確認したところ130でMoveType=Iでない場合は歩き(20)との間を往復してしまうようです(SC-/AssertSpecialのnowalkを使えば普通と同じようになるので)。131&132はステート移動が起こらず問題ありませんでした。 - 京太郎 2014-12-17 00:22:53
----ああ分かりました。ガード関係で130版にいる場合の持続処理~について書いてませんでしたね。 - ADI 2014-12-17 10:34:16
-Constの記事に正Const(Size.Head.Pos.Y)が誤Const(Size.Head.Pos Y)になっているようです。 - 名無しさん 2015-01-03 05:24:48
--ご報告ありがとうございます~ - ADI 2015-01-04 13:47:31
-ヘルパーがgivepowerの影響を受けない件ですが、どうやらヘルパータイプがplayerだと影響を受けるようです - 名無しさん 2015-04-29 22:38:21
--調査してみたところ、上手くいかず寄り精査した所、確かにHelperType=PlayerだとGivePowerが発生するようなのですが、こちらで更に調査した所どうやらこちらも【''同じスロットIDに一つ前に存在していたチームサイド側がGivePowerを受け取る''】という仕様なようです。情報ありがとうございました。 - ADI 2015-04-30 14:56:16
-SC-/LifeAddのabsoluteの項目に「1に指定した場合キャラの防御力で減少量が変化する。」とあるのは誤りではありませんか? - 京太郎 2015-05-24 22:04:26
--ご報告ありがとうございます~ - ADI 2015-05-26 21:47:26
-changeanim2の説明にsffは相手のものを参照すると明記しておいた方がいいかと思われます - 名無しさん 2015-09-09 19:48:10
--確かにそうですね。編集しておきます。 - ADI 2015-09-10 00:59:23
-cnsの記述は和訳kfmを参考にしたのになぜかcnsファイルが原因で、defファイルが読み込めないとmugenでエラーが出てしまいました。どうすればいいですか? - 豆大福 2015-09-21 10:56:29
--分かりません。少し試した辺りではCNS記述の中に欠けがある(あるいは誤字脱字がある)場合はdefファイル名を表示したエラーが発生するようなので、コチラで推測できる範囲ではもしかしたらCNS記述の中に間違いや欠けがあるのかもしれません。 - ADI 2015-09-22 01:29:41
-解決しました。ありがとうございます。それから、空中ダッシュと空中バックダッシュがコマンドを受け付けなくて困っています。cnsとcmdの指定したステート番号、それぞれの記述は合っているのになぜか空中で指定しておいたコマンドを押しても反応がないのです。どうすればいいですか? - 豆大福 2015-09-24 19:05:35
--分かりません。ただ思い通りに動かない場合は''【どこかしら記述が間違っている】か【余計な記述がある】か''がほとんどです。推測できる原因としては【''追加したCommandの記述が間違っている''(空中ダッシュ用に用意した[Command]がTime=1などになっている)】>Commandが地上ダッシュと共用などだとすると別の原因として【&b(){空中ダッシュの[State ]宣言や、Trigger記述に誤りがある}([State ]宣言に異常がある・TriggerにPos Y>-10(※超低空~地下)など指定を間違えている)】 - ADI 2015-09-24 20:31:25
-なるほど、理解が深まりました。重要な点を太線で示してくれて感謝です。 - 豆大福 2015-09-24 23:32:58
-ダメだ・・・ cnsとcmdの記述をいろいろ変えてみたけど、キーがまったく反応しない・・・ 余計な記述がないことを確かめたのに・・そういえば、[State 600]がいくつもある中で[State -1]が混ざってもいいんですか?[State ]宣言は唯一動いた、[Statedef 100]と同じ順番、同じ記述(変えるべき所は変えてある。)にしたのに変化がなかった。とりあえず、ここにファイルアップできるところとかあるでしょうか? - 豆大福 2015-09-25 01:16:35
--[State ]については、「&b(){[State }」(半角スペース込)で始まり、「'']''」で閉じていれば、StateDefに関わらず[State a]だろうが[State -1,xxx]だろうが関係無いですねー。 あと考えられるパターンとしては【''StateDefの指定がうまくできていない''(=ステートとして存在していない)】とかですかね。試しにChangeStateのValueだけを一旦=10(しゃがみ)などに変えて試してみて「空中でしゃがんだらChangeState自体は機能している(ステート側がうまくいっていない)」/「それでも反応しなかったらChangeState自体が機能していない(ステートコントローラーの指定が悪い、もしくはTriggerが通っていないなど)」ということが分かりますが。 ファイルについてはこちらでは用意しかねます。アップするならaxfcとかにアップする感じでしょうか。 - ADI 2015-09-25 05:13:56
---あともう一つ考えられるパターンは''[Command]の指定がうまくいっていない''可能性とかなんですが、その場合は一度Command=""の部分をComamnd="holddown"(方向キー下入れ)などに変えて試してみる。「それで動いた場合は[Command]で指定している内容に不備がある」/「動かない場合は[Command]以外の部分に問題がある」ということが分かりますね。 - ADI 2015-09-25 05:19:04
-2つ試してみましたが、どちらも動きませんでした。Axfcにうpしたんで、[Statedef 110],[Statedef 115]の記述をどう変えればいいかご教授お願い押します。 - 豆大福 2015-09-25 10:42:45
--アップしたファイルのところのURLを貼ってくれませんとこちらには分かりません…。 ただ2つを試してどちらも動かないとなると少なくとも【''ChangeStateは機能していない''】ようですね。 「ステートコントローラの記述,Triggerが間違っている」あるいは「ステートコントローラーを置く場所が間違っている」のではないかと推測できます(StateDEf-1の後側でもステコンの前に[Command]を置いてあるとか)。その問題を解決できない限り、110,番115番ステートを調整しても結果は変わりません。 - ADI 2015-09-25 15:22:57
-通常攻撃のステート番号を確認できるところはありませんか? - 豆大福 2015-09-25 11:36:32
--発言の主旨をつかみそこねているんですが。&br()■1.【一括してステート番号を確認できる方法はありません】ので、ステートファイルを開いて一つ一つ確認していくしかありません。&br()■2.Common用ステート(およそ0~199辺りと5000~5999辺りの中身)以外のステートは◯◯番でなければならないといった決まった番号はありません。ただKFMの設定を踏襲して200番台に立ち通常・400番台に屈み通常・600番台に空中通常を入れることが多いですが、絶対にそうでなければならないというわけでもありません。- ADI 2015-09-25 16:17:57
-Axfcにファイルアップしたんで、アップしたURLを貼りたいんですが、このページのどの設定を変えればいいかお願いします。 - 豆大福 2015-09-25 17:01:27
--URLをこのコメントに書き込んでください。 - ADI 2015-09-25 17:28:11
-確認してみましたが、ステコンの前に[Command]は置いてありませんでした。 - 豆大福 2015-09-25 17:06:22
--まさかとは思ったんですが…。&br()[State a]&br()Type=posadd&br()Trigger1=1&br()Y=-1&br()こうした記述をそのステコンの前に置いてみて貰えないでしょうか? 常時座標を少しずつ上げる・浮かせるという記述なんですが、コレを-1ステートに置いて機能しない場合''Cmdファイル自体を読み込むことができていない''ことが分かるんですが。 - ADI 2015-09-25 17:40:43
-ありがとうございます。無事空中系がmugenで反応したんですが、今後同じことが起きたことに対する対処とさせていただきます。あと、空中バックダッシュは成功したんですが、移動距離があまり変わらないんですよ。前方空中ダッシュと違って指定した方向どおりにバックダッシュしてくれないんです。velset = -10,0という感じで変えてみたんですが直りませんでした。どうすればいいですか? - 豆大福 2015-09-25 21:25:44
--分かりません。一応VelSetをいじっても変わらないという場合は大きく2つ【''VelSetを読み込んでいない''(指定の方法が悪いとか、そもそも飛ばしたいステートに飛んでいないとか)】、もしくは【''直後にVelSetをして上書きをしてしまっている''(中身にVelSetのステコンがある)】というケースを推測できます。ステート内部に他のVelSetなどのステコンが無いのであれば、ほぼ間違いなく前者です。StateDefの冒頭オプションのVelSetは問題ない可能性が高いので、移動するChangeState記述のValueが間違っていないかどうか・Commandがちゃんと前後で分かれているかどうか・同じ番号のステートを作ってしまっていないかどうか。 - ADI 2015-09-25 22:35:29
-ChangeState記述の「Value = 51」ですが、空中ダッシュの最後でもなってました。それでも110番の空中ダッシュのほうは問題なく動作していましたが、指定した51番のほうはairで登録していない番号です。 - 豆大福 2015-09-26 00:04:29
--ChangeState記述のvalue~というのは-1ステート側にある空中後ろダッシュのステートへ飛ばすChangeState記述のvalueのことです。 - ADI 2015-09-26 00:50:22
-value = 51を115にしたら、後ろにバックダッシュするようになったけど、そのステートから抜け出せなくなった。Changestate記述のValue= は具体的に言うと何という項目の番号を指定すればいいですか? - 豆大福 2015-09-26 10:25:56
--''分かりません''。恐らく115番ステートに存在するChangeStateもValue=115にしてしまったのだと思いますが、その場合115番のステートに再度跳ぶだけです。 - ADI 2015-09-26 11:04:58
-valueを51にすると何故か直りました。 - 豆大福 2015-09-26 23:53:38
-キャラの基本動作用.cns(やられ系、歩き、ダッシュ、ジャンプ系など)と通常技用.st(立ち通常攻撃、しゃがみ通常技、空中通常技など)に分けてキャラフォルダの中に入れたんですが、動いたはずの動作が動かなくなり、デバッグで「STATE ○○○○○;changed to invalid state:○○○○○」と連なって出てくるのです。1つにまとめると正常に動くんです。(他のキャラでは記述が多いようなのでわかりやすく基本動作、通常技、必殺技などに分けています。)原因はわかるでしょうか? - 豆大福 2015-09-27 18:44:01
--そのデバッグのエラー表示は【''移動した番号のステートが存在していません''】という表示です。つまり実際にはステートが読み込まれていない=''ファイルの読み込みが行われていない''と推測できます。恐らくキャラクターのdefファイルの[Files]記述でそのファイルをステート用ファイルとして指定できていない(記述がない、あるいは文字が間違っているなど)のだと考えられます。 - ADI 2015-09-27 21:31:47
-HitDefの項目の「ID」に、省略時:0って追加して頂けませんか?省略したHitDefで殴ると0がセットされるみたいなんで。一応です、一応( - ワープスター 2015-09-27 23:37:36
--確認しますー - ADI 2015-09-28 00:33:20
---追記シておきましたー。 - ADI 2015-09-28 01:29:55
-[State 30000, 1];オーラ消し超人時 - 豆大福 2015-09-28 10:17:12
-「[State 30000, 1];オーラ消し超人時 (中略) trigger1 = Anim = 30000 (中略) ID = 30001」 、他に「trigger1 = Anim = 30320,Anim = 10320,ID = 10320」のように「trigger1 = Anim = 」と「Anim =」で指定した部分が違うのですが、これはどういう意味ですか?また、ステート番号にairのアクションで指定したものに含まれていない番号をが入っていたのですが、ステート番号はどこの何番を指定すればいいですか? - 豆大福 2015-09-28 10:23:05
--Typeの部分、何のステートコントローラーの部分であるのか省略されているとどういう意図の記述であるのか分かりません。ただ【''State,Anim,IDなどなどの番号は、それぞれの番号は個別に設定して扱うものであり必ずしも一致させる必要はないし、また必ずしも同じ番号のState,Animを用意する必要もない''】ので数値が違う・同番号が用意されていないなどは『''そういう設定にしているから''』でしかありません。 - ADI 2015-09-28 16:39:09
-ステート番号は指定範囲内であれば、好きな数字を入れてもいいのですか?(例えば、必殺技のステート番号が1000番から2999番の間であれば、設定する番号は何番でもかまわないのか?ということです。)また、ID番号は好きな番号を指定できるのですか? - 豆大福 2015-09-29 12:13:14
--概ねそうです。【''ステートの番号は好きな番号に設定して良い''】ですが【''そのキャラに全く同じ番号のステートが複数ある場合は、その中の1つしか読み込まない''】のと【マイナスは-1~-3までで全て[[常時監視ステート]]という特殊なステート】なので、通常のステートの番号はマイナスでなく重複していないのであれば自由です。ただしステート番号に使える数字の上限は【''2147483647''】までです。 ID番号も(0~2147483647までの)好きな番号を指定していいですが、重複しないよう気をつけるべきです。 - ADI 2015-09-29 16:46:57
-前にも書いたと思いますが、ファイルをアップしたURLがここに書き込めません。書き込んだら、エラーが出てしまいます。 - 豆大福 2015-10-01 23:24:27
-和訳kfmでキャラ製作の練習をしているが、cmdでエラー落ちしてしまった・・・内容は「cmdが読み込めない」とのこと。URL載せておくんで、cmdとdefの中身の確認をお願いします。ttp://www1.axfc.net/uploader/ - 豆大福 2015-10-01 23:41:38
--ダウンロードするファイルが分かりません。 - ADI 2015-10-02 00:05:01
--ただエラーメッセージが&br() Error message: Can't open file&br() Error in 【cmdファイルの名前】&br() Error loading 【Defファイルの場所】&br() Error loading p1&br()という感じである場合は、''Defファイルの[Files]のcmd=で指定したファイルが存在しない''というエラーです。cmdファイルの名前と、cmd=の指定が間違っていないかどうか。あるいは「ファイル名」の部分が文字化けを起こして指定したファイル名とは異なるものになっている場合は、cmdファイルに「半角英字や半角記号」など以外の2バイト文字(もしくはマルチバイト文字)が使われていて読み込めない状態です。 - ADI 2015-10-02 00:13:50
--あと考えられるケースとして''ファイル名の前後に『全角スペースを入れている』''という場合も全角スペースがファイル名の一部として認識されてしまいうまく読み込むことができません。 - ADI 2015-10-02 00:20:09
-エラーとして出た内容は「Can`t read file. Error Loading Chars/キャラ名(英字)/キャラ名(英字).def Error Loading P1」です。全角スペースは使われていませんでしたし、defファイル内の「Data」の「cmd = 」の部分とファイル名は一致していました。 - 豆大福 2015-10-02 10:32:39
--すみません。&b(){Can't read file.}のエラーがどういう状況で発生するのか、私側の環境で検証しても再現できないためどのようなバグが発生してるのか見当がつきません。&br()状況からの憶測でしかないのですが、&b(){Cmdファイルを別名保存で「(キャラ名)_cmd.txt」に変えて保存し、cmdのファイル名指定を(キャラ名)_cmd.txtに替えてみる}とかでどうにかならないでしょうか。 - ADI 2015-10-02 16:56:38
-試してみましたが、やはり同じエラーが出ました。後考えられる原因としてもう少し何かありませんか? - 豆大福 2015-10-03 10:49:50
--状況からの憶測としては''ファイル以外の要因でファイルの読み込みが正常に行われていない''ように思えます。それこそ''パソコン側の問題''かもしれません。 - ADI 2015-10-03 15:22:42
-CNS開こうとすると、何故かデスクトップ画面に移りCNS開けない。(ほかのファイルもそう。)タスクバーで開いているブラウザクリックすると、直るけどなんなのコレ。(デスクトップ画面が点滅した光のように出てくる) - 豆大福 2015-10-03 11:26:19
--そのような挙動については''分かりません''。 - ADI 2015-10-03 15:25:06
-勝利後のステート180への移行条件ですが、どうやらCtrlがなくても移行できるパターンがあるようです。倒した技の終了後ステート0から1F後に独自に用意した、見かけだけ勝利ポーズを取るステートに移行させ、ステート180に移行してもアニメを変えない方式を取ると、独自ステートに飛んでから40F程度で勝手に180に移行しました。ですが表示するアニメを変えると自動で移行しなかったりとイマイチ条件がわかりません。よければ検証お願いします。 - 匿名 2015-10-08 08:19:33
-どうやら、ステート0に1Fだけいることが関係あるようです(?)もしかしたらCtrl=1は1Fだけで、その後ずっとCtrl=0でも移行できるかも? - 匿名 2015-10-08 08:33:54
--なるほどー? 調査してみます。 - ADI 2015-10-08 20:33:41
--調査してみた所、おそらく【勝利ステートへの以降の条件は&b(){RoundState=3になってからしばらく後(fight.defの設定と試合の状態に左右される)、全体が1Fだけでも満たせばRoundState=4に移行する。}その後はfight.defのover.wintimeの分待機した後に、条件が満たされていなくても勝利ステートへと移動する】という感じっぽいです。 - ADI 2015-10-08 21:29:34
---この仕様から考えると【1FだけCtrl戻して後はCtrl=0のままで待機】というのは厳しいです。受け付けのタイミングが状況や設定でブレる上、全体の状態をコントロールすることはできない(タッグ持は特に)のでキャラ単体で意図的にRoundState=3→4移行を1Fだけで制御するというのは厳しいと思います。 - ADI 2015-10-08 21:34:39
-cmdのファイルの読み込みはできましたが、「Error Detected. Need at least one statedef Error in marisa_kirisame.cns:79 Character mugen version is older than this version of M.U.G.E.N Error loading chars marisa_kirisame/marisa_kirisame.def Error while precaching 」とエラーが出てしまいます。「(前略)marisa_kirisame.cns」の後ろの「:79」は何なのでしょうか?それと、このエラーがなくなる方法をお願いします。 - 豆大福 2015-10-13 01:15:42
-cmdのファイルの読み込みはできましたが、「Error Detected. Need at least one statedef Error in marisa_kirisame.cns:79 Character mugen version is older than this version of M.U.G.E.N Error loading chars marisa_kirisame/marisa_kirisame.def Error while precaching 」とエラーが出てしまいます。「(前略)marisa_kirisame.cns」の後ろの「:79」は何なのでしょうか?それと、このエラーがなくなる方法をお願いします。 - 豆大福 2015-10-13 01:16:27
--そのような記述配置のエラーメッセージを見たことがないので''分かりません''。一行目?は「''ステート記述が1個以上必要''」という文言、二行目?が「&b(){cnsファイル名:79行目 キャラクターのmugenバージョンが古い}」という感じの文言のようですが、どうすれば修正できるのかは''分かりません''。 - ADI 2015-10-14 02:03:12
-二回投稿してしまいました。二つのうち、下のほうのやつを削除願います。 - 豆大福 2015-10-13 01:17:59
-79行目を確認してみたら、[Movement]の行だったのですが少なくともエラーメッセージに「cnsファイル名:79」のように記されていたら、79行目は使っているmugenに対応していないということですか?(つまり、79行目の生でエラーが出る?) - 豆大福 2015-10-14 11:06:11
--''分かりません''。エラーメッセージの書式としては「そうとも読める」という程度で、そもそも1行目(ステートの不足)・2行目(行指定の異常通知)の、恐らく別々のエラーが同時に表示されている状態というのがよくわかりません。 - ADI 2015-10-14 14:23:49
-一つお聞きしたいことがあるのですが、攻撃が当たったフレームでは座標移動が起きてしまうのは、どうしようもないことなのでしょうか? - 名無し 2015-11-04 20:56:01
-すみません、途中で送信してしまいました、そもそも攻撃が当たったフレームで速度があった場合、そのフレームでは座標移動が起きる、というのは正しいのでしょうか - 名無しさん 2015-11-04 20:59:47
--仕様としては【 全てのキャラの処理(その中に速度の移動処理)→攻撃の命中する判定 】のはずですので、『命中したフレームでも座標移動が起きる、というよりも''座標移動が起きた状態で攻撃の命中判定を行う''』、はずです。 - ADI 2015-11-05 12:02:57
---付け加えると攻撃が当たった時の速度については、基本的に攻撃を受けて飛ばされるコモンのくらいステート(5000番など)でvelset=0,0を行うのでそれの読み込みを行うのはは命中した次のフレームなので【命中した次のフレームで速度が0になる】という表現もそれ自体は間違ってはいません。ただvelsetを行って移動処理が行われるので【当たった次のフレームでの移動処理時点では速度が0になっているので動かない】のです。 - ADI 2015-11-05 12:16:00
-返信ありがとうございます。結論としては、例えば次のフレームで座標を戻すなどの手段でしか解決できないという事でよろしいでしょうか?この方法だと画面上にも動きが反映されるので、違和感がありできれば使いたくないのです。 - 名無しさん 2015-11-05 14:17:24
--そもそも【相手が動いている場合に座標を戻さなければならない状況】というのがどういう状況なのか疑問なのですが、投げ技などで『一定の範囲内であることを条件としてHitDefなどを発動させる→範囲外に出ていても当たった時に範囲内に引き戻したい』みたいな状況(距離を条件にした起動→距離外の相手への対応)でしょうか。【''攻撃がヒットした相手を特定の範囲内に収めたい''】ということであればHitDefに''MinDistとMaxDist''を指定すれば「攻撃がヒットした時に相手が指定範囲外であれば範囲内に引き込む」ということが出来る、はずです。 - ADI 2015-11-06 01:07:06
-申し訳ありません、説明不足でした。原作再現が目的で、主に空中技ヒット時の挙動が異なることによりコンボなどにも影響が出てしまっている状況です。 - 名無しさん 2015-11-06 01:36:29
-SC-/TransでAddAlphaの背景透過度によって影の濃さが変化するのを発見しました。透過度が大きいと影が薄くなります。256で影が消えます。Airでの指定では影に影響ありませんでした。 - 京太郎 2015-11-26 22:10:03
--情報ありがとうございます、検証・確認しました。Add1もAddAlphaと同様の扱いのようで、影の濃度に影響を与えるようです。 - ADI 2015-11-27 16:31:02
---Add1…そういうのもあったのか…さすが、抜かりないですね。 - 京太郎 2015-11-27 23:22:06
-ctrlを押しながらだとconstの設定を無視して空中ジャンプが(無限に?)可能みたいですが、これもデバッグキーになるんでしょうか? - 名無しさん 2015-12-14 23:41:01
--こちらの環境(winmugen)では確認できませんでした。1.0以降の仕様でしょうか? - ADI 2015-12-17 04:21:47
---すみません、勘違いでした・・・ - 名無しさん 2015-12-19 00:15:59
-SC-/HitDefのpausetimeについてですが、まずステートの初めにVar(0) - 京太郎 2016-03-02 19:50:33
--途中送信失礼。Var(0)を0に初期化し、その後trigger1=Time<10でSC-VarAddによりVar(0)を1ずつ加算すると、10になるのはお分かりでしょう。ここでVar(0)加算途中にHitDefによる硬直があった場合、SC-/VarAddにIgnoreHitPause=1を適用すると… - 京太郎 2016-03-02 19:58:28
--HitDefでpausetime=x,yだと当てた側のVar(0)の最終値が「10+x-1」になってしまうのは何故でしょうか。ちなみにx=0の場合はx=1と同じくVar(0)=10になりました。 - 京太郎 2016-03-02 20:03:27
---どうやらフレーム計測上は【PauseTime=0,0】と【PauseTime=1,1】は差がないようです。 おそらく【PauseTimeが1の場合フレーム終了時点でPauseTime-1をしている】ため、1=そのフレーム時点で終了=CNS上では停止をしていない、っぽい感じです。 - ADI 2016-03-02 23:40:57
----追加>ただし『PauseTimeの有無による変化』自体は発生していて、PauseTime=0,0と1,1では PauseやSuperPause中の挙動が変化します。 PauseTimeがあると「PauseTimeの分だけ動ける時間が伸びる」という性質があり、0の場合動ける時間は伸びないため、SuperPauseで停止中の相手にその攻撃を当てても(そのキャラのステートの読み込みが無いので)ダメージ処理が行われません。この辺り追加しておいた方が良さそうですね。 - ADI 2016-03-02 23:50:30
-projのoffsetはfloat型にするとエラー落ちするようです - 名無しさん 2016-05-13 16:28:26
--ご報告ありがとうございます。エラー落ちを確認しました。修正致します。 - ADI 2016-05-13 19:23:59
-SuperPauseの項目に P2DefMul = (Int型) とありますが、Super.TargetDefenceMulの値的にもFloat型の間違いではないでしょうか。 - 名無しさん 2016-06-23 22:48:29
--ご報告ありがとうございます。修正しました。 - ADI 2016-06-24 03:22:58
-HelperのPosですがLeftやRight、BackやFrontのYの軸は画面下端です Explodにも同様のPosのオプションがありますがこちらのYの軸は画面上端です - 名無しさん 2016-10-11 04:32:05
--下端ではなく射出するPlayerのY座標基準だったかと - 名無しさん 2016-10-12 03:27:15
--遅ればせながらご報告ありがとうございます。Helperのページについて検証し、「地面」に修正しました。Explodのページは書かれたままです。 - ADI 2016-10-21 22:51:04
-mugenメモの対めくり用InGuardDist補助を利用させて頂いたところ、説明と記述でVar(40)とVar(41)の+-が逆になっていました。記述に合わせるならHelper(**),Var(40) = Pos X+100のInGuardDistかと。 - 沼の爪 2016-11-11 20:42:00
--ご報告ありがとうございます。確認しました~。修正しておきます。 - ADI 2016-11-19 06:55:50
-commonステートのstateno=170,stateno=180はそれぞれサバイバルモードのリザルトスクリーンにmo使用されるみたいです. - 名無しさん 2017-03-10 18:04:06
--ありがとうございます。追記しました~。 - ADI 2017-03-17 09:05:11
-Helperの解説部分にSize.Ground.Nack = (Int型)となっている誤字があります。 - 名無しさん 2017-03-21 02:47:06
--ありがとうございます。修正しましたー - 名無しさん 2017-03-21 14:07:21
-p2getp1state=1のついたProjectileはHitOverRideのついたキャラにも当たります。 - 名無しさん 2017-03-24 18:42:57
--ありがとうございます。挙動確認しました。「ステート奪取せずにヒットする」ようですね。 - ADI 2017-03-25 01:42:04
-EnvColorの記述例がtype=Underになっています - 名無しさん 2017-12-19 19:17:59
--ありがとうございます。修正しました - 名無しさん 2017-12-25 05:03:10
-4人制タッグ時、Enemy(2)、Enemy(3)で3人目以降の相手を参照することはできますが、Enemynear(2)、Enemynear(3)を参照することはできないようです。 - 名無しさん (2018-03-29 16:33:31)
-そもそもEnemynearが3人目以降の相手を認識しないみたいです。 - 名無しさん (2018-03-29 16:45:02)
-リダイレクトのPartner.からEnemyNEar(1).まで「,」が「.」になっています - 名無しさん (2018-12-11 20:05:48)
--ご報告ありがとうございます。 - 名無しさん (2018-12-11 21:23:31)
-AfterImageのPalMulはFloat型です。省略時の値も65, .65, .75と小数点がありません。 - 名無しさん (2018-12-17 03:27:16)
--ご報告ありがとうございます。 - 名無しさん (2018-12-19 18:36:34)
-statetypesetの解説ページのphysicsを押すとVelのページに飛びます - Lkn (2019-02-03 13:56:45)
--physicsの情報はVelのページにまとめて記載しています。 - 名無しさん (2019-02-04 06:05:24)
-Airファイルの解説ページのClsn1Default及びClsn2Defaultは全てのElemに作用するものでは無くそれを指定したElem以降のElemに作用するものです。 - 名無しさん (2019-02-07 23:50:00)
--ご報告ありがとうございます。 - ADI (2019-02-08 16:08:10)
-相手がstatetype=SやCになっても、movetype=Hのままだとjuggle値はリセットされないようです。空中やられの相手が気絶して立ちやられ(statetype=S movetype=H)になっても、juggle値はリセットされませんでした。 - 沼の爪 (2019-03-19 21:46:21)
--ご報告ありがとうございます。 - 名無しさん (2019-03-24 20:18:26)
-ここはmugenの記述や仕様をまとめてあるwikiだと思うのですが性能階級ページのところにある愚痴じみたことと書いてあるところは筆者の個人的な意見でしかないのでいらないと思います。やるなら個人のサイトでやってほしいです。あと他にも凶悪キャラを貶すようなことも書いてありますがここは凶悪界隈の人も見ているのでよくないと思います。凶悪界隈の人に見られたくないというのであればトップページで強調して書いておくといいです。 - 名無しさん (2019-04-23 15:00:03)
--コメントありがとうございます。すみませんが、読み返しても私にはどこが問題であるのか、「貶すようなこと」に読まれるのかあまり理解できず、問題のある部分を検証できなければ対応できません。&br()そもそも該当ページ「階級性能」自体がCNSなどとは離れた話題で、それが必要であるかどうか考慮しなければならないページであり、しかし考慮した結果必要だと判断しまとめたものとなっています。そこに書かれている全てが必要であると判断して書かれたものです。理由があれば適時編集をしますが理由なく編集することはありません。 &br()もし情報に齟齬がある、誤り・誤解が存在するというのであればその点に関して情報を提供していただければ適切に対応できますが、内容への反論なども無くただ削除を要求されてもそれに対応することはできません。 特に「事実」あるいは「実質的にそうであること」について心情を理由として削除することはできません。&br()また「凶悪界隈の人」を言及されていますがこちらは凶悪界隈の内情については存じ上げませんので、よく知りもせず特別に対応することは不適切であると考え、知らない方々へそうした対応をすることはできません。- ADI( 記事編集から 2019-05-01)
---きつい言い方だったのが直ってますね修正ありがとうございます。自分もちょっと感情的になり過ぎました。すみません。ただ、凶悪キャラは意図的にバグを起こすことで普通のキャラでも起こる原因不明だったエラー落ちや不具合の解明に繋がる(最近だと437エラーの原因が判明したりProjでのair.juggleの挙動判明など)ことも少なくないのでその辺りも書いてくれたら嬉しいです。 - 名無しさん (2019-05-07 16:43:30)
-参考ページ一覧の「不明」と書かれている部分は「wm氏」で、サイト名は「無目的研究室」です。(アーカイブで確認) - ピチュマ (2019-11-15 22:09:39)
--ウェブアーカイブで確認しましたー - ADI (2019-11-16 14:29:45)
-トリガーのTeamModeの説明ですが、当方WinMugenで製作していますが""を引数につけるとエラー落ちします。 - 名無しさん (2020-01-15 23:39:29)
--情報を確認して修正しました。 - ADI (2020-01-17 22:41:57)
-すみません 「MUGEN CNS WIKI CHAOS」のリンクを 是非mugenドット絵板に張らせて頂きたいです 良いでしょうか? - Yes (2020-01-16 17:45:47)
--リンクは基本的に自由ですが、他サイトの一部かのように見られないような注意はお願いします。 - ADI (2020-01-17 22:50:04)
-ありがとうございます!ところでこのサイトのバナーってありますか?特になければ私の方で用意しようかと思います - Yes (2020-01-18 08:21:14)
-Airについてのページ(ttps://w.atwiki.jp/mugencns/pages/46.html)内の必須アニメの項目について。5番(Stand turning)及び6番(Crouch turning)は必須アニメではないでしょうか。ソース:ttp://www.elecbyte.com/mugendocs/air.html - 名無しさん (2020-02-28 01:09:07)
--Air,5-6番は(少なくともwin版では)「絶対に無ければならない」わけではなく実際は"無くてもエラー表示が起きない"=必須アニメではないとしています。 - ADI (2020-02-29 01:57:03)
-何故かエフェクトの位置がずれると思ったら、ヘルパーからExplodを出して同時にヘルパーを消去すると[Size]のDraw.Offsetが無視されるようです。 MUGEN1.1b1にて確認しました。ステートを移動して移動先でDestroySelfしたとしても起こるので、同時に処理しないか、もしくは無視される分を記述する必要があります。 例)Pos = off_x + Const(Size.Draw.Offset.X), off_y + Const(Size.Draw.Offset.Y) あまり言及されていないようだったので一応。そもそもこのパラメータを使っていなければ起こらないのでほとんどのキャラには関係ない話です。 - 名無しさん (2020-02-28 12:58:23)
-(追記)解決法としては、同時に処理しないようにする場合にはDestroySelfをTrigger1 = Timeで処理するステートにChangeStateする方法があります。 こちらの方がConstを加えたり処理順をずらしたりする必要がないためコンバート作業がしやすいです。 RemoveExplods = 1やRecursive = 1がある場合はステートを別に作ってやれば良いかと思います。 ただこの方法にも問題があり、ChangeStateで処理を1F遅らせることで不具合が起きる場合があります。 そういった場合には先述の例で挙げた方法で解決します。 - 名無しさん (2020-02-28 13:21:15)
--win版で調査しましたが、win版では起きないみたいです。1.0~あたりでヘルパーの処理が変更されてるのでしょうか。 - ADI (2020-02-29 02:25:56)
---そのようです。2件とも、ご対応ありがとうございます。 - 名無しさん (2020-03-01 11:28:30)
-MUGENメモにて公開されている「いっしょにとれーにんぐ非公式拡張ファイル」等がDLできない状態になっているのですが、リンク先が消えてしまっているかもしれません。確認できませんでしょうか。 - 矢印 (2020-12-13 06:51:27)
--確認が大きく遅れて申し訳ありません。今確認したところ問題無くDLできていたのでアップローダーの一時的な障害だったのかもしれません。 - ADI (2021-01-27 14:35:42)
---手元でも最新版のDL確認できました。回答ありがとうございました。 - 矢印 (2021-02-05 23:41:17)
-projectileパラメータのRemVelocityがRemVlocityになっています - 名無しさん (2021-03-23 11:52:03)
--報告ありがとうございます。修正しました。 - ADI (2021-03-31 04:02:26)
-報告です。まだ詳しく検証はしていませんが、AnimElem=1のElemTimeが-1のアニメを使用した状態でAngleDrawを掛けると分身のようなものが出る不具合を見つけました。私はヘルパーでその症状を発見しましたが、まだ本体で同症状が出るかは把握していません。 - unknown37564 (2021-07-06 01:45:57)
--ページを確認しましたが「最中のElemに-1設定をしている場合に→AngleDrawで回転をかけると、右向きへ回転させた分身が表示される(右向き時は見えないが左向き時は見える)」という状況であるなら既知の現象ですね。説明的に最初を含まないともとれる表現だったので一応修正しておきました。 - ADI (2021-07-06 19:07:19)
2021-07-06T19:07:19+09:00
1625566039
-
SC-/AngleDraw
https://w.atwiki.jp/mugencns/pages/74.html
戻る→[[ステートコントローラーの一覧]]
----
:※解説修正情報※|
//●&font(12,b){日付:修正部分の概要}
●&font(12,b){2021-07-06:注意点について説明の不備を修正}
●&font(12,b){2014-10-13:Scale処理について}
----
//ほかページヘのリンクはLv0のみで。(Lv1~でリンクしようとすると煩雑になりそうなので)
*■AngleDraw【描画回転反映・拡縮】
:▼概要|
基準位置を中心にして、画像の回転などを行う。表示の効果は1F。
//Angle系テンプレ
[[SC-/AngleSet]]・[[SC-/AngleAdd]]・[[SC-/AngleMul]]で指定された回転は[[SC-/AngleDraw]]で反映される。
''Drawが実行されなければSet,Add,Mulは機能しない''。
表示効果は実行時の1Fだが、角度はDrawをしなくても保持されるため注意。
また''判定枠は変化しない''ため、回転に対応した判定枠を使いたい場合は要注意。
判定枠の回転させたい場合は[[File-/Airファイル]]で直接指定する必要がある。
//細かいことは[[SC-/AngleDraw]]のページを参照
//Drawオプション
win版からDrawのオプションでSetの処理を指定できる他、拡大縮小も可能になっている。
:▼必須記述|
-無し
:▼オプション|
-※Win版以降限定
&b(){value = (Float型) };角度を度数法で指定 小数可
-省略時:変更無し
-度数法(一周=360)で''正数値で後ろ周り''
--左向きであれば正数値=時計回り。
--[[SC-/AngleSet]]と同じく指定数値に設定する。
&b(){scale = (Float型,X),(Float型,Y) };拡縮を指定
-省略時:変化無し
--1,1なら1倍。0.5,0.5なら1/2縮小。2,2なら2倍拡大。
--負数指定の場合、反転状態になる。-1,-1で180度回転したような表示に。
--※効果数値は1F持続。処理が重複した場合、変更倍率からの倍率指定に。
----
**■Lv1-記述例・補足・注意点
:記述例|
[State 1500, Angle Draw]
Type = AngleDraw
trigger1 = 1
-既に指定されている角度を表示に反映させる。
:補足|
-角度の数値はずっと保持される。
--角度指定後しばらくしてからDrawのみを実行しても指定角度は反映される。
--[[SC-/AngleAdd]]や[[SC-/AngleMul]]が機能するのはそのため
--そのため角度を指定する場合''最初に0へSetする''ようにしたほうが良い。
---なお、角度を確認するためトリガー情報は存在しない。
-Scaleを変更した状態でもHelperなどを射出する大きさは変化しない。
//''検証不足'' Scaleを変更して射出したHelperでの扱い。
:注意点|
-実行中はAirファイルで指定した''座標指定・反転・透過処理が無効化される''とのこと。
-回転する基準はキャラの基準位置。
--キャラの中心を指定して回転させたい場合は&br()体の中心を基準としたスプライトを登録して使う必要が。
--また体の中心で回転させる際、Y座標をズラすことになる。
-''判定枠は変化しない。''
--判定枠を対応したければAirファイルて調整すること。
-効果は1Fのみのため効果の時間はTriggerで調整。
-回転時、最後以外のElemに-1設定のアニメが存在する場合
--それ以降のElemの回転表示で「右向き時と同じ回転方向の表示も出る」
--右向き時は問題ないが左向き時に左右対称の角度で分身が表示される。
--元々最後以外のElemに-1を指定すること自体イレギュラーだが注意。
-90度間隔以外の回転を行うと表示がやや荒れる。
--特に小さい表示の場合は、細部が潰れることもある。
-Scaleの指定は1F効果数値が持続し、効果が重複する。
--同じフレームで2度以上実行すると、リセットされての1倍からではなく、&br()それまでの設定倍率に設定倍率を乗算した倍率となる。
--例:0.5倍指定の後、同じフレームで再度2倍を実行すると0.5×2で1倍表示となる。
//:AI制作時の注意点|
//-あれば
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
//----
//#region(■Lv4-バグ利用)
//**■Lv-4-バグ応用
//あやしい仕様を活用する関係。
//#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
//----
//:※解説修正情報※古い履歴|
//●&font(12,b){日付:修正部分の概要}
//
----
2021-07-06T19:06:17+09:00
1625565977
-
SC-/Projectile
https://w.atwiki.jp/mugencns/pages/257.html
戻る→[[ステートコントローラーの一覧]]
----
:※解説修正情報※|
//●&font(12,b){日付:修正部分の概要}
●&font(12,b){2017-03-25:P2getP1Stateの処理について}
●&font(12,b){2016-05-13:OffSetはFloat型の数値をそのまま入れるとエラーで落ちる。ただし例外有り?}
●&font(12,b){2015-11-07:Proj***Bound系について追記}
●&font(12,b){2014-10-18:ProjPriorityとProjHitsの関係性・相殺打ち消し計算が判明}
●&font(12,b){2014-10-18:ProjPriorityについて検証。またProj相殺処理はProjくらい判定同士で発生する模様}
●&font(12,b){2014-10-13:Scale処理について間違っていた。}
●&font(12,b){2014-10-11:PauseTime設定やProjHits・ProjMissTimeに関して。・HitDefとの性質の違いについて}
●&font(12,b){2013-06-20:P2getP1Stateの処理について}
----
//ほかページヘのリンクはLv0のみで。(Lv1~でリンクしようとすると煩雑になりそうなので)
&b(){※検証の足りない部分が多々ありますので、使用する際は検証しつつ使いましょう}
*■Projectile【飛び道具を発射する】
:▼概要|
飛び道具「Projectile」の射出を行う。「Proj」と略される。
[[SC-/HitDef]]とほぼ同様の攻撃定義を持ったアニメを発射する。
射出後はパラメーターに従って残存・消失する。
アニメを用意すれば基本HitDefの定義へProj用のパラメータを入れるだけで使える。
なお本体の[[T-/MoveType]]は影響しないが、、基本的に''Movetype=A''でなければならない。
:上限数|
またProjは''キャラ毎の''総数に上限があり、それを超えると射出できなくなる。
限数は[[mugen.cfg>File-/MUGEN設定ファイル ]]で設定。
[[SC-/Explod]]や[[SC-/Helper]]と異なりプレイヤー毎の総数?
//初期値不明?
:Proj関連|
個数:[[T-/NumProj]][[T-/NumProjID()]]
命中:[[T-/ProjContact]][[T-/ProjHit]][[T-/ProjGuarded]]
命中後時間:[[T-/ProjContactTime()]][[T-/ProjHitTime()]][[T-/ProjGuardedTime()]]
相殺後時間:[[T-/ProjCancelTime()]]
:▼必須記述|
-パラメーター指定がなくてもエラー無し。
-ただし攻撃用に使用する場合は[[SC-/HitDef]]と同じ指定は必要。
:▼オプション|
-攻撃定義:[[SC-/HitDef]]とほぼ同じ方式で記述する。
--''PauseTimeの自分側''は本体に影響を与えず、Projのみが停止するため''0''が望ましい。
---停止中は「複数ヒットの処理」が停止される。アニメ処理や消滅処理は停止中でも行われる。
--[[Juggle]]値はAir.Juggleで指定する。本体のJuggle値設定は無関係?
--なお[[SC-/HitDef]]同様、実行時点のパラメータのみが有効。
---[[ダメージ]]のページも参照
--AffectTeamで味方に当たる設定でも、''管理キャラ自体には命中しない''
--Hitonce(単一ヒット設定)は機能しない?
&b(){ProjID = (Int型) };Proj系トリガー情報に用いるID。HitIDとは異なる。
:射出位置|
&b(){PosType = (文字列) };表示の基準点。Offset=0,0とする場所。
-''P1'':実行するキャラの座標。 省略時P1
-''P2'':P2相手の座標。(P2相手については[[リダイレクト]]参照)
-''F'':Front:キャラの前の画面端,地面。
-''B'':Back:キャラの後ろの画面端,地面。
-''L'':Left:画面自体の左端,地面。
-''R'':Right:画面自体の右端,地面。
--Front,Back,Left,Rightは頭文字だけで識別?スペルミスしていても動く。
--F,B,L,Rは全て''地上の高さを基準として設定している''
--向きは常に''キャラの向き''が基準となる。
&b(){Offset = (X座標Float型), (Y座標Float型) };発射座標 省略時0,0
-座標指定パラメータは''PosではなくOffset''。間違えないように。
-※''Float型の数値をそのまま入れるとエラー落ちする模様''。数値入力ではInt型望ましいかも。
--※記述を工夫すると例外的にFloat型を使うことができるみたい?
---「Int型+Float型」など数式にして、数式の最初の数値をInt型にする。(例:10+0.13)
---Flaot型のトリガー情報を記述する。([FVar()]を含む)
----以上の書式にするとFloat型を使ってもエラーで落ちることも、エラーが流れる事も無い模様?
:移動速度|
&b(){Velocity = (X速度Float型), (Y速度Float型) };速度 省略時0,0(静止)
&b(){Accel = (X加速度Float型), (Y加速度Float型) };加速度 省略時0,0(無変化)
&b(){VelMul = (X速倍率Float型), (Y速倍率Float型) };速度倍率 省略時1,1(無変化)
-速度の基準の向きはPosTypeの基準と同じ(向き基準)
-速度がアニメの向きを制御し常に左右の''進行方向へ向く''。
--ただしAccelの値は射出時点の基準の向きで処理をする。
-Proj自体の移動速度。出現時点から移動する?
--Accelは出現時点ではかからない?
--攻撃判定は動いた跡に行われる。[[フレーム処理]]参照
&b(){RemVelocity = (X速度Float型), (Y速度Float型) };Remove時点の速度
-消失時点で''上書き設定される速度'' 省略時0,0(停止)
:アニメ系|
&b(){ProjAnim = (Int型) };基本アニメ 省略時0
-くらい判定がある場合、ProjやHitFlag=Pによる相殺が可能になる。
--Proj同士の相殺は''くらい判定同士の重なり''で発生する。攻撃判定は不要。
---※Projのくらい判定は[[Ctrl+C>デバッグ]]では表示されないため確認には注意。
---攻撃処理とは別でAttrにP属性を指定しなくてもProj同士である場合は相殺・打ち消しは発生する。
--HitDefによる打ち消しはHitDefの攻撃判定→Projのくらい判定によって成立する。
---ただし同時にProj攻撃判定がhtidef側へ命中する場合、''Proj命中が優先され打ち消しが起きない''
&b(){ProjHitAnim = (Int型) };ヒット''消滅''時アニメ 省略時-1(無)
&b(){ProjRemAnim = (Int型) };条件消失時アニメ 省略時HitAnimと同一
&b(){ProjCancelAnim = (Int型) };相殺時アニメ 省略時RemAnimと同一
-複数ヒットする設定の場合、消滅するヒットの時のみProjHitAnimに変化する
-「RemAnim」の条件はProjRemoveTimeやBound系の適応消失時。
--ちなみにRemAnimに攻撃判定があると基本同様ヒットするらしい?
&b(){ProjScale = (X縮尺Flaot型), (Y縮尺Float型) };表示スプライトの縮尺指定。省略時1,1
-''この設定では判定枠の大きさは変化しない''
-[[File-/CNSファイル]]のサイズ設定、Proj.DoScale設定を基準とした倍率を指定する。
--親サイズが2,2でもProj.DoScaleが0の場合は1,1を基準とし、ProjScale=2,2なら通常から2倍の表示。
--親サイズが2,2でProj.DoScaleが1だと2,2を基準とし、ProjScale=2,2なら通常から2☓2の4倍の表示に。
--[[SC-/Helper]]が親の場合、Helperの設定を基準とする。(省略時、その親と同じ)
&b(){ProjSprPriority = (Int型) };アニメ表示優先度 省略時:3
:特殊効果|
&b(){ProjShadow = (赤Int型), (緑Int型), (青Int型) };影設定 省略時0,0,0(影無し)
-''-1''設定でステージ依存、255,255,255で真っ黒に。
//&b(){Proj = (Int型) };
:消失関係|
&b(){ProjRemove = (bool型) };ヒット時の消失フラグ 省略時:1(ヒットで消失)
-1の場合はProjHitsの残り回数が0になると消失する。
&b(){ProjRemoveTime = (Int型) };消失までの時間
-省略時:-1(時間では消失しない。)
-カウントと消失は[[フレーム処理]]の最後。詳しくは[[フレーム処理]]を参照。
&b(){ProjHits = (Int型) };ヒットする数 省略時:1
-''ヒットカウント数ではなく、連続ヒットする回数''
--ヒットカウント数は[[SC-/Hitdef]]同様''NumHits''を使う。
--ヒットカウントではなくヒット回数での管理のため、複数相手でも指定回数ヒット。
--複数の相手に同時に命中すればProjHitsの数値より多いヒットカウントになるが、&br()個別に命中した場合は合計で設定値の回数分しか命中しない。
-ヒット回数の他、ProjPriorityの打ち消し・相殺の処理にも関係する。
&b(){ProjMissTime = (Int型) };連続ヒット制限 省略時:1?(毎フレーム)
-ProjHitsの数が2以上の場合、ヒット毎の間隔を指定する。
--10とすれば一度命中した後、10F後2回目が命中する。
--Pausetimeの自分側が設定されているなら''自身のPausetime停止が終わった後から数える''。
---Pausetimeが10,xでProjMisstimeが5とした場合、命中してから15F後に命中する。
---相手が複数居ても待ち時間は変わらない。当てた相手に当たるようになるまで他には当たらない。
-ステコン一覧では省略時0(一度に全ヒット)とあるが少なくともWin版は1扱い。
&b(){ProjPriority = (Int型) };飛び道具の強度・優先度 省略時:1
-''Proj同士での相殺''の耐性値B。ProjHitsも耐久値に関わる。
--[[SC-/HitDef]]でのProjへの攻撃はProjPriorityに関係なくProj命中かProj打ち消しとなる。
--詳しい打ち消し処理については後述
:消失関係・範囲|
&b(){ProjEdgeBound = (Int型) };画面外射程 省略時:40
-表示している画面の端からさらに指定値分外にでると消滅する。
--画面端の広さ設定は考慮しない。表示のまま。
&b(){ProjHeightBound = (上空Int型),(地面Int型) };画面上下射程
-省略時:-240,1 (空中-240、地面下1まで)
--指定範囲の外側へ向けた速度があり、指定範囲の外側に居ると消滅する。
---つまり上側の範囲外では上向きの速度がある場合、&br()下側範囲外なら下向き速度がある場合に消滅する。
---範囲外でも上側の範囲外で下向きの速度、下の範囲外で上向き速度では消えない。
&b(){ProjStageBound = (Int型) };ステージ外射程 省略時:40
-外向きの速度をもって、カメラの動ける端からさらに指定値分外側に出ると消滅する。
--ステージの外側にいても、速度がステージ内側へ向いてるなら消滅しない。
--画面端の広さ設定は考慮しない。ほぼ表示のまま。
-[[座標]]について詳しくは該当ページを参照。
-※ProjEdgeBound(カメラ外)は速度に関係なく、外側へ出た時に消滅する。
-※ProjHeightBound (ステージ上下)、ProjStageBound (ステージ左右)は&br()外側に出ていてかつ外側へ向けた速度がある場合に消滅する。
:Pause無視系・MoveTime|
&b(){SuperMoveTime = (Int型) };[[SC-/SuperPause]]を始動から指定フレーム中だけ無視
&b(){PauseMoveTime = (Int型) };[[SC-/Pause]]を始動から指定フレーム中だけ無視
-いずれも省略時は0、一切無視をしない。
--親キャラ(本体)にMoveTimeが無い場合、''MoveTimeが有っても動けない''
-ただし射出時点のフレームはMoveTimeに関わらず動く。※MoveTimeの分とは別計算?
-''MoveTimeの影響時間はPause中の経過でなく射出からの時間''?
--SuperMoveTime=120の場合、射出から約2秒間のみ影響を受けない。
--120設定なら射出から2秒以上経っている場合は影響を受ける。
:その他|
&b(){▼[[SC-/AfterImage]]パラメータの全て} ステコン一覧には書かれていないが指定可能。
&b(){AfterImage.Time = (Int型) };AfterImageのTIme値 省略時:0
&b(){AfterImage.#### = #### };AfterImageの####値。
-AfterImage.####で[[SC-/AfterImage]]の設定項目を指定するとAftarimage(残像)を表示できる。
-[[SC-/AfterImage]]のPalBright値なら、AfterImage.PalBright=XX,XX,XXという感じ。
--なお、残像はProjが存在している間のみ有効。消失すると残像も全て即時消滅する。
--消滅時に表示消しつつ残像を一定時間残したい場合は、消滅アニメに無表示アニメを指定すると良い。
----
**■Lv1-記述例・補足・注意点
:記述例|
[State 1200, Projectile]
Type = Projectile ;HitDef
Trigger1 = AnimElem = 4
;HitDef用のパラメータを記述する。
;以下、Proj用に最低限必要な記述
ProjID = 1200 ;ProjID
Offset = 20, -50 ;射出位置
Velocity = 3, 0 ;発射速度
ProjAnim = 1201 ;射出アニメ
-必要最小限の設定
-必要なら細かいパラメーターを追加すること。
:補足|
-残存時間に関しては[[SC-/Explod]]と非常に近い。
--[[消失処理のタイミング>フレーム処理]]は''ステート処理よりも後''
-Velocityによって移動するタイミングは''攻撃判定よりも前''
:ProjStageBound|
-ProjStageBoundはステージ幅自体を基準とした数少ない処理の1つ。
--自由に使える処理としては唯一と言って良い。
-これを利用することで、ステージの幅を認識する手段が存在する。
--詳しくは[[座標]]のページの下Lv3の欄を参照。
:HitDefとの違い|
[[SC-/HitDef]]とは一部、攻撃判定として処理に違いがある。
-''Pausetimeの自分側はProj自身にかかる''。本体には影響しない。
-''HitOnceが機能しない''。複数の相手が重なっている場合Porjは同時にヒットする。
--Projのヒット回数はProjHitsで設定されるため、&br()時間差で当たっていない相手にだけ当てることはできない。
-[[ステート奪取]]設定(P2GetP1State)をした場合に[[SC-/HitOverride]]が起動する場合にも通常ヒットはする。&br();HitDefのステート奪取設定ではそもそも命中自体しない。Projではステート奪取設定が無い攻撃として命中する。
''※ただし処理の関係上、そもそもP2StateNo・P2GetP1Stateの設定は使うべきでない''
-それ以外にも細かい違いがある、はず。
:Helperとの違い|
飛び道具自体は[[Helperでも可能>Helper技術]]だが、それぞれに欠点がある。
-Helperの場合
--ステートを作成する要領で作成することができる。
--細かい記述を入れれば細かい制御もできる。
--[[リダイレクト]]を用いれば細かい確認もできる。
--ただし上限数があるため闇雲に使うことができない。
--制御を誤ると分身の発生する危険がある。
---[[SC-/HitDef]]を使う場合[[SC-/ReversalDef]]の危険も。
----ただしMoveTime(Pause中作動)を永続にするなら危険は減らせる。
-Projの場合
--記述は単純だが、細かい制御が一切できない。(更新Proj型で多少対応可能)
---攻撃力の更新などは更新Proj型のみ可能。
--個数確認とヒット確認以外の情報を確認できない。
--[[SC-/Pause]]などの停止で本体が停止した場合、動かない。
--[[SC-/ReversalDef]]の対象外。
--Win版では?:常に[[SC-/PalFX]]の影響を受ける。
--Pause中は本体が動けなければ動けない。
-[[更新Proj>Helper技術/更新Proj型攻撃判定飛び道具]]型については該当ページを参照。
--簡単に言うと「''Projを更新していく方式''」で細かい制御を行える。
--ただしその分、記述が面倒になりがち。
--Projの欠点としてPause中は本体が動けなければ動けない。
-なお更新Proj型の方式など使うとHitDef代替のProj型攻撃も可能。
--[[SC-/HitDef]]でないため[[SC-/ReversalDef]]に関与されない。
--欠点として本体へ自動でのPauseTimeを付加させることができない。
:注意点|
-射出する際は必ず[[T-/Movetype]]をAにすること。
--それについて詳しくは[[発生1F目攻撃の弊害]]のページも参照。
-Projは射出時点のパラメータのみが有効で補正値の更新は&br()[[Projを更新していく方式>Helper技術/更新Proj型攻撃判定飛び道具]]でなければ不可。
--[[ダメージ]]のページも参照
-Projを参照するトリガーは個数確認とヒット確認しか存在しない。
--そのため、細かい状況を把握するには特殊な調査が必要になる。
-Projは&b(){[[SC-/Helper]]から実行しても本体の管理}になる。
--HelperからProjを出しても個数を確認する場合は本体の情報を参照する。
--「Root,NumProj」という具合。
-ProjRemoveTimeは影響・表示フレーム数で、残存時間は+1フレーム長い。
--[[SC-/Explod]]と同様に消滅するフレームでは存在が消えていない。
--1では「射出時点F(表示)→次Fの終了時点(消滅)」まで残る。
--詳しくは[[フレーム処理]]のページを参照。
--なお攻撃がヒットした場合はその時点で消滅している。
-ただし[[SC-/Pause]]などで''本体が動けない場合はProjは動かない''。
--PauseMoveTime,SuperMoveTimeは''本体に対応MoveTimeがある場合のみ有効''
--なお、射出したフレーム時点ではPauseに関わらず処理を行う。
---ProjRemoveTime=1で本体停止中・MoveTime有りの場合、&br()アニメ表示が行われない(判定はあり命中もする)
-Win版では、OwnPalが機能せず本体の[[SC-/PalFX]]の影響を受ける。
:P2GetP1State([[ステート奪取]])、P1StateNoについて|
''Projではステート変更のオプションを使用しないほうがよい''。
-もし[[ステートを奪われた状態>ステート奪取]]でProjが命中すると
--ステートは奪われたままP1StateNoの指定番号の''相手側ステートを読み込む''。
--P2GetP1State(P2StateNo)については''本体ステートの主ステートを読み込む''
---ステートを奪われている場合''ステートを奪っている犯人のステートを読みこませる''
---場合によっては&b(){[[ステート奪取]]された状態で自身のステートを読み込むこともある。}
なお常に本体管理になる関係上[[SC-/Helper]]からProjでは危険度が跳ね上がる。
-後述
:Pause中の親のMoveTimeについて|
[[SC-/Pause]]、[[SC-/SuperPause]]での停止中、
Projは本体のMoveTimeが存在しない場合、ProjのMoveTimeが有っても動かない。
基本的に本体以外の停止で停止するというものだが、
例外的に攻撃が命中した際にもMoveTimeは発生する。
-そのため自分以外の時間停止中に攻撃を受けると、&br()停止していたProjが動くという現象が起きうる。
:Proj相殺・打ち消しの処理|
Proj同士の相殺はProjのくらい判定同士が重なることによって発生する。
-AttrのP属性はHitDef用で、Projはくらい判定が互いにあればP属性が無くとも発生する。
Proj相殺は''ProjHitsとProjPriorityの合計値を比較''して処理をする。
-PH+PPの合計値が同一である場合、相殺して互いに消滅する。
-PH+PPの合計値の同一でない場合、多い方を残し、少ない方は打ち消される。
--残った側は(自分PH+PP)-(相手PH+PP)の数値まで、PH+PPが減少する。&br()''単なる相手PH+PPの合計値ではない。''
---減少はProjPriority側から。減少値がProjPriority値を上回ったの分ProjHitsが減少する。
---ProjPriorityが命中前に0だった場合、ProjHitsの減少処理の後ProjPriorityが-1される。
---ProjPriorityがマイナスの場合、次の減算処理で更に自分PPのマイナス分ProjHitsが減少する。
----ProjPriorityがマイナスでも、マイナスなだけでは消滅しない。
-計算例
--PH10,PP0のProjは、PH1,PP0のProjに4回目で相殺となる。
---一回目10-1で残りProjHitsは9、PPが0だったため-1され合計値はPH9+PP-1の8。(攻撃は9回分)
---二回目8-1で残りProjHitsは7に、PPが更に-1されるため、合計値はPH7+PP-2の5。(攻撃は7回分)
---三回目5-1で残りProjHitsは4に、PPが更に-1で計-3、合計値はPH4+PP-3の1。(攻撃は4回分)
---四回目は1対1と同一値のため相殺が発生する。
--PH5,PP5のProjは、PH1,PP0のProjに7回目まで耐え、8回目で打ち消される。
---一回目~五回目:PPが-1ずつ減っていき5回目でPPが0になるがProjHitsは5のまま維持される。
---六回目:5-1でProjHitsが-1され、PPが0のため-1され合計値はPH4+PP-1の3(攻撃は4回分)
---七回目:3-1でProjHistは2に、PPが更に-1され合計値はPH2+PP-2の0(攻撃は2回分)
---八回目:0対1のため自分側が打ち消され、相手側が残る。
//:AI制作時の注意点|
//-あれば
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
----
**■Lv-4-バグ応用
#region(■Lv4-ProjP1StateNo利用ステート奪取(通称:OTHキラー・トムキラー))
**ProjP1StateNo利用ステート奪取の仕組み
''※凶悪系技術※'' 通常のキャラでは絶対に使いません。
筆者は詳しくは知らないので多分の推測混じり。凶悪系では入門レベル。
以下、基本的な原理
-対象:[[SC-/HitDef]]を有する[[SC-/Helper]]を使用する相手
-[[SC-/ReversalDef]]で相手の該当Helperを[[ステート奪取]]。
-該当HelperからP1StateNo(''自分側変更'')指定したProjを射出する。
--P1StateNoの番号は該当Helperが読み込んでいたステート番号など。
--Projは''常に本体管理''のためステート変更するのは相手''本体''。
-そのProjを適当なくらい判定へ命中させ、相手のステートを変更させる。
--なお進まず・戻らず場合の回避手段として&br()別に通常ステートへ飛ばすProjを用意する場合も。
-相手本体に(元々飛び道具用だった)[[SC-/HitDef]]を実行させる。
-自分側の[[SC-/ReversalDef]]で相手本体の[[Target]]を取得する。
-あとは好きな様に料理する。
--最低限、相手がHitDefを持ったHelper飛び道具を使い、&br()攻撃判定のある相手アニメ、攻撃の通る相手ステートを知る必要がある。
--対策され[[SC-/HitDef]]が実行されない場合[[SC-/ReversalDef]]が当たらない。
応用としては
-相手に読み込ませるステートを対象飛び道具のではなく、&br()くらい判定が有効な適当なステートにし通常の攻撃判定を当てる方法もある?
-相手側が持っている殺害ステートを読み込ませて自殺させる手法もある。
-またHelper自体のステート奪取の方法は[[混線バグ>Target]]でも可。
由来などについてはニコニコMUGENwikiが詳しい。
//キャラに関することなのでコメントアウト。
//:OTHキラーの名前の由来|
//本体がくらい判定・攻撃判定を持たずHelperで攻撃をする、
//「オメガトムハンクス(Omega Tom Hanks)」という凶悪キャラおり、
//そのキャラの殺害手段として初めて確立された手法であったため、
//その手法を「オメガトムハンクスキラー」略してトムキラー・OTHKなどと呼ぶようになった。
//
//※なおオメガトムハンクス自身がそれを有しているわけではない。
//最初に搭載したのは608氏のD-Athena?とのこと。
//
メモリ変更を用いない手法としては基本であり究極の特殊殺害法。
#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
//----
//:※解説修正情報※古い履歴|
//●&font(12,b){日付:修正部分の概要}
//
----
2021-03-31T04:01:09+09:00
1617130869
-
1.0版
https://w.atwiki.jp/mugencns/pages/159.html
----
*■1.0版MUGENについて
Win版などとの差についてまとめるところ@予定
※初期編集者は1.0に疎いためわかってる情報のみ集積。
|~[[SC-/ReversalDef]]と[[T-/PrevStateNo]]|P1StateNo指定でのステート移動時にPrevStateNoが更新されない不具合の修正。|
|~同じX座標時の押し出し判定|1P2P基準から基本向き基準に。[[座標]]のページを参照|
|~壁までの距離|[[座標]]のページを参照。StateTypeによる幅が壁の押し出しに反映されない。|
|~トリガー情報の追加とか|いくつかある|
|~[[SC-/Projectile]]のパラメータなど?|"ProjEdgeBound"の数値が極大の場合、0として処理されるとのこと。この他にも同様の処理が行われている?|
*■1.1版について?
|~[[SC-/Explod]]|画面の拡縮機能追加に伴い?、射出のZ位置による拡縮対応するように?|
----
#pcomment(reply,20)
----
2020-05-05T12:53:54+09:00
1588650834
-
SC-/DestroySelf
https://w.atwiki.jp/mugencns/pages/212.html
戻る→[[ステートコントローラーの一覧]]
----
:※解説修正情報※|
●&font(12,b){2020-02-29:Helper,Explod射出関係についての説明を追記}
//●&font(12,b){日付:修正部分の概要}
//●&font(12,b){日付:修正部分の概要}
----
//ほかページヘのリンクはLv0のみで。(Lv1~でリンクしようとすると煩雑になりそうなので)
*■DestroySelf【Helper用・自身を消去する】
:▼概要|
実行した[[SC-/Helper]]を消去命令を出す。
''ステートの読み込みを停止するわけではない。''
※1.0版からは停止するようになったらしい?
:▼必須記述|
-無し
:▼オプション|
-無し
//&b(){Ctrl = (bool型) };Ctrlフラグを変更する。[[SC-/CtrlSet]]と同じ
//-省略時 変化させない
----
**■Lv1-記述例・補足・注意点
:記述例|
[State 2330, DestroySelf]
Type = DestroySelf
Trigger1 = AnimTime = 0
-アニメが終了した時点で消去命令を出す。
--消去自体は該当キャラ処理終了時点で行われる。
:補足|
-[[スロットID]]との関連性は該当ページも参照
--キャラIDの[[T-/ID]]と順番を決定するスロットDIは別管理。
--キャラIDは「同じIDが使いまわされない」のに対し、
--[[スロットID]]は「空いたスロットが使いまわされる」。
-[[Target]]に関することも該当ページを参照
--ヒットカウント、永続ターゲットに関するバグがある。
-消去のタイミングは''キャラのステート読み込みの直後辺り''の模様。
--※''検証不足''※ただし消失タイミングは140番や52番の処理の前後どちらかは不明。
:注意点|
-&b(){DestroySelfを実行した後、[[SC-/Helper]]や[[SC-/Explod]]などを射出するとエラーで落ちる。}
--※[[SC-/Helper]]や[[SC-/Explod]]の後にDestroySelfするなら概ね問題無く処理される。
--DestroySelf実行後、ステートを移動している場合気づきにくいため注意。&br()DestroySelfはなるべく番号ステートの最後尾に書いた方が良い。(消去させる際にヘルパー消去用ステートへ飛ばすなど)
-[[SC-/Explod]]は残らないようにすること。
--管理している親が消えると一部Explodはゴーストになって残ってしまう。
--[[SC-/RemoveExplod]]を掛けた上でDestroySelfする方が良い。
--&color(gray){※win版では確認できなかったが、1.1b1にて「Explod射出と同時にDestroySelfを行うとCNSファイルの[Size]のDraw.offset関係でズレが生じる」という報告あり。&br()そもそもDraw.offsetを変更しないか、DestroySelfのタイミングを遅らせる、あるいはExplod表示中はDestroySelfせずに最後RemoveExplodをかけてExplodを残さずDestroySelfする方が良いだろう。}
//:AI制作時の注意点|
//
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
//----
//#region(■Lv4-バグ利用)
//**■Lv-4-バグ応用
//あやしい仕様を活用する関係。
//#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
//----
//:※解説修正情報※古い履歴|
//●&font(12,b){日付:修正部分の概要}
//
----
2020-02-29T02:49:06+09:00
1582912146
-
File-/Airファイル
https://w.atwiki.jp/mugencns/pages/46.html
戻る→[[ファイルの一覧]]
----
:※解説修正情報※|
●&font(12,b){2019-02-08:Clsn#Defaultの指定について修正}
●&font(12,b){2013-01-22:5090番アニメは必須ではないっぽい・オプションCommonアニメを修正・再度}
----
*■Airファイル【アニメーション情報定義ファイル】
Animとして呼び出すアニメーションの定義ファイル。
スプライト表示の位置・時間・順番・効果の他、くらい判定・攻撃判定の設定も行う。
必須Animも存在しそれらは絶対に設定しておかなければならない。
※SFFファイルに登録する''必須スプライトの方については書いていません''。他のサイトを参照してください。
-参考:[[http://homotaro.s44.xrea.com/air.htm]]、MUGENのdocにあるair.txt、他
----
**Airの中身
-''用語について'' 簡単な概要を補足
--''Anim'':アニメーションのこと。またアニメーションの1組のこと。
--''Elem'':アニメーションの表示されている枚数のこと。
---Elem=1は1枚目(指定1行目)、2は2枚目(指定2行目)という具合。表示が長くても1枚は1枚。
--''アニメ総表示フレーム'':アニメが一周するまでの時間
---[[デバッグ]]表示にて左下表示の上から三段目の一番右の数字
---ただし[[デバッグ]]の数値は最後のElemの表示時間が''-1''設定だと-1と表示される。
--''Clsn1'':判定枠1、''攻撃判定枠の設定''
--''Clsn2'':判定枠2、''くらい判定枠の設定''
---''Clsn1Default'':常時指定枠1。指定行後のほぼ全てのElemへ入れる攻撃判定枠。
---''Clsn2Default'':常時指定枠2。指定行後のほぼ全てのElemへつけるくらい判定枠。
----Default系が指定されている場合、該当Clsnの無いElemはDefault指定の枠になる。
----反対に言うとClsnを指定しているElemでは該当Defaultは無視される。
----なおDefault系は基本的に最初に指定するが途中から指定・変更してもよい。
&b(){[Begin Action XXX]};Anim定義宣言。XXXにAnim番号がはいる。0以上のみ、上限不明。
&b(){Clsn1:X};下記するElemの攻撃判定枠の宣言。XにはこのElemで指定する枠の数を指定
&b(){Clss1[0]=-XX,YY,XX,-YY};判定枠の設定。[]は番号を0から始める。
&b(){Clss1[1]=-XX,YY,XX,-YY};-後ろ側,下側,前側,上側と、判定の距離を記述するのが基本。
&b(){Clsn2:X};下記するElemのくらい判定枠の宣言。Xは攻撃と同様、指定判定枠の数を。
&b(){Clsn2[0]=-XX,YY,XX,-YY};形式は攻撃と同様。
&b(){グループ番号,イメージ番号,X座標,Y座標,表示時間};Elem設定。それぞれの設定。
-グループ番号,イメージ番号はそれぞれSFFファイルで指定した番号を使用。
--X座標Y座標は基本的にSFFファイルで設定されてるのでほかと使いまわすときとかに設定。
-表示時間はこの行のElemを何フレーム表示させるか。
--最後のElemの表示時間に-1を設定するとループをせず、ずっと最後の画像を表示し続ける。
--ただし、通常Animtimeは-総評時間~0(ループ開始)の数値を返すが、&br()最後が-1設定の場合、Animtimeは1~経過時間を返す。
--ちなみに最中のElemを-1設定にした場合そのElem表示がスキップされる。
GN,IN,X,Y,F&b(){,HV,A};Elem設定オプション。説明下記。
-'',HV''部分の指定 反転処理
--''H'':左右反転指定
--''V'':上下反転指定
--''HV'':上下左右反転指定(180度回転)
---なおAirファイルの指定による反転はHiresの場合1ドットズレる、らしい。
-'',A''部分の指定 透過処理指定
--''A'':加算処理。画像を光らせるように表示。
--''S'':減算処理。明るいところほど暗く表示。
--''A1'':加算処理・50%。加算処理の度合いを半分にして表示
--''AS256D256'':256の数値は0~256までの数値。
---AS???:色の明るさ? 高いと通常・低いと黒化。
---D???:加算透過の度合い? 高いほど加算割合を増やす
---大体の参考。フェードアウトさせたい場合は、&br()AS256D0→AS128D128→AS0D256の流れでゆっくりと切り替える形になる。
--※ここでの透過処理指定は地面に映る影に影響しない。
--透過表示は[[SC-/Trans]]でも可能だが、ステコン側の場合はやや処理が重い。
-,HV,A部分は省略しても良い。
|参考|~D0|~D128|~D256|
|~AS0|AS0D0&br()真っ黒|AS0D128&br()黒半透明|AS0D256無表示|
|~AS128|AS128D0&br()暗い|AS128D128&br()半透明|AS128D256&br()弱加算透過|
|~AS256|AS256D0&br()通常|AS256D128&br()弱加算透過,A1と同じ|AS256D256&br()加算透過,Aと同じ|
GN,IN,X,Y,F;
GN,IN,X,Y,F;
&b(){Loopstart};途中ループを開始する地点。
GN,IN,X,Y,F;
GN,IN,X,Y,F;
-通常ループは-1が無い場合、最初のElemへ戻って表示を繰り返す。
-Elemの間でLoopStartを指定している場合、ループはその地点から行うようになる。
--LoopStart指定された場合の[[T-/AnimTime]]はループするElemの時点まで巻き戻る。
-ぶっちゃけ中身の編集は専用のソフトを上手く利用する方が分かりやすい。
--とは言え、読めるなら読めるで不便しにくいので覚えておいてもいい。
--ソフトと手打ちを上手く合わせていく、というのも十分アリ。
--特にソフトだとコメントアウトによるメモが消えることが多いため&br()メモをしながら書くなら手打ちが基本、ソフトは補助程度となる。
**■必須アニメ
#region(''最低限設定しておく必要のあるAnimの種類と番号'')
-''最低限設定しておく必要のあるAnimの種類と番号''
--[[Commonステート]]にて使用されているAnimであり、&br()[[ステート奪取]]にて使用されることもあるため、絶対に設定しておくこと。
--なお基本的にLoopStart指定、表示-1指定はしないほうが良い。
--AnimTime基準の処理を行わない一部のみ途中ループ・ループ停止使用可。
---ただし、一部ステートは表示-1設定の必要あり。
-くらい判定の設定は''全てに設定する方が良い''。
--くらい判定を設定しておかないと押し出し処理が行われない。
--ステート奪取された状態で呼び出された時に攻撃が当たらないケースもある。
---特に''気絶アニメ''は忘れられやすいらしいので注意。
:下記の表について|
-※参考サイトページの表を編集しただけのもの※
--そのため、Commonに使用されているもの一通り+α。
--あと検証不足で情報に齟齬があるかも。
-''必須'':必須アニメ
--''--'':オプション。存在しなくても表示に問題が無い。(オプション以外はなるべくあった方が良い)
-終了:アニメ終了時点での挙動について
--''--'':待機アニメ。アニメ基準の移動がなく、大体ループが自然でないといけない。
---ただしくらいアニメは全体ループが不自然になるケースあり。
---LoopStartによる一部ループや-1設定の必要があるケースも。
--''移動'':AnimTime=0などでアニメの変更を基本としたアニメ。''ループ・-1設定不可''
--''停止'':最終の表示時間-1設定必須。(AnimTime=0でそのアニメに変更後、静止するタイプ)
---※''移動''タイプのアニメは全体の長さをKFMと合わせておくほうが望ましい。
-細かくは実際のAirファイル・Commonを参考にして調整すること。
|~番号|~必須|~終了|~内容・補足|
|~ 0|必須|--|ニュートラルモーション。立ち待機なのでいくら長くても良い|
|~ 5|--|移動|0→立ち振り向き→0 ※準必須?|
|~ 6|--|移動|11→屈み振り向き→11 ※準必須?|
|~10|必須|移動|0→屈み移行→11|
|~11|必須|--|屈み待機。|
|~12|必須|移動|11→立ち移行→12|
|~20|必須|--|前歩き。なるべく歩き速度に合わせること。|
|~21|必須|--|後ろ歩き。同上|
|~40|必須|移動|ジャンプ始動→41~43|
|~41|必須|--|垂直ジャンプ|
|~42|必須|--|前ジャンプ|
|~43|必須|--|後ろジャンプ|
|~44|--|--|垂直ジャンプ降下。''※空中ジャンプ始動と共有''|
|~45|--|--|前ジャンプ降下|
|~46|--|--|後ろジャンプ降下|
|~47|必須|移動|着地。※4Fで行動可能に。|
|~番号|~必須|~終了|~内容・補足|
|~100|必須|--|前ダッシュ。Common編集すれば柔軟に設定できるが、&br()ステート奪取時、走る姿のつもりでを読みこませることも。|
|~105|必須|--|後ろステップ。Common編集すれば柔軟に設定可能。|
|~120|必須|移動|ガード始動・立ち→130,131|
|~121|必須|移動|ガード始動・屈み→130,131|
|~122|必須|移動|ガード始動・空中→132|
|~130|必須|--|ガード待機・立ち|
|~131|必須|--|ガード待機・屈み|
|~132|必須|--|ガード待機・空中|
|~140|必須|特殊|ガード終了・立ち。特殊の内容は[[ガード]]のページ参照。|
|~141|必須|特殊|ガード終了・屈み。端的には-1設定だと即時通常状態へ戻る|
|~142|必須|特殊|ガード終了・空中。|
|~150|必須|--|ガード硬直・立ち|
|~151|必須|--|ガード硬直・屈み|
|~152|必須|特殊|ガード硬直・空中。複数枚の場合、途中ループ必須とのこと?|
|~170|必須|--|時間切れ負け。オプション?とのことだが、Commonでは必須。|
|~175|--|--|時間切れドロー。オプション。|
|~180|--|--|勝利ポーズ。KFMだと設定されているが、Commonが存在しない。|
|~190|--|--|イントロ。KFMだと必須・移動型だが、Commonではオプション。|
|~195|--|--|挑発。KFMだと設定されているが、Commonが存在しない。|
|~番号|~必須|~終了|~内容・補足|
|~5000|必須|移動|上段ヒットのけぞり(弱)|
|~5001|必須|移動|上段ヒットのけぞり(中)|
|~5002|必須|移動|上段ヒットのけぞり(強)|
|~5005|必須|停止|上段ヒット戻り(弱)|
|~5006|必須|停止|上段ヒット戻り(中)|
|~5007|必須|停止|上段ヒット戻り(強)|
|~5010|必須|移動|下段ヒットのけぞり(弱)|
|~5011|必須|移動|下段ヒットのけぞり(中)|
|~5012|必須|移動|下段ヒットのけぞり(強)|
|~5015|必須|停止|下段ヒット戻り(弱)|
|~5016|必須|停止|下段ヒット戻り(中)|
|~5017|必須|停止|下段ヒット戻り(強)|
|~5020|必須|移動|しゃがみヒットのけぞり(弱)|
|~5021|必須|移動|しゃがみヒットのけぞり(中)|
|~5022|必須|移動|しゃがみヒットのけぞり(強)|
|~5025|必須|停止|しゃがみヒット戻り(弱)|
|~5026|必須|停止|しゃがみヒット戻り(中)|
|~5027|必須|停止|しゃがみヒット戻り(強)|
|~5030|必須|移動|吹き飛び|
|~5035|必須|移動|各空中ヒットと、落下及び立ち直りの間|
|~5040|必須|移動|空中立ち直り|
|~番号|~必須|~終了|~内容・補足|
|~5050|必須|--|吹っ飛び~落下|
|~5060|--|--|落下。5050から繋がり。|
|~5070|必須|--|足払いやられ|
|~5080|必須|--|ダウンやられ|
|~5090|--|--|ダウンやられ・浮き(無い場合5030使用)|
|~5100|必須|移動|やられ地面激突→5160|
|~5160|必須|--|地面激突からの跳ね|
|~5170|必須|移動|跳ねからの地面激突→5110|
|~番号|||↑↓順番が前後しているので注意。|
|~5110|必須|--|ダウン中|
|~5120|必須|移動|起き上がり→0|
|~5140|--|--|KOダウン(通常ラウンド。オプション)|
|~5150|--|--|KOダウン(決着ラウンド。オプション。使用には5140必須)|
|~番号|~必須|~終了|~内容・補足|
|~5200|必須|--|受身着地→着地|
|~5210|必須|--|空中受身|
|~5300|必須|--|気絶※''必ずくらい判定を設定すること''|
|~5500|--|--|コンティニュー画面(オプション。省略時は気絶が表示される。)|
//未実装とのことなので割愛
//|~5510|必須||コンティニュー画面でYesを選択したときの絵(オプション。未実装。)|
//|~5520|必須||コンティニュー画面でNoを選択したときの絵(オプション。未実装。)|
|~番号|~必須|~終了|~内容・補足|
|~5051|追加|??|真上吹っ飛び系。処理は5050~と同様? 同系統が一通り存在|
|~5052|追加|??|斜め吹っ飛び系、らしい。同上|
-505x系はオプションのCommonの特殊やられアニメ管理。
--揃えておけばCommonで1桁目の数値の1~9を判別して&br()吹っ飛び~倒れ~起き上がりまで表示を行う。
--初期でも1はupくらい、2はdiag-upくらい用に設定されている。
---3~9版は空き。揃えて505x番へ変更させる条件を加えれば使ってくれる。
--うつ伏せやられ~倒れなどの分岐もこれで管理できる。
-途中で対応アニメが無い場合は、通常のくらいアニメを表示。
|~番号|~移動|~アニメの種類|
|505x|--|特殊吹っ飛び開始|
|506x|--|特殊吹っ飛び最中|
|508x|--|特殊倒れ待機くらい|
|510x|移動|特殊倒れ着地→516xへ|
|511x|--|特殊倒れ待機|
|512x|移動|特殊起き上がり→立ちへ|
|514x|--|特殊倒れ・死亡・通常ラウンド|
|515x|--|特殊倒れ・死亡・決着ラウンド※使用するなら514x必須|
|516x|--|特殊倒れバウンド中|
|517x|移動|特殊倒れバウンド着地→511xへ|
:■100番Animについて|
-絶対というほどではないが、一部キャラではステート奪取時、&br()走る姿として読み込ませるケースがある。
-走る姿以外の場合101番などを基本とし、&br()100番をステート奪取での表示専用として使うことも可。
-ごく一部のキャラなので必須というわけではない。
:■特殊やられ用の共通Animについて|
-一部のキャラでは専用の特殊やられアニメを呼び出すケースもある。
-そうしたAnimはまとめられているので調べてみるといい。
-''対応するつもりがなくても、うっかり重複しないよう一度調べておくほうが望ましい。''
//ニコニコMUGENwikiの「特殊やられ」のページが非常に詳しい。
//>http://www30.atwiki.jp/niconicomugen/pages/2606.html
#endregion
//&b(){};
----
*■Lv1-記述例・補足・注意点
:注意点|
-必須アニメは必ず埋めておくこと。
--加えて必須スプライトも必ず埋めること。
-表示時間の指定は基本-1設定を使用しないほうが良い。
--最後のElemが-1設定だと「Animtime=0」が使えなくなる。
-キャラ用のくらい判定の横幅は可能な限り
--&b(){[[File-/CNSファイル]]で設定したキャラ幅より広くすること。}
--足りない場合押し出し処理の関係でガクつくことがある。
--[[座標]]のページも参照
:判定の付け方|
-''攻撃判定・くらい判定共に、判定を細分化して設定する必要はない''。
--判定を細かく指定するメリットはほとんどない。
--大雑把にくらい判定攻撃判定共に1~2枠ずつ程度でもよい。
---斜めの判定であれば、枠を細分化してもいいが。
-上記している通り''くらい判定の横幅はキャラ幅設定より広くすること''
-また''攻撃判定は基本的にくらい判定の内側に記述すること''
--攻撃判定発生前にくらい判定を伸ばす必要はないが、&br()攻撃判定だけだと[[SC-/HitDef]]の''Priority(優先度)が機能しない''。
---攻撃のPriorityは''互いの攻撃判定が互いのくらい判定に重なっている''場合のみ適応されるため
--ただし打ち消しの不可能な飛び道具などであれば食らい判定は必要ない。
-[[ステートを奪った状態>ステート奪取]]から[[SC-/ChangeAnim2]]で表示させるアニメの判定は
--基本自身基準ではなく、''想定する相手の大きさを基準とする''ほうが良い。
--少なくとも律儀に''自身の大きさに合わせても不自然''になりやすい。
---特に小さいキャラ対大きなキャラでは顕著になる。
---おおよそ自分の大きさから一回り大きく1~2枠程度でも良い。
なお判定枠の編集は専用のソフトなら画像に合わせて編集できて楽である。
:発生1F目の攻撃について|
-→[[発生1F目攻撃の弊害]]
:記述例1|
//Another YUKAのAirから。なおAnother YUKAはSFFAIRMAKER2にて作成
#aa(){
[Begin Action 200]
Clsn2:1
Clsn2[0] = -20, -115, 56, 1
280, 0, 0, 0, 3
Clsn1:1
Clsn1[0] = 10, -105, 46, -9
Clsn2:1
Clsn2[0] = -20, -115, 56, 1
280, 1, 0, 0, 3
Clsn2:1
Clsn2[0] = -20, -110, 51, 1
280, 2, 0, 0, 3
Clsn2:1
Clsn2[0] = -20, -105, 41, 1
280, 0, 0, 0, 3
}
-Elemは全部で4枚。全て表示時間は3F。
--Elem=2で攻撃判定を指定している
--判定設定自体は各Elemにくらい1個+攻撃1個までとやや簡素な指定。
:記述例2|
//KFM
#aa(){
[Begin Action 200]
Clsn2Default: 2
Clsn2[0] = -10, 0, 19,-80
Clsn2[1] = 0,-94, 12,-80
200,0, 0,0, 2
200,1, 0,0, 1
Clsn1: 1
Clsn1[0] = 16,-80, 61,-71
Clsn2: 3
Clsn2[0] = 19, 0,-10,-80
Clsn2[1] = 6,-94, 18,-78
Clsn2[2] = 19,-80, 61,-71
200,2, 0,0, 4
200,1, 0,0, 3
200,0, 0,0, 2
}
-Elemは全部で5枚。表示は2-1-4-3-2とバラバラ。
--くらい判定にDefaultが指定されている。
--Elem=3で攻撃判定と個別くらい判定を設定
---ClsnX:nの数値がキチンとそのElemで指定する枠の個数分。
----
2020-02-29T02:29:41+09:00
1582910981
-
参考ページ一覧
https://w.atwiki.jp/mugencns/pages/19.html
*参考ページ一覧
----
**方針メモ
-個別でURLを挿入していくと変更したい時に大変なことになるので、一部を除きこっちで管理。
-細かいページであればページ自体にリンク貼る方向でいいけど大雑把なページ関係はこっちにも表記
-細かい情報は補足できないくらいいろんなところからの情報も含まりたりしていますが…。
-一覧にはないけどKFMは重要な参考キャラ。
//可能な限り参考・引用元の管理人に承諾を取る。
//リンクは[[>>]]、>2個で。そうすると別ウィンドウで表示してくれるので。
----
*参考
|~サイト|~制作者・管理人|~備考|
|[[MUGENてなんじゃい>>http://homotaro.s44.xrea.com/mugen.htm]]|wm氏|元サイト名「無目的研究室」※親ページ消失&br()CNS系の基本解説|
|[[ステートコントローラー一覧>>http://homotaro.s44.xrea.com/scr2.htm]]|~|上記サイトのページ|
|[[トリガー索引>>http://homotaro.s44.xrea.com/tr.htm]]|~|上記サイトのページ|
|-|-|-|
|[[ADIのMUGENメモ>>http://mugen.niza.nobody.jp/]]|ADI|Wiki編集者&br()→[[twitter>https://twitter.com/angel_dimerk]]|
|-|-|-|
|リンク切れ※書き溜め雑記|DLS氏|[[Target]]のTargetState制御について&br()[[ガードした相手を巻き込まないTargetState 改良版>>http://dls1tomemo.blog129.fc2.com/blog-entry-568.html]]を参考&br()URLhttp://dls1tomemo.blog129.fc2.com/:|
|[[DHQの雑記とか>>http://dhq.blog137.fc2.com/]]|DHQ氏|[[キャラ作成上とりあえずやっておいた方がいいこと>>http://dhq.blog137.fc2.com/blog-entry-3.html]]は&br()制作者なら一度は目を通すといいかも。|
|-|-|-|
|[[MUGENの便覧>>http://mugenbinran.web.fc2.com/index.html]]|vesper氏|雑多な項目の詳細な情報があります。&br()特に【一覧】→「製作支援ツール一覧」は役立つソフトの紹介をしています。|
//http://homepage3.nifty.com/andil/mugen/
//書き溜め雑記[[>>http://dls1tomemo.blog129.fc2.com/]]
*情報提供
|~サイト|~制作者・管理人|~備考|
|[[FreedoMugen>>http://hitotume.iza-yoi.net/]]|BK氏|[[StateNo=140>Commonステート]]に関する情報提供・検証。&br()その他、多数検証をしています。|
|リンク切れ※初めてのページ|ワープスター氏|[[SC-/ReversalDef]]のバグに関する情報提供。サイトにはwin/1.0の解説あり。&br()1.0に関する検証など&br()URL:http://www.geocities.jp/pac_n_roll/index.html|
|>|>|~◇|
||スケルトン氏|ご報告|
||ワーキペレウ氏|Projectileについて|
||京太郎氏|諸記述について|
||沼の爪氏|Juggleについて|
//[[初めてのページ>>http://www.geocities.jp/pac_n_roll/index.html]]
*wiki
|~Wiki名|~備考|
|>|~ルールはWikiごと違い、細かいルールは全く異なることもあります。&br()Wikiの編集はそのWikiのルールをよく読み守って編集しましょう。|
|[[ニコニコMUGENwiki>>http://www30.atwiki.jp/niconicomugen/]]|ニコニコ動画をメインとするmugenのwiki&br()元が自由なニコニコである関係上、非常に情報量が多い。&br()下手なwikiよりも詳しく載っているものもある。&br()管理者もよく読んでいるため''当wikiの用語の基準はこのwikiに近しい''。&br()ただし当wikiには''当wiki独自の呼称も多いため要注意''。|
|[[MUGEN凶悪キャラwiki>>http://www14.atwiki.jp/kyouaku/]]|凶悪系に関しては該当wikiの方が優しい。|
#co(){
|[[サイト名>>URL]]|管理者名|備考|
}
----
2020-01-17T22:58:37+09:00
1579269517
-
T-/TeamMode
https://w.atwiki.jp/mugencns/pages/194.html
戻る→[[トリガー情報の一覧]]
----
:※解説修正情報※|
●&font(12,b){2020-01-17:「""」が不要であると報告を受けて記載を変更}
//●&font(12,b){日付:修正部分の概要}
----
//ほかページヘのリンクはLv0のみで。(Lv1~でリンクしようとすると煩雑になりそうなので)
*■TeamMode【チームモード】
:▼概要|
試合の自身のチーム形式を確認する。
自分の形式であるため、相手の形式は[[リダイレクト]]が必要。
:▼情報・書式|
&b(){TeamMode=(文字列)} ;(文字列)を確認する条件式、bool型
-対応文字烈
--TeamMode=&b(){Single}:シングル
--TeamMode=&b(){Simul}:タッグ
--TeamMode=&b(){Turns}:チーム
-目的とする文字列と完全に一致させること。
-ステートコントローラー一覧では!=も可能と書かれているが…
--否定条件は!(TeamMode=(文字列))したほうが確実かと。
----
**■Lv1-記述例・補足・注意点
:記述例|
[State a, a]
Type = xxxx
Trigger1 = !Time ;ChangeStateなどをしてきた最初のみ
Value = xxxx
-記述例での目的
:補足|
-特に無し
:注意点|
-※検証不足
--サバイバルモードでの相手側のモードは多分"Turns"?
//:AI制作時の注意点|
//-あれば
//----
//**■Lv2-細かいバグ回避
//注意点で書いたことを回避したい場合用。
//----
//#region(■Lv3-細かい応用)
//**■Lv3-細かい応用
//他の記述と組み合わせて使用する関係。
//#endregion
//----
//#region(■Lv4-バグ利用)
//**■Lv-4-バグ応用
//あやしい仕様を活用する関係。
//#endregion
//----
//**コメント
//細かい話し合い・確認が必要な場合に開放しましょう。
//#comment()
//----
//:※解説修正情報※古い履歴|
//●&font(12,b){日付:修正部分の概要}
//
----
2020-01-17T22:34:25+09:00
1579268065
-
性能階級
https://w.atwiki.jp/mugencns/pages/100.html
----
:※修正情報※|
●&font(12,b){2019-05-08:追記}
●&font(12,b){2019-05-01:ざっくり書き直し}
----
-''CNSとはやや離れた事だが、キャラ制作においては必要だと言えることなので。''&br()哲学的な話、配慮の話が必要無い方は読まなくても良し。
-参考:ニコニコMUGENwikiの「ランク付け」「神キャラ」のページ。
*■性能階級
|>|~全体的な性能の階級。&br()細分すると各階級でも上中下の違いがある|
|~強さ|~解説|
|~神~論外|論外:''神よりも勝負をするつもりの無いキャラ''&br()あるいは''防御面のみ凶悪キャラ''|
|~|神:''基本、通常の不利が存在しないキャラ''&br()特殊な攻撃によって相手を滅ぼす。|
|>|~システム的な壁&br()「(↑)凶悪キャラ」と他の一般的なキャラ(↓)との壁|
|~狂|''非常に有利の大きいキャラ''&br()不利が少なく一方的な展開は珍しくない。|
|~凶|~|
|~強|''有利不利を持ったキャラ''&br()このランク同士での勝敗は不安定なのが当たり前。|
|~並|~|
|~弱|''勝つつもりが無い・勝機の薄いキャラ''&br()特殊な状況であれば勝てるケースもある。|
**■階級を考える理由・利点
「勝つか負けるか」という"勝負"を行うには基本同程度の強さのキャラと戦わせることが必要。
階級が違うと強さも格段に違い、上位階級のキャラへ下位階級のキャラが勝つというのは非常に難しく「勝って当然・負けて当然」ということになりやすい。
そのため''階級の大きく異なるキャラ同士を同列に扱うことは、あまり適切とは言い難い''
&br()
なのでキャラ制作においては「どの程度の強さを目安に作るか」によって、戦わせるのに適した相手が変わってくるという事になる。
強さが違えば枠組みが異なってくるものであり、枠組みが大きく違うキャラ同士を同列に扱っても顰蹙を買うことになるだろう。
&br()
※そうした「枠組みを分けて考える」ことは非常に大切であるためこのページにまとめている。
**■ここでの「凶悪キャラ」の定義
「凶悪なほど強いキャラ」を指して「凶悪キャラ」とひとまとめにされることもあるが、ここにおける「凶悪キャラ」は「システム的な戦い方を主とした強力なキャラ」の総称。
システム的な戦い方をするわけでなければどれほど強く作られていても「狂」の範囲とする。
また「システム的に凶悪キャラの技術が使われているが、強さは他の一般的なキャラと"勝負"できる程度に調整されている」場合などは、単純には凶悪キャラと定義しない。
&br()
もちろん基本的な有利不利のバランスからすれば、凶以上は凶悪なほど強く・狂に至っては論外と言っていいほどの差があるが、そうした単なる強さではなく「システム的な壁」を前提条件として「凶悪キャラ」を定義する。
ちなみに普段は一般的なキャラ程度の強さでも、異常に強いキャラや正常でない挙動をするキャラを相手にした場合にそれをトリガーとして凶悪キャラとしての本領を発揮するというキャラもいる。
----
**■弱
極端に言えば「いかに負けるか」を考えているキャラ。
そこまで行かずとも、非常に耐久性の無いキャラのこと。
体力が1だったり、あるいは攻撃に対して自殺を行うなど。
究極、相手に干渉せず自殺をする。
**■並~強
基本的なキャラ。
大抵の行動のリスク・リターンが釣り合っており、
上手く立ち回れば勝てるし、下手に立ち回れば負けるという範囲。
KFMも基本的にはこの部類。(永久使用では凶に入るが)
**■凶~狂
性能的に強いキャラ。
大抵の行動のリスクが小さく・リターンが大きい。
優しい部類なら並~強では上手く立ちまわれば勝てることもあるが、
厳しい部類だと並~強では勝つ方法が存在しないことも多い。
(※なお神〇〇といった名前のキャラでも、凶~狂程度の性能のキャラもいる)
**■神~論外
概ねシステム的に強いキャラ
いわゆる格闘ゲームとは異なる、「mugen」をしているもの。
特別「負け方」が用意されていない限り狂以下に負けることは無く、
キャラによっては用意された「負け方」で負けることはあるようだがそれ以外で正常に負けることをしない。
しかしシステムな弱点を突くことによってそうしたキャラさえも死亡させることのできるものもいる。
「負け方」が用意されていないなおかつシステム的な防御力の高いキャラは「論外」と分類されることも。
「キャラ同士が戦う」ようで「作者同士の戦いや遊び」に近く、
強さの関係性もほぼ固定的な"上下関係"だったり"相関関係"だったりする。
※どちらかというと「キャラを使って楽しんでもらう」だけでなくキャラ制作自体をより深く楽しむだとかmugenの可能性を研究するような方向性で楽しまれている面もある。
※凶悪キャラの技術を使っていても「狂」以下と勝負できる(真っ当に負けることもある)よう調整されているキャラに関しては「狂」以下と考えられる。
----
**■システムレベルの壁・「凶悪キャラ」について
MUGENは非常に自由度が高いため「普通の相手なら負けないキャラ」も容易に作る事ができる。攻撃力を上げたり、常時無敵を付与したり、ステートを固定したり。強力な性能にすれば、そうでないキャラに負けることは基本無くなるわけである。
キャラによっては強さだけではつまらないと特別な「負け方」を用意している場合もあるものの、簡単には負けないようになっているため正当な方法(普通の攻撃を与えてライフを削りゼロにすること)で倒せることが基本無いこともある。
ただそれらだけでは(ここで定義する)「凶悪キャラ」には満たない。
MUGENは自由度が高い反面、細かい部分は怪しい仕様の宝庫となっている。
そうした怪しい仕様も当然のように駆使していくのがいわゆる本格的な''「凶悪系」''。
普通には負けないキャラも、特殊な仕様を利用することによって強引に相手を倒すのである。
特に神系は''意図的にバグを引き起こす''ことで相手を倒すことも日常茶飯事で、
神系同士ではバグを前提に「バグを起こされても対応できる」ようにするような感じ。
…特に極端な場合''試合情報のメモリーを書き換えて相手を死亡させる''ことすらある。
ちなみにそうして仕様をより厳密に研究して利用することが多いため、結果的にmugenの仕様そのものを解明するということがある。
それによって凶悪系に限らず通常のキャラでも起きていたようなバグやよく分からない仕様が解明されたりといったケースもあるとのこと。
ただ結局、他の一般的なキャラとは目的・枠組みが大きく異なるものである。
''通常のキャラでは使いようのないシステム''は当wikiでは基本、割愛する。
----
**■いわゆる凶悪キャラ未満だが凶悪なこと
凶悪キャラの技術を使わずとも、標準的な仕様の中でも凶悪な仕様は多く存在する。
-攻撃系
--無敵が多い攻撃・射程の長い攻撃・[[発生1F目の攻撃>発生1F目攻撃の弊害]]・持続の長い飛び道具
--高火力な攻撃やコンボ・十分使える性能の即死攻撃・限定での十割
--使いやすいガード不可技(投技含む)・使いやすい当て身投げ
---つまり:反応しにくい技・反応しても対処のしにくい技・''反応できない技''
-防御系
--隙のない無敵回避・使いやすい当て身投げ・不利のない攻撃
--高い防御力・常駐アーマー・ノーコストくらい抜け(ガーキャン含む)
--特殊な無敵処理・体力回復(死亡回避)・ステート抜け
---つまり:ダメージを受けにくい・コンボを受けにくい・''攻撃を受けない''
こうしたものが低コストあるいはノーコストの場合、凶以上の仕様である。
特に、凶より上の狂では大抵こうした性能を''大量に''持っている。
そこまでいくと同程度の性能を持っていなければ手も足も出ない。
もちろん、そうした仕様でも''相応のリスクやコスト''があるのなら、
全体的な強さが強以下で保有しているケースもそう珍しくはないものの、
搭載する際は特に注意が必要な仕様であると肝に銘じておく方が良い。
***■凶悪キャラの領域について
極端な例になるが、標準の仕様での最強と言える''常時即死攻撃・常時無敵''でも
下手な組み方だと''いわゆる凶悪キャラには勝てない''。下手すると簡単に殺害される。
''即死や永久''があり1ヒットから勝てるキャラでも''触れられない相手には勝てない''し、
''常時無敵''で基本的な攻撃が通らないキャラでも''システム的な穴からなら殺せる''。
&br()
さらなる強さを求める場合、簡単ではない「システム的な強さ」を求め''凶悪系''への理解を深める必要があるわけである。
----
*■キャラの強さと「勝負」について
''公開するキャラを制作する人向けへの啓蒙、注意点''
キャラの強さの半分程度は概ね「狂」の範囲までならキャラ作者の裁量で決まる。
作者がどの程度の強さにするか考えてキャラを調整していくことで"決める"ものであり、
その上でプレイヤーや操作AIの技術によって残りの半分が決まり、強さを左右する。
特に「勝つか負けるかの勝負」が成立する範囲のキャラ同士であればどちらが勝つか分からないことが多く、有利不利があっても致命的なものでなければ番狂わせが起こりうる。
そうした範囲においては「その試合でどちらが勝つか」といった楽しみ方を繰り返しすることもできる。
ただ「凶悪キャラ」やそれに近いの範囲では作者の裁量というより作者の技量によっても左右する。
うまく倒せるように作られているか・耐久できるように作られているか、という状態で、
その範囲では一般的な格闘ゲーム的な戦い・操作ではなく「システム的な戦い」となる。
そのため「凶悪キャラ」や「凶悪キャラ以外では倒し難いキャラ」などでは特に「勝つか負けるかの勝負」が成立しないことが多くなる。
システム的な比べ合いで「勝てる要素を持ったキャラ・負ける要素の無いキャラ」が勝ち、
そうでないキャラは固定的に負けるといった状態になりやすい。
うまくランダム的な要素によって変化するよう仕組まれていて、それによって勝敗が変化しうる場合に限ってどちらが勝つか予測しにくくなる程度である。
つまり(特にコンピューター戦で)「MUGENでは、ただ闇雲に強さを追い求めてしまうと"勝負"という点において予測しやすいような状態に陥りやすい」。
勝てる相手にはほぼ絶対に勝てるが、勝てない相手には全く勝てない「勝ち負けの分かりやすいキャラ」となってしまいやすい。
そして「予測できない楽しみ」という点は"強さ比べを一回して終わり"となってやすく、それ以降勝ち負けという楽しみ方は損なわれることになる。
また「キャラに特別な思い入れがある」あるいは「どうしても蹂躙したいキャラがいる」といった勝つか負けるかの勝負以外の理由でもなければ「その強さを楽しむ」ということはしにくい。
そうした''短絡的に強さだけを求めても"楽しみ方が極めて限定的なものになってしまいやすい"という事はよく理解しておくべきである''。
**■補足:キャラの楽しみ方について
MUGENのキャラで使用者を楽しませる要素は大きく3系統に分類できる。
''「エフェクト」「変動性や多様性」「攻略性」''
「強さ」は楽しませる要素としては「それらを発生させる間接的な要素」でしかない。
-''エフェクト''
キャラの外見や設定、ネタや演出効果など『試合の中身とは本来関係ない部分』のこと。
極端な例えをするなら「球体がただうごめいて戦う」のと「かっこいいキャラがかっこいい演出を交えながら戦う」のとでは、かっこいいキャラが戦っている方が圧倒的に楽しみやすい。
試合内容とは全く関係なくとも、娯楽として"見栄え"は非常に重要な要素、あるいは最も重視される要素である。
なお「エフェクト」は試合の画面に表示されるものに限らない。キャラが持っている設定や性格、立ち振る舞いや扱われているネタなども「見ていて楽しめる」というエフェクトとして機能する。
ちなみに「極めて強く作られたキャラでも親しまれているキャラ」は大抵このエフェクトの要素が極めて優れている。「見ているだけでも楽しい」ため、勝負という面において難があっても親しまれるわけである。
ただ「強いキャラ」ほど一方的に負ける可能性を減らせ、自分の持つエフェクト・演出を発揮しやすい傾向もある。
-''変動性や多様性''
端的に言えば「パターンにならないこと」。試合を見ていて予測がしにくく、真新しさを感じられることである。予測しにくい・多彩な動きはそれだけ「勝負している」ように見せて楽しませることに繋がる。
ただ一方的にならないこと・一方的にされないこと・勝ったり負けたりすることについては、「互いの強さが合っているかどうか・有利不利が極端でないか」によって変わってきやすいため、相手側のキャラにも影響される。
ただ伝統的なパターンによるエフェクト、あるいは一方的な勝利による攻略性といった楽しみ方もあるため、この点はあくまで他を引き立てる一要素に過ぎない。
なお言っている通り「極端に強いキャラ」は変動性を持ちにくいという性質を抱える。
-''攻略性''
見る側としては「凄いと思うようなことをやってのけること」
プレイヤーとしては「特定の物事を達成できるかどうか」
「不利な状況から逆転して勝つこと」や「扱いの難しい特殊な技を成功させること」、あるいは格上に見えるキャラ相手に勝ったりなどのこと。
ただ『勝負に勝つこと』も単純な攻略性であるものの"強い方が単純な戦法で圧倒する"といった展開では攻略性が薄くその点では楽しみにくい。
一応「基本的なキャラの強さとしては大きな格差があるが、相性は非常によく通常なら弱い方が強い方を倒してしまう」という展開であれば、凄いと思われやすく楽しまれやすい。
しかしながら、うまく凄いと思わせる展開になるかなどはやはり相手側のキャラに大きく左右される。
互いの強さが合っていない場合は一方的に倒されるばかりになりやすく、プレイヤー操作で挑む以外に楽しめるパターンは稀となる。
また極端に強いキャラでは相手が良い勝負のできる同程度に強いキャラなどでなければ攻略性を感じさせることはできないし、また強さが同ランクでも極端に強いキャラにおいて起こりやすい極端な相性や単純な試合展開では攻略性を感じさせにくい。
-強さの要素
書いている通り「強さ」は試合の変動性や攻略性の見せ方に影響を与える要素だが、「相手側のキャラの強さ」によっても左右される
ある程度、勝負のできる相手がいるような範囲の強さであれば様々な相手と様々な戦いを楽しむことができる。
ただ特に極端な強さのキャラの場合どうしても変動性や攻略性の見せ方に難を抱えやすいという性質があり、同程度の強さの相手側も同様の性質を抱えているという問題がある。
そのためその辺りでは特に魅力的なエフェクトがなければ楽しんでもらいにくい。
mugenのキャラで"楽しんでもらう"ためには演出も考えずに「ただ強ければいい」というわけではない。
そして"楽しんでもらう"ことができなければキャラを使って貰うことさえままならない。
そのため広く楽しみやすいキャラを目指すのであれば基本並~強、派手なキャラであれば凶~狂も視野に強さをうまく調整すると比較的親しみやすくできるだろう。
-「凶悪キャラ」の楽しみ方について
「凶悪キャラ」は単純に使用者に楽しんでもらう、「使ってもらって楽しんでもらう」だけではなく、
「mugenの仕様を利用してどのようなことができるか」といった研究・検証などを作者などが楽しむ面も大きい。、
また、ただ見る分にもキャラについてよく覚える前は「どちらが勝つのか」というのは分からないし、それはそれで楽しむことができる。
当時「絶対的に強い」と思われていたキャラクターをも倒す方法が発見され、新たなキャラによって倒されるというのも中々にエキサイティングである。
**■補足:"意図的であるかどうか"について
「意図的な性能」についてそれ自体をどうこう言うのはナンセンスである。
もし面白くないなどと感じるとしても、それはその作者の''意図''と合わないだけであり、
「意図的に強くした」のなら、そうした''意図''を「間違っている」というようなこともまた適切ではない。
作者としても意図的ではない性能については、修正が入るかもしれない。
----
-以下、補足の原典。
#region(''格納'')
#region(''■強さと魅せの話'')
※以下の話は主に「通常のゲーム上の戦い」や「それを観戦すること」を主として書かれた文章です。
筆:ADI 原典:[[http://mugen.niza.nobody.jp/Neat.txt]]
''「強さの極限に娯楽はない。そして求められるのは娯楽である。」''
:■娯楽の重要性|
MUGENにおいて''強さは主題とはなりえない''。
強いだけなら神系になるが、その類であっても''面白みのないキャラは避けられる''。
そのクラスになるとカラーによって強さの変動する仕様のキャラは珍しくない。
見ていても使ってもつまらない場合どうなるか? ゴミ箱に棄てられるだけである。
重要なのは''いかに楽しませるか''にあり、
それは''プレイヤーを楽しませる''・''観戦者を楽しませる''両方を含む。
強さというのはそのための要素に過ぎない。
:■魅せとは?|
魅せの要素は分解すると3つに分類できる。
-1.キャラ・ネタ・演出効果など試合の中身とは本来関係のない''エフェクト''
-2.試合の有利不利が変わり続け、同じ展開も少なく勝敗の読めない''変動性・多様性''
-3.難しく大変そうな動作をやってのけたと感じさせる''攻略性''
人によって重視する部分や感じ方はことなるが、ほぼこの3系統である。
:エフェクト|
極端に言えば''一切の特徴のない真っ白な人物同士が演出もなく戦う''のと
''よく知っているキャラ同士が凝った演出を交えながら戦う''のとでは、
圧倒的に後者の方が楽しみやすい、というもの。
試合とは関係ないが、''娯楽において最も重要視される要素''である。
エフェクトがあるのとないとでは楽しみやすさは雲泥であるし、
特に神以上の凶悪キャラではエフェクトが9割。
凶悪キャラでなくともエフェクトは要素の大半を占めているいっても過言ではない。
ただしエフェクトと一口に言っても、試合中の効果演出のことだけではなく、
キャラの性格・立ち振舞といったものもエフェクトの一部。
いわば「''その試合を構成する全ての要素''」がエフェクトである。
:変動性|
試合の分からなさ・真新しさのこと。単純に言えばパターンでないこと。
一方的にならないこと・一方的にされないこと、勝ったり負けたりすること。
ただし伝統的なパターンによるエフェクト、
あるいは一方的な勝利による攻略性も存在するため、
絶対的ではなく、あくまで他を引き立てる一要素に過ぎない。
特に凶悪キャラは基本的に変動性を持たない。
:攻略性|
観戦者としては''凄いと思うようなことをやってのけること''であり、
プレイヤーとしては''特定の物事を達成できるかどうか''である。'
この要素も知識や技術によって感じ方が変化し、その割合は大きい。
分かりやすい攻略性はキャラ性能の差が少ないのにチーム戦で連勝すること。
あるいは挑発を出しきるといったこともエフェクトを併せた攻略性である。
勝つことは単純な攻略性ではあるが、単純過ぎる勝利方法では非常に軽い。
明らかに性能の差がある試合で強いほうが勝っても攻略性は感じられない。
:|
変動性、攻略性は相手との性能差・相性差によって大きく左右される。
丁度いい相手と戦えるかどうか、その際に''強さ''が手段となる。
'''強さ''そのものをエフェクトの一部としている場合もあるが。凶悪系は特に。
:意図的な性能|
なので''意図的な性能''について、どうこうと言うのはナンセンスである。
面白くないと感じるのならその制作者の''意図''と反りが合わないだけだ。
意図的でない性能については、修正が入るかもしれない。
:勝敗というエフェクト|
''勝敗''自体は結果に過ぎず、いわば試合そのものと関係のない''エフェクト''である。
特に人の手の入らないAI戦であれば、''勝敗は偏りのあるランダム''にすぎない。
星数だけに主題を置いてしまったら、サイコロの目を競うのとなんら変わりない。
:|
特にAIにおいて、冒頭の言葉は肝に銘じていかなければならない。
キャラにおいても、もし強さだけを求めたなら、
MUJGENの底の見えない地獄に突き落とされるようなものだ。
#endregion
#endregion
----
2019-05-08T18:55:31+09:00
1557309331