werepanda.jp

イベントコマンド「数値入力の処理」のウィンドウを機能強化して、キャンセルボタンを有効にしたり、数値入力の前後に文字列を追加したり、入力可能な数値の最小値・最大値を指定できるプラグインを作成しました。

RPGツクールMZ専用です。ウィンドウ系は仕様が異なるため、MVでは使えませんのでご注意ください。

• 数値入力ウィンドウ強化プラグイン(PANDA_ExNumberInput.js)

※ 2025-01-04追記：
Version.1.1.0にアップデートして、桁移動ボタンの追加とキャンセルボタンの位置指定が可能になりました。機能の詳細は「数値入力ウィンドウをさらに強化」をご参照ください。

※ 2022-03-30追記：
オプションでタッチUIをOFFにした場合エラーが発生するバグを修正しました。お手数ですが、Version.1.0.1にアップデートをお願いします。

標準のイベントコマンド「数値入力の処理」では、入力した数値を受け取る変数と数値の桁数を指定するだけですが、このプラグインを導入すると、追加で以下のことができるようになります。

• キャンセルボタンで数値入力をキャンセル
• 数値入力の前後に文字列を追加
• 入力可能な数値の最小値・最大値を設定

標準の「数値入力の処理」ではキャンセルが効かず、数値が0だったらキャンセルと見なすといった処理にすることが多いですが、それだと支障のあるケースもあると思います。

「キャンセル有効」をONにすると、ESCキーやキャンセルボタンで数値入力をキャンセルすることができるようになります。キャンセルした際に変数に格納する数値を指定できるので、-1など通常では入力できない数値を設定しておいて、変数の値が-1かどうかで分岐することができます。

また、数値入力の前後に文字列を追加することができます。入力値の説明や単位などを追記して、分かりやすくすることができます。文字列には各種制御文字も使用可能です。

さらに、入力可能な数値の最小値・最大値を指定できます。最小値・最大値はそれぞれ、直接数値で指定することも、変数で指定することも可能です。

最小値・最大値を可変にしたい場合は、最小値・最大値を変数に格納して、その変数を指定するといった方法になるかと思います。

なお、最小値・最大値の指定処理はトリアコンタンさんのプラグインを参考にさせていただいております。ありがとうございます。

具体的な使い方としては、プラグインコマンド「数値入力ウィンドウ設定」でこれらの設定をすると、次の「数値入力の処理」の際に適用されます。

一度「数値入力の処理」が行われると、これらの設定はリセットされるので、「数値入力の処理」の直前でプラグインコマンドを呼び出すようにするといいでしょう。

ただしRPGツクールの仕様上、「文章の表示」と「数値入力の処理」の間に別の処理を挟むと、数値入力の前にメッセージウィンドウが閉じてしまうため、本当の直前ではなく「文章の表示」よりも前に呼び出す必要があることに、ご注意ください。

具体的な活用方法ですが、私は銀行システムを作る際に活用しています。

銀行に入出金できるのは1000G単位にしたかったため、後ろに文字列で「000Ｇ」と追加しています。

また、入力可能な数値の最大値を設定して、所持金以上に預け入れたり、預金額以上に引き出したりできないようにしています。

質問やアドバイスなどはコメント欄まで、お気軽にお願いします。素材利用条件などについては、このサイトについての「提供素材について」の項目などをご覧ください。

敵が蘇生スキルを使ってくる際に、死亡者が複数いたとしても、ランダムではなく必ず先頭の死亡者が対象になってしまうという、RPGツクールMZのコアスクリプトの不具合を修正します。

• 敵蘇生対象選択修正プラグイン(PANDA_FixedRandomDeadTarget.js)

RPGツクールMVにも同様の不具合があるのですが、ターゲット選択部分のコアスクリプトの構造が微妙に異なるため、今回はMZ専用プラグインとなります。MVへの移植も容易なのですが、検証作業がめんｄ

以前にも「正しい蘇生術」で、RPGツクールVXに同様のプリセットスクリプトの不具合があることを解明し、修正スクリプトも公開していました。

当時の不具合は、Game_BattleActionのdecide_random_targetメソッドにおいて、対象が味方単体(for_friend?)ならば（生存中の）味方からターゲットをランダムに決定、対象が戦闘不能の味方単体(for_dead_friend?)ならば戦闘不能の味方からランダムに決定、としているつもりが、for_friend?にはfor_dead_friend?の場合も含まれるので、この判定順序では対象を戦闘不能の味方にしていても通常の味方単体で選ばれてしまう、というものでした。

実はMZが出た時に、この不具合がどうなっているのか、コアスクリプトを調べてみたことがあります。

対応するGame_ActionのdecideRandomTargetメソッドを見ると、ちゃんと戦闘不能の味方(isForDeadFriend)を先に判別しており、さすがに不具合は解消されているものだと思っていました。

ところが最近になって、蘇生魔法を使用する敵を作って戦闘テストをしていたところ、何度試しても先頭の死亡者ばかり蘇生してきます。

そこで改めてコアスクリプトを検証してみたところ、Game_ActionのdecideRandomTargetは敵の通常行動時に呼ばれるものではなく、敵がターゲットを決めるメソッドはmakeTargetsであることが判明しました。そしてここから呼ばれているtargetsForDeadを見ると、敵が蘇生スキルを使用するという前提がないせいか、先頭の死亡者が選ばれるような構造になっていました。

本プラグインはそれを修正して、敵が蘇生スキルを使ってくる際に対象者をランダムに選ぶようにしたものです。

質問やアドバイスなどはコメント欄まで、お気軽にお願いします。素材利用条件などについては、このサイトについての「提供素材について」の項目などをご覧ください。

RPGツクールMV/MZ用に公開していた「エクセルで能力値かんたん調整」と「エクセルで敵キャラかんたん設定」の2つのExcelツールに不具合があったので、修正版をアップしました。

• 能力値かんたん調整 for RPGツクールMV/MZ
• 敵キャラかんたん設定 for RPGツクールMV/MZ

※ 2023-04-03追記
名前やメモ欄に"があると正常に出力できない不具合を修正しました

各ツールの使い方については、それぞれの記事を参照してください。

今回修正したのは、各職業や敵キャラのメモ欄等に\で始まる制御文字を使用していると、出力されたjsonファイルが読み込めなくなるという不具合です。jsonファイルの中では\が特殊な意味を持つので、\自体を出力するためには \\ としないといけないのを、そのまま \ と出力してしまったため、読み込みエラーが起きていました。エラー報告をいただき、ありがとうございました。

制御文字を使っていない場合は特に関係ありませんが、何かの拍子に制御文字が入らないとも限らないので、念のためアップデートをお願いいたします。

なお、64bit版のExcelをお使いの場合は、そのままでは動作しませんので、
https://tablacus.github.io/scriptcontrol.html
から、64bit版で動作するScriptControlである「Tablacus Script Control 64」をダウンロード＆インストールしてください。

これはtwitterとツクールフォーラムでしか言及していなかったと思うので、改めてエクセルツール上にも記載しました。

もしこれらのツールを使って、うまく動作しないだとか、jsonファイルが読み込めなくなったといったことがありましたら、お気軽にご相談ください。場合によってはファイルの復旧が不可能なこともありますが、その時はご容赦ください。

※ 2021-12-10追記：
RPGツクールMZのVersion 1.4で、タイマーの挙動が修正されました。が、条件分岐のタイマー判定が正しくなっただけで、残り秒数の画面表示や変数取得の場合はこれまで通り小数点以下が切り捨てられる仕様のようです。これらの挙動も修正したい方、およびRPGツクールMVをご利用の方は引き続き本プラグインをご利用ください。

RPGツクールのタイマー機能には、想定より1秒早く終了判定されうるという不具合があります。

RPGツクールMV/MZにて、その不具合を修正するプラグインを作成しました。

• タイマー修正プラグイン(PANDA_FixedTimer.js)

RPGツクールシリーズにはタイマー機能があります。

昔のシリーズから存在する機能で、秒数を指定してのタイマーの始動と停止、タイマーの残り秒数による条件分岐、およびタイマーの残り秒数を変数に取得・操作することができます。また、タイマーの稼働中は画面内に残り秒数が表示されます。

この機能を使うと、1分以内に脱出！とか、30秒後に爆発する爆弾！とか、リアルの時間経過に依存するイベントを作成することができます。ミニゲームや時限イベントで活躍する機能です。

先日、星潟さんより、一部のツクールシリーズではこのタイマー機能に小数点以下の計算が行われない不具合がある旨、報告がありました。

こちらで調べたところMZでも同様の不具合があったので、修正プラグインを作成しました。

なお、VX Ace用の修正スクリプトは上記、星潟さんのサイトにあるので、そちらをご利用ください。

不具合の内容と原因

例えば右のように、タイマーを3秒で開始して、タイマーが0秒以下になるまでループさせるイベントを組んだ場合、実際には3秒ではなく2秒でループが終わってしまいます。

タイマーを1秒にすると一瞬で終わるので、より顕著に不具合が分かります。

不具合の原因は、条件分岐でタイマーの残り秒数の判定をする際に、小数点以下の秒数が切り捨てられている点です。

タイマーは内部ではフレーム数（1フレームは1/60秒）で管理されており、1フレーム経過するごとに残りフレーム数が1ずつカウントダウンされます。

そして残り秒数の判定や表示の際には、残りフレーム数を60で割って残り秒数として使用される仕組みになっているのですが、この時に小数点以下の秒数が「切り捨て」られるようになっています。

この時どうなるかというと、残り1秒から1フレーム経過して残り0.983秒（59/60秒）となった段階で、小数点以下が切り捨てられて0秒として判定されてしまいます。実際にはまだ0.983秒残っているにもかかわらず、1秒をわずかでも切った時点で0秒と判定されてしまうのです。

条件判定が「以上」の場合は正しく判定されますが、「以下」の場合は約1秒早く判定されてしまいます。たいていは「0秒以下」の条件で終了判定する使い方だと思うので、不具合の影響を受けることになります。

たった1秒ではありますが、たいていタイマー機能は制限時間内に何かせよ、というイベントやミニゲームで使用されるので、1秒といえどもかなり重要な意味を持つのではないでしょうか。

修正内容

このプラグインを導入すると、条件分岐のタイマー判定が小数点以下まで含めて正しく判定されます。

具体的には条件分岐のタイマー判定においては、小数点以下込みの数値で判定されます。例えば条件を「3秒以下」とした場合、正しく3.00秒になった瞬間に条件に合致します。従来は3.99秒になった瞬間に条件に合致してしまいました。

また、画面内に表示される残り秒数は、小数点以下を「切り上げ」て表示するように修正しています。従来は残り秒数が1秒を切って0.99秒になると、画面内の表示は0:00となっていましたが、上記不具合が修正されたことにより、このままだと画面上は0:00と表示されながらも、実際にはまだあと1秒弱の猶予があります。これだと紛らわしいため、表示が0:00になった瞬間にタイムアップとなるよう、小数点以下の秒数を「切り上げ」としています。

それから「変数の操作」にも、タイマーの残り秒数を代入・操作する機能があります。これは画面上に表示されている残り秒数と同じ秒数が取得できた方がよいと思うので、同じく「切り上げ」としています。

なお、既に修正前の状態で秒数の調整をされている場合は、本プラグインを導入して修正することによって、逆に想定よりも1秒長くなってしまうことになるため、タイマーを使用しているゲームに後から導入する場合は、ご注意ください。

質問やアドバイスなどはコメント欄まで、お気軽にお願いします。素材利用条件などについては、このサイトについての「提供素材について」の項目などをご覧ください。

RPGツクールではスキルやアイテムに「速度補正」を設定でき、通常よりも先行して放てる技や、逆に発動に時間のかかる必殺技などを実現することができます。

代表的なのは「防御」や「かばう」のスキルです。これらの速度補正を1000や2000といった高い値にすることで、敵の攻撃よりも先に防御や身代わりの体勢をとることができるようになります。

しかし、RPGツクールのデフォルト機能では、1ターンに2回以上の行動をする場合、それぞれの行動の速度補正のうち最小値が採用されるようになっています。そのため、速度補正の高い「防御」や「かばう」と、速度補正が0の通常の行動とを同時に行うと、速度補正としては0が採用されて、真っ先に「防御」や「かばう」の行動をとってくれません。

そこで、複数回行動時の速度補正の算出方法を、最小値から変更するプラグインを作成しました。RPGツクールMVとRPGツクールMZの両方に対応しています。

• 複数回行動時の速度補正変更プラグイン(PANDA_BattlerActionSpeed.js)

このプラグインを導入すると、速度補正の算出方法を以下の6つから選択することができます。

• 各行動の最小値（ツクールの標準と同じ）
• 各行動の最大値
• 各行動の平均値
• 各行動の合計値
• 最初の行動の速度補正値
• 最後の行動の速度補正値

例えば3回行動で、それぞれの行動の速度補正が行動順に300、1000、-100だった時、算出結果は以下のようになります。

• 最小値：-100
• 最大値：1000
• 平均値：400
• 合計値：1200
• 最初の行動の値：300
• 最後の行動の値：-100

考え得る限りの算出方法は用意しましたが、どれが良いのかは議論の余地があります。

特に、速度補正がプラスのものとマイナスのものとを同時に行った場合、どうなるのが自然なのかによるのかなと思います。

プラスの方の速度補正は「防御」や「かばう」などそのターンの最初に発動しないと意味をなさない行動に使われるのに対して、マイナスの速度補正は単に詠唱時間が長いといったペナルティー要素として採用されるケースが多く、それを考えるとプラスの速度補正が重視された方が良さそうな気はします。

一方でマイナスの補正値が全く加味されないのも意味がないので、私は平均値を用いています。

他の方法を使いたいという要望があれば、可能な限り採用したいと思いますので、ぜひお寄せください。

質問やアドバイスなどはコメント欄まで、お気軽にお願いします。素材利用条件などについては、このサイトについての「提供素材について」の項目などをご覧ください。