New haloes were sometimes added to both new_haloes and invalidated_haloes,
and were therefore rendered twice in the same frame. As a result, the halo
added itself to its unrender buffer, and therefore remained on screen even
after unrendering.
Eliminating the entire new_haloes set fixes the issue. Fixes#2187.
This reverts commit cdec9b2a7a. This commit broke selection of different
brushes in the Editor. Using a single pointer means changes to the brush pointer in editor_toolkit aren't
reflected in the action objects.
The double pointer isn't the cleanest code, but I'm not sure how to improve it.
Squash and merge for three carpets terrain PR.
* Initial commit for carpets. WML, alignment, and demo only, images are unshaded place-holders.
* adding basic shading and better corner images
* completed shading for existing images
* refined large corner carpet rules
* got rid of some commented out leftovers
* initial commit for cave rug, Iwd
* regular carpet files, incomplete for now
* completed regular rug
* changed cave-rug underlayer to cave path instead of dark flagstones, and changed all rug terrain codes
* fixing some transition WML filtering for Urc (cave carpet)
wesnoth.current.event_context might not contain all information if the die event was triggered by wml ([fire_event]), this made wesnoth.get_unit error (invalid argument)
This is meant to be a cleaner replacement to the [size_lock] widget. Both keys are optional,
in which case the layout engine will assume dynamic sizing for that dimension. Dynamic sizing
will also occur if either the fixed with or height evaluates to 0 or less.
These have no effect in the GUI2 lobby, nor do I intend to make use of them (plus the lobby has
its own sort controls anyway). I'm assuming they were for the GUI1 lobby.
I can't find any code on the server side that would send this signal, so I'm assuming it must
be a relic of some removed feature. In any case, we don't support joining MP games by bypassing
the lobby.
Note the `if(!received_join_lobby)` check was removed since it could only apply to a case where
join_game was received, since there are only two loop-exit conditions.
Since track_ok is used as a loop control, we need to return true if current_track is null
in order to break out, else we get stuck in an infinite loop.
This does require some more usability improvements in the future, though. First off, this change was introduced
to get rid of that pause when the lobby is first opened before any contents appears. However, this change only
affects the initial connection, not any subsequent returns to the lobby.
Second, this also means the user doesn't have a way to quit to the titlescreen if the data fetching is taking an
especially long time anymore. It was suggested instead of this, we add some indicator to the lobby that data is
being fetched, but I don't know if that's really feasible with our toolkit. Still, we should add some way to exit
the loading screen if this is taking too long.
Lastly (and building on the above, though this is a more general issue), if at any point the server conks out and
doesn't send the lobby data, or a handshake, or anything, there's no way to exit the loading screen at that point.
Need to come up with a solution for that - either a timeout, or an exit button.
The regular append_children function makes a copy of the applicable child tags. This moves them
from the source to the destination configs. Do note it leaves the source tags empty.
When the AI moves a unit out of the way for another unit’s move, it is
occasionally possible for the former unit to use up all its movement
points (e.g. if it has few MP or on narrow crowded maps). If that unit
is on the list to be moved later during the same sequence, this caused
ai_helper.robust_move_and_attack() to return nil, which then made the
Fast Micro AI produce an error message.
For some reason, after d7302d684d a warning about Boost's use of gethostbyaddr and appeared
when compiling wesnothd_connection.cpp on Windows. No idea what change in the above commit caused
it, but it seems moving the _WINSOCK_DEPRECATED_NO_WARNINGS define to wesnothd_connection.hpp silences it.
This fully splits the wesnothd loading screen handling from the network_transmission dialog and
into wesnothd_connection. Much cleaner this way. I've also added wait_and_receive_data as a general
spin-and-wait-for-data-to-come-in function instead of having it local in open_connection.
This allows for compile-time verification of stage ID names, instead of leaving it until runtime.
It also allows the use of std::atomic for the current stage class variable since we're no longer
using a const-qualified type.
Previously, the use of the wesnothd_connect_dialog and wesnothd_receive_dialog wrappers meant
multiple loading screen instances were created when connecting to MP. This change means only
one (or two, if the config is reloaded) loading screen objects are created when connecting to
the server. It also ensures the entire connection process (ie, the extent of open_connection)
is done with a loading screen displayed.
