Search Issue Tracker
By Design
Votes
0
Found in
2021.3.29f1
2022.3.6f1
2023.1.7f1
2023.2.0b3
Issue ID
UUM-44476
Regression
No
Scriptable Object List not editable in the Inspector when a List references another List instance
Reproduction steps:
1. Open the attached project “DualReferenceIssue”
2. In the Project window select “Assets/Resources/New Dual Reference Scriptable Object.asset” asset
3. In the Inspector window try adding and changing the values of the “Source List” array
4. Try adding/removing and changing the values of the “Target List” array
Expected result: Editing values in any array the changes are represented in another array
Actual result: Only the “Target List” array elements can be edited and they are copied to the “Source List” array
Reproducible with: 2021.3.29f1, 2022.3.6f1, 2023.1.7f1, 2023.2.0b3
Reproducible on: macOS 13.4.1 (c)
Notes:
- List references are assigned in the OnEnable method, but is being called in Edit mode
- If another List<> element is added and is referencing the “Source List”, the “Target List” also becomes uneditable
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Errors in the Console when creating a new "2D Platformer Microgame" template project
- Prefab Override popup displays on wrong monitor when Inspector width is resized to minimum
- Scroll View is not moving by inertia after scrolling by click and dragging when Editor window is minimized and Canvas "Render Mode" is set to "World Space"
- "type mismatch error" occurs when the currentDirectionWS output of a Sample Water Surface node is connected to a float3 input
- URP Material Upgrade utility does not enable Alpha Clipping when material had Rendering Mode set to Cutout
Resolution Note:
Currently the serialization system serializes class fields in the order of their declaration and there is no mechanism for detecting which one of two lists was modified, to be able to prevent the override of the modified list.
In the case of the repro project this is what happens:
When user modifies one of the lists in the inspector a serialization of the corresponding scriptable object is triggered. First the list named "source" is serialized, and after that the list target is serialized. As both target and source point to the same location in the memory, whatever values the list "target" has will override the values of the source, even if the user modified the source. Note that if the order of the fields declaration changes in the class (e.g. source list is the second and the target is the first), then you'll see the opposite issue, where you can modify the source but not the target.