Changed from cfg["foo"] > number, to !cfg["foo"].blank(). Turned a cfg call into
just a default assignment. Added a .to_int to a cfg["foo"] call to prepare
against bad user input. Finally added whitespace to 2 lines to get them to line
up with the rest of the lines.
Add the following functions in `src/util.hpp`:
template<typename T> inline std::size_t bit_width();
template<typename T> inline std::size_t bit_width(T x);
These functions compute the size, in bits, of a type or value, providing
a convenient and self-documenting name for the underlying expression,
`sizeof(…) * std::numeric_limits<unsigned char>::digits`.
This commit adds two additional header `#include` directives in
`src/util.hpp`. The newly included headers are as follows:
- `<cstddef>`, for `std::size_t`; and
- `<limits>`, for `std::numeric_limits`.
At first, I obtained the bit width of a byte using the C preprocessor
macro `CHAR_BIT`, defined in the C standard library header `<climits>`,
rather than using `std::numeric_limits<unsigned char>::digits`, but I
subsequently switched to using `std::numeric_limits` per Soliton’s
recommendation at 2014-03-17 21:36Z in the `#wesnoth-dev` IRC channel on
the freenode IRC network (<irc://chat.freenode.net/%23wesnoth-dev>).
Here the changes to get whiteboard to work are mostly cosmetic, the
right cost for each unit is displayed on the unit in question. This
is mostly for peace of mind as the user looks at the screen they don't
get confused. The proper gold is also taken for each recall and
replaced for each canceled/undone recall while in whiteboard.
The previous implementation was not strongly exception safe.
This code is nearly identical logically, but with strong exception safety.
It's also good practice and more readable.
Codeblocks made some of my tabs into spaces and I had to fix it.
Also, forgot to mention this before, but I cleaned up some of the code
for astarsearch.cpp as well.
In many places, std::copy was used with back_inserters, or other
std::inserters. These have in most cases been replaced by using the
ranged insert member function of each stl container. Firstly, this makes more
readable code. Also, this is often more efficient because,
if the compiler can find the distance between the source iterators,
it only has to make one block allocation and then fill it
with values. In other cases, containers were being default constructed
and then std::copy'd into with some form of inserter. These were cleaned up
by using the iterator range constructor instead.
Use of std::copy was especially egregious in the case of associative
containers such as map and set. Sometimes back_inserter was
being used, other times std::inserter set at front, but it doesn't matter
because there is no front or back when inserting, and it's much cleaner
to just use set or map::insert(iterator begin, iterator end).
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.
Here the changes to get whiteboard to work are mostly cosmetic, the
right cost for each unit is displayed on the unit in question. This
is mostly for peace of mind as the user looks at the screen they don't
get confused. The proper gold is also taken for each recall and
replaced for each canceled/undone recall while in whiteboard.
Show in the recall dialog below the unit type the recall cost of
that unit. The costs are also colour coded, red for more then the
team/side recall_cost, white for same as team recall_cost and
finally green for below team recall_cost. It also alters the not
enough gold message from "you must have X gold to recall a unit." to
"you must have X gold to recall this unit." There is some new
comparisions to make this all work. The header for one function
(recall_dialog) has had a const of the team.recall_cost passed to it to
allow for the comparisions more easy to do in that function.
There is room for improvement here, perhaps removing the costs display
if no unit has a recall cost that differs from the others.
Actually allows for the unit instance recall costs to be used. Proper
taking of the gold and undoing the cost for each unit is implemented
and works. At advancement if the unit's current recall matches their
unit_type's recall_cost then it takes the new unit_type's recall_cost
otherwise it keeps whatever value it currently has until it fails this
check. Recall costs are also now persistant and will carry over from
one scenario into the next as well.
If a cost is not set, it will continue to use the team/side/default
costs, these changes should not affect the current workings when
dealing with unaltered scenarios, and unit config files. I repeat This
will not affect or change the currently way things work UNLESS a user
alters a file or includes the new recall_cost (as in copies and
modifies a unit in the scenario unit files) for a unit instance in
their scenario file(s).
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.
after fix of bug #21578, the behavior from 1.10, in which game may not
start until all sides have chosen factions as needed, was restored.
we move the party full bell appropriately.
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.
when the side engine in multiplayer_connect_engine.cpp loads a side,
if the game is a save game, the side is not allowed to have a human
player, and it is listed as "network", then we set it to ai,
assuming that it "should" be a "network_ai" if bug #18829 is ever
fixed
