bugBattle for Wesnoth - Bugs: bug #20353, Sound sources should continue...

Show feedback again

bug #20353: Sound sources should continue running while dialogs are on screen

Submitted by:  Ignacio R. Morelle <shadowmaster>
Submitted on:  Thu Dec 6 01:09:42 2012  
Category: Feature RequestSeverity: 3 - Normal
Priority: 5 - NormalItem Group:  None of the others
Status: NonePrivacy: Public
Assigned to: Karol Nowak <grzywacz>Open/Closed: Open
Release: 1.10.x, 1.11.0+svn r55812Operating System: All of them?

Add a New Comment (Rich MarkupRich Markup):

You are not logged in

Please log in, so followups can be emailed to you.


Wed Jan 23 04:34:32 2013, comment #2:

Attaching the aforementioned patch, which is probably the wrong approach to fix this after all.

(file #17001)

Ignacio R. Morelle <shadowmaster>
Project Administrator
Wed Jan 23 04:31:47 2013, comment #1:

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.

Ignacio R. Morelle <shadowmaster>
Project Administrator
Thu Dec 6 01:09:42 2012, original submission:

While any GUI1 or GUI2 dialog is running (in particular, the [message] dialog), any active [sound_source]s stop being processed until the dialog is closed. The sound file from the last active sound source continues playing while the dialog is active, but only once.

The ideal behavior in this case would be for sound sources to continue being processed during the GUI event loop.

Ignacio R. Morelle <shadowmaster>
Project Administrator


(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):

Attached Files
file #17001:  bug-20353.patch added by shadowmaster (2kB - text/x-diff)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by grzywacz (Updated the item)
  • -unavailable- added by shadowmaster (Submitted the item)

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.


    Error: not logged in



    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon Feb 4 10:19:50 2013grzywaczAssigned toNone=>grzywacz
    Wed Jan 23 04:34:32 2013shadowmasterAttached File-=>Added bug-20353.patch, #17001
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup