Need to sort out the problems with dispatching events to the HUD or the gamemap, respectively.
Disabling the HUD for now so it should be possible to interact with the map in case someone
wants to work on its rendering.
ee50171d13 broke some codes that relied on
unique save ids, that is in particular the statistic code and
scoped_recall_unit, so now these codes fallback to the side number if
the save id is empty.
Namely complete_redraw_event(), recalculate_minimap(), and redraw_minimap(). I had
been keeping the last around for reference (see f5ec886cb5) but I
figure it's not really worth it since this isn't the drawing method we'll want to
be using in the end anyway.
the wb recruit actions store temp units with fake ids and live longer
than a turn, so resetting the underlying id counter between turns might
result in dublicate id errors in wb recruit actions ( #1517 ), which
might lead to errors later.
With this it is of course possible to get erros when more than 2^31 (or
2^63 on a 64 bit wesnoth version.) fake units are generated during a
game, but that is less likely.
This was essentially only needed for the affects_side() helper. THAT'S IT. All this code just for
one single line... Anyway...
Utilized the display singleton's display_context getter instead. This also means fewer explicit
uses of resources::gameboard as the display_context object, meaning more compatibility with the
editor (not that that's relevant for most of the changed usecases, such as the AI, but it does
affect unit::get_abilities, which might be useful there in the future).
This also removes the display_context parameter from unit::invisible() since it was only passed to
unit::get_ability_bool().
unit::is_visible_to_team() also had its display_context parameter removed. It was used once as an
argument for invisible() and the other case was replaced with display::get_map().
This basically splits all the stuff in help/help_impl.*pp into multiple files by their
function, and refactors the entire workflow into a proper object-oriented interface in
modern C++.
There are still a features missing (such as hidden section parsing in the manager) that
I'll get back to.
Few incidental changes and fixes:
* Terrain topics now sorted alphabetically.
* Help text now small
* Fixed wrong toggle button id in browser. This is what was making it impossible to expand
any sections.
The GUI2 help browser is now back in working order, inasmuch as you can view all sections'
and topics' text (save units').
Report drawing was handled in draw_sidebar, so that function was also removed. The display
class won't be handling sidebar drawing anymore anyway.
Also removed display::invalidate_game_status and game_display::invalidate_unit which were
both used to set a flag dealing with report drawing.
This should finally get the display class close to map drawing only.
Design change from 075a9bac34.
After discussion with @celticminstrel, we decided it better for the controller to
own the UI object as well as the display object, instead of the display owning the UI.
I've added a pure virtual function declaration to controller_base to ensure all controllers
implement this.
This almost completely removes GUI1, save for the button widget (will remove once I get
all the Theme handling sorted out) and the editor's own GUI1 widgets.
This includes the GUI1 textbox, scrollbar, scrollarea, and menu widgets, as well as the
dialog_frame and dialog_manager classes. I've also removed floating_textbox. It was only
kept around for reference (it's unused as of the inclusion of the GUI2 command console).
gui::in_dialog has been replaced by GUI2's is_in_dialog directly now that we have no more
GUI1 dialogs.
\o/
I decided to go with a modular approach, where both in-game and editor UI dialogs inherit
from a single base class, a pointer of which is owned by the display class. That can be
used for common functionality that needs be shared by all in-game dialogs.
Right now the new UI is just static. It works with most stuff, but not key presses. Working
on that...
This removes all the code related to invalidating locations, any functions used to set, modify, or propagate
location invalidation, and several functions that no longer serve any purpose anymore since their only purpose
was to handle invalidated locations.
The old floating textbox was extremely entwined with the controller_base, play_controller, and menu_handler
classes. controller_base::have_keyboard_focus essentially controlled whether some events were executed based
on whether the floating textbox was open or not. Additionally, those events weren't even reached if a UI dialog
was open at all.
The new design features a singleton console class that can be called from anywhere, not just the game. I've also
decoupled the execution object from play_controller. The relevant functions in menu_handler are now passed to
the console as callbacks.
To work around map events such as clicking not being available if the console was open, I removed the exclusionary
is-in-dialog check from controller_base::handle_event and instead exit early out certain types of events using
controller_base::have_keyboard_focus. As mentioned in the accompanying comment, this isn't the best solution, but
it will do for now.
The new console also isn't fully feature-comparable with the old GUI1 one. The following are still missing:
* The checkbox, for use when sending messages.
* Tab completion.
* A crash occurs when existing the app if a game was exited with the console open.
I'm leaving the old floating_textbox code around for now for reference.
This ensures that throwing an exception through
game_events::manager::execute_on_events() won't corrupt the stack frame
counter and disable event handler cleanup forever.
I also added a safety check in case there are some kind of ephemeral
event handlers which run a nested game loop and never return. Saving in
such a state wouldn't be safe.
Now when play controller can outlive AI manager, it needs to register
itself as an observer when the AI manager is recreated.
While I was working with this code, I also moved the existing
registration from playsingle_controller to play_controller (for
consistency) and stopped using the singleton pointer to access the
manager.
Thanks to @gfgtdf for spotting 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*
I had re-added it in a limited context in eaea9be117 since I needed it to fix
(IIRC) a crash in the editor when adding units, since the editor didn't have a game_board.
However, looking at the code again, I realized that the display class (base of editor_display)
holds a pointer to a display_context object. map_context inherits from display_context, and
the editor sets the editor_display's display_context to the current map_context. Therefor, I
could just access the units needed via display::get_units, instead of needing a global pointer.
This is consistent with the use of display::get_singleton() (in fact, it's the same
pointer). It also makes the code more readable, and means we get to further clean up
the resources set.
Fixes#2372.
It turned out that the AI kept dangling references to the old Lua state,
and crashed while destroying AI contexts for destroyed sides.
The best way to avoid it is to ensure that game_state, which already owns
the Lua state, also owns the AI. That way, the AI will be destroyed before
the Lua state and a dangling reference can't stay.
After testing, it seems these calls to raise_draw_event and display/game_display::draw()
were unnecessary - or at least, became unnecessary at some point. One or two are definitely
still needed, but removing these doesn't seem to cause anything to to glitch out. Likely
explanation is anything that needs updating just gets updated either immediately or on the
next play_slice loop.
* Dropped unused CVideo class member references.
* Replaced the lone usecase of the CVideo member in loadgame with the singleton and removed said member.
* Removed CVideo references from a bunch of addon management functions.
* Cleaned up a *lot* of now-unnecessary forward CVideo declarations.
Essentially, we had CVideo arguments being passed down this chain:
- game_launcher
- free-standing MP initialization functions
- campaign_controller
- playsingle_controller/playmp_controller
- play_controller
- game_display
- display
And likewise down through
- game_launcher
- editor_controller
- editor_display
- display
With only a minimal number of actual calls along the way. :| There were maybe... two remaining?
This removes the CVideo arguments and class members from both chains (except of course, game_launcher.
That's where the "real" CVideo object lives).
The display class now initializes its CVideo reference from the singleton, which is also used in the
very few other places it's needed. I also replaced a check for a null video ptr in show_tooltip()
with a faked() check (see src/tooltips.cpp). That seems to make more sense, since CVideo is never
null now.
I had left the former alone in the above commit since I thought it might be worth keeping for the
faked() call, but that's not really a great reason.
As for the latter, I didn't realize the CVideo argument wasn't really even needed. I didn't even
need to replace it with a get_singleton() call since the resolution list is updated by set_resolution_list
before it's used.
This also removes a bunch of unnecessary CVideo arguments from various savegame functions that
emerged as I cleaned up the unused parameters. savegame::save_game did take a CVideo pointer
that did look like it was intended to be a sort of do-show-dialog flag, but since that parameter
was never passed as null, I removed it.
This a two part commit. First:
----------------------------------------------------------------------------------------------------
Added and deployed two new helper macros for the standard implementations of the static execute
and display functions. I also made use of a variadic template in order greatly simplify code
maintenance. Now, even if the dialog's ctor parameters change, no one has to worry about updating
the associated execute/display functions (though of course, this only applies if the helper macros
are used). \o/
I did not deploy the macro in cases where there were multiple overloads or the functions did more
than just show their dialogs. I might add an additional __VA_ARGS_ parameter to the macros later.
Do note for the end_credits dialog I moved the default empty-string parameter from the display
function to the ctor.
Second:
----------------------------------------------------------------------------------------------------
Another change is that modal_dialog::show and modeless_dialog::show no longer take CVideo arguments.
Since the video argument couldn't be included in the parameter pack (maintaining the argument would
have meant making it the first one, which would be just as much work), and using CVideo::get_singleton
in the macros would require adding video.hpp includes in a whole bunch of files, I simply removed the
argument. I had been intending to do this for a while anyway.
This therefor also removes the CVideo argument from:
* All dialog display/execute functions.
* modal_dialog::show
* modal_dialog::build_window
* modeless_dialog::show
* modeless_dialog::build_window
* wml_exception::show
* gui2::show_message
* gui2::show_error_message
* gui2::show_transient_message
* gui2::show_transient_error_message
* gui2::show_wml_message
* gui2::build
* gui2:🪟:window
* gui2::dialogs::tip::show
* Various GUI2-related Lua functions. The video_dispatch helper was also removed.
* Any functions that took a CVideo argument for the sole purpose of passing it to one of the above.
Ya know, all these damn CVideo arguments didn't actually do anything, besides an occasional check to
CVideo::faked. At the end of the pipeline, they just got assigned to the video_ member of gui2::window.
Huge code bloat for nothing.
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.
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
