No ToString or FromString blueprint nodes for FPrimaryAssetId in Blueprint

I was unable to find a reference to PrimaryAssetId (as parameter, return value, or variable) in the UKismetSystemLibrary class (KismetSystemLibrary.h & .cpp). Which functions are you referring to specifically to help me find the same section of code.

Additionally, if you’re able to provide a screenshot of the functions you’re accessing in the editor, that would be helpful as well. I was not able to find a reference to an “equal” function when pulling off of a Primary Asset Id pin in blueprints.

Hey RoyAwesome-

I apologize, I hadn’t realized you were talking about 4.17. I now see what you are referring to and have entered a feature request for ToString and FromString functions to be exposed (UE-47642). Please be aware that this request may not be implemented, or that it may not be prioritized to occur anytime soon.

Cheers

Hey , I don’t really understand your use case here, can you explain what you want to do in more detail? I have no problem exposing FPrimaryAssetId->String as it’s a useful debugging thing, but string->FPrimaryAssetId is pretty unsafe because you can easily accidentally construct an invalid primary asset id that will never work. The native API has to/from strings that work fine because the expectation is that people working in Native will understand this risk but in general for blueprint APIs we avoid making it easy to accidentally make errors.

Pretty much the title. C++ has ToString and FromString functions for FPrimaryAssetId, but these aren’t exposed to blueprint. They are incredibly useful for serializing off AssetId references to external systems, so not having them in blueprint is a little funky.

Hey -

Looking at the code for FPrimaryAssetId, the reason the functions are not exposed is because FPrimaryAssetId is a struct, and struct functions cannot be exposed. Attempting to declare a UFUNCTION inside a USTRUCT causes a VS compile error, and if the struct is not declared as a USTRUCT then it is not exposed to the reflection system to begin with.

Cheers

Yeah. What I mean is that a number of functions related to FPrimaryAssetId are exposed in UKismetSystemLibrary (including Equals and NotEquals nodes), but the ToString and FromString functions are not. It’s missing functionality that exists in C++ but not in Blueprint. Just about every other function related to FPrimaryAssetId is exposed here.

These functions are definitely there in 4.17 Preview 2.

https://github.com/EpicGames/UnrealEngine/blob/4.17/Engine/Source/Runtime/Engine/Private/KismetSystemLibrary.cpp#L2439

This functionality is referenced in the 4.17 preview thread here: Unreal Engine 4.17 Preview - Announcements - Epic Developer Community Forums

The Asset Manager now has Blueprint access and is ready for production. The Asset Manager is a global object that can be used to discover, load, and audit Maps and game-specific asset types in the editor or at runtime. It provides a framework to make it easier to create things like Quests, Weapons, or Heroes and load them on demand, and can also be used to set up cook and chunk rules when packaging and releasing your game. The Asset Manager tab in Project Settings can be used to set up the rules for your game. Primary Asset Types that are scanned by the Asset Manager can be queried at runtime before they are loaded, and can then be asynchronously loaded on demand. To use the asset manager, call functions on the native UAssetManager class (which can be subclassed for your game), or call Blueprint functions in the Asset Manager category such as Async Load Primary Asset.

The ‘ToString’ and ‘FromString’ functions for FPrimaryAssetId in C++ are missing from this Blueprint Access feature.

Hey Ben.

So, I had a number of Character Classes for an RPG. I wanted to store off the character data to a remote database, and I needed an easy way to serialize off the Character Class. I was using the Asset Manager for my UI code to display character classes in the character create screen, and I was prototyping the database push in Blueprint before moving it to C++.

Yeah, for a use case like that I think doing it in C++ is more appropriate, we try to hide internals in Blueprint land generally. I’ll consider adding this but it’s relatively low priority

Ok. It’s really no biggie because I ended up exposing them myself as I understood the risks.