目次

冪乗(累乗)の計算

冪乗を計算する演算子**はx.0**y.0またはx.0**yまたはx**y.0というように引数の一方がfloat型でないと正常な値を返さないことがあります。
int型で出したい場合はfloorかceilを使ってください。
また、float型は元々誤差が生じるので、大きな値(7桁以上?)では誤差が出る可能性があります。
引用元1:整数乗[製作日記]
引用元2:引用?されてたので、注釈を[製作日記]

トリガーのRandomの発生確率のズレ

トリガーのRandomは0~767以下の方が768~999より発生確率が高いです。
原因を知りたい方はこちらを御覧ください:擬似乱数その3[制作日記]

読み込みと処理順

ファイルの読み込み順

defファイルに同項目が複数指定されている場合(st=が2つあるなど)

上側に書かれているファイルのみが読み込まれます。
(読み込まれないのでエラー落ちするようなエラーがあってもエラー落ちしない)

異なるファイルに同じStatedefがある場合

下記の優先順位に従います。
st > st0 > st1 > st2 > ・・・ > st8 > st9 > cmd > StCommon
この優先順位で上位にあるファイルのStatedefのみ読み込まれます。
(余談ですがStateを書けるファイル指定は上記の13個です。)

同ファイルに同じStateDefがある場合

最も上に書かれているStatedefのみが読み込まれ処理されます。

試合中の各フレームごとの処理順

プレイヤーの処理順

P1 > P2 > P3 > P4 > ヘルパー群(※ヘルパーに関しては詳しくは下記参照)
しかし、movetype=Aのプレイヤー(ヘルパーも含む)は他のプレイヤーより優先されます。
例:P2とヘルパー2がmovetype=Aの場合、
  P2 > ヘルパー2 > P1 > P3 > P4 > ヘルパー1

各プレイヤーのStatedefの処理順

[StateDef -3] > [StateDef -2] > [StateDef -1] > [StateDef 個別]
なお試合開始時にプレイヤーはStateNo=5900に存在します。

ヘルパーの処理順

基本的には出した順番ですが、消去されたヘルパーがある場合変わることがあります。
まず、ヘルパーはcfgファイルの設定で最大56まで出せるようになります。
このときヘルパーは入ることのできる場所が56部屋あるとし、
ヘルパーを出すと1部屋目から順に入っていき、消去されると部屋から出て行くと考えます。
消去され空いた部屋がある場合、
新たに出現するヘルパーは前から順に部屋を見て行き、
途中に空室があればそこに入ります。
例えば5部屋目まで埋まっていった時に3部屋目が出ていった場合、
6個目のヘルパーは6部屋目ではなく3部屋目に入ります。
このため、ヘルパーの処理順は
1個目のヘルパー>2個目のヘルパー>6個目のヘルパー>4個目のヘルパー>5個目のヘルパー
注意点:movetype=Aの場合は上記の通り全プレイヤーの中で優先度が上がる

stcommonの仕様

defファイルの項目stcommonには主にコモンファイルを指定します。
このstcommonは他の項目と若干異なる仕様があり、
指定ファイルがキャラフォルダ内に存在しなかった場合、dataフォルダ内の同名ファイルを参照します。(dataフォルダから同パス)
例としてKFMではstcommon = common1.cnsとして指定されていますが、
KFMにはフォルダ内には存在しないためdataフォルダ内のcommon1.cnsが参照されています。

キャラによっては独自のコモンファイルを使うためにキャラフォルダ内にコモンファイルを置く場合があります。
しかしここでその独自のコモンファイルの名前をcommon1.cnsとするのは避けたほうが良いでしょう。
これはそのファイルに「typeでステコンを指定していない、triggerが無い、必須パラメータが無いのいずれかを満たすstateが存在する」
もしくは「stateが一つも存在しないstatedefが存在する」
といった通常はエラー落ちする場合に問題が起こる可能性があるためです。

上記のエラーがキャラフォルダ内のcommon1.cnsファイルにある場合、
MUGENはdataフォルダ内のcommon1.cnsも読み込みます
そしてキャラフォルダ内のcommon1.cnsのエラー箇所より前までのstatedefと、
dataフォルダ内のcommon1.cnsの全statedefが読み込まれます。
ただし重複したstatedefはキャラフォルダのものが使われ、
重複していないstatedefはそのまま両方のファイルのものが使われます。
(ある意味14ファイルにStateを書けるとも言えるが・・・。)

このためキャラフォルダ内のcommon1.cnsではエラー落ちする箇所があっても
dataフォルダ内のcommon1.cnsと被ったstatedefであった場合、
common1.cnsのstatedefは正常なのでエラー落ちしません
(ただし、キャラフォルダ内のcommon1.cnsの最初のstatedefにstateが一つも存在しない場合は通常通りエラー落ちします。)
エラー落ちしないことにより独自のコモンファイルが正常に動作していないことに気づかない可能性がありますので、
独自のコモンファイルを作る際にはcommon1.cns以外の名前にするのが良いでしょう。

敵(味方)コマンドのリダイレクト参照に関して

 敵や味方のコマンドをリダイレクト参照すると、commandの値が正常に取得できないことが多いです。
 これはそれぞれのコマンドの真偽はcmdファイルでの「[Command]のname」(以下ラベルと書く)が登録されている順番によって管理されているためです。
 なので参照される側のn番目のラベルの真偽を参照したい場合、
参照する側はn番目のラベルの真偽を判定する
という方法でしか参照できません。
例えばcmdファイルで
1P側のキャラのコマンド設定を
[Command]
name = "1"
command = a
[Command]
name = "1"
command = b
[Command]
name = "2"
command = c
2P側のキャラのコマンド設定を
[Command]
name = "one"
command = x
[Command]
name = "two"
command = y
[Command]
name = "three"
command = z
のように設定し、2P側が1P側のコマンドをリダイレクト参照(enemy,commnd)する場合を考えます。
 1P側でaまたはbを押した際は、1番目のラベル(command="1")が真になりますが、
これを2P側が参照するには2P側の1番目のラベルを使い、enemy,command="one"としないと参照できません。
 同じように1P側でcを押した際は、2番目のラベル(command="2")が真になるので、(3番目に見えますが上2つは同じラベルなのでこのようになります)
2P側は2番目のラベルを使い、enemy,command="two"としないと参照できません。

ただし例外としてcommand="recovery"のみはラベルの位置ではなく、[Command]のラベルで判断されます。
例えばcmdファイルで、
1P側のキャラのコマンド設定を
[Command]
name = "a1"
command = a
[Command]
name = "b1"
command = b
[Command]
name = "recovery"
command = s
[Command]
name = "c1"
command = c
2P側のキャラのコマンド設定を
[Command]
name = "recovery"
command = s+a
[Command]
name = "a2"
command = a
[Command]
name = "b2"
command = b
[Command]
name = "c2"
command = c
のように設定し、2P側が1P側のコマンドをリダイレクト参照(enemy,commnd)している場合を考えます。
 まず1P側がbを押した際は、1P側も2P側も2番目のラベル("b1"と"a2")が真になります。
 次に1P側がaを押した際は1P側の1番目のラベル("a1")が真になりますが、
2P側の1番目のラベルの"recovery"は位置ではなく名前のみで判断されるため真になりません。
 そして1P側がsを押した際は1P側の3番目のラベル("recovery")が真になり、
2P側は1P側の"recovery"が真のため3番目のラベル("recovery")が真になりますが、3番目のラベル("b2")は真になりません。
 最後に1P側がcを押した際は1P側も2P側も4番目のラベル("c1"と"c2")が真になります。

 以上から、あるFに相手にどの方向キーやボタンが入力されているかを参照するだけでも、
単コマンドとrecoverコマンドのラベルの登録位置が一致していないと完全なコマンドのリダイレクトできません。
 単に何かのボタンが入力されたことを判定するだけの場合でも、互いのrecoverコマンドのラベルの登録位置が一致していないと、 参照する側のrecoverコマンドと参照される側の登録位置が同じコマンドのリダイレクトはできません。

味方のコマンド参照をする場合も同様のことが言えます。

HelperのID指定におけるnumhelper(*)の参照先の予想

下記のような記述(カンフーマンに追加するとしゃがむ度にヘルパーを召喚する)で、
ヘルパーAとBが交互に1つずつ出て欲しい(NumAとNumBが交互に1と0)のだが、
召喚するHelperのID指定にnumhelperを用いると上手くいかない。
[Statedef 10000]
type=s
anim=170

[State ヘルパー(10000)消去]
type=Destroyself
trigger1=Ishelper(10000)
trigger1=Numhelper(9999)
trigger1=Time>5
[State ヘルパー(9999)消去]
type=Destroyself
trigger1=Ishelper(9999)
trigger1=Numhelper(10000)
trigger1=Time>5


[Statedef -2]

[State しゃがむと召喚]
type = Helper
trigger1= Stateno=11&&Time = 5
ID = 10000-Numhelper(10000)+(var(11):=Numhelper(10000)&&0)
Stateno = 10000
Ignorehitpause= 1

[State クリップボード]
type = DisplayToClipboard
trigger1 = 1
text = "NumA=%d,NumB=%d,var(11)=%d"
params = Numhelper(10000),Numhelper(9999),var(11)
Ignorehitpause = 1

上記の記述で起きる事。

A=Helper(10000)、B=Helper(9999),var(11)=Numhelper(10000)
大文字=存在するヘルパー、 小文字=destroyselfしたヘルパー
意図してない動作:消したヘルパーをnumhelperがカウントすることがある。
Helperの召喚位置
(下段はdestroyself後)
召喚後の実際のAの数 召喚後の実際のBの数 var(11)
(召喚前のNumHelper(A)の値)
A 1 0 0
AB
aB
0 1 1
BB 0 2 1
BBA
bbA
1 0 0
BbA
Bba
0 1 1
BAa
b
Aa
1 0 0
BAb
Baa
0 1 1
BBa 0 2 1
BBB 0 3 1
BBBA
bbbA
1 0 0









実際にメモリエディタなどで調べられていないので原因の予想です。
解決策としては
消去・再召喚を行うHelperをIDに使わない。
または
[State しゃがむと召喚]
type = Helper
trigger1= Stateno=11&&Time = 5||(var(10):=numhelper(10000)&&0)
ID = 10000-var(10)
Stateno = 10000
Ignorehitpause= 1
のように事前に参照して変数に代入し、その変数をIDに使う。
など。

最後に
質問に答えていただい方や解説していただいた方に感謝です。
ページのトップへ戻る
inserted by FC2 system