Sounds enum values can be lost due to regeneration

[WilliamRitson]

Bug Description

When you Re-Generate audio in the Audio Manager it can result in old enum names being assigned new indices.

This means that if you are using the Sounds enum as something that can be set in the inspector for a monobehavior or scriptable object whenever the Audio Manager regenerates the value set in the inspector might change to a different sound.

It is possible to work around this by just setting AudioFileObjctets in the inspector then using instance.PlaySoundInternal to play them. That works for me, but I only figured it out by reading the source code for the build in components.

Thus, I recommend the wiki be updated to mention this issue and suggest a best practice workflow for storing sounds in monobehaviors/scriptable objects without losing data.

Steps to Reproduce

1. Add an audiomanager and a sound file called "B" then generate library
2. Create a monobehavior with a public or serialized Sound field
3. Create an instance of the monobehavior and set the Sound field to Sounds.B
4. Create a new sound file called "A" then regenerate the library
5. The monobehavior field will now the value A instead of B

Unity Versions Tested With 2019.4.10f1

[jackyyang09]

Thanks for reporting such a major design oversight, the backend system will be reconfigured for the next release so that references won't shift around like that, or at least not as easily!