ドウメキ不具合調査中の思考経路垂れ流しまとめ
昨日うにゅう＠もどき板ゴースト製作上の質問スレでドウメキの不具合相談がありまして、問題は解決したのですが、特定の現象の解決法そのものよりも、その解決に至るプロセスの方が多くの人にとって価値があると考えたため、その過程を思い出しながらまとめてみました。
不具合の原因の特定に至る時間の節約に役立てれば幸いです。
以下、その時の脳内ダダ漏れ
※SSP固有の機能を利用した部分に【！】マークを付けています。
報告内容
これを起動して開発パレットのスクリプト入力から、
\h\i[79]\e
というスクリプトをおくると40秒ほどでアニメーションが止まってしまいます。
ドウメキ起動
- 【！】Ctrl+S
- "\h\i[79]\e"と打つ
- 数十秒待つ
- 再現した。(通常のバグ報告の場合ここまで来れば90%解決したも同然です)
- surfaces.txtをさらっと眺める
- 数十秒でアニメーションがとまるような記述は見当たらない
※SSPはSHIORIイベントを投げて返ってきたSakuraScriptを再生するだけの装置である
※SSPが勝手に判断してゴーストを制御することは（原則として）ない
【！】SSPのログ起動
機能＞スクリプトログ
- もう一度再現手順を繰り返す
- アニメーション停止と同時に"\0\s[0]\1\s[10]\e"再生キタ！(ここで99%解決したも同然です)
- こいつが原因だ。SHIORIが"\0\s[0]\1\s[10]\e"を投げ返すきっかけとなったイベントは何だ？
【！】SSP SHIORIログをとる
機能＞開発用パレット＞「SHORIログを取る」にチェック
- もう一度再現手順を繰り返す
- ゴーストディレクトリ内のssp_shiori_log.txtを開いて"\h\i[79]\e"で検索
- その次に来る"\0\s[0]\1\s[10]\e"を検索
- イベント名確認
- OnSurfaceRestoreと判明(ここで99.9%解決したも同然です)
=====send=====
GET SHIORI/3.0
ID: OnTranslate
Charset: Shift_JIS
Sender: SSP
SecurityLevel: local
Reference0: \h\i[79]\e\e
=====response=====
SHIORI/3.0 204 No Content
Charset: Shift_JIS
...(略)
=====send=====
GET SHIORI/3.0
Charset: Shift_JIS
Sender: SSP
SecurityLevel: local
ID: OnSurfaceRestore
Reference0: 0
Reference1: 10
=====response=====
SHIORI/3.0 200 OK
Value: \0\s[0]\1\s[10]\e
Charset: Shift_JIS
脳内中間報告
里々がOnSurfaceRestoreで"\0\s[0]\1\s[10]\e"を返していることが原因だった
OnSurfaceRestoreで何も返さない(204 No Contentを返す)ようにすれば直るはず
解決策の模索
- 「何も返さない」ことを明記して基底の処理をオーバーライドする必要がある(どうやるんだっけ？)
- 里々Wikiで"204"で検索
- ＄今回は喋らない【タブ】有効
- 直った！！！！(100%解決)
＊OnSurfaceRestore
＄今回は喋らない【タブ】有効
おしまい
【！】でマークした部分を駆使すれば、今まで闇雲にバグ潰しにかけていた時間がかなり節約できるかもしれません。
何よりも今回は90%解決済の状態で報告が上がっていたので解決は容易でした（要点を得ない、再現しないものは解決不能）。再現のため単純化したNARを添付するのは再現性を確実にする上、原因の絞り込みを容易にするための模範的なレポートだと思います（自分一人でデバッグする際も大事なことです）。ということで勝手にご紹介させて頂きました。