Search Issue Tracker
Fixed in 2019.3.X
Fixed in 2019.2.X
Votes
0
Found in
2019.2
2019.2.0b3
Issue ID
1156837
Regression
Yes
CustomPropertyDrawers have different behavior now in 2019.2
CustomPropertyDrawers have different behavior now in 2019.2
1. What happened
Previously, a List<Something> where there is a CustomPropertyDrawer(typeof(Something)) would properly draw if a call was made to the list, such as:
EditorGUILayout.PropertyField(somethingListProperty, true);
Each individual element in the list would be called with the CustomPropertyDrawer. Now, the whole list is being passed to the CustomPropertyDrawer.
This is a regression.
2. How we can reproduce it using the example you attached
i. Open the project and double click on the WorkaholicDomain asset in the main Assets/ directory.
ii. Click on the Workstation trait
Notice the NullRefExceptions; This occurs because the TraitDefinitionFieldDrawer is no longer getting the element, but the whole array.
TraitDefinitionDrawer is where the call comes from, which is itself a CustomPropertyDrawer.
This functionality works correctly on 2019.1 where it was developed, but you won't be able to convert back to that version easily without fixing up the manifest.json and resolving conflicts. If you'd like to test in 2019.1, then I can provide another project as well.
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Articulation Body with 'Revolute' Joint Type has erratic behavior when Upper Limit is set to above 360
- WebGL Player fails to render Scene when Terrain with Detail Mesh is added and WebGPU Graphics API is used
- Inconsistent errors are logged when different types are passed into the Query "Q<>" method in UIToolkit and the ancestor VisualElement is null
- Crash on GetMaterialPropertyByIndex when opening a specific Scene
- Discrepancies in the styling are present when using a TSS file instead of a USS file in custom EditorWindow
Add comment