Mechanical sound support part 3

[arthurkehrwald]

Picking up where linojon left off in #466. I merged his changes into my fork and rebased the feature branch onto the upstream master branch. Here are the problems I have identified so far:

Problems

Usability

Add mech sound button situation ✅

• Initial problem: Unity does not respect default volume when adding new mech sound using the + button in the inspector list view
• Attempted solution: linojon added another button as a workaround
• New problem
  • The + button is still there
  • There are now two ways to do the same thing
  • Only one is correct, but there is no obvious way for a user to tell which
  • Choosing the wrong one will result in no audio being played, because the volume is zero by default

Audio playback in editor ✅

SoundAssets have a button to play back their audio in the editor. Pressing this button creates a new game object with an audio source in the currently open scene, if such an object doesn't already exist. This behavior is an unexpected and unwelcome side-effect, because it permanently alters the currently open scene.

Sounds must be added manually

Users must manually add sounds to each game object (these should be included in prefabs instead).

Architecture

Inheritance for the sake of type constraints ✅

DropTargetBankApi needed a reference to the associated DropTargetBankComponent to call its EmitSound method. In other xApi classes the associated xComponent instance is referenced using the MainComponent property defined in the abstract base class ItemApi . DropTargetBankApipreviously did not inherit from ItemApi because ItemApi has a type parameter for the component type and a constraint that requires that type parameter (in this case DropTargetBankComponent) to inherit from the abstract base class MainComponent, which DropTargetBankComponent did not. linojon solved this by making DropTargetBankComponent inherit from MainComponentpurely to satisfy the constraint of ItemApi without actually implementing any of the abstract methods of MainComponent (and instead throwing an Exception when they are called). This is bad because it leads to unexpected results when calling those methods

Diligence

• Questions in code comments
• Commented out code
• SerializableDictionary with NonSerialized attribute in MechSoundsComponent seems a bit pointless, but I have not yet checked whether it actually is
• Redundant use of Serialized and NonSerialized attributes
• public fields all over
• Fading logic is absolutely bizarre

Bugs

• Sound fading doesn’t work if fade duration is shorter than one second
• MechSound.volume is not applied

Incomplete

• Score motor sounds ✅

[freezy]

Awesome!

This will take a little bit of time to review, trying my best for this week.

[arthurkehrwald]

Committed a fix for the zero-volume-by-default problem when adding MechSound instances to the list in the inspector. It applies the default value the first time an instance is serialized based on the value of a private flag. The downside is that it only works for the first item added to the list, because Unity clones the field values of each subsequent instance (including the flag) from the previous item in the list, but that is arguably ok because any unreasonable values that are cloned from the previous instance are the user's responsibility since they must have changed the defaults at some point.

[arthurkehrwald]

I have read through the guide @Mr-Jay-Gatsby followed to implement sound fading, so I understand why he chose not to simply fade the volume on the AudioSource directly and opted to fade the volume of audio mixer groups trough an exposed parameter instead. (Smooth interpolation in case of low frame rate) What I don't get is how this is supposed to allow fading audio sources individually. Is there supposed to be an audio mixer group for every single audio source? That is not at all what they are meant for and will quickly get out of hand. Also, there seems to be no API to create mixer groups and expose the volume automatically, so for every MechSound in every MechSoundsCommponent, the user would have to:

1. Manually create an audio mixer group
2. Expose the volume to scripts with a unique identifier
3. Enter that identifier and assign a reference to the mixer group in the MechSound drawer in the inspector

If this is the only alternative, I think we should just use AudioSource.volume to fade and accept the choppy interpolation when the framerate is low.