I am trying to understand collision responses and try to set an example using C++.
I have an AActor and the following Constructor:
ASCollisionActor::ASCollisionActor()
{
// Set this actor to call Tick() every frame. You can turn this off to improve performance if you don't need it.
PrimaryActorTick.bCanEverTick = true;
MeshComp = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("MeshComp"));
MeshComp->SetSimulatePhysics(true);
MeshComp->SetEnableGravity(true);
MeshComp->SetCollisionEnabled(ECollisionEnabled::PhysicsOnly);
MeshComp->SetCollisionResponseToAllChannels(ECollisionResponse::ECR_Block);
MeshComp->SetCollisionResponseToChannel(ECollisionChannel::ECC_Pawn, ECollisionResponse::ECR_Ignore);
RootComponent = MeshComp;
}
But in the Blueprint based on this C++ class on the Mesh it looks like this:
Is that a bug? I am on engine version 4.22.3. Is there a workaround to properly update my original BP class with the collision set according to the C++ ?
sorry about my late answer. I don’t agree with you, I know the yellow arrows are there to reset values. But what I did is set the collision in the C++, compiled from Visual Studio and in the engine the collision values from C++ did not reflect.
Only after I recreated my Blueprint based on the C++ and recompiled from Visual Studio they were set correctly in the engine.
I was just wondering if I needed to clear some cache? I don’t want to recreate my blueprint class when I change collision values in C++
The bp compiler remembers the changed values, just because you changed it in the constructor does not automatically change the value. It respects your original changes. If this is a bug then so be it, but i tend to like it, cause it means if i have changed that variable for other derived blueprints, it doesn’t reset them. Imaging have 10 child BP’s of your main class, you change one properties defaults and it changes ALL your bps. That would be a nightmare.
It’s not a bug, you just have to be more careful and think about what a CPP constructor is.
Once you’ve created the Blueprint, many of it’s properties are serialized - even properties that you remove from the native CPP class will remain serialized in the Blueprint if they were set to non-default values. The constructor of a native CPP object runs long, long before the Blueprint itself is loaded. Once it loads, all serialized properties will be restored regardless and overwrite whatever the CPP constructor does.
Generally speaking, you should avoid making changes to native constructors once you have a Blueprinted object, unless you are adding new properties or changing properties which have not been modified in that Blueprint. It’s very common to need to re-create Blueprints when changing/removing properties like that when you are in the early stages of setting up a CPP class.
Hello both, Thank you very much for your thorough explanations. I was not aware of this but will keep this in mind as I move on in the engine.
This saves me a lot of headaches.
Best regards, Peter
Hi, I just resolve the problem by close Unreal Editor and open it by pressing F5 in Visual Studio.
I think these is a bug of hot reload function. So each time we change class constructor, we should close editor and reopen it, instead of hot reload.
Yeah its Hotload most likely, it’s kinda flaky. I by habit do 2x compiles in a row just because hot reload fails about 50% (with no errors). And every once in a while, the entire process can become stuck, and you must restart the editor. (one time I couldnt disable the cursor from showing, no matter what I did, tried for like 2 hours with code and blueprints and what not) restarted editor, code starting working cursor was disabled finally.
People say live programming is better, but for some reason I cannot enable mine, go figure, I might have to start a new project and migrate everything if I want to use the live coding feature.
Blockquote
If you close and open the UE editor the collision channel gets updated.
This is not accurate. When you reopen the editor, the variable value in the Blueprint will still remain the same as before, even if you reset it to the preset value. I just tested it in UE 5.2.1. The only way to make the new value apply is to create a new Blueprint. So, @Jambax is correct! Please test before answering questions.
I have the same issue. After choosing new collision profile setting via the constructor, the old checkboxes for blocking are still active.
i.e. MyMeshComponent->SetCollisionResponseToAllChannels(ECollisionResponse::ECR_Overlap);
The only way to obtain the new defaults is to create a new blueprint of the same base and reparent the old one.
You can also just update them to match the new defaults you set in C++.
My point remains - once you have created a Blueprint, any changes you make to the C++ constructor are NOT garaunteed to propagate to it because the C++ constructor occurs much, much earlier than asset serialization.
Anything serialized into the Blueprint will overrule the C++ constructor, which is of course intentional.
