Hi! With 5.6 the edition/recompilation of blueprints during PIE, which used to be opt-in, is now opt-out on a per-class (and children) basis. We’ve been discussing this internally in our team and the consensus is that this is generally dangerous - notably we can crash the editor when editing some of our BP classes that are tied to native code - though there are a few cases that are helpful, usually involving editing properties only and not the BP logic. So, a few questions:
- what was the rational for enabling this behavior in 5.6, generally?
- do I understand correctly that an Actor class being live-recompiled will have its instances go through initialization again (Load/PostLoad and BeginPlay?) but the instances themselves will not be replaced in the world?
- the case we’re most interested in would be the ability to change the default values of properties within a BP asset and have them propagated to the instances in the PIE world, but without triggering that re-initialization of the instances. Is it something that can be achieved somehow?
Thanks,
Ben
Hey Ben,
We’ve been discussing this internally in our team and the consensus is that this is generally dangerous
I agree that there are many things that can go wrong and it’s wise to add classes to the opt-out list as you encounter them. You can also consider just adding Actor to the opt-out list. (For some reason Object isn’t selectable, which we may address if it is reported by people as a hindrance.)
What was the rational for enabling this behavior in 5.6, generally?
There are use cases that are very powerful, like rapid iteration and injecting debugging blueprint code at runtime. The common user would likely want to know that live recompiling exists (and then gradually run into the risks…) rather than finding out years later. So we decided on default enabled and opt-out.
Do I understand correctly that an Actor class being live-recompiled will have its instances go through initialization again (Load/PostLoad and BeginPlay?) but the instances themselves will not be replaced in the world?
On an actor blueprint recompile the actor instances will actually be replaced in the world, so the existing actor goes through its EndPlay sequence, while a new instance of the actor goes through its init + BeginPlay sequence. The actor’s property values will be retained by copying from old to new actor via CopyPropertiesForUnrelatedObjects. Everything described here in section 2.6 happens during PIE recompile to actors alive in PIE.
The case we’re most interested in would be the ability to change the default values of properties within a BP asset and have them propagated to the instances in the PIE world, but without triggering that re-initialization of the instances. Is it something that can be achieved somehow?
Yes: if you modify a property in a blueprint class in the editor any instances loaded in memory that inherited the old value will also receive the new value if the instance’s value didn’t change yet. This propagation of values happens even without recompiling the blueprint. That propagation of changed value to instances happens in PreEditChange:
> UnrealEditor-CoreUObject.dll!UObject::GetArchetypeInstances(TArray<UObject *,TSizedDefaultAllocator<32>> & Instances) Line 1007 C++ UnrealEditor-CoreUObject.dll!UObject::PreEditChange(FEditPropertyChain & PropertyAboutToChange) Line 535 C++Unfortunately I see that excluding an actor class from PIE recompile also excludes you from editing it during PIE. However, you can edit the property and not press compile. No reinstancing takes place then, but the value will propagate to existing instances. I’m going to suggest internally whether we can separate the two: excluding a class from PIE recompile but still allow editing and value propagation.
Hi, thanks a lot for the details that is extremely helpful!
Object isn’t selectable
But it can be added through ini so workaround is decent. It was a bit of a surprise not to see it in the selection menu initially, indeed.
The common user would likely want to know that live recompiling exists
Yeah discoverability is a good reason indeed. We didn’t know that was possible prior to 5.6 either.
any instances loaded in memory that inherited the old value will also receive the new value if the instance’s value didn’t change yet
Talk about discoverability, fells like I should have known this 
. Awesome!
I’m going to suggest internally whether we can separate the two
That sounds like a great suggestion, thanks!
Cheers,
Ben
Glad to hear that! I’ll close this question. If I have a fast enough conclusion to the internal discussion on separating PIE compilability and editability I’ll update it here. Otherwise, keep an eye on patch notes.