Half-fix for issue #1634 and issue #1924.
The issue that remains to be solved is that on subsequent sessions after
a campaign has failed to load, it is possible for the game to generate a
cache entry for it that only contains the main menu WML for it.
Apparently the config cache transactions mechanism causes the game to
try to generate a cache entry with the wrong defines (a define set that
doesn't include the campaign's symbol, for instance) instead of the ones
that are actually needed and used to match the cache entry's filename
via checksumming. As a result, on subsequent sessions the failed
campaign is aborted with "failed to load the scenario" instead of
displaying the real WML error again (since the error is not hit again if
it depends on the campaign's symbol being defined).
In the meantime, this at least removes the red herring error and makes
the underlying issue a bit more visible. It's a very crude hack but it
does the job.
For lobby messages, there was a length cap in place already, but the
truncated message was lost in processing because it ended up in a WML
document that isn't the one relayed to listening clients.
On the other hand, whisper messages were missing the truncate logic
entirely. Oops.
(The logic for in-game messages does truncate messages correctly as far
as I can tell, and additionally the client UI doesn't allow overlong
messages.)
Thanks to Soliton for pointing me towards the faulty code.
menu_button doesn't even actually inherit from clickable_item. The only reason
[dis]connect_click_handler was declared in this class is the original implementation
was copied extensively from the Button widget.
Using NOTIFY_MODIFIED also means callbacks can fire if set_value/set_selected is used
on a menu_button.
The [dis]connect_click_handler functions were also removed from multimenu_button. All
callbacks for this widget type already used NOTIFY_MODIFIED signals.
Retvals are only relevant for widgets that are supposed to trigger something
like a window closure, and that makes sense for neither of these widgets. The
only reason the Menu Button widget has it is its original implementation was
largely copied from the Button widget, and the Multimenu Button widget copied
from the Menu Button widget.
This was due to the change in the MP initialization process wherein the lobby wouldn't
show up until the initial gamelist was received. Since the admin auth message is sent
after [join_game] and before the initial gamelist, and the chatbox widget handled parsing
the auth message, the client was never marked as authenticated and therefor couldn't
observe private games. This fixes that by adding auth parsing to the MP initialization
process.
Note this doesn't fix the issue of the auth confirmation not showing up in the lobby chat
(issue #2920). I'll have to think of a way to fix that separately.
Makes it easier for translators to do something specific with this label if needs
be. I remember the reason the count (NUMx) label was moved prior to the name had
to do with language conventions too, so this should alleviate any other such issues.
Also made the name label default size instead of small.
Automatically checking the path relative to a maps/ directory without binary
path support results in an invalid path almost every single time. If I remember
correctly from my testing, the only time that worked was if I added a data/maps
folder.
ee50171d13 broke some codes that relied on
unique save ids, that is in particular the statistic code and
scoped_recall_unit, so now these codes fallback to the side number if
the save id is empty.
The variable **always** changed when event handlers were run, and thus the
optimizations to avoid updating some status after WML/Lua has run weren't
doing anything. In addition, commit 62ec3b3951 removed the most
important optimization that relied on wml_tracking().
Resolves#2578.
Since there were weapons included that weren't shown, it was possible for the best
weapon selection to be a hidden one (in which case, the initial selection would be
wrong, and it was possible for the returned index to point to a hidden, disabled
weapon.
This resolves both issues by excluding these disabled attacks from the weapon choices
list altogether. They aren't considered when calculating the best attack either.
mouse_handler::fill_weapon_choices is also used in mouse_handler::attack_enemy_, but
I don't foresee this change should cause any issues there, since you aren't supposed
to be able to actually attack with disabled weapons anyway.
This commit is the followup to a similar one I did regarding window initialization. Instead
of widgets being created on the heap and not being managed by a smart pointer until they're
added to a grid, they are now always managed by a shared_ptr. To that end, this commit covers
bunch of things:
* builder_widget::build (both overloads) and all its overrides (which have now been marked
as such) now return shared_ptr<widget>.
* The builder_grid::build() override now returns the same instead of grid* since you can't
use covariant return types with smart pointers.
* The two implementation build helpers in builder_grid have been combined with an optional
replacement map as the second parameter. Uses of the version that took a grid pointer could
be easily converted to pass a reference instead.
* The pane, matrix, and viewport build() functions were removed in favor of making the ctor
public. In case there was a deprecated ctor, that was removed.
* The viewport now keeps a widget shared_ptr instead of a reference that was then deleted
by address-of. This was both better design and necessary to fix a crash.
* build_single_widget_instance_helper and build_single_widget_instance were renamed to
build_single_widget and build_single_widget_and_cast_to to better represent their roles
and to indicate the latter was more a convenience extension for the latter than the other
way around.
If dc happens during asio read that would call server::add_player
then a "ghost" player will appear in games_and_users_list_. Fix works by
moving the list update into the handler, it will be called only if read is
successful.
This should prevent issue #2989 unless it has some other mechanism
This is a debug mode-only dialog. If I want to spawn a unit, the game
had better allow me to spawn any unit I want. do_not_list was created
for use by wmlunits anyway.
This time I added an option to disable the feature to allow the currently
playing track to finish when changing the playlist. This allows more
fine-grained control of distinct use cases.
In wesnoth.cpp:do_gameloop(), I reversed the order of the title screen
music and default music because otherwise adding the default music would
enable play_once for the title screen music and prevent instant music
change when the player loads a save. I play title screen music with
immediate=yes, so it's still played first.
