ツクマテ

YEP Battle Engine Core の動作を真似しようと下記のプラグインを作成しました。

とりあえず動いたプラグイン

一応、動いているようなのですが、さらに競合対策が出来ないかと考え、下記の記事を参考に変更しました。

参考記事
https://qiita.com/yamachan360/items/416 ... f25bbf0050

変更物

変更物は下記のエラーが出てしまいます。

コード: 全て選択

rpg_managers.js:1949 ReferenceError: animationId is not defined
    at Game_Enemy.Game_Battler.startAnimation (MNKR_OnceAnimation2.js:21)
    at rpg_windows.js:4983
    at Array.forEach (<anonymous>)
    at Window_BattleLog.showNormalAnimation (rpg_windows.js:4982)
    at Window_BattleLog.showActorAttackAnimation (rpg_windows.js:4969)
    at Window_BattleLog.showAttackAnimation (rpg_windows.js:4962)
    at Window_BattleLog.showAnimation (rpg_windows.js:4954)
    at Window_BattleLog.callNextMethod (rpg_windows.js:4838)
    at Window_BattleLog.update (rpg_windows.js:4795)
    at rpg_core.js:7035

参考記事は、既存のコアの処理に処理を追加する内容のようですが、それを置き換える動作には向いていない書き方ということなのでしょうか？

何か、こういったコアの処理を置き換えるのに、競合対策的な処理の手法などをご指導いただければ幸いです。

変更版は引数を忘れていますね。
競合ではなく、プラグインが単体でバグを起こしています。

また、call(this)での関数呼び出しもパラメータが無く正しく動きません。
引数を追加すれば正しく動きます。

一応、動いているようなのですが、さらに競合対策が出来ないかと考え、下記の記事を参考に変更しました。

（前半の記述は間違いだったので削除しました）

それから、20行目のretへの代入は不要です。 startAnimation は戻り値を持たないメソッドですし、その後retを使用されていませんよね。

致命的な点ですが、元の startAnimation を呼んでしまうと、その後でせっかく1回目以外アニメーションをpushしないコードにしているのに、その分岐を絶対に通らなくなってしまいます。

参考記事は、既存のコアの処理に処理を追加する内容のようですが、それを置き換える動作には向いていない書き方ということなのでしょうか？

こちらの質問に答えていないことに気が付きました。これはそのとおりです。
既存の処理を呼び出した上で追加処理を行うという記述ですので、元々あった処理を置き換えるには上書きするよりありません。

ただ、今回のケースでは、関数定義まるごと上書きせずに対応する方法があるにはありそうです。

Window_BattleLog.prototype.startAction で、元の関数に対して targets のユニークをとった配列を渡してあげることで、お望みの機能を実現できます。
渡されるtargetsが変わるので、そういった意味での競合は起き得るのですが……。

コード: 全て選択

  const _Window_BattleLog_startAction = Window_BattleLog.prototype.startAction;
  Window_BattleLog.prototype.startAction = function(subject, action, targets) {
    _Window_BattleLog_startAction.call(
      this, 
      subject, 
      action, 
      targets.filter((element, index, self) => self.indexOf(element) === index)
    );
  };

ツキミさんにご指導いただき（内容は理解できませんでしたが…）、コアを見直したところ、削りすぎた箇所がココかな？という箇所を追加したら、エラーは出なくなりました。
しかし、これで少しは競合対策になっているのでしょうか？

また、Plasma Darkさんからいただいたコードはまだ実験できていません。
まるっと違う処理みたいなので、別物ということなのでしょうけれども、後ほど試してみます。

＃追記
Plasma Darkさんからいただいたコードを試しましたところ、同様の動作を確認できました。
こちらの方がベター（競合しにくい）なコードということなのですよね？

こうなるとPlasma Darkさんの作品になってしまいますが(笑)

しかし、これで少しは競合対策になっているのでしょうか？

18行目で既存の処理を変数に退避していますが、どうせ使っていないので不要です。
関数をまるごと上書きするタイプのプラグインは、別のプラグインが同じことをしようとすると絶対に競合を回避できません。
ので、せめて別のプラグインが競合を回避してくれることを願って、プラグインリストの上の方に読み込む、くらいしかないですね。

こちらの方がベター（競合しにくい）なコードということなのですよね？

競合のしにくさはどっこいな気がしています。
私のコードだとアニメーションの挙動を操作したいのに startAction をいじっているので、もしも startAction 内の targets を別用途に使うプラグインがあったら競合します。
（コアのコードでは targets がアニメーションにしか使われていないので問題ないのですが……）

なので、どちらがベターかと言われたら私は即答しかねます。

Plasma Dark さんが書きました:
しかし、これで少しは競合対策になっているのでしょうか？
18行目で既存の処理を変数に退避していますが、どうせ使っていないので不要です。
関数をまるごと上書きするタイプのプラグインは、別のプラグインが同じことをしようとすると絶対に競合を回避できません。
ので、せめて別のプラグインが競合を回避してくれることを願って、プラグインリストの上の方に読み込む、くらいしかないですね。

こちらの方がベター（競合しにくい）なコードということなのですよね？
競合のしにくさはどっこいな気がしています。
私のコードだとアニメーションの挙動を操作したいのに startAction をいじっているので、もしも startAction 内の targets を別用途に使うプラグインがあったら競合します。
（コアのコードでは targets がアニメーションにしか使われていないので問題ないのですが……）

なので、どちらがベターかと言われたら私は即答しかねます。

となると4番として出したものと、最初に出したものは大差ない（というか無駄な処理を足しただけ？）ということですよね？

やはり基礎から学ばないと無駄足ばかりになりそうですね…

となると4番として出したものと、最初に出したものは大差ない（というか無駄な処理を足しただけ？）ということですよね？

残念ながらそういうことになります。
未使用の変数はコード中に残しておくだけ邪魔なので、視覚的に未使用変数をわかりやすくしてくれるエディタの使用をオススメします。

色々とご指導いただき、ありがとうございました。

今回の件では「関数上書き系のプラグインでは競合対策はそもそも難しい」ということが分かりました。
また別件で質問すると思いますが、よろしくお願いいたします。

ツクマテ

【解決】プラグイン制作で競合対策としてできることを教えて下さい

【解決】プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい

Re: プラグイン制作で競合対策としてできることを教えて下さい