When writing some menu code, I found that programatically driving SetSoundMixClassOverride does not allow for any type of input for the Sound Class pin because the Sound Class type is forbidden to be used in Blueprints.
It would be nice if this was somehow resolved so that logic like this would not have to be made:
Hey Allar, good idea… I think SoundClasses should be readable from BP, but not writeable. They’re created and connected in a singleton sound class graph so we shouldn’t be able to create them on the fly, but I don’t see why wouldn’t be able to read them. I’ll look into it.
Added it in our dev branch, should make it out in 4.19 assuming we don’t find any catastrophic knock-on bugs from it. If you need/want it sooner, my change basically changed the UClass markup to be
UCLASS(config = Engine, hidecategories = Object, editinlinenew, BlueprintType)
class ENGINE_API USoundClass : public UObject
Then went and added BlueprintReadOnly to all sound class properties, and removed ENGINE_API from individual functions. ENGINE_API was needed due to a linker error in a separate module using sound classes that occurred due to new generated code by UBT. I also went and did the same thing to the UStructs in that file for settings so you can inspect sound class properties, etc.
This is correct… after branch time, focus is stability. This change is anything but a stable change. I’m pretty sure it’s cool, but I’m going to let QA see if they can think of a reason why this wasn’t already exposed to BP. It’s been that way forever and the progenitors of that code may have done it for a reason that I am not currently thinking of.