データ置き場

＜プレイヤーが攻撃する時の回避の判定順＞
マヌーサ($059F8D)
会心($059FA6)
回避判定($059FC8)

関連記事：回避（モンスターがプレイヤーに攻撃する場合） 

2014.01.19追記: 手っ取り早くバグの対策をしたい場合は最近公開した判定ツールを使う事をお薦めします。

【グレムリン戦までのエンカウントでの確認事項】
・敵のサイズを考慮しなくても、見かけ通りにエンカウントグループを考えるだけで大抵の場合、グループ分けを把握できる！
大灯台2～3Fではエンカウントしない場合、しても”ドラゴンフライのエンカウントや1～2匹のエンカウントだけ”の場合であれば、グループ分けは見た目通りになり確実に把握できる。この場合なら慣れてしまえば瞬時にグレバグが起きるか判定可能。
道中で4体目までのグループ番号を確認し続ければグレバグをほぼ判別可能

～4体目までのグループ番号つけ方～
敵ごとにグループ番号が割り当てられ、同じ番号であれば同じグループになる。左端の敵を0とし、隣の敵はグループ（種類）が変わる度に1増加させる（画像参照）。
(敵の総数制限・サイズ制限にかかっておらず、)出現が3体以下であれば残りの番号は以前のエンカウントのものを引き継ぐ。例：0123の状態から同グループ2体(00--)のエンカウントした場合0123→00[23]　[]内が番号を引き継いでいる。引き継ぐ場合には -を適宜記入することにする。
さらに具体的に：ラリホーアント2、グレムリン1、アンデッドマン1(0012)がでて、次にゴーゴンヘッド1、グレムリン1、ラリホーアント1(012-)が出た場合（どちらも4～8Fのエンカ）、4匹目のアンデッドマンの番号が引き継がれ0122となる。ラリホーアントとアンデッドマンのように種類の違う敵のグループ番号が同じものとして扱われるので戸惑うかもしれないがこれで問題ない。

ただし2～3Fの3体エンカウントでは4匹目の番号が最大3通り想定される場合がある。 3匹目と同じ、一つ高い、前のエンカウントの番号を引き継ぐの3通り。

2～3Fで3体のエンカウントであっても最終エンカウントで次のような構成であればグレバグは起きない
サーベルウルフ3匹のみ、ミイラおとこ3匹のみ、3体目がアンデッドマン
（グレムリンの構成：一つ目は4匹(0000)もしくは3匹,1匹(0001)の構成。2つ目は3匹,1匹(0001)の構成。3つ目は2,1,1匹(0012)または4体共別グループ(0123)の構成。）

【対処：そのままではグレバグが起きる場合】
グレバグは宝箱を開ける段階で4体目までのグループ番号に番号の欠如があると起きる
グレバグが起きるグループ番号（全パターン）：0002,0003,0022,0023,0013,0113,0020,0103
つまり”4体目までのグループ番号で1や2が欠けてなければバグ回避できる。”
（0121のように番号の並びがおかしいだけならフリーズしない）

4匹のエンカウント(32.80%)を出せば回避可能。
既に書いたが、次のエンカウントが最終エンカウントであっても良い（ただし大灯台2～3F）。
サーベルウルフ3匹のみ、ミイラおとこ3匹のみ、3体目がアンデッドマン
（一つ目はグレムリン4匹もしくは3匹,1匹の構成。2つ目は4体の構成。3つ目は3～4グループの構成。）
これらいずれかになる確率は32.80+20.69=53.49%

4体目までのグループ番号で1だけ欠けていてグレバグが起きる場合(0002、0020、0022、0023の場合)(0003は除外)、2グループ以上のエンカウントが出ればほぼバグ回避される(例外は0023の時で001[3]や011[3]になる場合がある)

万が一グレバグが起きたら（リンクのグレバグ遭遇時の対処法を参照）

【データ】
-大灯台2～3Fで3匹のエンカウントが出る確率 ：1エンカウントあたり54.87%
-大灯台2～3Fでサーベルウルフ3匹のみ、ミイラおとこ3匹のみ、3体目がアンデッドマンいずれかが出る確率 ：1エンカウントあたり20.69% (54.87-20.69=34.18%)
-大灯台2～3Fで4匹のエンカウントが出る確率：1エンカウントあたり32.80%
大灯台２F～３Fエンカウント内容とグループ番号の一覧

はじめに
乱数生成パターンを解析するのは無理だけどフレームカウンタなら調整できるかもしれないと思って考えたやり方。
乱数調整せず、フレームカウンタだけ調整。でも難易度は・・・。そういう意味でネタです。
現段階で人力でやるのは現実的ではない。やるなら自己責任で。
理想的に操作ができたとしてもメタル出現率は50％程度で逃げることも十分考えられます。
調査内容が一部間違っている可能性を否定しません。

＜DQ1＞7E0027, 7E10B9, 0050BF(出現敵決定)
エンカウント
・半歩移動は8フレーム。周期８フレーム
→歩行中の入力精度は8フレーム以内でOKなはず
・出現する敵はフレームカウント$68（0-4，周期５フレーム）で決定される
・タイミングが重要！1フレームもずれてはならない
・$68は画面の切り替わり，メッセージウィンドウ表示，勇者の攻撃などの時にカウントを飛ばすことがある。
*入力受付→1F後7E10B9=1→さらに8F後$68取得→さらに2F後画面がフラッシュ
*$68が常に1フレームごとに1回カウントされると仮定する。
フラッシュから5N+4フレーム後のキー入力を受け付けるときに動画の山の位置へ移動開始する。
その後ミスせず移動していれば50%くらいでメタルスライムが出現する。
（エンカウント率を平地：山=1:3として考えた。平地3回山1回のループになるので確率は50%程度となる）
参考動画：　http://www1.axfc.net/uploader/P/so/88548.avi
連射設定おかしいのかダメージ固定されていません。エミュの連射＋Joy to Keyの低性能連射
連射設定を直しても撮影したエミュレータだと押しっぱなしでは2回に1回しか入らない模様。原因はよくわからない。
Snes GT Ver 0.218の連射機能だとダメージが入るときは途中でキーを離しても必ず入り、外れるメタルはとことん外れる。予め入力可能なフレームが決まっているのだろうか。（この検証は改造ロム使用）

【移動】
入力は”v v > ^ > < ^ < < < ”のループ
「適切なタイミング」で右へ半歩移動。 以後1フレームの無駄もなく動くｗ
下（海）、下（平地）と入力し、角テクで右に半歩さらに下へ半歩移動（ここも平地判定）
右（平地）、上（平地）、右（山）[ここまでで半歩移動5回，ループ前半終了]
左（平地）、上（海）と入力する。（角テクで右に半歩移動）
左（平地）、左（平地）、左（山）
ここまでで一ループ。エンカウントするまでひたすら繰り返す。
※海と書いているのはその位置で無理やりエンカウントさせると背景が海だったから
ちなみに半歩テク使用時はエンカウント判定に使う乱数が取得されないため、
敵出現エリアで同じルートを通っても半歩テクありとなしでその後の乱数が変わってくる。

「適切なタイミング」→攻撃エフェクトや足元調査などで変わってくる
事前のエンカウントで、エンカウントテーブルの5番目に設定された敵が出現していたとする。
このエンカウントのフラッシュが目安。フラッシュした瞬間から5N+3フレーム後に方向キー入力が入れれば良い。（Nは整数。テーブルNo2なら5Nフレーム後）
ただし、このエンカウントからメタルスライム出現までフレームカウンタ$68が正確に１フレームに1回動いているものと仮定しており、通常はずれるはず。
また、移動のキー入力受付は8フレームに1回しかないのでタイミングが合わないことが多い。

【カウンタ$7E0068がずれる例】
・リセット直後はカウントが止まったり、2フレームに一回進んだりする。
・勇者の攻撃ヒット時
・足元調査のウィンドウ消失時

補助ツールとしてメトロノームなどを5フレームに1回のペースで鳴るようにしておくのもあり？

追記
位置と出現が期待される敵の関係は表のようになる。

入力（地形）	期待される敵	エンカウントNo.
下（海）	出現しない	1
下（平地）	鎧の騎士	2
右（平地 ）	メイジキメラ	3
上（平地）	影の騎士	4
右（山）	メタルスライム	5
左（平地）	死霊の騎士	1
上（海）	出現しない	2
左（平地）	メイジキメラ	3
左（平地）	影の騎士	4
左（山）	メタルスライム	5

【判定法】プログラムのROMアドレス(PC)004812-004827
購入後の所持金を16進数にして3バイト(#$00-FF)の合計を計算する。
一番下の位(0-F)が1か3であれば条件を満たす。
（アイテムの空きの検索処理は未確認だが空きが2つ以上ないと貰えないはず）
一覧表はこちらから
所持金Xはメモリの7E0C81,7E0C82,7E0C83に格納されている。
・エクセル的に条件を書くと以下のようになる
A: 7E0C81の一の位 MOD(X;16)
B: 7E0C82の一の位 MOD(INT(X/256);16)
C: 7E0C83の一の位 MOD(INT(X/65536);16)
IF(OR(MOD(A+B+C;16)=1;MOD(A+B+C;16)=3);"もらえる";"もらえない")

【数学的に考えてみる】→従来の式は間違ってはいない。電卓使って16進数で考える方が楽
購入後の所持金をY、「Yを65536で割った時の商をA」，余りをq(1)とする。
Y = 65536×A + q(1)
q(1)を「256で割ったときの商をB」,余りをq(2)とする。
q(1) = 256×B + q(2)
A,B,q(2)の和を16で割ったときの商をC,余りをXとする。
A+B+q(2) = 16×C + X
Y = 65536×A + 256×B + (16×C + X - A - B) ①
（= 65535×A + 255×B + 16×C + X ②（要注意）)
X = Y + A + B - (65536×A + 256×B + 16×C) ③
Xが1または3となるYが福引券をもらうことのできる金額である。
所持金が65536未満であればA=0なので従来の式「255*m+16*n+1,3」は間違ってはいない。
ただ、mが所持金を256で割ったときの商であることに気づかないと間違った結果になる。

～式に関する注意～
Bは255で割ったときの商ではなく、256で割ったときの商である！（Aも同様）
例えば511の場合に②の式を使って
511 = 65535×(0) + 255×(2) + 16×(0) + 1
とすると間違いである(511<256*2 A=0,B=2,C=0,X=1)
正しくは③式より
X = 511 + 0 + 1 - (65536×0 + 256×1 + 16×C) = 256 - 16×C = 0
(A=0,B=1,C=16)


【(所持金<65536(=#$10000)の時の)16進数で金額のばらつきについて考える】
ここでは＋１型と＋３型は比較せず、同型の貰える金額の差を考えてゆく。
・一般的に貰える金額は#$10間隔である。(#$01,11,21,...,F1)

・1,2桁目(1と16の位)が繰り上がるときは3桁目が＋１されるので1桁目は－1されなければならない。
そのため間隔は#$0Fとなる。(#$0F1->100; 5FC->60B; EF5->F04)

1,2,3桁目が繰り上がるときも同様である(_FF2->_001(+F)※_は0～E)
ただし、1の位が0の時は1,2桁目が繰り上がるには#$10以上増えなければならないので－1するかわりに＋Fされ、間隔が#$1Fとなる。
(#$01F0->20F; 11F0->120F) 1,2桁目が繰り上がるのは16回に一回、金額が#$10*0F+0For1F = #$FFor10F( =255or271)増えるたびに起きるはずである。
間隔が1Fとなるのも同様に16*16=256回に一回、つまり#$1000(10進数で4096)増えるたびに起きる
＜間隔が奇数になった例＞
#$100→#$20F(+#$10F) →#$30E(+FF) →...→#$1001(+FF) →#$1100(+FF) →#$120F(+10F)
#$30→#$40F(+#$10F) →#$50E(+FF) →...→#$1201(+FF) →#$1300(+FF) →#$140F(+10F)

回避の判定はマヌーサ(1/2)，通常回避(1/64)，身かわし(1/8)の順にされる。
()内は回避率。マヌーサ＋身かわしだと○，×○，××○の確率の合計なので57％，マヌーサのみは51％，身かわしのみは14％程度。(058AC5，058F7F以降を解読)
ただし、通常攻撃以外の打撃の場合は基本的に通常回避，身かわしによる回避の判定が行われない。
詳細は表のとおりである。
連続攻撃の二発目は通常攻撃と同様に判定される。
（集中攻撃をした敵の次のターン以降の攻撃は通常攻撃）

	回避の種類
判定	マヌーサ	通常攻撃	身かわし
各判定における回避率	1/2	1/64	1/8
PCアドレス	058AEB	058F8F	058FA2
攻撃	○	○*	○
痛恨発生時	☓	☓	☓
毒攻撃	○	☓	☓
眠り攻撃	○	☓	☓
連続攻撃一発目	○	☓	☓
連続攻撃二発目	○	○*	○
集中攻撃	○	☓	☓

*：受け手が眠っている場合、1/64の回避をしない（判定処理を飛ばす）[2013 1/18 追記]

追記→補足
通常回避の判定にはフレームカウンタ7E0067を使用している。
メッセージ速度8に設定していて次の行動が敵の通常攻撃である場合、
メッセージ送りのボタン入力から9フレーム後の値が0,40,80,C0であれば回避される。
つまり、フレームカウントが37,77,B7,F7の時にメッセージを送れば攻撃を回避できる。
（フレーム経過の検証数は少ないので多少ブレる可能性もある）

追記2
メッセージ速度1の場合
$67 (通常の回避判定)
DQ1や2でターン最初の行動が敵の通常攻撃であった場合、
戦闘メッセージ窓が下の枠まで表示されたフレームから9フレーム目に回避判定がある。
ここで7E0067=0x00,40,80,C0であれば回避することができる。
行動が2番目以降の敵の攻撃は、攻撃前のメッセージ窓の文字が消えたフレームの次のフレームで回避判定がある
(調査対象：DQ1スライム、ゴースト、DQ2ギガンテス、アトラス)

関連： 敵の行動別まとめ(DQ2MonsterAct.html)