When an option is selected in OptionsListView, disable all child OptionView GameObjects after fading the canvas alpha to 0. This is to avoid unintended effects of leaving the options active when the dialogue view itself is not active, such as animations, audio sources, or other scripts on a custom OptionView.
No longer disable all OptionView objects when initializing options in OptionsListView.RunOptions, as any existing ones will have been disabled at the end of the previous options interaction. New OptionView objects created are still disabled before their use.
Please check if the pull request fulfills these requirements
[ ] Tests for the changes have been added (for bug fixes / features)
[X] Does it pass all existing unit tests without modification?
If not, what did you change?
If you altered it significantly, what coverage issue did you fix?
[ ] Docs have been added / updated (for bug fixes / features)
[ ] CHANGELOG.md has been updated to describe this change
What kind of change does this pull request introduce?
[ ] Bug Fix
[ ] Feature
[X] Something else
What is the current behavior?
When an option is selected under an OptionsListView, the child OptionView objects are left enabled and only the canvas group is made transparent, hiding all options. This can lead to unintended behavior if a custom OptionView script or Prefab is used, as animations or sounds may continue playing, scripts will continue to Update, etc.
What is the new behavior (if this is a feature change)?
All child OptionView objects are disabled either when an option is selected, or when OptionsListView.DialogueCompleted() is called. The canvas is faded before options are disabled, so there is no visible change in behavior.
Additionally, previously created OptionView objects are no longer disabled when presenting a new set of options since they will already have been disabled.
Does this pull request introduce a breaking change?
No. If this functionality was desired, it would almost certainly be in the context of other custom views, and writing a custom options view to restore previous behavior would be simple.
Other information:
Although the change is minor, it removes the unintuitive behavior that when the options view is not active, its children remain enabled. They have to be disabled before displaying a new set of options in any case, so the work is done in advance for clarity.
When an option is selected in OptionsListView, disable all child OptionView GameObjects after fading the canvas alpha to 0. This is to avoid unintended effects of leaving the options active when the dialogue view itself is not active, such as animations, audio sources, or other scripts on a custom OptionView.
No longer disable all OptionView objects when initializing options in OptionsListView.RunOptions, as any existing ones will have been disabled at the end of the previous options interaction. New OptionView objects created are still disabled before their use.
See brief discussion on Discord: https://discord.com/channels/754171172693868585/1072667932078903400/1154638863877287936
Docs have been added / updated (for bug fixes / features)What kind of change does this pull request introduce?
[ ] Bug Fix
[ ] Feature
[X] Something else
What is the current behavior?
When an option is selected under an
OptionsListView, the childOptionViewobjects are left enabled and only the canvas group is made transparent, hiding all options. This can lead to unintended behavior if a customOptionViewscript or Prefab is used, as animations or sounds may continue playing, scripts will continue to Update, etc.All child
OptionViewobjects are disabled either when an option is selected, or whenOptionsListView.DialogueCompleted()is called. The canvas is faded before options are disabled, so there is no visible change in behavior.Additionally, previously created
OptionViewobjects are no longer disabled when presenting a new set of options since they will already have been disabled.No. If this functionality was desired, it would almost certainly be in the context of other custom views, and writing a custom options view to restore previous behavior would be simple.
- Other information:
Although the change is minor, it removes the unintuitive behavior that when the options view is not active, its children remain enabled. They have to be disabled before displaying a new set of options in any case, so the work is done in advance for clarity.