Additional Note Author: DesertEagle_PWN The idea of USTRUCTS() is to declare engine data types that are in global scope and can be accessed by other classes/structs/blueprints. Because of this, it is invalid UE4 syntax to declare a struct inside of a class or other struct if using the USTRUCT() macro. Regular structs can still be utilized inside your classes and other structs; however these cannot be replicated natively and will not be available for UE4 reflective debugging or other engine systems such as Blueprints.Additional Note Author: Darkgaze Concerning the variables visibility on the editor: In the example above, if you don't add "EditAnywhere" parameter into UPROPERTY inside the members of the USTRUCT, whey won't show up in the Editor panel. You will see the variable but there will be no way to see/change/unfold the values inside. The class that defines a new UPROPERTY using that struct type should have that parameter too. In case you can't modify the data and you are using blueprints, you should add BlueprintType inside the USTRUCT parenthesis.
UObjectand store the data per instance)
UParticleSystemComponent, you can just make a
USTRUCTto relate the various data types!
USTRUCTSfor each particle that you spawn!
UPROPERTY()and marking any UObject / AActor members as
UPROPERTY(), you are protected from dangling pointer crashes
UObjectsif you ever want GC to be able garbage collect those
AActorclasses, which must be utilized via pointers (
AActor*) you can directly copy the entire contents of a
USTRUCTof the same type with a single line of assignment!
MyStruct::MyIntArrayis not actually stored inside of
MyStruct. The new keyword creates the data somewhere in RAM and we simply store a pointer there. The address the pointer stores is copied over to
MySecondStruct, but it still points to the same data. In fact, it would be counterproductive to remove this functionality since there are cases where you want exactly that. Additionally the Unreal Property System does not support non-UObject pointers, which is why
MyIntArrayis not marked with
int32*) means the data is stored directly inside the struct and as such "deep copied". However, if you store a pointer to a
UObject, this object is NOT deep copied! Once again only the pointer is copied and the original
UObjectleft unchanged. Which is good because otherwise you might manipulate the wrong instance thinking you only had one to begin with leaving the original
UObjectunaffected, thus resembling a very nerve-wrecking and very difficult to track down bug!
EditAnywhere, BlueprintReadWrite, Category = "Your Category"to
USTRUCTproperties causes UE4 to automatically create Make and Break Blueprint functions, allowing to construct or extract data from the custom
UPROPERTY() variables of
USTRUCTS()are considered for replication!
USTRUCTis not replicating properly, the first thing you should check is that every member is at least
UPROPERTY()! The struct does not have be a
BlueprintType, it just needs
UPROPERTY()above all properties that you want replicated.
GENERATED_USTRUCT_BODY, in 4.11+,
GENERATED_BODY()should be used instead.
USTRUCTS(), thank you Epic!