NumHelperの引数

とあるキャラの記述を見ていたら、NumHelper(xxx)のxxxの値が
2147483647(2^31-1)を越えているキャラがいたんですよね。
しかしその記述は正常に動いていました。警告メッセージも無いです。
AnimやStatedefは2147483647を越えると自動的に2147483647として
扱われるのですがこちらも同じようになるのでしょうか？

と思って調べてみましたがその通りなようです。
NumHelper(2147483647)にしても同じように動きました。
そしてNumHelper(2147483646)にしてみると動かなくなりました。
つまり2147483647を越える値は2147483647に自動的に
置き換わっているということですね。
type=Helperステコンで2147483647を越える値を指定しても、
そちらの場合においても2147483647に置き換わっているようです。

HitDefとProjectileのヒット判定処理順

全ての本体とヘルパーのHitDefの接触判定・処理を行ってから、
Projectileの接触判定・処理を行っているかもしれません。
詳しいことは調査していないので確実に言えるわけではないのですが、
相手にこちらのProjectileが当たっていないと思ったら、
どうやら相手が自身のヘルパーで自身を常にHitDefで殴っていて、
それによって無敵状態が発生してこちらの攻撃が
当たらなくなってしまっているようでした。

結構これには悩まされました・・・
あまり攻撃をProjectileに頼らないように変えることも
考えなくてはならないかもしれません。

Projectileのprojedgebound

Projectileのprojedgeboundの値が2147483327を超えると
そのProjectileが消えてしまうみたいです。
一般的な数値の限界値である2147483647から320を引いた値ですね。
320というのはMUGENの画面の大きさですから、それが何か関係あるのかもしれません。
しかし詳しい原因については良くわからないです。
他のprojstageboundやprojheightboundは
限界値でも大丈夫だったのにどうしてこれだけ・・・

本当に限界値でも大丈夫なのか不安なので、
とりあえず2140000000くらいにしておくといいかもしれないですね。

mugen.cfgの設定と重さ

mugen.cfgのそれぞれの設定と重さがどれくらい関係しているのかを調べてみました。
mugen.cfgの中の[Config]という部分限定です。
他の部分が重さに関係あるかは調べていません。

■GameSpeed
まずこれを変えることは無いですので調査しません。

■DrawShadow
これも変えることは無いと思いますので未調査。

■AfterImageMax
処理の重さにそれなりに関わっている気がしますが、
10、20くらい増やしたところではあまり変わらない気もします。

■LayeredSpriteMax
どれだけ大きな値にしても何故か変化はほとんどありませんでした。

■ExplodMax
重さに非常に大きく関わってくるところです。
1000変化すれば違いが分かるくらいは影響していそうです。

■SysExplodMax
試合中の重さにはほとんど影響がありませんでした。
しかしセレクト画面等の試合外での重さに影響しているようです。
とはいえ10000くらいにしても大きな変化は無いくらい微々たるものです。

■HelperMax
さすがに神キャラを動かすなら56であってほしいので割愛します。

■PlayerProjectileMax
意外なほどに重さに影響があまり無かったように感じました。
とりあえず10000増やしたくらいではあまり変化が無さそうです。
ちなみに増やしすぎるとLayeredSpriteMaxの値をいくら大きくしても、
MUGENがキャラ読み込み後にエラー落ちすることがあるようです。
キャラ差が何故かありますが、ヘブンズゲートだと
31890くらいを超えたあたりでMUGENが落ちました。
ちょっと興味がありますが今回は深く調べていません。


今回の実験結果を見る限りExplodMaxが
試合での重さに大きく関わっているみたいです(Explodを誰も出してなくても)。
他の部分はある程度大きくしていても問題ないように感じました。
なので重いと感じた時はExplodMaxをいじると良いかもしれません。
製作者サイドとしてはエフェクトにExplodよりProjectileを
使った方が良い場合もあるのかも・・・？
とはいえProjectileはownpalが使えないという欠点がありますけどね。


しかし今回実験していて思ったことですが、
MUGENって起動するたびに重さがだいぶん変わっているみたいですね・・・
なので今回の実験結果もかなりあいまいなものになってしまいました。
もし体感で違うような印象を受けた場合は教えていただけると嬉しいです。

Targetリダイレクトで落ちる場合

複数Targetを保持している時に、ステートコントローラーのパラメータで
Targetリダイレクトをするとフリーズする場合があります(トリガーは問題無し)。
たとえばTargetLifeAddのvalueの部分でTargetリダイレクトをするとフリーズです。
この辺りは割と製作者さんなら知っている人も多いと思います。
というか知ってもらわないと困りますｗ

しかしパラメータによっては落ちないこともあるみたいで、
たとえばVarSetの変数代入は問題なくできますし、
HitDefのpausetimeなどでもフリーズしたりはしません。
valueを用いるところは大抵落ちるようですが例外もあって、
上記のTargetLifeAddのパラメータの1つであるabsoluteに
Targetリダイレクトを用いるとフリーズしました。
フリーズする基準がよく分からないですね・・・
本当はもっと調べた方が良いのですが、VarSetが問題なくできるなら
あまり気にしなくても良いかもしれないので後回しになりそうです。

今更ですがステコンオバフロについて

ほとんど自分用のメモみたいなものですが・・・
全てignorehitpause=1がステコンについている場合です。


●ステコンの順番に対応するアドレスの値が0の時、

１．ChangeState(以下SelfStateも含む)、persistent=xの場合(xは256で割った余り)

→対応するアドレスの値がxになる。

２．ChangeState以外(大抵はNull)、persistent=xの場合(xは256で割った余り。
ただし129〜255は意味をなさない)

→対応するアドレスの値がx-1になる。


●ステコンの順番に対応するアドレスの値が0以外の時、

→ChangeState、それ以外に関わらずアドレスの値が-1される。
　ただし対応するアドレスの値が129を越えていた時は即座に0になる。


●persistent=0の時、

→アドレスの値に変化無し。


●トリガーの条件を満たさない時、

→アドレス操作に関してはpersistentを書かなかった時と同じ挙動になる(？)。
　対応するアドレスの値が0以外なら-1されるが、
　0だった場合はpersistent=xと書いても0のまま。


とりあえずこんなところだと思います。
間違っている部分があったらご指摘ください。

ModifyExplodの奇妙な仕様

ModifyExplodでposを変えたい時はpostypeを一緒に指定しないと全く変化しません。
本来postypeを省略した場合は「p1」と記述したのと同じ扱いになりますが、
ModifyExplodの場合は省略しても「p1」と記述したのと同じにはなりません。
恐らくExplodステコンの場合と違って各パラメータに関する記述が無いと
何の処理も行われないのだと思います。

ちなみにModifyExplodでは弄れないパラメータが幾つかあります。

anim・・・弄れない。何と不便な・・・
ID・・・弄れない。そもそも"ID"と記述して何のExplodを変化させるか指定しますしね。
pos・・・弄れるがpostypeを同時に指定しないといけない。
postype・・・弄れる。
facing・・・弄れるがpostypeを同時に指定しないといけない。
　　おまけに何故か-1→1はできても1→-1はできない。
vfacing・・・弄れるがpostypeを同時に指定しないといけない。
　　おまけに何故か1→-1はできても-1→1はできない。なんでfacingと逆・・・
bindtime・・・弄れる。
vel・・・弄れない。
accel・・・弄れない。
random・・・弄れるがpostypeを同時に指定しないといけない。
　　えっ？なんで弄れるんですか？ｗ
removetime・・・弄れる。
supermove・・・弄れる。
supermovetime・・・弄れる。
pausemovetime・・・弄れる。まさか時止め関連を弄れるとは・・・ｗ
scale・・・弄れる。
sprpriority・・・弄れる。
ontop・・・弄れる。
shadow・・・弄れる。
ownpal・・・弄れない。まあさすがにこれは弄れちゃいけないでしょう。
removeongethit・・・弄れる。
trans・・・弄れる。
alpha・・・弄れる。

間違っている部分もあるかもしれませんが、このような結果になりました。
弄れるとは普通思わないものが弄れたり、弄れないと非常に不便なものが
弄れなかったりとよく分からないですね。特にanimとvel。

MUGEN内部のガードステート移行条件

http://dhq.blog137.fc2.com/blog-entry-2.html#more

＞3．フレームの開始時点か、ヒット判定が行われる時点で自分のcommand="holdback"&& command!="holdup"が成立している

つまり人間が操作する時は上入力がある場合MUGEN内部処理で
空中ガードステートへ移行してくれないというわけです。
どうりでチキガや逃げジャンプガード、飛び込みガードがやりづらいと思いました・・・
空中ガードに限りステコンでガードを行うようにさせて対処します。
これは多くのMUGENキャラ製作者さんに広まってほしい知識ですねー。

一応私の行った対処法は-3ステートに

[State -3, 空中ガード]
type = ChangeState
value = 132
triggerall = !IsHelper
triggerall = var(59) = -1
triggerall = command = "holdback"
triggerall = InGuardDist
triggerall = StateNo = 50 && StateNo != 132
trigger1 = ctrl

この記述を入れています。var(59)はAIか人操作か判断するためのものです。
StateType=AではなくStateNo=50としているのに特別な理由はありません。
空中攻撃の後空中ステートに戻らずctrlsetしている場合は
StateType=Aの方が良いかと思います。
StateNo!=132があるのはtimeがずっと0にならないようにするためです。
不要だと思いますがもしかしたらAI殺しになるかもと思いましたので。


ちなみに一番上で挙げたサイトはMUGENに関する知識が色々あって面白かったです。
特に並〜凶キャラを作る方は知っておくべき知識が結構あるかもしれませんね。

bindtime

これを0に設定できないのが不便ですね―。
0にした場合、基準位置を失ってpostypeが勝手にleft扱いになってしまうようです。
値を最小の1にした場合でも、1FはExplodが本体に追従してしまうので困りものです。
今回の本体Explod表示に関しては別に解決法があるのですが、
これから先この仕様に悩まされることが多く出るかもしれません・・・

ReversalDefのHitFlag

実はReversalDefにもHitFlagを設定できます。
恐らくHitDefで設定できる項目は全て設定できるのではないかと思います
(attrも設定できます。ちゃんとHitDefAttrも発生しますが、
相手には当たりません。その代わりReversalDefを食らいます)。
ただし、それぞれの項目がちゃんと機能しない場合が結構あります。
たとえばHitFlagに何も書かなかった場合でもしっかり当身します。
HitFlag=Pにすると一応Projectileに反応するのですが、
ReversalDefのp1statenoに移動はするものの、相手は何の変化も無いですし、
自分も相手もhitpausetimeが設定した値になりませんし、
相手の飛び道具がガード不能技でもガードされた扱いになります。
挙動を見るに、HitFlagのMAに対してはReversalDefで反応するのに対し、
HitFlag=Pの部分はHitDefと同じように反応しているのかもしれません。
Projectileから食らい判定を消したら反応しなくなりましたしね。