Announcement

Collapse
No announcement yet.

Allow Sound Classes to be variables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    [FEATURE REQUEST] Allow Sound Classes to be variables

    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:


    #2
    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.

    Also, we have a new audio forum if you want to join us and give us more suggestions. https://forums.unrealengine.com/deve...scussion/audio

    Comment


      #3
      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

      Code:
      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.
      Last edited by Minus_Kelvin; 09-21-2017, 07:32 PM.

      Comment


        #4
        Why 4.19 and not 4.18?

        Comment


          #5
          Originally posted by Raildex_ View Post
          Why 4.19 and not 4.18?
          Because 4.18 was branched off the master branch already, it'll probably only get bugfixes now until release and no new features.

          Comment


            #6
            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.

            Comment


              #7
              Originally posted by Minus_Kelvin View Post
              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

              Code:
              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.
              Thanks Minus_Kelvin.

              Comment

              Working...
              X