Unity初心者の俺が調べたことをメモするスレ

**名前は開発中のものです。** · 2023/08/30(水) 21:52:43.22

ちなスペックは
コード作成は生成AI頼り・基礎的なコンポーネントの使い方すら理解してない・C#の経験皆無
こういうレベル

**名前は開発中のものです。** · 2023/08/30(水) 21:58:13.30

基礎的なことすら理解してないから一歩ずつ調べてメモしていきたい

今日調べたこと

・EventSystemとPlayerInputの実行順序について
Project SettingのScriptExecutionOrderでは、EventSystemが-1000・PlayerInputが-100の実行順既定値が設定されている
これを見るとEventSystemの処理の方がPlayerInputより先に行われるように見えるが、EventSystemによるUI操作はUpdate関数でInput.Actionを購読しに行く形で行われる一方、PlayerInputはPreUpdateのタイミングでInput.Actionを生成しイベントを発火させるので、実はPlayerInputによる関数コールの方がEventSystemのUI操作より先に行われる

**名前は開発中のものです。** · 2023/08/30(水) 22:04:40.12

あとで見返すために番号付けとくか
なるべく毎日調べたこと書きたいね

**名前は開発中のものです。** · 2023/08/31(木) 18:16:21.62

その２ I〇〇Handlerについて
Unityでは独自のインターフェースとして、ISubmitHandlerなどのUIイベント発生時にコールバックを受け取る機能が実装されている。
インターフェースという概念自体はあくまでクラス外部向けに内部実装の設計を規律するものにすぎず、I〇〇Handlerを実装してもC#としてコールバックを受け取る機能そのものが実装されるわけではない。
コールバックの発火は① フォーカス、決定やキャンセルイベントなどEventSystemが発火を決定 → イベントを作成(BaseEventData) → ExecuteEventsに依頼してインターフェースを実装する該当クラスに送信してコールバックを発火するケースと、② マウスイベントなどInputModuleが自分でイベントを作成(PointerEventData) → ExecuteEventsに依頼して～、という二つの異なるパターンがあるらしい（もっとあるかも）。
疑問としては、InputSystem導入後にInputModuleとInputSystemUIInputModuleの二つを統合するBaseInputModuleクラスが導入されたらしいが、この場合はマウスイベントを発火させるのは何処なのだろうか？

**名前は開発中のものです。** · 2023/08/31(木) 18:16:23.48

その２ I〇〇Handlerについて
Unityでは独自のインターフェースとして、ISubmitHandlerなどのUIイベント発生時にコールバックを受け取る機能が実装されている。
インターフェースという概念自体はあくまでクラス外部向けに内部実装の設計を規律するものにすぎず、I〇〇Handlerを実装してもC#としてコールバックを受け取る機能そのものが実装されるわけではない。
コールバックの発火は① フォーカス、決定やキャンセルイベントなどEventSystemが発火を決定 → イベントを作成(BaseEventData) → ExecuteEventsに依頼してインターフェースを実装する該当クラスに送信してコールバックを発火するケースと、② マウスイベントなどInputModuleが自分でイベントを作成(PointerEventData) → ExecuteEventsに依頼して～、という二つの異なるパターンがあるらしい（もっとあるかも）。
疑問としては、InputSystem導入後にInputModuleとInputSystemUIInputModuleの二つを統合するBaseInputModuleクラスが導入されたらしいが、この場合はマウスイベントを発火させるのは何処なのだろうか？

**名前は開発中のものです。** · 2023/08/31(木) 18:33:55.46

なんか多重送信されてるわ

「PlayerInputの方がEventSystemより実行タイミングが早い」っていう昨日の話だけ覚えておけば、どこが発火するかなんて正直割とどうでもいい気はするが念のため調べてみた。
ところでEventSystem(UnityのUI)って基本的にはイベントが発生したことは取得できるけど、「どういうキーが押されてイベントが発生したか」っていう情報を取得するのが難しい（できない？）気がする
例えば、画面上にA・B・Cの三つのUIが横並びで配置されていて、「B」がフォーカスを取得した時に発生させるイベントの内容を、直前のフォーカスが右にあったか左にあったかで条件分岐したい場合、
UIイベントが発生する原因となったキー操作そのものをEventSystemはEventDataに内包してくれる訳ではないっぽいので、工夫をしないとこの分岐は実現できなさそう

一つの案は直前までにフォーカスを取得していたA又はCにIDeselectHandlerを実装（又はSelectableがA・Cの基底クラスにあるならオーバーライド）して、フォーカスを失ってOnDeselectが実行された時に自身の情報をマネージャークラスに渡しておいてBにそれを見て判断させるという方法
この方法は分かりやすいけどUIのゲームオブジェクトが変動する・動的に生成される場合には「隣にいた」認定の処理が面倒になりそう
もう一つの案はPlayerInputを利用して、該当するキー入力があった際に入力があったことをマネージャークラスやBに渡す方法
BがAの方から来たなら右キー、Ｃの方向から来たなら左キーが入力されているはずなので、Bはこの入力情報を見ればどっちから来たかが分かるし、UI要素が変動しても対応しやすい
ただしイベント発火が絡む関係でパフォーマンス面では前者の手法に劣りそう

**名前は開発中のものです。** · 2023/08/31(木) 18:49:55.41

んなややこしいことせんと
先入れ先出しのスタック1つ作っておけば？

**名前は開発中のものです。** · 2023/08/31(木) 19:22:23.67

>>7
独自のデータロード式スクロールビューに利用するんだけどもう後者を採用（PlayerInput）して一応完成させたのよね

上下キーでは要素1個ずつ移動、左右キーでは表示エリア全部をページ送りする機能を実装したかったんだけど
A（画面上では不可視）
B
C
D
E
F
G（画面上では不可視）
この順に子要素が並んでいて、Aにフォーカスが入った時に上方向にデータロードして子要素を並び替え（上からGABCDEFになる）、Gにフォーカスが入った時下方向にデータロードして並び替え（BCDEFGAになる）をする感じで動く
例えばBにいる状態で下キーをを押しっぱなしにするとCDEFGAB…ってループしながらリストや配列の次のデータを読み込みながらフォーカスを変えていく

各子要素には上下方向は上下に、左方向はAに右方向はGにSelectableのナビゲーションを設定してるんだけど、このデータロードを行う際にB→AやF→Gのフォーカスの移行が「上下キー」で行われたのか「左右キー」で行われたのかを判別する必要があったのよね
それでPlayerInput使う方法を思いついた