アーケードのストーリーボードに関すること

ストーリーボード、いわゆるOP・EDのことですね。
触ってみて分かったことをちょっとだけ書いておきます。
しかしストーリーボード作成に関することはググってもなかなか出てきませんねー。
一応ステージ背景の作成方法とほぼ同じだそうですが・・・

１、「Assert failure in charsel.c line 3162」のエラーは
　　ストーリーボード再生前に判定が行われる。

このエラーはmugen.cfgのAI.RandomColorを0に設定し、
更に登録されているキャラのdefファイルにpal.defaultsが
正常に設定されていない時に出すエラーです。
つまり、ストーリーボードが再生前にエラーが出るということは、
その時既に相手キャラが決定されているということですね。
まあそんなに役立つ情報ではないですがｗ

２、背景の記述で使う「type = PosSet」は「type = PosAdd」と同じ効果。

ストーリーボードでもステコンのようなものがあって、
スプライトの位置を変えたい時にPosSetを使おうとしたのですが、
どうやらPosAddと同じように指定した「x=aaaa」の値だけ加算されるだけのようです。
ものすごーく使いづらいですねー・・・
もしかしたらこちらの記述ミスかも知れませんが・・・

３、ストーリーボードの記述にエラーがあるとそのまま対戦に入る。

例えばストーリーボードで使えないステコン
(バックグラウンドコントローラという名称だと思うのでバクコン？)
を記述すると、ストーリーボードが再生されずに対戦に入ります。
エラー落ちしないのが意外でした。


とりあえずこのくらいで。
たぶんまだまだ良く分からない仕様があるかもしれませんね。

ParentVarSetの代入する変数番号に小数

[State -2, 【デバッグ】]
type = ParentVarSet
fv = 39.0
value = 1
trigger1 = 1

このような記述はエラー落ちします。
VarSetの変数番号に小数は使えないということですね。
しかし、

[State -2, 【デバッグ】]
type = ParentVarSet
fv = 1.0*39.0
value = 1
trigger1 = 1

このようにするとエラー落ちせず、ちゃんとfvar(39)に代入されます。
もちろん警告メッセージは出ますけどね。

全然役に立たない情報ですが、ちょっと実験してて
分かったことなので一応載せておきます。

用語解説

ttp://lunatic284.blog90.fc2.com/blog-entry-7413.html

確かにいろいろ神キャラの技術はその単語だけでは分かりにくいのが多いですねー。
実際自分も即死に挑戦してその内容を知ることが多かったですしね。
そんな隠すような内容でもないと思うので一部補足してみます。

トムキラー：ヘルパーHitDef当身→p1stateno付きProjectileで
　　本体にヘルパーの読むべきHitDefステートを読ませる。
オロチキラー：個人的には混線でヘルパーを奪い、p1stateno=169995
　　(LifeSet=0のステート、49000でもOK)のProjを出させるのがオロチキラー、
　　汎用だと混線即死返しと呼んでますね。
あゆあゆキラー：存在しないステートに飛ばすとMoveTypeがそのままになるので、
　　大ダメージと同時に存在しないステートに飛ばし、アーマーによるダメージ処理を
　　無視してMUGEN内部のダメージ処理を引き起こす。
究極kfmキラー：UKFMはとあるヘルパーとAnimを同期しているので、
　　ヘルパーを奪って食らい判定のあるアニメにすると攻撃が当たるようになる。
欠損キラー：メインはnormalヘルパーを相手に出させること。
　　大抵欠損キラーと言うとここまでです。
　　欠損少女の場合はヘルパーHitDefを当身してnormalヘルパーの出るステートに
　　送ることでヘルパーを奪い、更にHitByステートに送ることで即死できます。
間者・スパイ・バグヘルパー：混線で奪ったヘルパーにnormalヘルパーを出させることで
　　自分で自由な挙動をさせることのできるヘルパー。
　　利点はplayer型ヘルパーをうまく奪ってもすぐにステ抜けされて、
　　なかなかステート返しできない相手でも常にヘルパーを奪うことができること、
　　間者ヘルパーだけ奪っている状態なら相手の挙動がほぼ狂わないことなど。

あとpersistent偽装は恐らく誰かが、
persistent=256でChangeState・SelfStateをすると凍結中でも行動フラグを
リセットできる、というのをそう呼んだのが始まりだったような気がします。
まあ偽装というのはちょっと違いますかねｗ

他には、

行動フラグ：hitpausetimeが付いた状態でChangeState・SelfStateすると
　　そのステコンの位置(Statedefから数えた順番)と同じ位置のステコンが
　　hitpausetimeが無くなるまで機能しなくなってしまう、という仕様。
超即死改：超即死ステートを何度もループさせることで、Aliveの値が膨大でも
　　即座に0にすることができるようにすること。
　　この時に行動フラグが邪魔になるのでChangeStateを大量に置くか、
　　persistent=256を使えばちゃんとループできる。
　　

こんなところでしょうか。
mugen凶悪wikiに既に書いてあるものはある程度除外しました。
余計に難しくなったものや誤解を生む表現、
そもそも間違ってるのもあるかもしれませんｗ

hitpausetimeが発生するタイミング

HitDefやReversalDefヒット判定時(つまり全キャラ行動後)ではないのかもしれません。
潜入ヘルパーをそのヘルパーより早く行動するヘルパーで監視していたのですが、
ReversalDefを受けた瞬間は監視ヘルパーでhitpausetimeを感知できないのです。
もしかしたらhitpausetimeを1ずつ減らしているのも
そのキャラが行動する直前かもしれません。

これは困りましたね・・・
一部のキャラで512ステコンエラー落ちが出る最大の要因でしょう。
今までは本体でもヘルパーでも超即死ステコンを読み込ませる相手が
多かったから良かったものの、ちゃんとヘルパーには超即死を読み込ませない相手には
ほぼ確実にエラー落ちを起こしてしまいます。
変数を使ってでもこのエラーを回避しないといけませんね。

被弾ヘルパー

被弾ヘルパーというのは、例えばトムキラーはProjectileを発射しても、
そのProjectileを誰かに当てなくては当然ステート移動が起きることはありませんので、
そのProjectileを受けるためにわざと食らい判定を出しているヘルパーのことです。
そしてこのProjectileを受けるヘルパーにHitOverRideを設定してはいけません。
P1StateNoやP2StateNoが設定されたHitDefがHitOverRideを設定してあるキャラに
当たることが無いのと似たような感じで、P1StateNoやP2StateNoが設定された
ProjectileはHitOverRideの設定されたキャラに当たりはしますが、
自分も相手もステート移動が起こらないからです。

そして、被弾ヘルパーにはもうひとつ主な役割があり、
それは自身にHitPauseTimeを付けるためのHitDefを受けるというものです。
相手が食らい判定を持っていなかったり無敵だったりすることは非常に多いので、
確実にHitPauseTimeを発生させるためには食らい判定ヘルパーを出すのが無難です。

しかし、被弾ヘルパー1体にこの両方の役割を持たせるのは難しい場合があります。
それは相手が一切の途切れなくP2StateNoが設定された攻撃を垂れ流している時で、
P2StateNoが設定された攻撃がヒットすると、不具合回避のために
強制的に無敵になってしまうという仕様があり、
被弾ヘルパーがP2StateNoの設定された攻撃を受けて無敵になって
HitPauseTimeを付けるためのHitDefが当たらない、という事態が発生します。

これが非常に厄介なんですよね・・・
これを回避するためにはHitOverRideを設定していない被弾ヘルパーと、
HitOverRideを設定した被弾ヘルパーで2体のヘルパーを出してやる必要があります。
永続ターゲットを利用している場合、被弾させると強制的にターゲットが外れますので、
既存のヘルパーを流用することも難しいです。
現在のヘブンズゲートのヘルパー使用数は既に許容できる数を越えていますので、
更に増やすなんて迷惑な行為はしたくないのですが・・・
常にP2StateNoのついたProjectileを出しているキャラが本当に多くて困ります。

A-Bombの「assert failure in array.h line 110」

わざわざ隠すことでもないので記事に。
というかこれは知ってもらわなければならないことだと思います。

恐らくA-Bombが「assert failure in array.h line 110」というエラーで
落ちてしまうことはある程度知られていることだと思います。
このエラーは存在しないアニメ番号を指定した時に起こるものです。
例えば、AnimElemTime(0)という記述があればエラー落ちします
(AnimElemTime(x)はx番目のアニメになってから経過した時間を表し、
アニメは一番最初のコマを1番目として扱っている。
つまりAnimElemTime(0)は存在しない0番目のアニメを指定している)。

では、A-Bombの場合は何が原因かというと、airファイルの一番下にあるこれです。

; Dizzy
[Begin Action 5300]

(ﾟдﾟ)

製作に携わったことが無い方のために言うと、
アニメーションに本来あるべき画像が一切指定されていないのです。
そして相手のヘルパーを奪って当て判定のあるアニメや
食らい判定のあるアニメを検索しようとすれば、
5300番のアニメーションにChangeAnimした瞬間エラー落ちします。
これを回避するには混線でのアニメ取得をあきらめるか、
試合開始からしばらくはアニメ取得を行わずにさっさと倒してしまうか、
専用対策をしなくてはなりません。
技術力などの問題ではありませんので、
そういうのを試すキャラとしては不向きでしょうね。

はっきり言えば作者さんのミスなわけですが、
これでMUGENが起動できることの方が問題だと思います。
神キャラ自体バグの塊ですが、これはElecbyteに文句を言いたい気分です。
通常のキャラだって同じミスをすればエラー落ちしますしね。


ちなみに5300のアニメは全キャラ共通で存在するコモンアニメで、
コンティニュー画面でのアニメーションに使われています。
つまり、A-Bombがアーケードモードやサバイバルモードで敗北すると即落ちです。

F1が時々死なない理由

前提知識として、F1は混線即死返しで死にます。
現在の神キャラの基本技術ですね。注意点は試合前に混線を完成させる必要があること。
言ってしまえば即死の難易度は高くありません。
ステートを奪う攻撃もそれしかないので、神オロチのように
ただの投げ技を学習して返してしまうようなことも無いです。
それでもF1を倒せないということは稀に起こったりします。

その理由は、ステート返しは自分のステートを読み込ませているので
ステートを奪っているわけではないため、MUGEN本体AIが動くからです。
MUGEN本体AIと呼んでますが、これはMUGENが勝手にコマンドを実行することと、
勝手にジャンプしたりしゃがんだりガードしたり歩いたりすることと思ってください。
例えば「AIが無い状態」と言ってもカンフーマンは勝手に無造作に動き回りますね。
これらの処理は-3ステートよりも前に行われます。
-3ステートより前に実行されるChangeStateがあると思ってください。
キャラを製作したことがある方ならお分かりだと思いますが、
コマンドファイルに「上ボタンが押されたらジャンプステート(40)に行く」とか、
「前/後ボタンが押されたら歩きステート(20)に行く」という記述はしてないはずです。
それでもちゃんとジャンプしますし歩きます。
また、AIを作ってると「そんな時にジャンプする命令なんて書いた覚えは無い！」
と困ってしまった経験が一度はあるかもしれません。
これらはMUGENの内部処理、つまりコマンド実行とChangeStateが
-3ステートより前に行われているからです。

話は戻りますが、このChangeStateは恐らく無条件で行われるというわけではなく、
通常キャラが技を発動する場合と同じようにトリガーが設定されているようです。
これは全くの予想ですが、内部処理に書かれたChangeStateはこんな感じでしょうか。

[State -4, ジャンプ]
type = ChangeState
value = 40
triggerall = command = "holdup"
triggerall = StateType = S
triggerall = ctrl
trigger1 = random < xxx
trigger1 = (他の条件等、割愛)

そして、ステート返しによって特定ステートに飛びますが、
ステートを奪われていないので(?)ctrlが1のままであり、
ChangeStateが実行され、特定のステートを読み込ませることができません。
特にF1は試合が始まると常にctrlが1なので、物凄く頻繁にこのChangeStateが起きます。
デバッグでF1のStateNoを見れば20や40や10になっているのが分かると思います。
これがF1が倒せなくなる理由です。
運が悪ければ神キャラトップクラスの方々でも倒せない可能性はあります。
物凄く遠回りな言い方で申し訳ないです。もっと簡潔に書きたいのですけどね。

試してませんが、自分の考えていることが正しいならF1を自分で操作して
ずっと上ボタンを押してると誰も倒せなくなると思います。

対処法ですが、これから挙げるのは本当に効果があるのか
分からないものなので、その点にご注意ください。

１、原因は特にMUGEN本体AIが歩こうとすることなので、
　　　自分本体を相手の近くに配置してやりMUGEN本体AIが歩こうとしないようにする。
２、MUGENのオプションでDifficulityを下げることでMUGEN本体AIの行動確立を下げる。

このくらいでしょうか。２は実経験で効果があるような感じでした。
しかし本当に効果があるなら忘れられがちなこのオプションがこんなところで
意味を持つのかと思うと不思議な気持ちです。

何か間違いがあったらご指摘ください。

HitDefのAttrの特殊な記述

以前、当身されにくいHitDefのHitDefAttr発生条件についての記事を書きましたが、
その後身長学習のためにいろいろ試してみて分かったことをメモ用に記事にしておきます。

１．attr　=　,NA
このように1つ目の項目を空にすると、ある特殊なケースを除いて
ReversalDefが機能しなくなります。神キャラではこのような設定をしたHitDefで
自分のヘルパーを殴ることで安全にhitpausetimeをつけたりしています。
なお、この時の1つ目の項目である空間属性は「S(立ち状態)」扱いになるようです。

２．attr　=　S,AA
このように2番目の項目の最初を「A」にしてもエラー落ちしません
(普通はN、S、Hのどれかを記述します)。
とはいえ特別な意味は無く、「H」と記述するのと同じ効果になるようです。
恐らくNotHitByなどでAを指定できるようにするためにエラー落ちしないのでしょう。

３．attr　=　S,N
このように2番目の項目の2つ目を省略してもエラー落ちしません。
そしてこの場合だと特別な効果があって、
HitDefAttrはA(打撃)、P(射撃)、T(投げ)全てを兼用するようになります。
よってこの属性を指定したHitDefで相手を攻撃しようとすると、
打撃属性無効の相手にも、射撃属性無効の相手にも、投げ属性無効の相手にも
攻撃が当たるようになり、全属性無効でないと回避できません。
特定属性が無効のキャラはそれなりにいるのでなかなか使えると思います。
なお、HitOverRideで特定の属性のみ反応する場合でも常に反応し、
複数のHitOverRideを使って属性に応じて挙動を変えるようにした場合は
slotの値が小さい方のHitOverRideが優先されます。


そして未だに身長学習方法は確立できていないという・・・ｗ

当身されにくいHitDefのHitDefAttr発生条件

http://lunatic284.blog90.fc2.com/blog-entry-6059.html

上はlunaticさんのブログでの「hitdefattr 発生条件」という記事です。
非常に興味深い内容ですよね。並キャラにも神キャラにも使えそうな仕様(?)です。
そして最近ヘブンズゲートのAIを作っていて(もうすぐ再びパソコンを封印するのですが)、
この仕様を用いて相手の身長を学習しようとしたわけです。
当身されにくいHitDefを実行したヘルパーが相手と接触したら
HitDefAttrが出るのでその時の高さを記録すればいけるのかも？
普通のHitDefだとイントロ中無敵の相手に学習させることはできないけど、
当身されにくいHitDefならこの問題を突破できるのでは？
ジャッキーは別の方法で身長を学習していて確実性は非常に高いのですが、
かなり反則的な方法を使っていてこのキャラには搭載させたくなかったので、
こちらの方法を試してみようと上記の記事を見てから思っていました。

そして挑戦してみたのですが・・・何故かできない。
無敵状態の相手に接触させたのにHitDefAttrが発生しません。
もちろん無敵ではない相手にはちゃんとHitDefAttrが発生していました。
どうなってんだちくしょー！何か特殊な条件があるのかー！
とか思いながら今度は無敵を設定する側をいじってみて分かりました。

当身されにくいHitDefで無敵状態の相手と接触した時にHitDefAttrが
発生するためには、無敵にする方法が
１、type = HitBy　で　value =
２、type = NotHitBy　で　value = SCA,AA,AP,AT
というものでない時のみということです。
ちょっとピンとこないかもしれないので更に言うと、
type = NotHitBy　で　value = SCA
という方法で無敵にした相手にはHitDefAttrが発生してしまうのです。

本当に意味分からんｗｗｗｗｗｗｗ
どっちも同じ完全無敵なのに・・・どういうことなの・・・
他にもいろいろ試してみると、当身されにくいHitDefの属性がNA(通常打撃)の時に、
type = NotHitBy　value = SCA,AA,NP,SP,AT
という状態(超必飛び道具属性のみ食らう)の相手にもHitDefAttrが発生しました。
これは単なる予測ですが、無敵状態の設定には
S、C、A、NA、SA、HA、NP、SP、HP、NT、ST、HT
のそれぞれが格納されるメモリがあって、
それらがすべて埋まった時はHitDefAttrが発生しないのかもしれません。

しかしこれが分かったのは良いのですが、
本来の目的である身長学習をどうしましょうか・・・ｗ

heightについて

最大Lifeや最大パワーゲージ、歩く速度や重力等の基本データを設定する部分のうち、
「Size」のところにある「height」という設定項目があります。
これは、入力された数値の高さまで相手が自分より上にいると、
自分と相手の「当たり判定」が接触していてもすり抜けられる、という意味を持ちます。

これが意外に知られていないようで、キャラの中にはheightの値を
そのキャラの身長と同じ値に設定している場合があります。
相手のAIに自分の身長を知らせる意図でこうしている方もいらっしゃるかもしれません。
身長が高くないキャラであればこれでも構いませんが、身長が高いキャラの場合、
ハイジャンプ等を使わないと相手を飛び越せなくなる可能性があります。
古いゲームの移植キャラだとジャンプが低く、
ハイジャンプも持っていないというケースもあります。
相手を飛び越せないということは格ゲーの戦略のひとつであるめくりと、
それに付随する駆け引きができなくなるということですから、
実際の見た目の身長よりも値を小さくする方が親切だと思います。

で、これだけだとまるで誰かを批判しているような印象を与えてしまうので、
このheightの値が適用される条件について少し調査したものを載せておきます。


■条件１、飛び越す側と飛び越される側との「ぶつかり判定」が接触している。
ここで言う「ぶつかり判定」は「当たり判定」と別物と思ってください。
X軸ではそれぞれのground.frontやair.frontを考慮したもので、これは地上と同じです。
そしてY軸ですが、これが少々特殊で、飛び越される側はheightの値、
飛び越す側は自身の足元(Clsnで言えば0の高さ、
デバッグモードでキャラの名前等が表示される位置)まで「ぶつかり判定」があります。
つまり飛び越す側の下辺りに「当たり判定」が無くて、「当たり判定」を考慮した高さが
飛び越される側のheightを越えていても、そのキャラの足元が
相手のheightを越えていなければ飛び越すことができないということです。

■条件２、飛び越される側のStateTypeがSになっている。
つまり飛び越される側のStateTypeがS以外だと、
飛び越す側と飛び越される側の「ぶつかり判定」が変わるということです。
その時の「ぶつかり判定」は単純にY軸上の「当たり判定」が用いられます。
X軸上の「ぶつかり判定」は常にground.frontやair.frontを考慮しているようです。
また、飛び越す側のStateTypeは特に影響を与えることが無い模様。
この仕様上、飛び越される側のheightが低く、屈んだ時の姿勢が高い場合、
立っている時よりも屈んでいる時の方が飛び越し辛くなるという珍現象が起きたりします。