Sort of.
The only things that are converted here are the version headings and the
category sub-headings, up to and including version 1.1.9. Versions older
than that have mixed root items and categories, and converting those to
Markdown that renders correctly on GitHub without mixing up extraneous
root items with the categories' own entries requires some non-trivial
hand-fixing that I'm not going to do (at least not right now).
[ci skip]
[ci skip]
Only the 1.13 section was touched. One line was merged in order to have it function properly
as a header without half its text being split onto a new line.
similar to the extra options which Firefox has
with an right click one can launch the editor now
one could as well add an "cheating mode" option for -d
Many distributions use modified desktop files, and add a 2nd
to launch the map editor. I think that's a better idea, because
it's less hidden than this feature. However, I think one doesn't
out-rule the other.
The translations are taken from downstream's desktop files for
the map editor - unfortunately they aren't complete
[ci skip]
In multiplayer mode, the LoW campaign has multiple start points, and some
persistent storage that stores the characters at the end of a chapter, so that
a new game starting from the next chapter starts with those stats.
The data for chapter 2 wasn't saved, because the campaign tried to create it in
a cutscene scenario that doesn't have the expected sides.
This will allow direct use of the window pointer without binding in hundreds of different
callbacks just because we want to use it for, say, find_widget.
This is just the base change. I still might change my mind as to this method, and I have
yet to undertake any refactoring around this.
modal_dialog::get_window and modeless_dialog::get_window remain.
The doc comment indicated this should be removed once dialog_callback was refactored out,
which has now been done.
This function just a wrapper for window::dialog(), which I left. That makes sense, since
windows and dialogs are closely related. If one *really* still needs to get the dialog in
which a widget is placed, they can still use widget.get_window().dialog().
dialog_callback was designed to be passed where a void(widget&) function was expected.
It took the widget parameter, then found its dialog and window, and called the given
callback on that dialog object with the window as a parameter. I had left a few remaining
usecases for convenience, but it's not needed anymore.
* Faction Select: window parameter can be directly bound with std::ref
* Unit Create: window parameter not even needed, was only there to satisfy dialog_callback's
signature.
* MP Create Game: window parameter needed, but I changed it to an in-function variable using
modal_dialog::get_window. There's no window object to directly bind in the constructor, and
using the actual callback widget's own get_window method just seems redundant.
previously the unit ctor could invoke arbitrary umc lua code, for
example via advance_to -> add_modification ->
resources::lua_kernel->apply_effect and during that call the unit was
not owned by a unit_ptr, so the code could not use unit_ptr objects at
several places because the unit might not be owned by a unit_ptr object.
this changes it so that the during events the attack_type references its
context units always by location, like it was done in 1.12, considering
the soon 1.14 release i think this is the best fix
The problem with the old implementation basically was that if a wml
script replaced the unit in a attack events the
attack_type::self_/other_ would point to an outdated unit during the
next handler of the same event.
