ツクマテ

プラグインの並び順を
MNKR_MenuCommand
MenuSubCommand
にすることで、解消は出来ました。

const _Window_MenuCommand_initialize = Window_MenuCommand.prototype.initialize;
Window_MenuCommand.prototype.initialize = function () {
  _Window_MenuCommand_initialize.call(this, eval(WindowX), eval(WindowY));
};

Plasma Dark さんが書きました: 競合の原因を探るためには、当然ですが競合しているプラグイン同士のコードを見比べる必要があります。

今回の競合の原因はまず、 Window_MenuCommand.prototype.initialize の再定義部分にあります。
先頭で Window_Command.prototype.initialize を呼び出していますが、これをすると先に読み込んだプラグインで定義された Window_MenuCommand.prototype.initialize をすっ飛ばしてしまいます。
ですので、面倒かとは思いますが、しっかり Window_MenuCommand.prototype.initialize を控えておいて、それを呼び出したほうが良いでしょう。

コード: 全て選択

const _Window_MenuCommand_initialize = Window_MenuCommand.prototype.initialize;
Window_MenuCommand.prototype.initialize = function () {
  _Window_MenuCommand_initialize.call(this, eval(WindowX), eval(WindowY));
};

ただ、ここまでやっても MenuSubCommand （2.7.0） とはまだ競合します。
MenuSubCommand では Window_MenuCommand.prototype.initialize が引数を無視するように再定義されてしまっているため、せっかくウィンドウの位置を渡しても捨てられてしまうのです。
これは MenuSubCommand 側の問題ですので、あちらに修正PRを送るか、issueでも立てて直してもらうのが筋ですね。


ついでにコードレビューしてしまうと、eval周りにバグがあります。

Stringの中身、右側にデフォルト値を書くのは良いのですが、カッコの中は先に評価されるため、クォートなりダブルクォートなりで囲んでしっかり文字列にしてあげないと、デフォルト値が評価されるタイミングでエラーになります。（実は、ここが評価されるタイミングはあんまりないんですが）

また、ゲームでほとんど問題になることはないかと思いますが、evalはバグや脆弱性の温床なので、あまり使用をオススメしたくはありません。

トリアコンタン さんが書きました:こんにちは！
ご指摘の件は、『メニュー画面のサブコマンドプラグイン』の実装ミスのため修正しました。
ご確認ありがとうございました！

2.7.1 2020/03/13 Window_MenuCommandの初期化で引数を渡し忘れていたのを修正
https://raw.githubusercontent.com/triac ... Command.js

試行錯誤した結果、指摘された箇所の競合対策とそれ以外も（必要かどうかは分かりませんが）同様の処理を追加することが出来ました。
また、潜在的なバグについても理解できたと思います。

evalが推奨されないとなると、代替手法があると思うのですが、それは複雑化してしまうので、ここで書かれていないのでしょうか？

パラメーターで式を使えるようにするのに、ベターな方法があればご指導ください。

Plasma Dark さんが書きました:

試行錯誤した結果、指摘された箇所の競合対策とそれ以外も（必要かどうかは分かりませんが）同様の処理を追加することが出来ました。
また、潜在的なバグについても理解できたと思います。

完全に上書きすると競合しやすくなるのは事実ですが、処理的に上書きせざるを得ないというか、元の処理を呼び出したところで意味がなかったり、かえってバグってしまうこともあるので、考えなしに追加すれば良いものではないというところはご注意ください。

evalが推奨されないとなると、代替手法があると思うのですが、それは複雑化してしまうので、ここで書かれていないのでしょうか？

パラメーターで式を使えるようにするのに、ベターな方法があればご指導ください。

代替があるというより、可能な限り使用箇所を減らしたほうが良い、ということです。
evalそのものはコアスクリプトでもダメージ計算で使われていたりしますし、RPGツクールMV製ゲームであればevalの脆弱性で問題になることは（よっぽど変な使い方をしない限り）まずないので、絶対使っちゃいけないというものではないです。

ですが、例えばメニュー画面の maxCols や numVisibleRows の戻り値を動的に変える必要があるでしょうか。
メニュー画面はゲームにおいて頻繁に開かれる場所ですので、コロコロ変わってしまってはプレイヤーの混乱を招きかねません。
本当にevalを使うべき場所であるかどうか注意深く検討した上で、それでも必要であった場合のみ使うべきだと考えています。

1.プラグインパラメーターの初期値指定を修正しました。

2.Window_MenuCommand.prototype.initialize 以外にもconst処理を入れました。
これは、return で返してしまっているので、あまり効果がないかもしれませんが、同じ関数を使っているプラグインと競合した時にエラー回避くらいにはなるかな？という考えです。（合ってますか？）

同じ関数の置き換え処理がされているプラグインがある場合、プラグイン管理で下にある方が上書きされると解釈していますが、合っているのでしょうか？

3.初期ウィンドウのY位置をコマンド表示とウィンドウサイズに合わせて最下部に表示したいのですが、どうしても連動した動作をする式が作れませんでした。
もし現状で「この式で動く」というものがありましたら、ご指導ください。

Plasma Dark さんが書きました:

1.プラグインパラメーターの初期値指定を修正しました。

LGTM

2.Window_MenuCommand.prototype.initialize 以外にもconst処理を入れました。
これは、return で返してしまっているので、あまり効果がないかもしれませんが、同じ関数を使っているプラグインと競合した時にエラー回避くらいにはなるかな？という考えです。（合ってますか？）

.call(this); が抜けているので、何も呼ばれない気がします。

maxCols や numVisibleRows は値を返す以外に何もしないというか、するべきでない関数なので、完全に上書きしてしまうくらいでも良いと思っています。
あるいは、プラグインパラメータで設定されるデフォルト値を空にしておいて、空だった場合は上書き前の関数を呼んでその戻り値を返す、としても良いかと思います。

いずれにせよ、何も考えずに上書き前の関数を控えて呼び出すだけ、というのは筋が良くないというか、これで回避されるような競合であればむしろそちらが悪いので、わざわざ対応してあげないほうが良いまであります。

同じ関数の置き換え処理がされているプラグインがある場合、プラグイン管理で下にある方が上書きされると解釈していますが、合っているのでしょうか？

この認識は正しいです。

3.初期ウィンドウのY位置をコマンド表示とウィンドウサイズに合わせて最下部に表示したいのですが、どうしても連動した動作をする式が作れませんでした。
もし現状で「この式で動く」というものがありましたら、ご指導ください。

Graphics.boxHeight - this.windowHeight() になるんじゃないでしょうか。
ゴールドウィンドウとかぶってしまうので、そこは工夫しないといけないですが。

そして、ウィンドウの位置を設定する汎用的なプラグインが実はすでに存在します。
トリアコンタンさんの GraphicalDesignMode.js に任せて、ウィンドウ位置は特に設定させなくても良いと割り切ってしまう手もありだと思います。

https://github.com/triacontane/RPGMaker ... ignMode.js