Tachi.jsプラグインの戦闘スピードを自由に調整できるように改造（テストしてくれる方募集中）

[メルサイア]

yamachanさん

いつもおありがとうございます。

た、タイプミス…す、すみません。。意図的じゃないです。ミスです。。。
undefinedになるの、これだったのですね…。
全部this._waitCountに修正します。
（やっぱり、varで宣言してないキーワードを事前チェックするプラグインやコンパイラがほしい・・・です。。。。）

その他、_speedのif文でも順序が変なところを、道楽さんに見つけてもらいました。
同じ指摘を、Trbさんにも頂いて、twiterでも何人かの方にたすけていただいて、ほんと感謝です。
（初歩的なミスなのですごく恥ずかしいですが…）

修正したものでもう少し頑張ってみます。

[やなつき]

有料のIDEですが、WebStormは定義されていない変数に対して判定を行うと、チェックが入ります。
また、定義されてから一度も使われていない変数や、単純なスペルミスに対してもチェックを行ってくれます。

画像14.png (914 バイト) 閲覧数: 5850 回

画像15.png (730 バイト) 閲覧数: 5850 回

画像16.png (603 バイト) 閲覧数: 5850 回

一応、こんなのもあるよーってことで。

[メルサイア]

やなさん

紹介ありがとうございます。
すごい…WebStorm、これだと、VisualStudioでC#やってる並に、事前コンパイルしてくれるようなものですね。とてもケアレスミスが減りそう＆参考になります。
でも、使用権は、約5000円/1年ですか…落とし切りなら変えたかもしれないのに、、ちょっと年間契約は尻込みしてしまいました。
もう少し検討してみます。
こんなのもあるのなら、次第に他のIDEもサポートできそうですね。なんか、javascriptの未来がちょっとだけ明るく見えました。
教えていただけてありがとうございました～。

[メルサイア]

いつもお世話になっております。

Tachi3.js最新版のURLと、ここまで出来た点、現在つまっている点をお知らせします。
https://www.dropbox.com/s/tzgj75ldqzl2h ... i3.js?dl=1

＜ここまで出来た＞
・Window_BattleLog.prototype.updateWaitCountで、
　　・this._waitCountとthis.waitCountの不揃い　　　→　this._waitCountの値に、正常な値が入った。
　　・if(...) {} if (...) {}で複数判定されて不正値代入 →　if(...){} else if{} else if{} ... という書き方に変更した。
　　・_speedの値が0になると無限ループしていた　　　 →　_speedを_reduceCountに改名し、1以上を保証した。
・全てのメソッドに競合対策を施した　　　　　　　→　上書きから、追加定義に変更した。
・パラメータの説明文を整形した　　　　　　 　　 →　「スピード変更を禁止するか」、「戦闘全滅後もゲームを継続するか」、「吸収技にもダメージエフェクトをつけるか」などを、個別に設定できるようになった

＜ここで詰まっている＞
・戦闘中、２ターン目に、必ずフリーズする
　→　this._waitCountの値が、不意にundefinedになる可能性を排除しても、フリーズする。
　→　this._waitCountの値が0になっても、なぜか待っている？　（もっと詳細なデバッグが必要）
　→　Window_BattleLog.prototype.updateWaitCountをまるごとコメントしても、フリーズはなくならない。
　→　どこかで無限ループしている可能性が大だが、場所が特定できない。
　→　現在、手詰まり状態…
・パラメータ「スピード変更を禁止するか」をONにすると、エラーが出る
　→　原因は不明。スタックトレースを辿っても、Tachi3.jsは出てこない。
　→　デフォルトのメソッド呼び出しが悪さをしている可能性大。

もう少しだと思っているので、もしお時間ある方がございましたら、ご助言賜りたいです。
よろしくお願いいたします。

[Trb]

まず2ターン目にフリーズする点ですが、1ターン目には何をしてますか？
もし1ターン目に相手にある程度ダメージを与えている場合、身代わり関連の部分のミスだと思います。
2027行目の

コード: 全て選択

var members = this.members();


ですが、BattleManagerにmembers()というメソッドはありません。
ここはターゲットがアクター側かエネミー側かによってどちらのメンバーを取得するかを分けたいので

コード: 全て選択

var members = target.isActor() ? $gameParty.members() : $gameTroop.members();


とすればいいと思います。
(もし防御などをしていて1ターン目に何もしていなくてもフリーズする場合こちらでは現象が確認できないので分からないですが、なんにしても上の部分は修正すべきです)

それからスピード変更のパラメータについては、元のメソッドの呼び出し方が間違っています。
1313行目で

コード: 全て選択

return _Scene_Map_updateMainMultiply(this, arguments);


となっていますが、元のメソッドを呼び出すには

コード: 全て選択

return _Scene_Map_updateMainMultiply.apply(this, arguments);


というようにapplyを付けます。
注釈文にはご自分で//applyがいいよと書かれているので単なるうっかりミスだと思いますが、1313行目以外にもスピード変更のパラメータで分岐させている部分全てapplyが抜けちゃっています。
もしかしたら他にもapplyが抜けている部分があるかもしれません。

とりあえずここまで修正して試してみてください。

[メルサイア]

Trbさん

ありがとうございます！！
…やっぱり、私には見えてない部分がたくさんあるようです…。修正箇所の特定、感謝です。
２箇所、さっそく修正してトライしてみますっ。

[メルサイア]

Trbさんのご指摘の通り、修正したものを、添付します。
https://www.dropbox.com/s/0ux2k1yy7xnyy ... i3.js?dl=1
■修正箇所
・2027行目: var members = target.isActor() ? $gameParty.members() : $gameTroop.members();
・「.apply」が抜けている部分: 引数部分が共通しているので、"(this, arguments)"を検索して、「.apply」を追加（数カ所）

＜ここで詰まっている＞
・戦闘中、エディタの命令で「ウェイト」が１フレームでも入ると、必ずフリーズする
　→　武器エフェクトや通常の戦闘ログの待ち時間ではフリーズしない。
　→　原因を探ってみたが、見つからず。。。
　　　（おそらく_waitCountが0になっても、次の処理に移行していない可能性が大ですが、どこに原因があるかがわからずじまうです。。）

詰まっている部分の再現（フリーズ確認例）は、添付の画像のようにすると、容易に確認できます。

毎度毎度でほんと頭がさがる思いですが、ご助言賜りたく存じます。

[Trb]

原因わかりました。
1181行目からの

コード: 全て選択

    var _Game_Interpreter_command230 = Game_Interpreter.prototype.command230;
    Game_Interpreter.prototype.command230 = function() {
        if(isSkipMode() === false){
            _Game_Interpreter_command230.apply(this, arguments);
        }
    };


ここですね。

こいつの元のメソッドを見てみると

コード: 全て選択

Game_Interpreter.prototype.command230 = function() {
    this.wait(this._params[0]);
    return true;
};


というように最後に true を返すようになっています。

イベントコマンドの処理は true を返すまで次のコマンドに進まないようになってるようで、上の改変したものでは何も返さないようになってしまっているのでいつまでも先に進まないということです。
なので、

コード: 全て選択

    var _Game_Interpreter_command230 = Game_Interpreter.prototype.command230;
    Game_Interpreter.prototype.command230 = function() {
        if(isSkipMode() === false){
            return _Game_Interpreter_command230.apply(this, arguments);
        }
        return true;
    };


もしくは

コード: 全て選択

    var _Game_Interpreter_command230 = Game_Interpreter.prototype.command230;
    Game_Interpreter.prototype.command230 = function() {
        if(isSkipMode() === false){
            _Game_Interpreter_command230.apply(this, arguments);
        }
        return true;
    };


とすればいいです。(4行目が少し違う)
今回の場合は元のメソッドが true しか返さないと分かっているので後者のほうが少しコードが短くていいかもしれないですが、
元のメソッドが何を返すか分からない時は前者のようにしたほうがいいです。

[メルサイア]

Trbさん

あ、ありがとうございます！
なるほど。trueを返さないように上書きされていたのが運の尽き、ということですね・・・。
return文はできるだけ共通化し、returnの分岐は極力少なすくるべき（でないとreturnし忘れのミスをする可能性がある）、
という教訓を、しっかり頭に刻みました。。。

とりうより、上書きメソッド（_下のメソッド名.apply）は、全てreturnを付けるのが鉄則ですよね。。
他の上書きメソッドもやっちゃってるかの星あるので、あとで、全部チェックして直します。

明日、これでもう一度試してみますっ！

[Trb]

そうですね。
だけど、たとえば
var ○○' = ○○;
○○ = function(){
○○' .apply(this,arguments);
△△ = ××;
};
のように元のメソッドを呼び出した後に新しい処理を追加している場合は、apply しているところに return を付けるとそこで処理が終わってしまって後ろまで行かなくなるので気を付けて下さい。

<NG>
var ○○' = ○○;
○○ = function(){
return ○○' .apply(this,arguments);
△△ = ××;
};
↑これだと △△ が実行されなくなってしまう