#Component turns null after construction

1 messages · Page 1 of 1 (latest)

half shard
#

Hi, i have a problem where i make a movement component in the constructor of a pawn, it gets saved in the class but at begin play it is null. after looking into this issue i found that it might be an unreal bug. One solution i found was to delete the blueprint that was created from my code. This worked for me on my device but when other people try it on their device it is still broken. Is there a way to fix this without everyone im working with having to re create the blueprint?

radiant stone
#

How are you storing the pointer to the component?

#

What are the specifiers in the header?

#

Usually stuff like this is because the pointer to the component is allowed to be edited and is then accidentally serialised as nullptr.

half shard
#
protected:
    UPROPERTY(VisibleAnywhere, BlueprintReadWrite, Category = "Custom|Components")
    TObjectPtr<UFloatingPawnMovement> _movementComponent;
#

this is how i store it in the header

radiant stone
#

For subobjects the correct UPROP is:

UPROPERTY(VisibleAnywhere, BlueprintReadOnly)
TObjecPtr<UComp> TheComp = nullptr;
#

VisibleAnywhere is correct but BP-RW could be problematic

hidden geyser
#

also post creation code

radiant stone
#

The pointer should never be edited outside the ctor

half shard
#

ill try changing that

radiant stone
#

It won't repair any BP:s that have already been broken.

#

But it will keep them from breaking in the future

radiant stone
half shard
#
    _movementComponent = CreateDefaultSubobject<UFloatingPawnMovement>(TEXT("Movement"));
#

this is how i construct it

hidden geyser
#

also, i hope you launch editor from IDE and not try to bruteforce things with live coding

radiant stone
#

correct, although you don't need the TEXT macro

half shard
radiant stone
#

When stuff like this happens I usually cut my losses and rename the component in C++.

hidden geyser
#

don't see anything wrong. other than that _ ticking me off. usually component name and property name should be same for sanity reasons.

easiest way to debug is set a breakpoint at the CreateDefaultSubobject, when hit set a data breakpoint for a property change at property address, then resume until data breakpoint hits

radiant stone
#

Renaming both the pointer name and the name given in CreateDefaultSubobject.

#

It will be reset to defaults of course, but usually restores the BP functionality.

#

Also making sure to have some source control in place!