ありがとうございます。今では完璧に動作しており、まさに私が求めていた通りです！
次に問題が発生した際には、またお知らせします。
プレイヤーを追従する攻撃の衝突判定を、使用していないときは透明にし、攻撃中の場合は表示されるようにしたいのですが、その方法がわかりません。アドバイスはありますか？
また、現在プレイヤーが実行できる実際の攻撃を実装しようとしていますが、半分くらい成功しているといった感じです。1つの投稿に複数の質問を投稿しても大丈夫ですか？ 多くの攻撃を実装したいと考えており、ほとんどの質問は「ここに作成したコードがあるのですが、（これ）の動作をしません。なぜでしょうか？」という形になるため、これが最も効率的な方法だと感じています。
移動ルートのリストで透明化（ON/OFF）するのが最も簡単な方法です。これには1フレームしか要せず、すべてのイベントで機能するため、攻撃共通イベント内の攻撃判定部分に「移動ルートの設定」を追加し、最初に「イベント位置の設定」の直後に「透明化 OFF」を、最後に「攻撃」が OFF に切り替わる直前に「透明化 ON」を設定してください。もし「前方へ一歩」「後方へ一歩」のルートが残っている場合は、それぞれ最初のコマンドと最後のコマンドとしてそのまま使用できます。もし後からフェードアウトさせたいのであれば、「透明度の変更」で 0 と 255 を切り替えるのでも同じ効果が得られます。
両方の切り替えは、衝突判定の並列イベントではなく、共通イベント内に保持しておくことをお勧めします。イベントは一度に1つの強制ルートしか保持できないため、もし衝突判定の並列イベントから「攻撃」が ON の間にルートを強制すると、攻撃中のルートの途中にあるものが上書きされてしまいます。
1つの投稿に複数の質問を含めても問題ありません。システム全体を1つのスレッドにまとめる方が、散らばった5つのスレッドよりも優れています。あなたがこれまで行っていたように、正確なブロックのスクリーンショットを貼っていただければ、私がそれを読み取るのが最も速くなります。
はい、機能しました。では、最初の複数質問に移ります。
これはシールド行動のコードです。プレイヤーの前方に攻撃判定を移動させ、Xキーを押している間、その位置から1タイル前方に留まるように設計しています。Xキーを離すと、シールドは消滅して無効化するはずです。
しかし、実際にXキーを押すと、シールドはプレイヤーの前方に移動した直後に瞬時に消えてしまいます。さらに、この行動を何度も試していると、ランダムにプレイヤーがどの行動も実行できなくなる現象が発生します。
何か解決策はありますか？
この行動は、プレイヤーの速度を5秒間上昇させ、その効果が切れると、次の5秒間は再度この行動を使用できなくする（クールダウン）ものです。
しかし、実際にはプレイヤーの速度は上昇したまま元に戻らず、結果としてクールダウン期間が発生しません。
何か解決策はありますか？
この行動は、プレイヤーを無敵にし、前方へ4タイル突進して、衝突した敵をダメージを与えながら吹き飛ばすことを目的としています。敵が壁に当たるまで吹き飛ばし続けます（この吹き飛ばし処理は敵イベント内で実装されています）。
しかし、プレイヤーが静止状態の場合、画面揺れと効果音は再生されますが、プレイヤーは動きません。その後、どの矢印キーを押しても、プレイヤーは元の行動を実行した方向へ4タイル分移動し、その間キーを押している間は操作可能ですが、4タイル移動後に通常の操作に戻ります。
何か解決策はありますか？
- シールド内の3つの事項。
ホールドチェックは1回しか実行されません。ステップが完了した後、isPressed ブランチは1回だけ評価され、ブロックは終了するため、タップはElse節に収まり消え、ホールドはpressed側に入り、その後に底部へ抜け落ち、ATTACKING がオンのままになり、それをオフにするものが何もありません。pressed側に「1フレーム待機」、released側に「ループ終了」を配置してループで囲んでください。
リリース側も順序が間違っており、これが「一切のアクションがない」状態の原因です。ATTACKING がオフの間、衝突判定自体の追従ロジックが毎フレーム強制的に移動ルートを設定します。イベントは一度に1つの強制ルートしか保持できないため、OFF に切り替えた後に設定した「透過 ON」のルートは完了する前に上書きされ、そのルートの「待機」は戻ってきません。イベント全体がここでフリーズします。ルート設定を先に行い（待機を含む）、最後に ATTACKING をオフにし、衝突判定にルートを設定する他の処理にも同じルールを適用してください。
CurrentX2 と CurrentY2 は「このイベント」を読み取りますが、そのイベント内ではそれは攻撃衝突判定ではありません。キャラクタードロップダウンから攻撃衝突判定を選択するか、またはそれら2つの行と、その下にある「イベント位置の設定」を削除してください。ATTACKING がオンの間、衝突判定は移動しないためです。また、「前方へステップ」ルートにも「移動できない場合はスキップ」を適用してください。「スキップ」がオフの場合、ブロックされたステップは同じフリーズを引き起こします。
◆ループ
◆条件分岐: スクリプト: Input.isPressed("action2")
◆待機: 1フレーム
◆それ以外
◆イベント位置の設定: 攻撃衝突判定、({BPlayer X},{BPlayer Y})
◆移動ルートの設定: 攻撃衝突判定 (待機)
: 透過 ON
◆スイッチの制御: #0181 ATTACKING = OFF
◆ループ終了
◆分岐終了
◆上記を繰り返す
- 「300フレーム待機」はイベント全体を一時停止させるため、その5秒間他のすべてのアクションが無効になります。また、その間にイベントインスタンスが再構築されると（マップ移動はそれにあたる）、処理は中断し、その後「速度4」が実行されなくなります。テスト中にドアをダッシュで通過した場合、これが「戻ってこない」現象の原因です。さらに、ブロック内にはクールダウンがまだ実装されておらず、「速度4」の実行後に終了するだけです。
2つの変数を使用し、「待機」なしで実装することをお勧めします。トリガー時に、両方が0の場合のみ、速度を設定し、DashTimer を300に設定します。トリガーチェックの上に、毎回のパスで、DashTimer が0より大きい場合は1減算し、0になった時点で「速度4」を設定し、DashCooldown を300に設定します。DashCooldown が0より大きい場合は1減算します。減算処理は存在するイベントインスタンス内で実行されるため、マップ移動後も保持され、他のアクションをブロックしません。
- そのブロックは標準プロジェクトでは正しいです。プレイヤーに対する強制ルートは、キーが押されているかどうかに関わらず実行され、その間矢印キー入力は無視されるため、矢印キーが効いていることと、停止状態が何もしないことが、両方ともブロック外の問題を示唆しています。
2つの質問があります。アイドル状態の攻撃衝突判定は、プレイヤーのタイル上にあるのか、それとも前方のタイル上にあるのか、また「すり抜け」がオンになっているか？ 「スキップ」がオンの場合、衝突判定が占有しているタイルへ「前方へステップ」を実行すると、再試行ではなくスキップされるため、4回のブロックされたステップが4フレームで完了し、プレイヤーは全く移動しません。これがまさに停止状態の結果です。また、移動プラグイン（特にVisuStellaのEvents and Movement Core）を使用していますか？
- 現在の状況です。
- 現在の状況です。SCREENSHAKE MEDIUM より下は何も変わりません。
- 待機中の攻撃判定は、プレイヤーの上に位置しています。ATTACKING がオフの間、常に強制的にその位置に固定されています。Through はオンです。VisuStella プラグインは使用しておらず、互換性について悪い噂を聞いているためです。
もし他にミスがあれば申し訳ありません。あなたの言っていることを理解しようと、本当に必死に努力しています。
これは、私がこれまで携わってきたイベント作成よりも何桁も複雑で、圧倒されないようにと必死に全てを理解しようとしています（笑）。これまでに示してくださった忍耐に、心から感謝しています。
-
確かにその通りです。CurrentX2 と CurrentY2 はもうどこからも使われていないので、残していても消してもどちらでも構いません。特に問題にはなりません。
-
タイマーのロジックが
isTriggeredブロックの中にあります。そのため、キーを押したフレームでのみ実行され、押されたときしかカウントしないタイマーは減算されません。減算処理は、イベントの毎フレーム実行される部分（トリガーチェックより上）に置く必要があります。もう一つのポイントは、DashTimer = 0の分岐です。これはアイドル状態の間ずっと真となるため、毎フレーム発火してしまいます。これを減算処理の中にネストすることで、タイマーが実際に 0 になったフレームでのみ発火するようにします。構成は以下のようになります：
◆If: DashTimer > 0
◆Control Variables: #0207 DashTimer -= 1
◆If: DashTimer = 0
◆Set Movement Route: Player
: Speed: 4
◆Play SE: STUTTER
◆Control Variables: #0206 DashCooldown = 300
◆End
◆End
◆If: DashCooldown > 0
◆Control Variables: #0206 DashCooldown -= 1
◆End
◆If: Script: Input.isTriggered("action3")
◆If: DashTimer = 0
◆If: DashCooldown = 0
◆Common Event: SCREENSHAKE MEDIUM
◆Play SE: GO UP
◆Set Movement Route: Player
: Speed: 6
◆Control Variables: #0207 DashTimer = 300
◆End
◆End
◆End
- 移動中の衝突判定がプレイヤーのタイル上で発生しているため、私が考えていた可能性は除外されます。そこで次の質問です。プロジェクト内で、矢印キーが押されていない間にプレイヤーに対して移動ルートを設定しているものは他にありませんか？ 待機ポーズの表示、画像の切り替え、何かを向くための回転など、静止しているときに毎フレーム実行されるような処理です。衝突判定と同じく「一度に一つの強制ルート」というルールが適用されます。もしアイドル中に何かしらがプレイヤーに毎フレームルートを強制している場合、羊のルートは実行される前に上書きされてしまいます。プレイヤーはルートが常に強制されているためフリーズしたままになり、矢印キーを押した瞬間にその強制が解除されると、羊のルートがようやく実行され、向いていた方向へ 4 タイル分移動することになります。これがまさに、何も起こらない状態、矢印方向が無視される状態、キーを押している間のみ移動するという現象の原因です。
これらについて謝る必要はありません。イベントシステムはアクションシステム用に作られたものではなく、あなたは十分に対応できています。
-
シールドは意図した通りに動作していますが、シールドが有効な間、プレイヤーが動けなくしたいです。現状では、シールドを召喚してXキーを押しながら逃げることができます。どうすればいいでしょうか？
-
これが今のコードです。青く選択された部分の下はすべてエンドコマンドです。プレイヤーの速度が一向に落ちないため、まだ正常に動作していないようです。おそらくここでも何かを壊してしまいました。あーあ。
-
それはちょっと怖いですね。いいえ、パレllelプロセッサがプレイヤーに移動ルートを適用しているという記憶はありません。私が知っている限りでは、プレイヤーの向きに合わせて攻撃判定の方向を変えるためのコードや、特定の変数に基づいてプレイヤーの外見を変更するコードがありますが、それらも単に「アクター画像の変更」コマンドを使用しているだけです。
- 強制移動経路とは、プレイヤーの入力をブロックするもので、実行中は矢印入力が無視されます。したがって、終了しない強制経路を設定します。シールドブロック内の「ATTACKING = ON」の直後で以下のようにします：
◆移動経路の設定: プレイヤー (リピート)
: 待機: 1フレーム
「移動経路をリピート」にチェックを入れ、「完了を待たない」にチェックを入れません。これによりループし、他の処理で置き換えるまでプレイヤーは移動も回転もできなくなります。その後、シールド解除のブランチでは、「ATTACKING = OFF」の前に以下を追加します：
◆移動経路の設定: プレイヤー
: 待機: 1フレーム
同じコマンドですが、「リピート」はオフです。これは1フレーム実行して終了し、入力が有効に戻ります。注意点として、シールド使用中にプレイヤーに設定された他の経路は、このフリーズを置き換えるため、ダッシュの速度4でシールド中に着地すると、プレイヤーが早期に解放されてしまいます。
-
全体は依然として最上部の
isTriggeredで囲まれているため、タイマーは押したフレームでのみカウントされます（以前と同じ）。外側のIfとEndを削除し、2つのタイマーブロックがイベントの最上位レベルに位置し、内部のisTriggeredが唯一のトリガーとなるようにします。内容は正しいので、問題なのはラッパー部分だけです。 -
そのリストのどの項目も該当しないため、また推測するよりもテストを実行した方が良いでしょう。マップ上に捨て用の「アクションボタン」イベントを作成し、そこに全く同じ経路を設定します。具体的には、「移動経路の設定: プレイヤー」で「スキップ」と「待機」をオンにし、「4歩前方へ」を4回設定し、プレイヤーが静止した状態でそれと対話させてみます。プレイヤーが4タイル移動する場合、経路自体は正常であり、実行コンテキストに何か問題があります。プレイヤーが動かない場合、プロジェクト内の何かがプレイヤーの経路全体に影響を与えているため、
action1からaction4の入力を追加するプラグインを含む、すべてのプラグインリストが必要です。また、シールドとダッシュがイベントをフリーズしなくなった今、再度試す価値があります。あなたが以前見た現象の一部は、古いハング（固まり）だった可能性があります。
1-はい、それで完了です。
一つ気になる点として、念入りにテストしていたところ、矢印キーとXキーを同時に押すと、シールドが有効な間、プレイヤーがシールドから1タイル離れた方向に回転して移動してしまう現象が見つかりました。また、プレイヤーの移動速度が6の場合、シールドがプレイヤーの動きについていけないせいか、約半数のケースでプレイヤーの前にスポーンするのではなく、プレイヤーの上にスポーンしてしまいます。
2-今度は完璧に動作します！
3-CTRLキーを押しながらイベントをクリックしたところ、プレイヤーは確かに4タイル分前方に移動しました。
- これらはどちらも同じルートです。盾の位置と向きは、プレイヤーより1フレーム遅れて動作する衝突判定の追従ロジックから借用されています。同じフレーム内で矢印キー＋Xを入力すると、衝突判定のターンが適用される前に盾のルートがそれを入れ替えるため、プレイヤーがターンして新しい方向へ歩を進めている間、盾は古い方向へ歩を進めます。速度6の場合、同じラグにより、盾はプレイヤーの次のタイルではなく、すでにプレイヤーがいるタイル上に配置されてしまいます。修正策は、盾を歩かせない代わりに、プレイヤーの現在の位置と向きを同じブロック内で計算して、手前のタイルに直接配置することです：
◆制御スイッチ: #0181 攻撃中 = ON
◆移動ルートの設定: プレイヤー (繰り返し)
: 待機: 1フレーム
◆SE再生: ダークネス6
◆変数操作: シールドX = プレイヤーのマップX座標
◆変数操作: シールドY = プレイヤーのマップY座標
◆変数操作: シールド方向 = プレイヤーの向き
◆条件分岐: シールド方向 = 2
◆変数操作: シールドY += 1
◆イベントの場所設定: 衝突判定, ({ShieldX},{ShieldY}), 下
◆分岐終了
◆条件分岐: シールド方向 = 4
◆変数操作: シールドX -= 1
◆イベントの場所設定: 衝突判定, ({ShieldX},{ShieldY}), 左
◆分岐終了
◆条件分岐: シールド方向 = 6
◆変数操作: シールドX += 1
◆イベントの場所設定: 衝突判定, ({ShieldX},{ShieldY}), 右
◆分岐終了
◆条件分岐: シールド方向 = 8
◆変数操作: シールドY -= 1
◆イベントの場所設定: 衝突判定, ({ShieldX},{ShieldY}), 上
◆分岐終了
◆移動ルートの設定: 衝突判定
: 透明 OFF
: 画像: MH VitalAttacks1(2)
◆ループ
...
プレイヤーの向きは、下=2、左=4、右=6、上=8として返されます。フリーズが先に行われるため、すでに進行中のステップは最後のものになり、プレイヤーのマップXおよびY座標はステップの途中ですでに目的地のタイルになっているため、盾はプレイヤーが最終的に停止する位置の手前に着地します。透明化と画像の設定ループには、待機処理は不要です（終了を待つ依存関係がないため）。
- 問題ありません。
- Ctrlキーを押さずにそのテストをやり直してください。プレイテストでは、Ctrlキーを押すと通行不可能フラグが無効になるため、押したままにするとルートは常に歩行し、テストが何も教えてくれません。Ctrlキーを押さなくても4タイル分移動する場合、ルート自体は正常であり、次のテストとして、ラムブロックをコピーして独立した新しい並列共通イベントに配置し、隣接するブロックが干渉していないかを確認します。Ctrlキーを押さずに移動しない場合、前方のタイルが停止状態から通行不可能として認識されているため、ステップがスキップされています。その場合、プレイヤーの周囲や上に他に目に見えないオブジェクトがあるかどうかを教えてください。
1-これは正常に動作していると思います！
3-プレイヤーがイベントに無限にぶつかり続けるのを防ぐため、最初に「ランダムな方向に移動する」コマンドを追加しました。そして、プレイヤーは確かに移動を完了しています。
- よさそうですね。
- だとすると、ルート自体は正常で、実行環境に問題があるということになります。次のテストの前に、実際のイベントで使われているRAM（ランダムアクセスメモリ）をもう一度試してみてください。最初に報告された際、シールドとダッシュの両方でそのイベントがフリーズしていたため、修正後もRAMが依然として誤動作しているかどうかを確認したかったのです。もし現在問題なく動作するなら、それが原因だったことになります。
それでもフリーズする場合は、さらに2つ試してみてください。SCREENSHAKE MEDIUMの中身を貼り付けてください。これは私がまだ確認していないRAMブロックの一部分です。また、RAMブロックを、他に何も含まない全く新しい並列コモンイベントにコピーして、そこからテストを行ってください。もし単独で正常に動作するなら、隣接するブロックのいずれかに問題があり、一つずつ無効化していくことで、どのブロックが原因かを特定できます。
いいですね、これで近所の人々は除外できます。動作するアクションボタンテストと、動作しないこの並列処理の間に残っているのは、ブロック内の2つの相違点、つまり「シェイク共通イベント」と2つの「ATTACKING」行、そしてトリガーキーが関与する何かです。
代替テスターで2つの簡単な編集を行います。まず「Common Event: SCREENSHAKE MEDIUM」行を削除してテストしてください。ラム（RAM）が走れば、それはシェイクプラグインが原因です。もし走らなければ、それを元に戻し、両方の「Control Switches」行を削除して再度テストしてください。
別途、ScreenShakePlusが存在することは、プロジェクト内にプラグインがあることを意味します。そのため、プラグインマネージャーからの完全なリストが必要です。私が最も気にしているのは、Sをaction4に割り当てているプラグイン、そしてそれがリスト内の他の何かと同様に、移動、WASD、8方向移動、ピクセル移動などのいずれかを処理しているかどうかです。action4かつ移動入力として機能するキーがあるかどうかは、知っておく価値があります。
そのリストの中で、特に気になるものがあります。「TurnInPlace」は、入力からプレイヤーの移動方法をどのように変更するかを定義するもので、「ステップ」と「実際の移動」の間に位置するプラグインは、プレイヤーの強制ルートがイベントの同じルートとは異なる動作をする原因となり得るものです。あなたが説明したすべての要素は、方向キーが押されている間のみプレイヤーが歩行を許可するプラグインに一致します。
「TurnInPlace」をオフにして、Alternate testerからラムを実行してください。もしうまくいけば、それが原因です。ラムを回避しながらそれを維持する方法について話し合うことができます。もしうまくいかなければ、一つずつ「BUTTON ADDERS」と「ToshA_Footsteps」で同じことを試してください。これらはプレイヤーの移動や入力に影響を与える他の2つの要素だからです。
やっぱり、問題はTurnInPlaceプラグインだったんだね。今はRAMも正常に動作しているから、そういうことかとは思うけど、ちょっと残念だな（笑）。
できれば、このプラグインを使いたいんだ。自分がその場で回転できるのが好きだし、他の攻撃でも重要になる場面があるからね。でも、もしやむを得ない状況になったら、外すしかないかな。
幸いなことに、それは保持したままにしておくことができます。アクションボタンのテストが手がかりです。同じルートが、実行中のイベントからは正常に動作しましたが、並列イベントからは失敗しました。つまり、TurnInPlaceはイベントが制御を握っている間は身を引くようであり、並列から来るプレイヤーのルートにのみ干渉しているようです。
コードを変更しない解決策としては、ラム（羊）の動きを実行中のイベントから来るようにします。ラムに独自の共通イベントを用意し、トリガーを「自動実行」に設定し、スイッチ（RamGoと名付けます）を追加します。並列イベントのアクション4ブロックは、RamGoをONにするだけです。共通イベントでは、画面揺れ、効果音（SE）、攻撃中ON、待機付きのルート、攻撃中OFF、そして最後の行としてRamGoをOFFにします。自動実行は、アクションボタンイベントと同様にマップのメインインタプリタ上で動作するため、プレイヤーは操作中に移動できません（これが今回の望ましい動作です）。また、これはすべてのマップで機能します。今後、ステップ移動でプレイヤーを動かす攻撃が発生した場合でも、同じ形状を使用できます。
もしソース側で修正したい場合は、TurnInPlace.jsの内容をここに、またはPastebinに貼り付けてください。おそらく短いコードでしょうし、修正は「移動ルートが実行されている間はプレイヤーを無視する」という数行の記述で済むはずです。これですべての問題が一度に解決されます。
天才的な動きだ、lol。これ追加して、結果を教えてね。
こんな感じで実装できないか試してみよう
Action4 Triggered=turn MOVINGATTACK ON
そして、MOVING ATTACK HANDLER という新しいハンドラで
-MOVINGATTACK が ON なら、
-MOVING ATTACK HANDLER の2ページ目に移動
-if MOVINGATTACK が ON かつ ATTACK TYPE=3 なら、攻撃を実行