ずあずあ

ク、クマが・・・

例えば、決定キーを押したまんま
次にキャンセルで戻った時、
一度決定キーを離さないと反応しないか、
そのまま反応するか、
あるいはコンマ何秒後に反応するかとか、
そーゆーのとの戦い。

カーソルを動かして0.1秒以内に
決定キーを押す人間はいても、
カーソルを動かして0.1秒以内に
キャンセルキーを押す人間はほとんどいない。
そこにつけこむ。てゆーか楽をする。

一番根幹的なシステムがちょっと前の厨スレで
これは嫌だと言われてても男の子なので負けません。
きー！

バグが全く特定できん。
プログラムは出来る出来ないで100倍効率が違うというが、
もしかして俺、末端100倍君？

完全に同じ処理だ。
キー押下で連続処理させるとバグる。
リストの左右のページ切り替えなんだが、
しかも右の処理は通って、
左の処理の分岐を入れるとバグる。
確かに左は少し危うい処理をしてるのだが、
連続処理のループ中に接触する部分は無い。
どうもアイテムデータからリストを作る時の
引数が乱れてるようで、リストの最大表示行数を超えて
アイテム所持数が表示される。
ループ中に変なものが入ってるとしか考えられない。
あるいは何かしら変則的な初期化を忘れているとか・・・
連続処理を入れないで通常分岐を二つ入れて
変数状態を見るか。ループが問題なのか、
関数が連続呼び出しに対応できてないのか見てみられ。

問題なし。2ページ戻るだけ。
別に左押した時にバグるのなら納得もいくが、
分岐入れただけでバグる。
分岐の条件自体が間違ってるか、キー受け取りを
変な数で初期化してるかしないとありえん動作だ。
コピペなんだからそれこそありえん。
あーだー

いや、逆に考えろ。
むしろそうだとしてもバグりはしない。
基本的に各タスクはいつでもバグるという前提で
作ってる。大いに無駄だが、
演算や変数はほとんど共有されていない。
ここまで全体に悪影響出るのは、
むしろ容疑者は相当絞り込まれるはず。
考えろ！考えるのじゃ！

ちょっとマジで今日中に防具くらいは・・・

ありえんのだ。
リスト側にカーソルが移ると同時にバグるなどというのは。
決定キーでリストに進んだ時、
連押しストッパーがオンになり、
四方向キーのみの待機なしキー受付をする。
そのとき四方向キーが押されていない限り、
下の待機ありのキー受付で停止するのだ。
受け付け直前には間違いなく0で初期化されている。
どうやって誤動作できるっちゅーんじゃい！！

実行されてない文でバグるなんてことはありえん。
まあプログラムならメモリのズレで
もとあるバグが顕在化することがあってもだ。
つまり、括られている条件分岐を辿っていけば、
どっかに侵入してくる穴があるはずなのじゃ！
クマー・・・

ありえない、こんなバグは。
100％無い。
と、なると・・・

オーケー修復完了。裏は取れた。
というか以前ノクターンの人の所で見て
うろ覚えに疑ってはいたんだけど、繰り返しのバグな。
いやしかしまず己のミスを100％疑うてこそな。
男の道がな。
疲れた・・・