URL:
<http://gna.org/bugs/?14039>
Summary: All initial music playlists broken since r36270,
more potential side-effects
Project: Battle for Wesnoth
Submitted by: shadowmaster
Submitted on: Thursday 07/30/2009 at 11:05
Category: Bug
Severity: 4 - Important
Priority: 5 - Normal
Item Group: None of the others
Status: None
Privacy: Public
Assigned to: boucman
Originator Email:
Open/Closed: Open
Discussion Lock: Any
Release: 1.7.1, 1.7.2, 1.7.2+svn
Operating System: Any
_______________________________________________________
Details:
SVN revision #36270 introduces some changes in game_events.cpp which prevent
music playlists from being modified in any temporary or permanent way while
the game display is not available or locked for any reason. The original
commit's reasoning was "skip WML created sounds, messages, floating labels
and labels during quick replay, fix bug #13519". However, during scenario
prestart events, the display is by design unavailable (locked?) so WML coders
can do some stuff "behind-the-scenes" before the player gets to see the
scenario (version 0.9.6, solves bug #12957).
Since most, if not all, mainline scenarios use the INTRO_AND_SCENARIO_MUSIC
and EXTRA_SCENARIO_MUSIC macros, which set the definitive music playlist
using prestart WML event handlers, we are left with a monotonous tune
intended to be used in storyscreens (first argument to
INTRO_AND_SCENARIO_MUSIC) instead of the tunes actually intended for the
scenario (second argument to INTRO_AND_SCENARIO_MUSIC, additional tunes set
by EXTRA_SCENARIO_MUSIC), which is obviously not a good thing at all.
I suspect that setting [label]s dynamically during prestart events is broken
too as a side-effect of that commit. I do not know of any mainline scenarios
setting them on prestart events to check.
Reverting the guilty commit immediately fixes the issue with the initial
music playlists. The problematic piece of code repeated for various handlers
as can be noted in the revision's diff, follows:
++
game_display* disp = game_display::get_singleton();
if(!disp || disp->video().update_locked() || disp->video().faked() ) {
// We get here on prestart events too!
return;
}
--
I'd suggest as a better solution to the original bug that this commit was
fixing (#13519) that the quick-replay status is checked using a different
condition. I am not familiarized with the replay system, but it is possible
that this may involve exposing extra properties somewhere for the game events
engine (C++).
I'd also suggest that the commit is reverted if this cannot be fixed before
the next release, and reopen the original bug.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?14039>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs
