You can save any UObject that is represented as an asset within a UPackage using this method: bool SaveToAsset(UObject* ObjectToSave) { UPackage* Package = ObjectToSave->GetPackage(); const FString PackageName = Package->GetName(); const FString PackageFileName = FPackageName::LongPackageNameToFilename(PackageName, FPackageName::GetAssetPackageExtension()); FSavePackageArgs SaveArgs; // This is specified just for example { SaveArgs.TopLevelFlags = RF_Public | RF_Standalone; SaveArgs.SaveFlags = SAVE_NoError; } const bool bSucceeded = UPackage::SavePackage(Package, nullptr, *PackageFileName, SaveArgs); if (!bSucceeded) { UE_LOG(LogTemp, Error, TEXT("Package '%s' wasn't saved!...

There is a std::variant class template in the standard library that is essentially a type-safe  union. It is generally used when we are not sure in advance which object should be populated from our list of object types, so we assume that one of the specified objects must be there at a time. Unreal Engine has an alternative implementation called TVariant that works the same, except that all the types in the declaring template parameter pack must be unique....

Unreal Engine has an alternative implementation of std::mutex called FCriticalSection which makes it possible for your data to be safely accessed from different threads, preventing race conditions. This takes the same approach, handling it with one thread locking until the other thread completes the necessary operations. There are two ways to handle lock/unlock logic. The first is low-level, which is used to directly lock and unlock threads. Use with caution due to possible deadlocks ....

This article addresses the question of how to work with UObjects in a thread-safe way when dealing with workers, async tasks, thread pools, or whatever else using a non-game thread. One critical issue to address is the handling of garbage collection. When passing an UObject, which is not set to root, directly to a background thread, there’s a risk that the garbage collector may silently delete the passed UObject. Even frequent validity checks of the UObject (e....

By default, when a non-const reference is specified in a function, it will be treated by Blueprints as an output parameter: Show/hide content UFUNCTION(BlueprintCallable) static void RemoveDots(FString& String) { String.ReplaceInline(TEXT("."), TEXT(" ")); } There is a macro called UPARAM which is not widely used, but can control the behavior of parameters specified in UFUNCTIONs. In particular, it can change the behavior of passing non-const references by specifying a ref meta:...