1) We now use a single function to set slider min/max value, this fixes#1641
(sliders having a temporary invalid (min > max) state between set_min() and
set_max() calls)
2) I split the sliders_base class from the scrollbar_base class to not
accidently break the rather complicated scrollbar_base class while
refactoring sliders.
3) We don't use floats in the slider code to make sure no rounding errors happen.
4) This fixes#1539 by removing slider::in_orthoginal (which made it impossible
to pull a slider to its maximum/minimum) and intead clamping the mouse
position in range.
5) This fixes#1656 and #1767 by refactoriung code (that bug happend mainly
because the old code used variables that contained the position in 'steps'
as pixel position and vice versa)
6) Sliders now 'snap' to the correct values just like the gui1 sliders did.
7) Slider positions are now poperly rounded to its neariest values
instead of just beeing 'floored'
As a bonus, this also makes the images show up when a save from Windows
is loaded on GNU/Linux or macOS.
It would be particularly useful if Steam Cloud was supported.
This reverts commit 02de08338c.
Mainline does *not* contain paths with backslashes. If it did, the game
would be broken on GNU/Linux and macOS (and we'd need to fix it anyway).
Instead, it's more likely that we have code somewhere that generates
paths dynamically using backslashes on Windows, and the correct fix is
to change that code to use forward slashes instead.
We have needed to suppress it in a bunch of places because GCC has kept
giving false positives depending on optimization settings. When I noticed
yet another false positive when I attempted to build the game with PGO
profiling data using CMake, it was the last straw.
Let's just suppress the warning globally and move on with our lives.
Follow up 'ceba081542a4'. It is nice to remove the previously
announced message when announces are being delivered very quickly, but
maybe movement feedback announces should be exempt of that. Before
this rev, Whenever an 'Enemy unit sighted' message was being ordered
coupled with a subsequent 'press $HOTKEY to keep moving', the 'Enemy
unit sighted' message was getting discarded.
src/actions/move.cpp: Movement feedback is important, do not remove
previous messaging when announcing.
src/display.cpp: Do not remove previously announced label when so
requested.
src/display.hpp: Add a `struct` device meant to pass optional
arguments to `void announce(const std::string&, const color_t&, ...)`
instead of primitive typed optional arguments (one, `int`, was being
in use, I would have needed to add a second one, `bool`, but when
trying to do that, the `bool` value would be received by the function
as the `int` argument when not providing an explicit value for the
`int` argument (see `src/actions/move.cpp`). Given C++11, for optional
arguments, does not (to the extent of my understanding) allow
specifying the argument name on the calling place, I was forced into
adding this struct in order to jail all primitive typed optional
arguments.
src/synced_commands.cpp: Adapt to new public API in `class display`.
Use the idiomatic combination.
Update reference to particular comment line of
'src/widgets/textbox.cpp' in comment with the current line where the
comment is now.
Remove `unsigned` as the type for `copypaste_modifier`, because it was
a little bit less future proof that way, it is better as an
`SDL_Keycode`, which at the moment is `Sint32`, which in turn is
`int32_t` ultimately. Reuse the constant for 'select all' so renaming
it to `modifier_key`.
Coverity has been complaining that a few uses of show_message do not have their return value checked.
Casting to void supresses these warning be documenting the value is intentionally not checked.
This closes
CID 1380185
CID 1380186
CID 1380258
This was a regression from 8d2ae80b32. Since quotes got stripped from cl arguments when they were parsed,
and since the utils::join call expected a space as a delimiter, the arguments would get put together incorrectly.
One possible fix would have been to wrap every argument in quotes, but that could potentially some issues for
certain non-quoted arguments. Instead, we just take the original command line output from the console.
For Campaigns, I needed to store the campaign name in the classification info.
For Eras, I repurposed the mp_era_addon_id key I added a year ago in d88f591eb5. It wasn't used anywhere
else, and having a better name for missing eras was the original reason to add it. I'm not sure why I
didn't think to use the name directly at the time; I do seem to have used addon_id for mod names too, but
that was changed in 5a55899b83 and again now (see below).
For Modifications, I added the relevant mod name to the server data. Why only this type of content
required a server change I'm not entirely sure. :/ This also finally properly fixes#1794.
Also contains a minor fixup of db8891fa3c (sign type mismatch warning fix).
For some reason, the use of the side-1 fallback in the to_unsigned() calls was making every
side get assigned the color red... Sadly, this means an saved games created in the past 12
hours or so have broken color data. Oh well.
Coverity has been complaining about using rand() as an insecure function. As we're using it, this function is not insecure; but is also not a very good RNG. We're using MT19937 in a system-independant manner. But some uses of rand() were never converted. This converts them.
This closes the following Coverity issues:
CID 1356297
CID 1356299
CID 1356303
CID 1356304
CID 1356306
CID 1356312
CID 1356314
CID 1380163
CID 1380173
CID 1380179
CID 1380191
CID 1380198
CID 1380201
CID 1380210
CID 1380214
CID 1380215
CID 1380219
CID 1380230
CID 1380241
These changes cover areas from PR #2101, excluding the removal of the numeric ID color ranges.
That can't be done yet (it breaks things).
This also excludes any changes to the connect_engine color handling. That needs to be refactored
separately. Despite the fact that it's done very similar to the new get_side_color_id function,
I need to deal with the fact that every side_engine member in the connect engine keeps a copy of
the default color options.
* Added a general-purpose function to extract color data from a config.
* Refactored the team class's general get-side's-color-data function so it always returns a color
ID instead of falling back on a number.
* Deployed this change for the leader image coloring in the save_index; said coloring is now always
done by ID.
* Save color data by ID in team_info instead of using the side number if no color was provided.
* Renamed get_side_color_index to get_side_color_id to better reflect its purpose.
This reverts commit 1b9c07eb40.
I'm reverting this (at least temporarily) since it seems mainline contains *numerous* paths with
backslashes. This change basically spams console with warnings just from mainline/core content,
in addition to having other negative side effects such as leader image generation failing when
populating a save_index file. Plus, if backslashes really broke things on Linux, I think we'd have
had a multitude of people complaining about half their images not showing up on that platform, which
(AFAIK) has not been the case.
Regression from commit f6c4f3d214.
The code divided by zero and the probability to stay unscathed ended up as
NaN, which triggered an assertion failure if the AI simulated one more
fight for either combatant.
* Remove dependencies on SDL2_net.lib (hasn't been required since at least 8b341411)
* Remove unnecessary backslashes introduced in dccd73d1
* Sort associated filter.
[ci skip]
Windows XP and later define DOS device names for several system devices
that will be handled as if they had directory entries everywhere. Their
names may not be used on the left side of a file name if a dot is
present, otherwise the read or write operation in progress (if
applicable) is redirected to the device in question, with unexpected
results (e.g. writing to CON writes to a console that may or may not be
attached, writing to COM1 will send data through the first enumerated
serial port, and so on).
Thus, we really don't want add-on authors to either intentionally or
accidentally use them on non-Windows platforms and cause Windows-based
clients to do unexpected things.
Emitting special messages for the UI in this case seems unnecessary and
it'll be a waste of space most of the time since these names should crop
up extremely rarely. Better just tell people what's up on a case-by-case
basis if they decide to post in the forums about it.
The option to play SP campaigns in MP had been locked since support was shaky. I'm not entirely sure
how good it is currently, but games at least seem startable. This will also allow us to get more bug
reports if issues do arise, too.
This was basically used to separate players from the general controller options. In the GUI1 dialog it
was unselectable. I never got around to implementing that in the GUI2 dialog, but regardless, it doesn't
look great in the menu so I'm removing it. Plus, since the dropdowns are GUI2, we could apply different
text formatting to denote players if we wanted.
* Got rid of custom color class member variable. It was no longer used except in the ctor, so it could
be demoted to a local value.
* Use color id instead of color index for coloring unknown unit image in MP Staging.
The tests haven't been run for a couple of months.
The test executable crashes on startup with the error message
Xlib: extension "RANDR" missing on display ":99.0".
After ten attempts, the test wrapper just gives up and returns success.
So, let's not even pretend that we have C++ unit tests running in Travis.
We just don't. Explicitly disabling the tests makes it more clear.
Turns out that this is enforced by C++ unit tests (which haven't run
successfully in Travis for a couple of months).
The tests started to fail in commit d864a89a15 when random factions
were set to always be the first in the list
(and therefore always initially selected).
Reverts a change in commit 2eacb4e1c3.
The comparison in this unit test compared an *attribute* to an empty
string, not a *string*. Furthermore, the entire point of the test was
to verify that an empty attribute doesn't compare equal to the empty
string. In its old form, the test was just wrong (and failing).
