dropdown.choices에 List를 넣고 List에 "분류/항목" 식으로 요소를 넣어주면 알아서 항목들을 분류해준다.
field나 dropdown의 value는 SerializedProperty의 stringValue 등과 다르다.
Bind()를 해야 UI Value와 SerializedProperty의 data가 이어지는 것.
직렬화된 객체의 참조를 가져와서 에디터에서 바꾼다고 하더라도 EditorUtility.SetDirty()를 호출하는게 아니면 저장이 안된다.
Scriptable Object를 SerializedObject로 감싼 후에 SerializedProperty로 UI에 바로 연결한다면 저장이 바로 되긴 함.
Serialization 개념 (https://www.youtube.com/watch?v=kEu_AQ_Es-8)
PropertyDrawer의 CreatePropertyGUI()에선 기준 VisualElement 하나만 던져주면 [CustomPropertyDrawer(typeof())]에서 지정했던 대로 drawer의 element들이 만들어진다.
PropertyDrawer가 받는 인수인 SerializedProperty는 '각각의' field를 의미한다. List를 bind했을 때 각각의 요소를 의미한다는 뜻.
SerializedProperty로 리스트 (List<T>)를 바인딩한 상태에서 에디터 UI(PropertyField)를 통해 요소를 추가하면 그 리스트 내부의 요소가 SerializedProperty에도 반영됨
ExposedRefernce<T> 사용법
유니티는 멀티 씬 편집을 지원하기 때문에, GameObject.FindFirstObjectByType<T>()을 호출하면 열려있는 씬들 중 하나에서 첫번째 T를 찾아줌.
계획
list<string> 형태로 저장된다list<string>에 대응되는 list<type>도 저장해놔서 캐스팅할 때 사용한다PropertyDrawer로는 임시 caching을 통한 코드 줄이기와 성능 향상이 어려워서 VisualElement를 상속받은 별도 클래스를 만들어서 그 안에서 상태를 저장할 수 있도록 만듬.
근데 테스트를 해보니 아예 커스텀 설정들을 무시해버림. 알고보니 gpt 코드 복붙하는 과정에서 CustomPropertyDrawer Attribute를 빼먹어서 그랬던 것.
동적으로 파라미터 타입에 따라 필드 생성하는 건 UI Toolkit으로는 무리라고 함. 그러면 유니티 Inspector에서 Custom class의 parameter 처리하는 건 어떻게 하냐고 물었더니, 그건 컴파일 타임에 정해지니까 가능한거고, 동적으로 하는 건 무리라고 함. Unity에서 기본적으로 [SerializedField] 처리 해주는 부분들만 해주는 쪽으로 타협하기로.
메서드 이름을 바꾸면 전부 망가지고, condition에 넣은 field의 이름을 바꾸면 전부 망가진다는 치명적 결함이 있음. 이걸 그대로 강하게 결합된 상태로 둘건지, 이벤트로 돌아가서 느슨한 결합을 할건지 정하기.

1h 40m
