Turns out that it's still crashing on startup in Travis,
but no longer giving the old error message
Xlib: extension "RANDR" missing on display ":99.0".
I also removed the old line that ran test_executor.sh only if WML tests had
failed. That made no sense.
Regression from commit f2b31ba082e1ff47443120469e06b89318f37284.
The calls to get_fake_display() must not be removed. They are essential to
change the size of the fake screen. Fortunately we have a unit test to
check that constructing GUI2 windows doesn't succeed if the screen is way
too small.
LTO for Windows is disabled for now, as TDM-GCC does not work well with it.
LTO for Travis is also disabled, due to the extra time linking with LTO takes.
[ci skip]
* Expanded the text to explain how to read '5×4' and what it means
* Changed the wording slightly to emphasize the order of damage times attacks
* Added a message explaining the format of the tutorial
* Separated some long messages into multiple messages instead
* Removed some unnecessary wording to keep things simpler
* Changed some spelled numbers to regular numerals when referring to game currencies (such as gold and income)
* Minor changes to grammar
Had forgotten to call prefrences::set_options. Instead of adding an extra call in the
SP Options Manager, I just moved the call to configure_engine::set_options, which is
called by both SP and MP codepaths.
[ci skip]
Previously, the scenario only ended if you triggered the sighted Hamel event with Tallin.
If you triggered it with any other unit, you wouldn't progress since you can't fire a
sighted event on a unit already visible.
I've changed the condition to move within five hexes of Hamel with Tallin. Still possible
this might result in an unwinnable scenario, but that's much less likely than with what
was there before.
The problem was that the code copied the entire list of unit types every
time Lua moved to the next unit type. Fixed by taking a reference to it
instead.
Thanks to @ilyapopov for identifying the problem.
The only function that display meaningfully implemented was get_disp_context. It did implement
get_tod_man, but only meaningfully in its two derived classes (it returned the result of
resources::tod_manager in display). Additionally, the long-ass comment in the header stated the
display class should *not* inherit from filter_context. Do note that get_disp_context was retained
as a display member function.
Upon further investigation, I found that there were only two places where the display class was
passed to unit_filter. All others passed resources::filter_con. The editor_display class was also
assigned to resources::filter_con in editor::context_manager. So, I removed the second filter_context
argument from unit_filter and initialized it from resources::filter_con in all cases.
unit_filter only used the filter_context to get its display_context and the unit_map within anyway.
When using display::get_disp_context in-game, that would return a game_board object. Using
resources::filter_con in the same context would return the game_state object that owned the
aforementioned game_board, and calling get_disp_context on that game_state would return the board
as well. So we end up in the same place.
To be complete, I also made editor::context_manager inherit from filter_context. It makes much more
sense, since it can nicely implement 2/4 of the fc functions. It also ensures resources::filter_con
is valid in the editor, in case it's needed. I'm not 100% sure it is, but since it was assigned
before (to editor_display), it's very likely.
Another side effect of the above is that get_tod_man is now implemented in a more apropos class
in the editor. Essentially, editor_display (where it was implemented before by reaching into the
context_manager) holds an editor_controller which holds a context_manager (where it's now implemented).
It wasn't even really needed in editor_display and was only called once.
Similarly, get_tod_man has been removed from game_display. Again, it was only present to "properly"
implement the function in display, which only existed because display inherited from filter_context.
And get_tod_man wasn't even needed in display, game_display, or editor_display (save for the one
aforementioned call)!!! AND in game_display, it simply dereferenced a pointer to the *actual* ToD
manager in the game_state class, WHICH IN AND OF ITSELF INHERITS FROM FILTER_CONTEXT!!!
I have removed the tod_manager pointer in game_display and replaced its use with resources::tod_manager,
which in the context of the game (where game_display) would be use, point to the same thing the class
pointer did. I suppose I could have left it, since I'm trying to remove/improve the use of the
resources pointers, but I felt it better to decouple the two classes (game_display and game_state)
slightly, especially since its main purpose for existing (overriding display::get_tod_man) no longer
exists.
Finally, some of the instances where a unit_filter object is created had to be changed to use brace
initialization or else the build failed. @celticminstrel tells me this might be because of some "most
vexing parse" issue.
Some formatting and virtual/override specifiers were also applied/added.
*huffs*
Also did some formatting cleanup in game_board. Didn't really care to touch the others.
Removed virtual specifier from non-const game_board::teams. It didn't override anything
in the base class (display_context, which has the const version) and nothing inherits
from game_board to override it (the non-const version) later.
cppcheck (via Codacy) notes that it's not clear that the iterator (j) cannot exceed end() because most don't expect pointer math.
Rewrote to make it more clear what is going on.
cppcheck (via Codacy) had a problem with the form `T & T` so used `auto & T`
This is probably a bug in cppcheck but reported to Codacy in case it's their fault since the message form was for && and this was just &.
cppcheck (via Codacy) pointed out that a variable was initialized, then reassigned, before the initialed value was used.
Moved the variable declaration to the point the actually-used value was assigned.
cppcheck (via Codacy) rightly noted that the construct ((!!w ^ !!h)) was confusing.
Rearrange the code a bit, note some things must be true without testing them, and we can eliminate two variables, make the code faster than the "cute optimization" and make it FAR easier to read.
