Posted Articles

2023年 01月's articles. (3)

わんころのUE5勉強会 Jan/18/2023 00:03

自作ゲームの進捗05:引き出しとドアの開閉処理

ここ1週間ほど UI 周りを触っていてメインの処理から離れていました。
動画のようなインタラクト処理の一部で、引き出しとドアの開閉処理を作成しました。

この辺りの処理はこれっきりの BP だと勿体ないので再利用できるようにある程度は柔軟にしたつもりです。

久々に通常の BP を作成して目に見える部分が出来た気がします。
今のところ BaseBP やシステム周りの部分を作っていたので動きが出てくると楽しみも一気に増しますね。

この作業でこの一週間分は一段落したので動画作成もしないとですね。

動画作成してる途中に辞めたお蔵入りシリーズも公開していこうかな...

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Jan/07/2023 22:07

【UE5】Enhanced Input で利用できる他の関数

Enhanced Input に関数は沢山ありますが、調べても日本語の情報があまり見つからなかったので私なりに検証した内容をまとめています。

相変わらずですが間違ったことを書いてる可能性がございますのでご注意下さいませ。

C++(ヘッダ/ソース)ファイルの場所

UE5.0 のデフォルトのインストール先:
C:\Program Files\Epic Games\UE_Version\Engine\Plugins\Experimental\EnhancedInput\Source\EnhancedInput

UE5.1 以降のデフォルトのインストール先:
C:\Program Files\Epic Games\UE_Version\Engine\Plugins\EnhancedInput\Source\EnhancedInput
(UE5.1 以降で Experimental でなくなったためファイルパスが変更されています)

上記ファイルパスまで移動し
「Private」に ".cpp"
「Public」に ".h" が入ってました。
その中の EnhancedInputSubsystemInterface.h(.cpp)、EnhancedInputLibrary.h(.cpp) にこの先出てくる関数が確認できました。


IMC の大事な仕様(2023-12-07 文面を修正)

個人的に結構大事な仕様だなと思ったのと、マニュアルに書いてなさそうだったので追記しました。

IMC を開くと一番上に Mappings という項目があり、その横の [+] ボタンをクリックすることで入力アクションやキー入力の割り当てが出来るようになっています。


この情報は IMC の「Get Mappings」から配列で取得でき、型は Enhanced Action Key Mapping構造体 になっています。


この IMC に対して例えば「Unmap All(後述)」を使うと IMC の中に割り当てた Mappings を全て削除することができますが、Blueprint からIMC を直接書き換えた場合、上書き保存を示すマーク「*」が付きません

そのためプロジェクトを再起動する時に保存が聞かれることもないですし、プロジェクトを再起動後は「Unmap All」する前の状態に戻っています。これはパッケージ化したゲームでも同じ挙動になっています。

この挙動はバグではなく仕様とのこと。

Unreal Engine Issues にて「ゲームプレイ中に行われたInputMappingContextへの変更は、エンジンを再起動すると以前の状態に戻ります」という報告があります。

By Design と記載されており仕様のようです。
IMC を直接書き換えた後、起動中は問題ないですが、ゲームを起動し直す時には注意が必要ということになります。

以前アップロードした動画でキーコンフィグを実装する際、IMC を直接書き換える方法で紹介しましたが、上記理由から IMC を書き換えるキーコンフィグはやめておいた方がいいかなと思いました。


そのため、Enhanced Input でキーコンフィグを実装する場合は、SaveGameObject で割り当てたキーを保存するようにしておき、ゲーム起動時にその情報をロード> 後述の「Add Player Mapped Key」を使って表面上キーを置き換える方がいいかなと思います。
※UE5.3で非推奨な機能となり利用できなくなっています

以降は過去に検証などを行った関数をまとめたものです。


Has Mapping Context

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/MappingQueries/HasMappingContext/


Enhanced Inbput Local Player Subsystem に "Mapping Context" で指定した IMC が追加されているかを確認する関数です。

True でその IMC は追加されていて、
False でその IMC は未追加であることが分かります。

「Add Mapping Context」されているか確認したい時に利用できそうです。


Query Keys Mapped to Action

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/MappingQueries/QueryKeysMappedtoAction/


"Action" で指定した「入力アクション」のキーすべてが "Return Value" の Key構造体の配列で返ってきます。


例えば "Action" に IA_Jump を設定し、IMC に割り当てた IA_Jump が、画像のように三つのキーで設定されていた場合は "Return Value" の Key構造体の配列には下記のように割り当てた順番で返ってきます。

Key構造体[0]:「スペースバー」
Key構造体[1]:「マウスの右ボタン」
Key構造体[2]:「T」

この関数には IMC の指定はなく、入力アクションのみ指定しています。
IA_Jump を利用している複数の IMC があると配列の中身がどうなるか気になります。

そこで「IMC_A」「IMC_B」と二つの IMC を用意してみました。


検証1:Priority で優先順位を与えた場合


IMC_A と IMC_B に画像のような "Priority" を与えています。(「Add Mapping Context」する時の "Priority" のことです)
  • 「Print String」で配列の中身を出力したところ、Priority の高い IMC から先に配列に格納されていることが確認できました。(「Print String」の出力は下の方が先に処理されています)
  • IA_Jump で設定した順番で配列に格納されていることも確認できます。また、IMC_B の4キーとKキーの位置を入れ替えた場合は配列の中身もそれに合わせて出力されていました。
  • 重複したキー(スペースバー)が見つかった場合、2回目は出力されていないことも確認できます。
    重複したキーがあった場合、Priority の高い方が先に配列に入り、低い方は無視されるといった結果になっていました。

検証2:同じ Priority の場合

  • 後から「Add Mapping Context」した方が先に配列に格納されたことが確認できました。
  • こちらも同じく重複したキーがあった場合2回目は無視されます。

IMC_A だけ「Add Mapping Context」した場合は IMC_B の結果は配列に入りませんでした。「Has Mapping Context」が True を示すもの(現在有効な IMC) のみに対して作用するということです。


Query Map Key in Active Context Set(2023-03-20追記)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/MappingQueries/QueryMapKeyinActiveContextSet/


何を行うための関数なのか分かりませんでした...
一応リストに載せてたのでそのまま残しています。

Query Map Key in Context Set(2023-03-20追記)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/MappingQueries/QueryMapKeyinContextSet/


何を行うための関数なのか分かりませんでした...
一応リストに載せてたのでそのまま残しています。


Break Input Action Value

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/BreakInputActionValue/


Input Action Value 構造体("In Action Value")を、X, Y, Z に分解する。サポートされてない値(軸)は 0 が返ってきます。

軸を扱う入力を分解するようなので
「Break Vector」に似たような扱いでしょうか。


Make Input Action Value

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/MakeInputActionValue/


XYZ の値を使って Input Action Value構造体を作成します。

"Match Value Type" が参照渡しになっており、接続しないと有効なインプットが必要とエラーが出ます。
利用されてない軸には 0 が設定(無視)されるようです。

既存の Input Action Value を変更することを目的としているようです。後述の「Inject Input for Action」「Inject Input Vector for Action」などと組み合わせて使ったりできそうでした。


Inject Input for Action(2023-01-19追記)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/InjectInputforAction/


"Action" に繋いだ指定の入力アクションへのトリガーを "Raw Value" の値に応じてシミュレートするような使い方になりそうです。
"Modifiers" や "Triggers" も考慮したシミュレートをしたい場合は必要に応じて設定できます。


例えば "Action" に IA_Jump を設定し、"Raw Value" に前述の「Make Input Action Value」を使って Input Action Value構造体を渡します。

これでプレイしてみると1キーを押した時に入力アクション IA_Jump がトリガーされジャンプしたことになります。

この関数に IMC を指定するところはありませんが、「Has Mapping Context」が True を示すもの(現在有効な IMC) が対象になります。

この入力アクションを何らかの理由でトリガーしたことにしたい時に使えそうな気はしましたが、そういうシチュエーションを思いつかなかったので例を挙げることができませんでした。


Inject Input Vector for Action(2023-01-19確認)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/InjectInputVectorforAction/


上記「Inject Input for Action」の Vector 入力が取れるバージョンです。
これも入力アクションのシミュレートをしたりなどに使えるんだと思いますが、そういうシチュエーションが想定できず...

Request Rebuild Control Mappings(2023-05-31修正)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/RequestRebuildControlMappings/


"Rebuild Type" で指定した内容に沿って IMC の再構築を行います。

この関数は「Add Mapping Context」「Remove Mapping Context」「Clear All Mappings」などの、IMC を更新する関数で利用されてました。

そのため、IMC 自体をなんらかの手段で変更する場合は、この関数を使って更新する必要があります。


一例ですが、ゲーム中のキーコンフィグでユーザが入力したキーに変更するといった処理を実装したとします。

IMC に登録している Mappings(Enhanced Action Key Mapping構造体)を参照で取得してメンバ内を直接書き換える実装をした場合、IMC のファイル上は変更されますが、「Request Rebuild Control Mappings」が呼ばれないとゲーム内では反映されませんでした。

先程挙げたような Blueprint に公開されている関数内で「Request Rebuild Control Mappings」が呼ばれているものを使った場合は問題ないですが、特に手動で IMC を触ることをした場合は、ゲーム内だけで見ると反映してないように感じるので注意が必要です。



再構築を行う対象は「Enhanced Input Local Player Subsystem」が持つ IMC すべてに実行されます(前述の「Has Mapping Context」が True を示すものが対象です)

"Options" は「Add Mapping Context」などに出てきた "Modify Context Options 構造体" です。

ピンを分割(もしくはBreak)して表示される "Ignore All Pressed Keys Until Release" は True にしておく方がいいかもしれません。

"Options" については 以前の検証記事(Ignore All Pressed Keys Until Release) をご覧ください。

"Rebuild Type" は EInputMappingRebuildType という Enum 値を指定します。

  • None:再構築は行わず何も処理しないようです。
  • Rebuild:一般的な再構築ならこれでいいと思います。各入力アクションの Triggers/Modifiers などの情報がそのまま保持されます。
    キーコンフィグでは一般的にユーザが入力したキーを入れ替えるだけで良さそうなのでメインはこれになりそうな気がします。

  • RebuildWithFlush
    「入力アクション」自体の Triggers/Modifiers など変更を加えた場合、上記 Rebuild だけでは再構築されないようです。
    一度フラッシュを行い、そこから再構築という流れを取ってる感じがします。キー以外の変更を伴う場合のオプションではないかと思います。


Map Key

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Mapping/MapKey/


”ターゲット” に指定した IMC 内で、"Action" に指定した入力アクションを対象に "To Key" で指定したキーの割り当てを追加します。


例えばこの画像の場合 ”ターゲット” で指定した IMC の中にある IA_Jump に対して Bキーを追加するという挙動になります。


「Map Key」の注意点は、割り当てるキー("To Key")に関しては重複チェックはされていないようで、「Map Key」を呼ぶたびに上の画像のようにキーが追加され続けるので注意です。

キーが追加されるだけなので Triggers/Modifiers のようなオプションなどは考慮されません。

Unmap Action

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Mapping/UnmapAction/


”ターゲット” に指定した IMC 内で、"Action" に指定した入力アクションを丸ごと削除します。


例えばこの画像のような設定で "Action" に IA_Jump を指定した場合、入力アクション(IA_Jump)ごと消えていることが確認できます。

Undo(Ctrl + Z) が効かないみたいなので、動作確認する時はファイルコピー推奨です。


Unmap Key

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Mapping/UnmapKey/


”ターゲット” に指定した IMC 内で、"Action" に設定した入力アクションを対象に、"Key" で指定したキーと同じキーの割り当てがあった場合それだけ削除します。

上記「Unmap Action」に、追加でキーを指定できるバージョンです。


例えばこの画像の場合、"Action" に IA_Jump、"Key" にスペースバーを指定した場合、スペースバーだけが削除されます。

"Action" や "Key" を指定しない場合は、対象の入力アクションやキーがないため削除されませんでした(何も起こらない)

Undo(Ctrl + Z) が効かないみたいなので、動作確認する時はファイルコピー推奨です。


Unmap All

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Mapping/UnmapAll/


”ターゲット” に指定した IMC のマッピングを全てクリアする。
入力の割り当てを綺麗にする効果です。

Undo(Ctrl + Z) が効かないみたいなので、動作確認する時はファイルコピー推奨です。


Clear All Mappings(2023-07-07追記)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.1/en-US/BlueprintAPI/Input/ClearAllMappings/

「Add Mapping Context」で追加された IMC を全て削除する。

例えばゲーム中にリトライや、タイトル画面からやり直すなどした場合に、実装によっては余分な IMC が追加されている可能性があるため、一度すべて削除して必要な IMC だけ再登録するような処理などに使えそうです。


Add Player Mapped Key(2023-05-31修正)

※UE5.3で非推奨な機能となり利用できなくなっています

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/PlayerMappable/AddPlayerMappedKey/

"Mapping Name" に指定した名前と一致する名前を探し、見つかった場合そのキーを "New Key" に置き換えます。
実行中、一時的にキーを変更したい時に利用する関数みたいです。


一致する名前が複数ある場合、そのキー全てが置き換えられます。


"Mapping Name" の名前というのは IMC で割り当てた各入力アクションの中にある Player Mappable Options 内の "Name" がここに該当します。

上記二つの画像が示す挙動は、有効な IMC に "JumpMappable" という名前があるかを確認し、一致した名前があった場合、その名前をすべてチェックします。

そして、IA_Jump に割り当たっているスペースバーに "JumpMappable" という名前が見つかったので、"New Key" に指定した「5キー」がジャンプのキーに置き換わります。


例えば IA_Jump にスペースバーと左クリックが割り当たっていて、両方 "JumpMappable" という名前にしていた場合、この二つのキーが両方「5キー」になります。

入力アクションを跨いでも同じ効果があるため IA_Shoot に "JumpMappable" という名前を設定したらこれも置き換わります。

"Mapping Name"に同じ名前を指定するケースがあるのか分かりませんが、もし同じ名前にした場合は「Add Mapping Context」で指定する Priority が高い方が優先される挙動になっていました。


また、IMC 自体を直接編集している訳ではないみたいです。
(IMC を開いたままゲーム中の挙動を確認しても IMC 自体には何の変化もありませんでした)


前述の「Request Rebuild Control Mappings」を使ったあと、ゲームを起動し直しても IMC 自体は書き換わっていませんでしたので置き換えると表現しています。

キーコンフィグに利用する場合は、Save Game Object を利用してキーコンフィグしたキーを保存し、ロード時にその情報を使ってこの関数で置き換えるような実装でキーコンフィグが実現できそうです。


戻り値の "Return Value" は置き換えられたマッピングの数を Intger型で返すそうですが、複数あっても1しか返ってこなかったためよく分かりませんでした。

"Options" は Modify Context Options構造体です。
Options については 以前の検証記事(Ignore All Pressed Keys Until Release) をご覧下さい。


Get Player Mapped Key(2023-05-31追記)

▼ 公式ドキュメント
<見つからず>

前述の「Add Player Mapped Key」にて置き換えられたキーを取得する関数で、この関数だけ単体で使っても(多分)None しか返ってこないです。

ここで指定する "Name" は前述の「Add Player Mapped Key」の引数にある "Mapping Name" と同じ名前を指定します。

「Add Player Mapped Key」で置き換えたあと、そのキーだけ取得したい場合に利用できます。



Add Player Mappable Config(2023-03-20追記)

▼ 公式ドキュメント
https://docs.unrealengine.com/5.0/en-US/BlueprintAPI/Input/PlayerMappable/AddPlayerMappableConfig/

"Config" に指定の "Player Bindable Input Config" を追加します。
UE5.1 だと名称が変更されており、Player Mappable Input Config になっています。

"Player Bindable Input Config" / "Player Mappable Input Config" についてどういうファイルなのかは別記事で簡単にまとめました。


Get All Player Mappable Action Key Mappings(2023-05-31追記)

▼ 公式ドキュメント
<見つからず>

"Is Player Mappable" が ON になっているキーだけを取得出来る関数ですが、取得可能な範囲は「Has Mapping Context」が True を示すもの(現在有効な IMC) が対象になります。

キーコンフィグ可能なキーだけ取得できる凄い関数ですが、前述の通り現在有効な IMC に設定された "Is Player Mappable" のキーのみ取得されます。

例えば乗り物に乗った時だけそれ用のキーを割り当てた IMC を追加するような実装をしていた場合は、キーコンフィグ時に乗り物に乗ってないと「Add Mapping Context」されていないのでそのキーが取得できない状態が予想されます。

これを解決できるアセットが用意されています。
別記事にて紹介している"Player Bindable Input Config" / "Player Mappable Input Config" に簡単な使い方をまとめています。



"Is Player Mappable" というフラグは IMC を開き、各入力のキー割り当てを展開すると出てくるフラグのことです。

このフラグにチェックを入れたあと保存してエラーが出た場合、"Player Mappable Options" を展開すると出てくる "Name" に好きな名前を入れておきます。



例えば移動キーで使われる WASD のキーで A と D だけ "Is Player Mappable" にチェックを入れ、上記の画像のように1キーを押してこの情報を出力した結果がこれです。

「Add Mapping Context」で複数の IMC が有効になっている場合はそれらも含まれます。


ややこしすぎるって...

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

わんころのUE5勉強会 Jan/01/2023 00:00

【UE5】Enhanced Input:Priority や Consume Input の検証

皆様、あけましておめでとうございます!!
今年も一年宜しくお願い致します!

2022年で一番触ったはずの Enhanced Input が未だによく分かっていません。
すべての始まりである「Add Mapping Context」も初心者の私にはややこしかったため、色々確認したことをまとめた記事になります。

【この記事の内容を YouTube の動画で公開】
https://youtu.be/j8pUpNu8CuE


「Input Mapping Context」を記載するのが長いので、以降 IMC と記載しています。

Add Mapping Context


Enhanced Input を触った時に一番最初にお世話になるノードだと思います。

機能としては "Mapping Context" で指定した IMC を追加し、入力を使えるように準備します。

"Priority" で入力の優先度をつけることができます。
数字の大きい方が優先度が高くなります。


2023-01-02 追記:
"Options" ですが、とても重要なオプションであることが分かったため追記致しました。
どういうオプションなのかについてページ下部の「Ignore All Pressed Keys Until Release」に追記しております。


抑えておくメインの機能についてはたったこれだけです。
これだけなんですが、どういう挙動を示すのかを見ていくと意外とややこしいです。

しかも Enhanced Input を使う上で絶対理解した方がいい挙動ばかりでした。


▼ Enhanced Input の公式ドキュメント
https://docs.unrealengine.com/5.0/ja/enhanced-input-in-unreal-engine/

公式ドキュメントにこのような記載がされています。

適用したコンテキストに優先順位を付けることで、同じ入力を受け取る複数のアクション間の競合を解決できます。

複数の IMC があり、それぞれで IA_Jump という同じ入力アクションを設定した場合、ジャンプボタンを押した時にトリガーされるのは1回なのか、複数回なのか気になりますよね。

この記事はその優先順位に注目しています。
そんなわけで下記いくつか検証を行ってみました。

検証の前に

今回の検証ではジャンプのトリガーを基準に見てみます。


まず IMC_A と IMC_B の2つを用意し、両方に入力アクションの「IA_Jump:スペースバー」を割り当てています。

IMC_A は Triggers に Pressed を指定しています。
(Pressed はキーを押した瞬間トリガーされます)

IMC_B は Triggers に Released を指定しています。
(Released はキーを離した瞬間トリガーされます)

また、入力アクション IA_Jump には Triggers/Modifiers は設定していませんが、大事な設定なので "Consume Input" に赤枠をつけています。
最初は ON の状態で確認します。



トリガーの確認方法ですが、ジャンプがトリガーされた時「Print String」で "Jump" と出力するようにしました。

押した離したでどうなるか見ていきます。

検証1:IMC_A の優先度を高くする


「Add Mapping Context」の Priority を IMC_A が高くなるようにしました。

プレイして確認すると IMC_A の Pressed 入力が優先され、スペースバーを押した瞬間に1回トリガーされます。

IMC_B の Released はトリガーされません。


検証2:IMC_B の優先度を高くする


今度は IMC_B の Priority が高くなるようにしました。

プレイして確認すると IMC_B の Released 入力が優先され、スペースバーを離した瞬間に1回トリガーされます。

IMC_A の Pressed はトリガーされません。


検証3:同じ Priority にする


今度は両方の Priority を同じにしました。

プレイして確認すると後で追加された IMC_B の Released 入力が優先されスペースバーを離した瞬間に1回トリガーされます。

IMC_A の Pressed はトリガーされません。
同じ Priority の場合は後から追加したものが優先されます。


ここまでの結果で、入力が被った場合は Priority の高い方が優先され、同じ場合は「Add Mapping Context」で後から追加したものが優先された入力になることが分かりました。


検証4:割り当てるキーが違う場合


今度は IMC_B のスペースバーの代わりにマウスの右クリックを割り当てました。

入力の被りがなくなった場合はどう処理されるかも見てみます。
結果は Priority に関係なく両方ともトリガーの対象になります。

IMC_A のスペースバー(Pressed)と、IMC_B の右クリック(Released)が両方とも利用できるということです。

同じ IA_Jump を使ってるので Priority の高い方が優先されるのかなと思いましたが、キー入力も完全に一致してる時じゃないと効果はないようですね。


この設定をちぐはぐにしておくメリットがあるのか分かりませんが、入力があっちもこっちも反応してる場合はこの辺りを見直したほうが良いかもしれません。

検証5:Consume Input とは?

※ IMC_A と IMC_B 両方ともスペースバーの入力に戻しました


ここまでの検証は "Consume Input" が ON でした。
OFF にするとどういう挙動になるかも見ていきます。

結果は Priority に関係なく両方ともトリガーの対象になります。

入力はどちらもスペースバーですが、押した瞬間、離した瞬間それぞれでトリガーされるということです。

"Consume Input" は入力が被ったキーがあった場合、優先度が低い入力も処理するか?という設定になることがわかりました。

2023-01-03 追記:検証6:複数の IMC で入力アクションは異なるが同じキーを割り当てた場合


今度は IMC_B に違う入力アクション IA_Jump2 を割り当て、キーはスペースバーで同じキーを割り当てました。

入力イベントは異なっているが、割り当てたキーは同じというシチュエーションです。

この結果は Priority の高い方が優先されます。
それぞれの入力イベントでトリガーされるだろうと思っていたので意外でした。

検証の結果

ここまでの結果で、Enhanced Input の入力は、入力アクション(IA_○○)よりも割り当てたキーが被っているかどうかを優先的に判断し、その結果を Priority や Consume Input に準じて処理するという結果になっています。

入力が競合しないようにと、簡単に書いてましたが、
細かい挙動はドキュメントを見ただけでは分からない内容ばかりでした。



ただ追加するだけですが、設定によって色々なパターンがあることが知れて非常に勉強になりました。


IMC はキャラ移動用や UI 操作用など、ゲーム内で必要な新しい入力を追加することができるので、優先度について知っておくことは今後必要になると思います。


おまけ1:Remove Mapping Context


"Mapping Context" で指定した IMC を削除します。
IMC がなかった場合はエラーや警告もなさそうでした。

主に「Add Mapping Context」で追加した IMC を削除する時に利用することになると思います。

一例ですが、インベントリを開いた時に 「Add Mapping Context」で UI用の入力を追加し、閉じる時に「Remove Mapping Context」で削除するような使い方が出来ます。

IMC がアセット単位のためこういう付け替えが容易にできるのは非常に嬉しい機能です。


おまけ2:Clear All Mappings


追加したすべての IMC を削除できます。

ゲーム中タイトル画面に戻ることを想定した時、色々な IMC が追加されていることも予想されるため「Clear All Mappings」で綺麗にしてから必要な IMC だけ「Add Mapping Context」をするなどの初期化系の処理に使えそうです。

2023-01-02 追記:"Options"ピンの Ignore All Pressed Keys Until Release

先に Twitter へのリンクを貼っておきます。
https://twitter.com/UE5wancoro/status/1609488690421837825

どういうシチュエーションなのかというと
IMC_A に IA_OpenPauseMenu という入力アクションを用意し、Escキー(Pressed)で Pauseメニューを開くという実装をしました。

Pauseメニューを開く際、Pauseメニュー専用の IMC_Pause を「Add Mapping Context」で追加します。

IMC_Pause には、IA_ClosePauseMenu という入力アクションを用意し、同じく Escキー(Pressed)で Pauseメニューを閉じるという実装しました。

Pauseメニューを閉じる際、IMC_Pause を「Remove Mapping Context」で削除します。


こういうシチュエーションで、IMC も入力アクションも Open/Close で違うけど、両方同じキーを割り当てたという内容です。

Escキーで Pauseメニューを開くと、なんとメニューが開く→ 閉じる→ 開く...と Escキーを押しっぱなしの間これがループします。

「Add Mapping Context」で違う IMC を追加したにも関わらず、入力アクション(入力イベント)も違うのに、入力はフラッシュされず押した状態が継続しているということになり普通にまずい挙動です。

期待していた動作は Escキーを押せばメニューがちゃんと開き、もう一回押したら閉じるという動作です。


その前に、この動作については historia 様が公開して下さっているこの記事で解決できます!
本当にありがとうございます!!

▼ [UE5][C++]EnhancedInputで独自のInputTriggerを作る~UIカーソル高速移動編~
https://historia.co.jp/archives/26608/




補足となりますが「Add Mapping Context」「Remove Mapping Context」の "Options" は「Modify Context Options 構造体」となっていて、画像のようにピンを分割することができます。


右側のようにピンを分割するか、「ModifyContextOptionsを作成」ノードを使うと出てくる "Ignore All Pressed Keys Until Release" のフラグにチェックを入れれば先程のメニューが開いて閉じてのループはなくなります。

注意したい点は "Options" ピンが結合されている状態だと先程のループする症状が発生するということです。

"Options" ピンを分割するとデフォルトでチェックが入っておりループはしません。

恐らくデフォルトで "Ignore All Pressed Keys Until Release" が False になっていると思われるので、明示的に True にしておく必要があるようです。

今まで使った事がなかった "Options" ですがこんな大事な設定が隠れているなんて思いませんでした。
これを知らずにデバッグしても解決策は見つからなかったと思いました。


押しっぱなしで反応してもいいケースや、そういう挙動にならないケースであれば False でいいと思いますが、これからは「Add Mapping Context」と「Remove Mapping Context」の "Options" ピンは分割し、True でも False でも明示的に設定しようと思いました。

年明けからまた勉強になりました。


「Add Mapping Context」は追加と Priority を決めるだけで簡単に利用できるためか、細かい検証をしている情報には辿り着かなかったためこの記事を公開してみました。


今年は一本ゲーム完成を目指したい所です!!

If you liked this article, support the creator with a tip!

Sending tips requires user registration.Find details about tips here.

Monthly Archive

Search by Article Tags

Search by Exclusive Perks

Search Articles