ランダム宝箱のようなものを作りたいという事は恐らくランダムダンジョン系で大量に設置する事も考えられる。
テンポアップの為に、アイテム入手に反応するポップアップ系のプラグインをいずれ借りるかも知れない。
自分の使っているポップアップ系プラグインは Game_Interpreter じゃないと反応しなかった。
もしかしたら同じものを借りる事があるかもしれない。
確かに、 TinyGetInfoWndMZ.js 等のイベントコマンドによるアイテム入手をトリガーにした機能を使おうとすると、 Game_Interpreter のメソッドを呼ばざるを得ないですね。
見過ごせないと書いたのは、 comandXXX を呼び出すコードの読みにくさも一つの理由ではありますが、もうひとつ、 Game_Interpreter インスタンスの状態に依存する拡張を入れていた場合に不具合を起こすためです。
Game_Intepreter.prototype は、イベント実行に使われている Game_Interpreter インスタンスではありません。
マップ上のイベントであれば、 Game_Map インスタンスが持っているものかもしれませんし、あるいはイベントが持っているものかもしれません。
Game_Interpreter インスタンスはコード上の数カ所で作られ、それらはそれぞれ別の実体です。
(詳しくは rmmz_objects.js 内を new Game_Interpreter でテキスト検索してみてください)
イベントコマンドのスクリプトを実行しているのも Game_Interpreter インスタンスで、その中で同一インスタンスを参照するためには this を用いることができます。
つまり、変数1番の値をIDとして持つアイテムを、イベントコマンドで入手するのと同じことをするためには、スクリプトに下記のように書けます。
コード: 全て選択
this.command126([$gameVariables.value(1),0,0,1]);
アーヴェルさんの書き方では、例えばイベントが実行されているマップIDによって処理を変えるようなプラグインが入っていた場合に問題になります。
下記は、イベントが実行されたマップではイベントコマンドによるアイテムの入手数(と消費数)が2倍になるプラグインです。
コード: 全て選択
(() => {
'use strict';
const _Game_Interpreter_command126 = Game_Interpreter.prototype.command126;
Game_Interpreter.prototype.command126 = function (params) {
const value = this.operateValue(params[1], params[2], params[3]);
const rate = this._mapId === 1 ? 2 : 1;
const newParams = [
params[0], // itemId
0, // operation: 加算
0, // operandType: 定数
value * rate // 実際の入手数
];
return _Game_Interpreter_command126.call(this, newParams);
};
})();
Game_Interpreter.prototype を直接参照してしまうと、そのインスタンスの _mapId は設定されていないので、マップID1番にいたとしても入手数が増えません。
そして、アイテムランダム入手についてはすでにプラグインがあるようです。
https://github.com/nuun888/MZ/blob/mast ... omItems.jsこちらは Game_Interpreter インスタンスを新しく作っていますね。