Search Issue Tracker
By Design
Votes
0
Found in
4.5.3f3
Issue ID
627125
Regression
No
Adding new (not mb) list elements in the inspector overwrites the object's default field values set in the constructor
To Reproduce:
1. Open the attached project or paste the attached script into a new file.
2. Change 'Test List' size to any value observe that the Constructor of 'Data' is called, but the new list element has it 'Vector3' field set to (0,0,0) instead of 'Vector3.One'
There is also another issue, when changing the list.size property in inspector to many (equal to size value) objects are constructed ,but the number of objects which are actually used seems to be equal the difference between the new & the old size values.
For example:
1. Change list size from 0 to 1.
2. Edit the first element, change size to 2
3. Notice that the constructor is called twice, even if only one additional element is added, also the new element is a duplicate of the first one
Comments (1)
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
- Redoing creation of Sub Scenes and Cube GameObjects in Hierarchy throws “Assertion failed on expression: 'targetScene != nullptr’” error in Console window
- Selecting “New Sub Scene” after assigning “New Scene” in Sub Scene Script Component throws “Destroying GameObjects immediately is not permitted” in the Console window
- Shader Graph "Zoom Step Size" can be set to 0 even though the zoom still works
- Enabling/Disabling the Deprecated Nodes doesn't apply to the opened Shader Graph unless any Variable is added to the Blackboard
- Group Selection title text size is smaller in renaming than the actual font size
Sycobob
Nov 29, 2015 23:51
Even if this is by design, it's a pretty big problem. There's no way for me to give designers sensible default values if I expose data to them in a collection.
Further, it means there's inconsistent behavior. Field initializers and constructors work on single fields but don't work on collections. That means I can't rely on field initializers working at all if I can't guarantee the type won't be used in a collection.
For the sake of usability, I'd like to request altering the design.