I have a UStruct with a non-standard integer UProperty as follows:
USTRUCT(BlueprintType)
struct FMyStruct
{
GENERATED_BODY()
UPROPERTY()
int64 MyProperty;
// Other data
};
As far as I can tell, this is supported so long as the property itself is not exposed through BlueprintReadWrite/EditAnywhere or related specifiers. For the most part everything is working as I’d expect, including replication of this struct.
There is a minor issue however. If I have a UFUNCTION taking this struct as an input parameter, and I call the function in blueprint without connecting anything to the pin, on blueprint compile the engine fails an ensure in KismetCompilerVMBackend.cpp. It appears the function in question is expecting only blueprint compatible properties.
No, the GENERATED_BODY macro has superseded all the older versions. There’s very little practical difference, but GENERATED_BODY should be used in all cases, as of 4.7 or so. Unfortunately that wiki page and many others are rather outdated now.
As for the UPROPERTY specification, BlueprintPure is only for functions, but anyway the point in this case is that while the struct is a blueprint type, the property itself is not exposed to blueprint. Being a 64 bit int, it can’t be.
Marking something as a UPROPERTY exposes it to the editor, which is most likely why you are seeing this ensure fail on your end. Try removing the UPROPERTY() from line 6, and seeing if you still get the same error.
As you’ve said, the 64 bit int is not supported in blueprint, which would explain why it is causing errors when you are trying to pass it into a function that is being called in blueprint.
I need it to be a UPROPERTY for serialization/replication support. Since it is not marked as Editable/Visible, nor BlueprintRead/Writable, the property itself is not exposed on the blueprint graph. As far as I understand, this shouldn’t preclude the struct from being a blueprint type, it will just mean this particular property cannot be accessed. I’ve done this many times before, the only difference here is that it’s a 64 bit integer. Since the property hasn’t been exposed to blueprint, I don’t think this should make a difference.
Anyway, regardless of what may or may not be supported, the point is that something which compiles without problem is causing a reproducible editor crash. So either there’s a bug in the function I linked, or UHT should be telling me that I can’t do what I’m doing at compile time.
The reason that the code compiles successfully is because that type is supported when using it in code. The ensure comes from attempting to use the unsupported type in a blueprint (as you have mentioned before).
I recommend using an int32 instead of int64, as this seemed to work correctly for me while I was testing.
Hi Sean.
I realize an int32 would work, however I’m using int64 for a reason, and anyway that’s not what my report relates to.
There is a difference between declaring a struct as
USTRUCT(BlueprintType)
struct FMyStruct
and declaring a property within a struct as
UPROPERTY(BlueprintReadWrite)
int64 MyProperty;
The former allows variables of this struct type to be used in blueprints. The latter exposes an individual property to be read/written in blueprint - in this case it would result in a compiler error since int64 is not blueprint compatible. In the code posted in my initial question however, the property is not exposed, and the code compiles.
This ensure leads to an editor crash in editor code. It doesn’t make sense to say that it’s expected because I did something I wasn’t supposed to. If it is actually the case that having an unexposed int64 property within a BlueprintType struct is not allowed, then this should be flagged at compilation time.
This is by no means a major bug, but I find it strange that you would maintain it is expected behaviour for the editor to crash without any prior warning. Ensures are checks against conditions that should never happen - if they trigger, it implies there is something wrong with the code which has allowed it to trigger, not user error. The latter should be handled via either compilation failure or controlled editor feedback.
I have been able to reproduce the crash that occurs when attempting to pass that struct into a blueprint function, and have entered a bug report (UE-27073). Thank you for your report and for providing the necessary information. I will provide updates on this issue as they become available.