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.
cppcheck (via Codacy) reports the lowest-quality C++ is src/sever/game.hpp with 41 warnings.
There is no need to copy the const socket_ptr struct all over place to pass-by-value. It's const, so we can pass-by-reference and save time and memory.
Map Context:
* Removed get_team() in favor of non-const local team() overload.
* Removeded get_map() (both overloads) in favor of map() and a local non-const overload of the same.
* Made both overloads of map() return editor_map instead of gamemap (former inherits from the latter).
Context Manager:
* Removed team, unit, and label accessors that only fetched the same info from the current map_context.
Having more functions of this name only made things a lot more confusing.
Editor Controller:
* Change all instances of the three intermediate accessors mentioned above to data queries directly
from the current map context via editor_controller::get_current_map_context. The result is the same,
we just no longer have three levels of indirection.
I had probably added this before since I wanted a player joining a game to always choose
a leader, but that's rather mitigated by the fact that there's a cancel button.
This used to need to be a class of its own in order to store some info prior to switching
the context, but that's not the case anymore. Moved map_context_refresher::refresh into
context_manager. Also moved the set_window_title call into the function as well, since it
was called in all three places the context refresher was used.
This reverts commit 0f8e25f970ee9b8fba010c5ffa528aa6238d8900. For some damn reason
this was causing invalid access crashes for me on VS 2017 release builds, but no one
else could repro. Since I can implement a non-const accessor in the map_context class
anyway, I'm reverting.
