Technically, all this code should work on Vista, (including the recent switch to using
SHGetKnownFolderPath), but since we're also considering requiring Visual Studio 2017
for building, we need Windows 7.
The specific case that brought this to our attention was color=100. In case such values
are used, the color reverts back to the default color for that side, as before.
The new codepath (team::get_side_color_id_from_config) is essentially the same as the old
one but more robust (range checking, for example, the lack of which was causing the crash
before).
This reverts commit 5fd833a91a. It was causing the lobby to
lag up to *three minutes* behind current activity due to multiple data packets being queued
(see #3046). It seems 100 ms was enough to mask this issue.
Several reports on Steam and our forums point at std::bad_cast being
thrown when accessing Preferences and the Multiplayer menu amongst
others. It's possible that the locale configuration on those systems is
not quite right, and compare() and icompare() are able to throw
std::bad_cast when this happens as they both use std::use_facet().
Note that much like the macOS/iOS version of icompare(), this stopgap
patch doesn't attempt to provide any form of case-insensitive fallback
and just uses a case-sensitive comparison instead.
Thanks to @ProditorMagnus for the suggestion. Note that here on master, this code isn't
really used right now, so it's mostly here for completeness if it turns out to be needed.
There isn't much point in doing more expensive ban look ups first.
(Also, yes, I am aware that as it is there's still two SELECT queries
that could be coalesced into a single one -- namely, the ones for the
user_email and user_id columns.)
This enables reporting back to the client the specific type of ban that
affects the account. This information is already normally provided by
phpBB when trying to view a page while banned, so we are not leaking any
new information here.
There isn't an API to retrieve the (user-visible) ban reason from the
ban list yet. It's probably not worth worrying about it since affected
users can see it when navigating to forums.wesnoth.org anyway.
This adds a user_is_banned() method to the user_handler classes that
returns whether a given username (and optionally IP address) is banned
by the user_handler platform. Obviously right now this is only intended
to work with forum_user_handler and phpBB.
Forum bans are checked against entries in the banlist table using
username (actually user id), IP address, and email address where
applicable. A user matching a ban on any of those three items will not
be permitted into the server *unless* they have the moderator flag set.
It might be worth making an exception for board founders as well,
although that is probably orthogonal to this patchset.
Right now there are a few missing items:
* The server sends clients an error that allows them to try again with
a different username/password combination immediately. Nothing stops
them from causing noise in the server logs this way, so we probably
need to ensure this counts as an authentication failure for the
purpose of temporarily and automatically banning the IP address.
* The user handler doesn't allow retrieving details about the ban, so
all that the main server code can do is report back to the client as
their nickname being banned, when this is not necessarily the case
(email or IP address bans). I need to figure out a better API for
retrieving this info.
* Likewise, the server does not log the specifics about the matched ban
yet unless the mp_user_handler log domain is set to the info log
level.
* There's no i18n support on the client side for the error message sent
by the server -- which is going to change anyway.
* Testing this patch uncovered an issue with the MP client not
displaying messages sent during the login sequence, including the mod
authentication notice.
This fixes issues reported on the forums where the weapons list now
includes weapon specials even when they aren't active, a regression from
1.12.x.
Closes#3033.
the wb recruit actions store temp units with fake ids and live longer
than a turn, so resetting the underlying id counter between turns might
result in dublicate id errors in wb recruit actions ( #1517 ), which
might lead to errors later.
With this it is of course possible to get erros when more than 2^31 (or
2^63 on a 64 bit wesnoth version.) fake units are generated during a
game, but that is less likely.
previously having a planned recall action could change the order of
units in the recall list, which might for example change which unit is
recalled by a [recall].
The firstproblem was that:
apply_temp_modifier adds the temp_unit_ to the map, then
remove_temp_modifier adds the temp_unit_ from the map to the recall
list, which resulted in the original recall unit beeing replaced by the
temp_unit_ of the recall_action We fix that by making sure that
temp_unit_ is always the same as athe recall unti not just a copy.
The second problem was that remove_temp_modifier reset the unit mp/ap to
a value differnt form the original mp/ap which could casue OOS later
since the ap/mp might be changed form that unsynced context, we fix that
by resetting the mp/ap in remove_temp_modifier
turned out 8bdccca7 was not enough because the mapbuilder erroneously
reset the units movement to full directly before it was applied. Since
the `resetters_` code in mapbuilder.cpp does not apply to
recruited/recalled units, we also have to reset the units mp in
remove_temp_modifier.
