入力イベントが複数ある時の優先順位
妹「アクターにキー入力イベントをつけたんだけどさ、アクターいっぱいあるのに1個しか反応してない気がするんだけど」
「アクターでキー入力とか出来たっけ?」
妹「Input Enableノードを使えば出来る。というか1個は反応してるから、そこは合ってるはず」
「調べた結果、キー入力イベントのノードにConsume Inputっていう設定項目があって、オンだとそれより優先度が低いイベントはなかったことにしてしまうらしい。そして標準だとオンになってる。そのせいで1個しか実行されない様子」
妹「そんな設定項目見たことないんだけど」
「ここのキー入力イベントを選択した状態で、横のパネルに出てくる」
妹「なんでそんなとこに隠してあるんだよ……」
「キーイベントの方にチェックボックス付けると邪魔になるからかなあ」
妹「これで優先度が低いイベントも実行されると……優先度ってナニ? また内部的に順番が決まってる系の話? ドキュメント見てもわからなかったんだけど」
「いやこれはちゃんと設定する方法がある。アクターのパラメータの中にあるInput Priorityを変えればいい。この数字が大きい方が先、小さい方が後になる。同じ数字だと結局内部的な順番になっちゃうけど」
「例外としてレベルブループリントの優先度は常に最低に設定されてるみたい。というかレベルはアクターじゃないから優先度を設定するところがなかった。Input Priorityをマイナスの数字にすると、0のやつよりは優先度下がるけど、レベルブループリントよりは優先度高くなってしまう」
妹「このAuto Receive Inputというのは?」
「なんかここにPlayerを設定しとくと、Input Enableしなくても入力が受け取れるようになるんだよ。Block Inputの方はイベントノードのConsume Inputと同じ用途みたいで、どっちかがオンだと優先度低いイベントを潰しちゃう効果がある」
妹「優先度で順番を決めるのはいいとして、なんで普通に全部イベント動いてたらダメなの? 標準でそういうオプションがオンになってるということは、あんまり良くないことなの?」
「良くないわけじゃなくて、どういうのを想定してるかという話だと思う。普段は攻撃ボタンだけど、NPCの近くに居る時だけInputEnableして会話する仕組みだった場合、会話と同時に斬りかかったらマズイだろうという話で。ドアを開けるとかでも同じ。ところで妹はどういう意図で複数のキーイベント作ろうとしてたの?」
妹「ただなんとなく実験してだけだから、まったく何の意図もないです」