Removed duplicate code that caused timer to be refreshed an additional
time if time runs out. The usual refreshing in
playmp_controller::after_human_turn is already called in this case as
well (after turn ends). The duplicate code gave the bonuses before the
turn ended, and after that the turn was ended (giving turn bonus again)
only if there was no random seed incoming from the server.
Conflicts:
changelog
The problam was that mp::configure is not used for reloaded games and so
mp_game_settings will not be fully initialised. This leads to using default
values rather than values set using mp::configure screen or from reloaded game
config.
The optimal solution would be to either display mp::configure for reloaded games
or to populate mp_game_settings using reloaded game config. However, both
solutions require rather a lot of code restructing and are probably not suitable
for a feature freeze.
Halos are never rendered for shrouded locations, but they are still
unrendered for them. A long-standing issue with [item] halos resulting
from this is that a halo that gets rendered to the screen at least once
for an unshrouded location later causes glitches if that location is
manually shrouded afterwards.
This can be avoided by not unrendering halos for shrouded locations. I
believe this solution makes sense because halos for shrouded locations
are never rendered first, and if the location is shrouded later on, the
display code will redraw the affected locations and overlay shroud on
top, causing the halo object's unrender buffer to become hopelessly
obsolete.
at a certain point in playcampaign.cpp after the level has ended, wesnoth was
grabbing .child("end_level_data"), and writing carry_over sides.
this would cause "mandatory child missing" errors in the test case described.
we fix the error by checking if the child was not present and if so adding it.
however, it may indicate a more fundamental bug involving reloaded games.
This was an oversight dating back to the introduction of the [filter]
tag as a possible parameter to this Micro AI. A part of the attack
code still relied on the id= key being given, although that key is not
required any more now.
it turns out that when the "network_ai" controller type was introduced,
it was implemented on the server in the following way:
a4f47a63c7/src/server/game.cpp (L464)
change_controller requests to the type "ai" are always transformed
by the server into either "human_ai" for host or "network_ai" for client,
and in thunderstruck's refactor of the mp_connect dialogs, ai sides are
always set to "ai" in the WML sent to the server (and set this way on
the host).
however, because of code in play_campaign.cpp which long predated this
refactor, all sides on an mp client are either set to human (if that
player controls them) or "network", or "null".
this causes problems because if that player saves the game, the savegame
will record these sides at human controlled rather than ai controlled...
if the game is reloaded oos can occur, although I won't detail it here.
we update the play_campaign.cpp code to ensure that "ai" controller types
always resolve to human_ai or network_ai as appropriate. additionally,
we make sure that on the host, sides always resolve to human_ai rather
than ai. so the type "ai" should never be observed during an mp game,
and only during scenario configuration, and perhaps during replays.
additionally, we ensure in playturn.cpp that if the client gets a message
from the server to set a side to "ai" during the game, it will in fact
set it to "human_ai" or "network_ai", to preserve the invariant.
finally we also switch over observers to follow this behavior --
previously there was a hack here in the server which would make sure
that any observers which join see all sides as controlled by "human"
a4f47a63c7/src/server/game.cpp (L197)
in order that they do not attempt to substitute themselves for a player.
we change this by removing the hack, and programming the client to remember
if the player is an observer, and if so not attempting to substitute themself
at game start.
in the refactor of mp_connect, one behavior from 1.10 that was
lost was that the host may not start a game until all sides have
chosen faction. we restore this, adding fields to the side engine
to fix in a robust manner, some debugging capabilities left over.
This raises the sound effect (SOUND_FX) channel group size from 5 to
21.
The rationale for this change is that the current SFX channel group size
is not enough in some situations (particularly during cutscenes and with
accelerated animations enabled), and decreasing the channel group size
for sound sources (currently 8, preserved as-is in this commit) doesn't
seem like the best solution at this point considering that the sound
source feature is neglected enough as it is. Three other channels are
reserved for the turn bell, turn timer countdown sound, and UI sounds,
and it'd be an even worse idea to drop those.
The SDL_mixer documentation suggests that increased mixer channel
allocations may be a memory usage concern with a high number of channels
("We're talking REALLY high!", their words), but hopefully this small
increase is good enough for our and the UMC making community's purposes
without impacting memory usage or performance on our main supported
platforms. At least Wesnoth's RSS didn't seem to change over a megabyte
when testing this patch on Linux (using ALSA).
Note:
Should this increased limit cause issues on some platform that matters
(hopefully not!) an alternative would be to reengineer the sound channel
selection done in sound::play_sound_internal() so instead of skipping
sounds when all channels are busy, the oldest playing channel is stopped
and reset to the requested sound, for channels in the SOUND_FX group.
However, this seems too complicated to do at this point for 1.12, so yet
another alternative would be to simply reduce the number of channels
reserved for sound sources and give those back to SOUND_FX.
For some reason, ~BG() used SDL_BlitSurface() directly instead of using
the alternate blit_surface() implementation, unlike every other image
path function type in existence that needs to do blitting.
This works the first time when scaling or cropping an image (say,
"misc/blank-hex.png~BG()~CROP(0,0,34,34)"), but the second time it's
used with different scaling/cropping parameters, it yields the result it
would without ~BG() in the pipeline. This is somehow remedied by this
change, and I don't see any potential issues arising from it anyway
(save for a negligible performance impact on ~BG(), maybe).
wesnoth.synchronize_choice checks the return value of toconfig fcn,
and if it indicated that it partially failed to convert the table,
it will chat a warning, IF wesnoth is running in debug mode
(that is game_config::debug = true, which is determined by e.g.
the command line flag --debug)
