検索結果

MVの場合、ステート付加可否の条件判定に、「バトラーに対する直近の行動結果で対象ステートが解除されていない」というものがあります。 単にremoveStateを呼んでしまうと、バトラーに対する直近の行動結果がリセットされず、そこで解除したステートが再度付加できません。 ステートの変更のイベントコマンドは、その直後に「対象アクターに対する行動結果をリセットする」処理があるため、イベントコマンドで付加すればこの問題は発生しません。 また、プレイヤーが歩いた際にも、全てのパーティメンバーに対して、そのアクターに対する直近の行動結果がリセットされるため、解除したステートを再度付加できます。...

なぜスクリプトでステートを付加しなければならないのでしょう。 ステートの変更イベントコマンドを使えない理由はありますか？ それはそれとして、挙動がおかしいようです。デフォルトのプロジェクト(コアスクリプト1.10.0)では再現しない挙動のようです。 何もプラグインを導入していないデフォルトのプロジェクトで試されていますか？ 何か並列実行のイベントが裏で走っているということもありませんか？ コアスクリプトの更新を行った後も再現しますか？ 追記: 早とちりしてMZで確認していました。MVだとまた違いますね

戦闘ログはツクールの中でも特殊な仕組みで動いているので、通常のウィンドウ向けのプラグインは使えないことが多いです。 ご提示いただいた BB_ItemIcon.js も例に漏れず、戦闘ログの行動表示に対しては特に効果がありません。 戦闘ログ内でアイコンを表示する、というだけであれば rpg_windows.js Window_BattleLog.prototype.displayAction とその関連コードを読んでプラグインを書く(あるいは人に依頼して書いてもらう)のが手っ取り早いと思います。 itemが渡されているのでアイコンのインデックスは取得できるし、公式プラグインの...

エラーが出たらエラーメッセージを読みましょう。 スタックトレースからエラーがどこで起きたかわかるので、その付近のコードを読めば原因がわかります。

スキルのデータ構造を確認してみてください。 $dataSkills[500] と、 $dataSkills[172] を見比べると違いに気づくと思います。 ゲームを起動した状態で開発者コンソールを開いて、コンソールにjsの式を入力すると、評価結果が表示されます。 ついでに読みやすさ管理しやすさの改善のヒントを書いておきます。 - varを使わず、スクリプト内のローカル変数は再代入不可にする - スクリプトイベントコマンドを使わずに、プラグインコマンドにする - 文字列は+で連結せず、テンプレートリテラルを使う

良いですね。コードが飛躍的に読みやすくなりました。 pandaさんの仰る通り、インデントを入れるともっと読みやすくなりますが、これはVSCodeを使って書く場合、ショートカットキーを押せばすぐにできます。 Windowsの場合は Shift + Alt + F キーです。 コードについてはpandaさんが回答してくださっていますが、私からも補足させてください。 まず、元のコードの良くないところですが、changeGraphicSymbolの値とConfigManagerに足す設定値のキーが一致しているのにバラバラに定義されています。...

なるほど、私の回答が質問の意図と食い違っていて、どう答えれば良いのかわからなかったのですね。 得られた回答の意図がわからなかった場合にも、それを無視しないようにしてください。 わからないなら「わからないので意図を教えてほしい」とか「＊＊＊の理由で、欲しい回答と違う」などと、自らの意思を伝えるようにしてください。 回答してくれた内容に対して黙ったままでは、あなたは親切心を無視する無礼者になってしまいます。 (たとえ東さんにそういう意図がなかったとしても、そう捉えられてしまいます) これは、人とのコミュニケーションにおいて、東さんにとって明確に不利になってしまう要素です。...

そうであれば、そう言っていただけないと回答者としては無視されたように感じてしまいます。 次からは気をつけるようにしてくださいね。 それから、東さんはもう少しもらった回答を落ち着いて読んでみたほうが良いでしょう。 これはとても重要な回答です。あなたの提示したコードは整形されていないので読む気が起こらない、という話をしています。 さて、以前にもあなたへの回答で書いた通り、この掲示板にはコードをわかりやすく整形して表示するためのタグが存在します。...

前回に比べてより具体的に書かれていて良いですね。 できれば前回のスレッドを打ち捨てたままにせず、解決までの道のりを後人が辿れるようにリンクを貼るなどしていただけたほうが良いと思います。 これだけであれば、CustomizeConfigItem.jsを利用すれば実現できますが、もうお試しになっているでしょうか。 もし既存のプラグインで目的を達成できない場合、何が足りないのかをもう少し詳しく書いていただけると、解決に近づきやすいです。 rmmz_XXXX.jsを直接編集するのではなく、同じ内容が書かれたjsファイルをプラグインとして読み込むようにしたほうが、管理しやすいと思います。...

まず、プログラムを読み書きするよりも先に自然言語でご自身の状況に関する説明を試みてください。 AIとの壁打ちには十分かもしれませんが、今の段階では人に対して質問を行うには説明が不足しすぎています。 やりたいことはわかっても、そのやりたいことに対して取るアプローチがいきなりコードを書くことになってしまっているのはなぜでしょう。 コンフィグに項目を追加するようなプラグインは探せばすぐに見つかりますが、なぜそれを使う方法を採らないのでしょう。 わかっていること、わからないことについても、もう少し丁寧に、読む側の認知負荷を意識して書いてみてください。...

MZ1.9.0の話であれば、Scene_ItemBaseでアイテムやスキルの対象を選択する際に表示されるウィンドウはメニューのアクターウィンドウ (Window_MenuStatus) ではありません。 Window_MenuStatusを継承したWindow_MenuActorです。 継承しているdrawXXXX系メソッドを再定義するようなプラグインを書けば、表示内容をカスタマイズできます。

Window_SelectableクラスのcallUpdateHelpに関するコードを読んでみると良いと思います。

Window_MenuCommandクラスはWindow_Commandを継承していて、そちらのdrawItem関数でコマンドの文字を描画しています。 drawTextの前にresetTextColorを呼び出しているので、Window_MenuCommandクラスにdrawItem関数を再定義してしまうのが良いと思います。 文字サイズはcontents.fontSizeの値を変更することで、色はchangeTextColor関数を呼び出すことで変更できます。 ところで、本掲示板にはコードをわかりやすく表示するためのタグが存在します。...

Consoleは、スクショを貼ってくださっていたエラーの表示されている画面のことです。 JavaScriptを入力して実行することができ、それによって解決につながる情報が得られる可能性があります。 貼ってくださった文法エラーはプラグインのコードを実行しようとして出力されたもののようです。 該当行を確認してみましたが、特にエラーが出るべきものではありませんでした。 ここから考えられる原因は、 1. そもそも実行環境が古く、プラグインのコードを実行できない 2. プラグインを正しくダウンロードできていないか、意図しない編集を加えてしまった...

Consoleで nw.process.versions.chromium と入力して、出てきた値を確認してみたいですね。

パラメータを入れ替えるステートを実現するプラグインを公開しています。 必要であればお試しください。

問題を整理してみましょう。 以下の1, 2で間違いないでしょうか。 1. 戦闘中にアクターのコマンド入力において、「攻撃」「防御」コマンドが無効になっている (文字がグレーアウトしていて、カーソルを合わせて決定キーを押すとブザーが鳴る) アクターは行動可能であり、攻撃スキル、スキル封印などの特徴も(装備・職業含めて)持たない。 スキルID1, 2どちらも消費MP,TPが0で、スキルタイプは「なし」、使用可能時は「バトル画面」で、武器タイプも設定されていない。 2. 戦闘中にアクターのスキルタイプ (魔法や必殺技など) を選択しても、本来使えるべきスキルが一覧されない...

戦闘中のアクターコマンドにおける「攻撃」「防御」はデータベースのスキルにおけるスキルID1, 2にそれぞれ対応しています。 そのコマンドが有効であるかどうかは、コマンド選択中のアクターが対象スキルを使用できるかどうかによって決まります。 スキルID1, 2について、使用条件や消費MP, TPを変更していたりしませんか？

これについてはpandaさんが仰る通り現実的でなく、考慮しなくても良いことはおわかりいただけていると思います。 方法ではなく、目的です。方法を考える前に目的をはっきりさせ、本当に必要なのか考えることが重要です。 コードを書くにしてもダミーのアクターを用意するにしても、目的をよく考えたら実は不要だった、となった時点で実装にかかった時間は無駄になり、その分だけゲームの完成が遅れます。 さて、与ダメージ計算の結果がInfinityによって正しくなくなることを防ぐ、という目的は、考慮しなくても良いことがわかりました。 では、それでも尚、追加ステータスの上限を設定したいのはなぜでしょう。...

私は、コードは目的に沿って適した書き方をするべきであり、書く以上は最終的にそのコードを理解・管理できるべきであるという思想を持っています。 そして、MZエディタ上でのスクリプトイベントコマンドや、変数の操作によるスクリプトの入力は、管理に難があるため、推奨はしません。 ですので、目的がまだ曖昧で、先の投稿にあるような説明でわからないという人に「こういうスクリプトを書けば良いよ」という結果のみをお教えすることはしていません。 スクリプトを使うにしても、まずは目的の曖昧さをなくしておきましょう。 これは目的というよりは手段で、上限を設定することによって何か達成したい目的があるはずです。...