This additionally:
* Makes all copyright notices identical aside from the starting year for Wesnoth-specific source files. Files not included: mariadbpp, lua, spirit po, xbrz, and bcrypt (crypt_blowfish).
* Removes all attribution from the files, since the vast majority of them are outdated or seemingly just outright incorrect. For example, I would guess that Dave is no longer the sole author of the majority of Wesnoth's current code.
Keep in mind ter_data_cache is simply a shared_ptr, and in all call locations it was grabbed from game_config_manager::terrain_types().
1. campaign_controller took and kept a member, which was passed to either...
2. playsingle_controller or playmp_controller, which passed it to their parent class...
3. play_controller, which kept a member to initialize...
4. game_state, which passed it on to...
5. game_board, which passed it on to...
6. gamemap, where it was *finally* actually needed.
This entire chain has been replaced with a single call to game_config_manager::terrain_types() in the game_board constructor.
gamemap retains its ctor parameter since editor_map passes in its own object.
The ter_data_cache alias has also been removed. It was just confusing.
wesnoth.create_side() can create a side while the scenario
is running, this is especially useful for [modification]s
that can not define sides by default.
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*
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.
Turns out I mistook @celticminstrel's opinion that we should use include guards over pragma (737916e).
Since all major compilers support `#pragma once`, there's no reason not to use it.
For future mergability reasons, this excludes src/spirit_po and src/xBRZ. It also excludes src/boost-patched.
This constitutes drop-in replacements for:
* boost::shared_ptr
* boost::scoped_ptr
* boost::weak_ptr
* boost::enable_shared_from_this
* boost::static_pointer_cast
* boost::dynamic_pointer_cast
This excludes boost::intrusive_ptr, except for stray includes. Refactoring that is more complicated.
This reverts commit c5e31e83f171dee025b24cba662dd3c21faff684.
This reverts commit 8447ebbb88c480301624a33dd1789a533dd0150e.
[event] in [unit_type] was broken during a refactor of the gamestate
initilisation that also involved the commits above. The commits above
didn't directly cause this bug but reverting them makes fixing this bug
much easier.
We fix the bug by initilizing the game_events manager before creating the
units.
It turned out that it isn't really possible to create the gamestate
without access to te gamestate from everywhere (resourcces::) the main
problem were the [effect] filters when creating units.
instead of calling constructor and init you now only have to call the
constructor.
In order to make this work this commit removes the uses of
resources::gameboard/units during team construction. while doing that i
moved the unit_creator class to a new file.
This commit also removes the ticks parameter from game_startes
constructor and replaces it with a ticks() function in play_controller,
other classes were also changed to use the play_controller::ticks()
function.
Allows to add 'unsynced' wml menu hotkeys which are not sended to other
players and are also clickable off-turn.
This can for example used for help menus and similar.
- eliminate the "gamestate::init returns a whiteboard" hack
- store all resources used in game_events in a shared_ptr for easy
access
- add a bind function for binding the gamestate to play_controller
assets
- eliminate obsoleted functions
This fixes up commit fbcfa99c811c91538588e783dfc2d97406ab84ee
the whiteboard needs for resources::teams.size() to have the
correct value, which only occurs after teambuilder phase, in
gamestate init.
this commit is an easy way to fix but it is pretty ugly, it will
be refactored soon.
After this commit,
- almost all data which is part of the game in the sense of being
synchronized / saved is in the game_state class
- still missing is the code / data related to determining whose
turn is next
- the game state needs to be bound to a play_controller, via its
init function. This is needed so that lua / game_events manager
callbacks can be evaluated, but future refactor should make it
unnecessary
- bug # 23071 should be fixed
TODO:
- allow the game state to manage whose turn it is, leave only UI
details in play_controller
- expose the lua kernel via the filter_context interface, and
make filters use it instead of resources
- make a proper copy ctor for game state, and improve encapsulation
