Unity初心者の俺が調べたことをメモするスレ (99ﾚｽ)
上下前次1-新
1(1): 2023/08/30(水)21:52 ID:zQtYmNBI(1/3) AAS
ちなスペックは
コード作成は生成AI頼り・基礎的なコンポーネントの使い方すら理解してない・C#の経験皆無
こういうレベル
2: 2023/08/30(水)21:58 ID:zQtYmNBI(2/3) AAS
基礎的なことすら理解してないから一歩ずつ調べてメモしていきたい
今日調べたこと
・EventSystemとPlayerInputの実行順序について
Project SettingのScriptExecutionOrderでは、EventSystemが-1000・PlayerInputが-100の実行順既定値が設定されている
これを見るとEventSystemの処理の方がPlayerInputより先に行われるように見えるが、EventSystemによるUI操作はUpdate関数でInput.Actionを購読しに行く形で行われる一方、PlayerInputはPreUpdateのタイミングでInput.Actionを生成しイベントを発火させるので、実はPlayerInputによる関数コールの方がEventSystemのUI操作より先に行われる
3: 2023/08/30(水)22:04 ID:zQtYmNBI(3/3) AAS
あとで見返すために番号付けとくか
なるべく毎日調べたこと書きたいね
4: 2023/08/31(木)18:16 ID:SnlLP3DA(1/4) AAS
その２ I〇〇Handlerについて
Unityでは独自のインターフェースとして、ISubmitHandlerなどのUIイベント発生時にコールバックを受け取る機能が実装されている。
インターフェースという概念自体はあくまでクラス外部向けに内部実装の設計を規律するものにすぎず、I〇〇Handlerを実装してもC#としてコールバックを受け取る機能そのものが実装されるわけではない。
コールバックの発火は? フォーカス、決定やキャンセルイベントなどEventSystemが発火を決定 → イベントを作成(BaseEventData) → ExecuteEventsに依頼してインターフェースを実装する該当クラスに送信してコールバックを発火するケースと、? マウスイベントなどInputModuleが自分でイベントを作成(PointerEventData) → ExecuteEventsに依頼して〜、という二つの異なるパターンがあるらしい（もっとあるかも）。
疑問としては、InputSystem導入後にInputModuleとInputSystemUIInputModuleの二つを統合するBaseInputModuleクラスが導入されたらしいが、この場合はマウスイベントを発火させるのは何処なのだろうか？
5: 2023/08/31(木)18:16 ID:SnlLP3DA(2/4) AAS
その２ I〇〇Handlerについて
Unityでは独自のインターフェースとして、ISubmitHandlerなどのUIイベント発生時にコールバックを受け取る機能が実装されている。
インターフェースという概念自体はあくまでクラス外部向けに内部実装の設計を規律するものにすぎず、I〇〇Handlerを実装してもC#としてコールバックを受け取る機能そのものが実装されるわけではない。
コールバックの発火は? フォーカス、決定やキャンセルイベントなどEventSystemが発火を決定 → イベントを作成(BaseEventData) → ExecuteEventsに依頼してインターフェースを実装する該当クラスに送信してコールバックを発火するケースと、? マウスイベントなどInputModuleが自分でイベントを作成(PointerEventData) → ExecuteEventsに依頼して〜、という二つの異なるパターンがあるらしい（もっとあるかも）。
疑問としては、InputSystem導入後にInputModuleとInputSystemUIInputModuleの二つを統合するBaseInputModuleクラスが導入されたらしいが、この場合はマウスイベントを発火させるのは何処なのだろうか？
6: 2023/08/31(木)18:33 ID:SnlLP3DA(3/4) AAS
なんか多重送信されてるわ
「PlayerInputの方がEventSystemより実行タイミングが早い」っていう昨日の話だけ覚えておけば、どこが発火するかなんて正直割とどうでもいい気はするが念のため調べてみた。
ところでEventSystem(UnityのUI)って基本的にはイベントが発生したことは取得できるけど、「どういうキーが押されてイベントが発生したか」っていう情報を取得するのが難しい（できない？）気がする
例えば、画面上にA・B・Cの三つのUIが横並びで配置されていて、「B」がフォーカスを取得した時に発生させるイベントの内容を、直前のフォーカスが右にあったか左にあったかで条件分岐したい場合、
UIイベントが発生する原因となったキー操作そのものをEventSystemはEventDataに内包してくれる訳ではないっぽいので、工夫をしないとこの分岐は実現できなさそう
一つの案は直前までにフォーカスを取得していたA又はCにIDeselectHandlerを実装（又はSelectableがA・Cの基底クラスにあるならオーバーライド）して、フォーカスを失ってOnDeselectが実行された時に自身の情報をマネージャークラスに渡しておいてBにそれを見て判断させるという方法
この方法は分かりやすいけどUIのゲームオブジェクトが変動する・動的に生成される場合には「隣にいた」認定の処理が面倒になりそう
省3
7(1): 2023/08/31(木)18:49 ID:/dI3F1uF(1) AAS
んなややこしいことせんと
先入れ先出しのスタック1つ作っておけば？
8: 2023/08/31(木)19:22 ID:SnlLP3DA(4/4) AAS
>>7
独自のデータロード式スクロールビューに利用するんだけどもう後者を採用（PlayerInput）して一応完成させたのよね
上下キーでは要素1個ずつ移動、左右キーでは表示エリア全部をページ送りする機能を実装したかったんだけど
A（画面上では不可視）
B
C
D
省7
9(1): 2023/09/01(金)15:34 ID:p9KeXpxb(1) AAS
普通に詳しいじゃん
上下前次1-新書関写板覧索設栞歴
あと 90 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s