I noticed that there is various places where support for all native data types is missing and only int32 is supported.
i.e. the following will result in grayed edit fields in the editor
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category=MyCategory)
this is very confusing and cost me some time to figure out why my actor had some fields that weren’t editable.
In fact I believe that is also the cause of a crash i reported here
Crash in STextEditHelper
GConfig->SetInt does not support uint32 and ofc does not support uint64 or int64
I think these should be added
This is actually not a bug. It is a result of legacy code brought in from UE3. Numerical data types available for use in Kismet in UE3 were limited to simplify its use. When the Blueprint system was created for Unreal Engine 4, the same principle was used and the same data types were made available to use in Blueprints. The only numerical data types that were intended to be used with Blueprints are
float. All of the other numerical data types are fully available to use in C++ code, but they cannot be accessed through Blueprints.
There has been some discussion going on internally with regards to supporting the larger numerical data types (ie.
double). It seems as though a lot of our developers favor the switch to the larger data types, but they still want to keep Blueprints simple by limiting the data types available (eg. you would be able to use
int64, but not
int32). Unfortunately, making this change would be a fairly large task, so it is unlikely to happen soon.
Have a great day!
Thanks for your answer.
I understand that there must be reasons for this decision.
Is there a way that a magic compile time check can be added that if the UPROPERTY that is being exposed is of type uint32 int64 or uint64 then it spits out a warning in the log ? (A bit like the one saying that “OVERRIDE” was deprecated and some other warnings that i saw floating around when building the engine). I know now how to fix this issue but others might have the same problem.
Have anice day.
Your suggestion of a warning message when compiling is a very good one. I went ahead and entered a feature request for that to be looked into (TTP# 346760).
One point of clarification regarding my previous answer: The developers are not actually interested in switching the default data types available in Blueprints, as I stated. They are actually considering exposing
double to Blueprints, which is still a very sizable job.
What did you do to work around the issue? I am dealing with epoch timestamps and trying to figure out the best way to store them.
I ended up adding support for uint32, int64 and uint64 for the GConfigvstuff myself. Never solved the other issues mentioned above though.
I just wanted to provide a quick update here. I just noticed that 4.8 Preview 1 now has an error message in Visual Studio if a class contains a UPROPERTY that is not supported by Blueprints.
Would be good a warning for UFUNCTION too.
I entered a new ticket to evaluate the possibility of adding a warning/error message during compile if an unsupported type is included in a UFUNCTION signature (UE-24723). I had not considered including UFUNCTIONs in the original feature request. That was an oversight on my part.