Follow-up Comment #1, bug #20353 (project wesnoth):
After further testing (and some experimentation with a patch to convert
soundsource::manager to inherit events::pump_monitor), it seems I was mistaken
about a few things:
- The affected sources all had the loop attribute unspecified (defaulting to
zero), which theoretically means (if the wiki were to be treated as a source
of accurate information, which it is not) that the sound should only place
_once_ until the player scrolls away and back to the specified location; sort
of like and incredibly large value for the delay attribute.
- However, the loop attribute does not work that way in practice when set to
zero. It only means that ONE of the chosen sound files from a list will be
played exactly once rather than being looped for the duration of the sound
source's effect. As a side-effect, no new sound will be chosen while GUI1 or
GUI2 dialogs are running. The rest of the time, however, it will continue
looping on the chosen file.
- If the loop attribute is set to -1, the game will pick one of the given
files in a list, and play the same sound forever for as long as the sound
source is active, _even_ when GUI1 or GUI2 dialogs are running.
A test case in mainline already exists in the test scenario; you can check its
unique sound source's behavior when the loop attribute is set to -1 (as it
already is) or 0.
This is all very confusing and suggests that I'm trying to implement a feature
that already exists but is just broken or incorrectly designed. I'm leaning
towards the latter.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?20353>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
