Struct ref

So I ask a question about an annoying problem that I have with structs declared in C++. So I have an array of these structs (let’s call the struct STRUCT) and I have a UFUNCTION (let’s call GET) that returns a reference to a struct at given array index. I have another function (let’s call it MOD) that takes this struct ref as input to modify some internal values in the struct. But when in my blueprint i call the GET function and then I use the output STRUCT by ref as input of the function MOD (this latest one is executed with no problems), the STRUCT in the array is not modified. It is like if the output struct doesn’t be a reference but in C++ I declare the output as UPARAM(ref)STRCUT& so I suppose it is correct. It is a very annoying problem for me and I have tried many way to resolve the problem, I really don’t know why this happens

Any help wold be appreciated

Okay sorry I may have found a sort of workaround but my question remains. If someone have any idea on why my problem happens I would be curious

Did you define the struct as USTRUCT(BlueprintType)? It might help to see your code…

I can show my code, I don’t know if it is really useful because it seems a generic problem but I will make a screenshot. USTRUCT is BlueprintType and in the return of the function there is a UPARAM(ref). I will write here the functions in a moment

← .h FILE →

UFUNCTION(BlueprintPure, Category = “…”)
UPARAM(ref) FQS_QuestInfo& GetQuestInfo(int32 Index);

UFUNCTION(BlueprintCallable, Category = “…”)
void SetActivityPending(UPARAM(ref)FQS_QuestInfo& InStruct);

← .cpp FILE →

FQS_QuestInfo& GetQuestInfo(int32 Index){
return UQS_Journal::QuestList[Index];

void SetActivityPending(FQS_QuestInfo& InStruct){
InStruct.Status = EQS_Status::Pending;

These are the two functions that give me the problem. One is the getter and the second is the setter. UQS_Journal is the class in which they are declared. EQS_Status is an enum. QuestList is an array of FQS_QuestInfo structs. USTRUCT is BlueprintType. UCLASS is Blueprintable, Abstract, BlueprintType. Sorry I hadn’t post this code in the previous question, I am new of this forum and I dont know how put the code in the squared section :wink: (now I have write it with my hands)

Interesting! That code looks good but I’m wondering if the setter isn’t allowing ReadWrite.
Was your work-around to remove the setter/getter and use a reference directly?

UPROPERTY(BlueprintReadWrite, VisibleAnywhere, Category = "...")
FQS_QuestInfo* QuestInfo;

(btw, the </> button is for adding code)

In reality my workaround was to use UObjects insted of structs because with them I have never encountered any problems. But for my purpose I think that a struct works better for many reasons. My structs are saved in an array like this:


TArray<FQS_QuestInfo> QuestList;

This array is a protected property, this may cause the problem? I declared it without BlueprintReadWrite because I want it to be not exposed to blueprints but I can try to add it and try

1 Like

Sorry I was wrong, this is how I declared the array

UPROPERTY(EditDefaultsOnly, Category = "Default")
    TArray<FQS_QuestInfo> QuestList;

EditDefaultsOnly would prevent it from being changed (or visible) except for the defaults in the details panel.
Yes marking that as protected might also prevent it - I’m not sure…

Okay so I have tried to change the specifier in EditAnywhere and nothing happens, the problem is still there, now I try with BlueprintReadWrite specifier

Nothing, the problem is still there even with BlueprintReadWrite

did you remove the “protected:”?

Protected yeas will prevent it from being modified directly by the C++ code and i a class that is not child of it but with a function like a setter that indirectly changes it I think there shouldn’t be any problems (but me too I’m not sure)

I will try now to remove protected

Still nothing. It is very strange

I really don’t know why this happens, probably I will use UObjects instead of structs, I have found a method to obtain the same result with the same running time but this problem remains very strange :thinking:

1 Like

Yes sounds like a good plan - something to keep an eye out for…

Yes at this point I will use them. I think UObjects are more expensive in terms of memory usage (not running time) but it is also true that I have never encountered any problems with them :laughing:

But if find any solution I will to post it here, thank you so much for your help