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 06 Dec 2012 01:09:42 AM UTC  
 
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 23 Jan 2013 04:34:32 AM UTC, 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 23 Jan 2013 04:31:47 AM UTC, 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 06 Dec 2012 01:09:42 AM UTC, 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):
   
   
Comment:
   

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.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

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

    Back to the top


    Powered by Savane 3.1-cleanup