Re 5): I’ve noticed a number of places where changing properties in code are “underwriting” the value on the instance. As in, the instance, despite not having its own value for a property it’s inheriting from its default object, is creating a value which overwrites the default object’s value when the default object’s value changes.
As in:
- I have a code class Foo_Code which
creates a float UProperty Bar = 1.0f - I create a blueprint Foo_BP which
inherits from Foo_Code. Its value for
Bar is set to 1.0f, and has no little
“reset” arrow. - I edit my code to set Foo_Code’s Bar
to = 2.0f - I recompile in editor
- Foo_BP’s value for Bar is still 1.0f,
but now there’s a little “reset”
arrow, which when pushed, sets Bar to
2.0f
I believe this is happening only if you do a compile while the editor is open. If you do it when it is closed, Foo_BP’s Bar will correctly match Foo_Code’s Bar when you reopen the level.
So I suspect this is part of a larger, rather impactful bug with how BP variables manage inheriting non-overwritten values from parent classes. No idea how that’s working under the hood, but most engines I’ve used that don’t have problems with this have a sort of hidden, explicit “this value has been overwritten” flag associated with all of its designer-facing properties, which will automatically be set if the value is changed in the editor, but can be manually set, manually reset (which will cause the value to revert to the inherited value) but which will never be automatically reset. (Which prevents problems with bob the designer setting a value which is by default false to true, but then having a programmer set the value to true by default, and then to false by default later, clearing Bob’s deliberately set values.)