Undoing unit recruits currently ends in oos in most cases, because the random generator is called during unit creation for creating random names.
This is not impossible to fix, ofc we could just enable it for nameless units, but i'm not 100% sure wether units with no names call the random generator for random names or not. Also names normaly don't have any influence on the game (same for genders maybe?), so there is no reason not to be able to undo it from a players point of view. We also cannot just store the random state in undo_stack->add_recruit, because the unit creation happens before that
From cd8c83532b0d33a3a2e24d9af04dac0455a84625:
gui::slider* s = gui().find_slider("map-zoom-slider");
if (point_in_rect(event.x, event.y, s->location())) {
scrollx = 0; scrolly = 0;
}
s is not guaranteed to not be NULL. display::find_slider() WILL return
NULL if it can't find the requested widget. As it turns out, the editor
currently lacks a slider called "map-zoom-slider".
From commits 36b6b60beb507a1277de59691da051d4a2f75171 and
d04f6af930b18a740c7fccd0ee91d0e635f288e5 (paraphrasing):
map_location original_loc = resources::controller->get_mouse_handler_base().get_scroll_start();
.
.
.
if (point_in_rect(mousex, mousey,rect) && resources::controller->get_mouse_handler_base().scroll_started()) {
.
.
.
When in the game map editor, resources::controller is set to NULL since
it is only intended to refer to a play_controller object. But there's no
need to look specifically for a play_controller in this code or get the
current pointer to a controller_base subclass since the pointer we need
is actually none other than 'this', which is always non-NULL.
(get_mouse_handler_base() is a method of the same class the faulty
handle_scroll() method is, controller_base. There are no derived classes
of it other than play_controller and editor_controller, and there is
only supposed to be one such instantiated at a time, so the fix is
trivial.)
This prepends font::NULL_MARKUP to file_menu menu entries so that any
WML formatting characters at the start of filenames such as "#foo.map"
('#' -> red font format specifier) are ignored.
Now that we have combo box options in Preferences -> Advanced, we can
finally present the saved game compression options in a user-friendly
fashion instead of having two separate options with an unclear
relationship.
However, in order to achieve this I had to move far more code than I am
normally comfortable with:
* Moved the config_writer::compressor enum type to a separate header
file, serialization/compression.hpp, in order to make it available to
more units without pulling a bunch of heavy crap (such as the boost
iostreams headers) that's normally unneeded. The new type is
compression::format.
* Added a compression::format_extension() function to determine a file
extension string according to a compression type. This is needed more
often than one would think, see below.
* Changed all savegame-related classes to use the compression::format
type instead of a single boolean flag and bzip2_savegame_compression
queries. This is a code-heavy task by design.
* Changed all code scattered around deciding whether to use ".gz" or
".bz2" for a save extension to use compression::format_extension()
instead. This affects both saved game implementation and interface
code for some reason (read: poor design).
* Removed the bzip2_savegame_compression preferences option, reusing
the previous compress_saves option for this feature, turning it from
a boolean option to a string option ("none", "gzip", "bzip2",
defaults to "gzip" per advanced_preferences.cfg).
* preferences::compress_saves() became
preferences::save_compression_format().
* Without bzip2_savegame_compression, people who previously enabled
bzip2 compression will revert to gzip compression. This seems to be a
rare enough case to me to bother with providing backwards
compatibility with a feature that only existed for [1.11.0, 1.11.8).
* For preferences files from previous versions where compress_saves was
set to either "yes" or "no", there will be a conspicuous value in the
second column of the advanced preferences list, especially if they
are using a translation; it'll be either "yes" or "no" as an
untranslatable string. A value of "yes" is equivalent to "gzip", and
a value of "no" is equivalent to "none". Any other unrecognized value
is equivalent to "gzip". As soon as the user chooses a compression
format again, one of the three supported values ("none", "gzip", or
"bzip2") will be written to the compressed_saves attribute in the
preferences file.
All in all, a ridiculously messy commit that's not particularly feasible
to break down into separate pieces because all of the involved code is
very closely related to the overarching feature that's being
implemented in it.
Note that the save_index currently only uses gzip regardless of whether
bzip2 is the current compression format choice. This was the case even
before this commit, and I'm not sure it's worth it to change it given
the potential CPU usage and the fact that save_index tends to be broken
most of the time anyway.
name_short is used for the value labels entered into the main advanced
preferences listbox, which ideally shouldn't be stretched too much
sideways because GUI1 sucks. (Optional, used instead of name.)
description is entered as a second column value in the combo box items
list when available, and should be used as a short description of the
entry. (Optional, used in addition to name in the combo box popup view
only.)
The irony of turning off spellcheck and misspelling spellcheck is obvious.
This magic comment is apparently unnecessary, though, since it wasn't
working, yet the file was not failing the spellcheck.
Most of the other signposts elicit a remark when a unit steps on them, but
curiously not this one.
Not only do I give the discovering unit a line, I have Tallin speak as
well. This may give alert first-time NR players a clue that this corridor
is important.
Some may prefer that players continue stumbling about, and object.
Unfortunately, there's no NR maintainer or active lord of prose to resolve
any difference of opinion.
Many UMC projects have a macro for this function, but the name isn't
standardized (RECALLXY and RECALL_POS are also in use). However, regardless
of name, all these macros follow the "id x y" order, so for compatibility
I have kept that order. UMC authors started with a RECALL macro and added
coordinates, while the unit-generating macros have to organize a lot of
extra fields that are irrelevant to [recall].
Although we can now auto-recognize characters in the core NAMED_*UNIT macros,
campaigns may have their own recruit/recall macros. This comment will tell
wmllint which field contains the macro's id.
The basic format is 'wmllint: whofield <macro> <num>'. This commit sets up the
dictionary, the next commit will actually parse the macros. It will explain
more details about how to use this magic comment in wmllint's introduction.
Usage example:
[advanced_preference]
field=test_combo
name= _ "Combo test"
type=combo
default=option1
[option]
id=option1
name= _ "Option #1"
[/option]
[option]
id=option2
name= _ "Option #2"
[/option]
[option]
id=option3
name= _ "Option #3"
[/option]
[/advanced_preference]
NOTE:
Now that there are more than two types of advanced preferences entries,
a problem with the saving and restoring of the previous screen surface
contents with the three GUI1 widgets involved (the checkbox, the combo,
and the slider) has appeared, resulting in the advanced preferences
slider glitching into view under certain conditions. This is apparently
related to the widget hiding/unhiding order; for example,
hiding/unhiding the advanced preferences combobox after the slider and
its label results in the combobox glitching into view when switching the
advanced preferences list selection instead.
