man 5 sysuses.d recommends:
It is strongly recommended to pick user and group names that are unlikely to clash with normal users created by the administrator.
A good scheme to guarantee this is by prefixing all system and group names with the underscore, and avoiding too generic names.
Looks better without underscore. wesnoth is unique enough to not clash, most daemons on Arch don't have an underscore either.
The group is created implicitely when the user is created.
Avoids two to four function calls on each SDL_MouseWheelEvent.
Also update code comment and changelog entry based on @vgaming's report
of issue #3362 being fixed.
Slightly improves commit ab4001d. Tested again with SDL 2.0.14 and
2.28.5.
selected schedule will write to utils/schedule.cfg on scenario save
HOTKEY_EDITOR_CUSTOM_TODS is disabled unless user loads scenario
custom_tod:Preview button and associated callback added.
editor:translatable attributes now written with leading underscore
editor:support for multiple custom time schedules
The required number is already in a WML variable, herbs_needed. However, the
string is used in an `[objective]` tag, which means we're not necessarily in
an ActionWML block when it's shown, and thus can't use the Lua API to look up
plural strings. Instead, brute force it by making 6 separate strings.
Also, use the mainline `ALTERNATIVE_OBJECTIVE_CAPTION` macro instead
of a campaign-specific translatable string.
* S04b start-of-scenario saves since 1.17.21 will be broken
* S03 mid-scenario saves since 1.17.21 will show a warning,
and players will only be able to go west
* Saves from earlier versions are already broken by the campaign rewrite
The changed function is only called when using --preprocess, but calls itself
recursively. This moves the filename filter to be around the recursive call,
thus skipping the check for the top-level call.
If a unit type has male and female versions, then two images of the unit are
displayed at the top-left of the help page. However, it did this even if the
two images were the same, which made the duplication look like a bug.
The Naga Fighter is one of the affected unit types.
At the suggestion of @stevecotton, I propose a special 'replacement_type' and 'alternative_type' attribute capable of modifying the type of attack used when the conditions are met.
Also make Holy water combine arcane damage with native type of weapon
Like holy water imbued ordinary weapon, it's seem logic what arcane damage dominant what if more efficient what original type(water can't altered pierce or blading of spear or sword)
With this it puts the player back to the title screen after showing
an error dialog, so it's not much better, but at least it's not a
crash.
Fixes issue 7164. We weren't able to work out what caused the file corruption
reported, but I believe it's a race condition about saving while the AI is
recruiting. The file in the bug report has a `[snapshot]` tag with
`init_side_done=yes` but without a `playing_team` attribute, which must be the
result of `game_state::write()` when not in the `PLAY` phase. Loading such a
file causes `game_state::start_event_fired_ == false`, and triggers
`play_controller::start_game` to call `replay::add_start_if_not_there_yet`.
The i18n'd string is reused from `game_launcher.cpp`.
using overwrite_specials alone means that we have only two possibilities, either one_side is chosen and in this case if the ability used as a weapon carrying the attribute is applied to the unit (apply_to=self), the other abilities are the same type applied also to 'self' not carrying the attribute will be overwritten, but those of the opponent with apply_to=opponent will be kept in the list; or else both_sides is chosen and all abilities of the same type that do not carry the attribute will be overwritten. To be able to use the attribute in abilities like [damage] for example, it is necessary to be able to be even more selective as for a 'charge' type leadership with multiply=2.5 but which must not be combined with the classic charge and without overwriting the aute [damage] as backstab, [overwrite_filter] to only match damage with apply_to=both and active_on=offense is then interesting.
adding priority allows you to select that it ability can use its overwrite_specials attribute while the others can be overwritten in the same way as an ability without the attribute. Finally, this system makes it unnecessary to limit the use of the attribute to abilities used as weapons but also to special weapons.
give abilities support of halo or overlay so that the unit benefits from a second halo or overlay when conditions are matched
One of the things that bothers me is the permanent character of the halos of the Mage of Light and other units with the "illuminates" ability, which forces them to program only a permanent illumination applied only to the possessor of the ability.
Adding the halo attribute to ability does not change anything about the behavior of the unit, but can be used in several cases:
1 allowing the use of ""illuminates" whose activity would be variable, in this case encoding the halo in [illuminates] ability and not in the unit_type allows to modulate the appearance of the halo under the same conditions
2. Applying illumination to adjacent units, I know it's pretty cheesy but a set developer might consider it easier if the hlo display follows the same logic.
3 The halo used to illustrate the possession in the unit of a special weapon used as leadership, the halo would be used to raise the possessor of the ability.
for overlay, same logic for illustrate possession of a special weapon used as leadership, or influence on student
with the "halo_image" attribute, it is now possible to give Sun Sylph units an illumination ability with an activity depending on the incarnate sun attack instead of giving the ability and the halo via obect and therefore allowing the player to have access to the description of the ability even when it is inactive.
Switching to a different item cleared the data, but didn't clear the
cache of where the page breaks are located. The subsequent call to
`get_data_paged(int which_page)` has a bounds check for the page number,
so it's sufficient to just clear the page breaks, which is already ok
as it resets the object to the same state as a newly-created instance.
Forward-ported but currently untestable in master, as the page-selection
buttons are only shown when there's a large amount of text, which triggers
the known regression (the credits-crash bug).
(cherry picked from commit 7cb5f09bcf)
The basis for this rework is lowering the extremes in acrance resistances between units and factions. That allows for more free usage of arcane damage and helps with balance of games in which high levels are way more frequent than in standard default 1v1 or 2v2.
Having these in canon felt like a plot hole in other campaigns. If an
apprentice mage could make these amulets circa 350 YW then every village and
border-fort should have them, but Wesnoth's storylines work better if a
messenger on horseback is the usual method of long-distance communication. For
example, TSG is about a commander sent to discipline a lazy outpost, only to
find that they should have brought reinforcements. When it's the enemy trying
to communicate, DM S21 and UtBS S08 both involve stopping the messengers.
This changes the intro to have a beacons for communicating with the trade
caravans, I'm leaving it ambiguous whether it's a smoke signal or a fire
signal. Fire beacons might make more sense if the village sees the caravan's
campfires at night and, in normal usage, light the beacon to trade.
While this adds beacons to canon, they're an ancient technology with a limited
range and very limited bandwidth. There are easy plot reasons not to set
beacons up, such as the costs of having people watch for and maintain them,
there are easy plot reasons why they don't work on a given day, such as
weather, and there are easy plot reasons for attempted communication to be
ignored by assuming that it's a fire for a different purpose.
Previously suggested in https://r.wesnoth.org/p669889 .
Adds support for using these in the weapons and ability filters:
* "-1", which was previously treated as an parse error (no number before the separator).
* "-3--1"
* "-infinity" as the lower number in the range, provided a different upper number is given.
This treats "-infinity" (with no other number), "-infinity--infinity",
"infinity" (with no other number) and "infinity-infinity" as errors. It seems
unlikely that someone would intend to use a filter that can't match any
reasonable number.
The range "-infinity-infinity" will be parsed successfully. I don't see a use
case for that, but nor do I see a reason to add extra C++ to reject it.
However, it's not added to the schema, as I think it's good for the schema to
give a warning when someone creates a filter which will accept every value
(including accepting the default, so "-infinity-infinity" accepts the unset
value too).
Includes new unit tests for the C++ and the Lua stringx.parse_range functions.
The next commit adds more WML tests, but is kept separate to credit the author.
This started as a change to move common filter functions from unit.cpp to
somewhere that they could be reused for other config-based filters. In the
process a missing feature was found and added, the move is still included in a
single Git commit because the move was required in order to make these
functions accessible to the Boost unit tests.
Two CodeBlocks project files additionally get src/utils/any.hpp added,
which was in one of them but missing from the other two. I noticed because
these are alphabetically at the start of the src/utils file list.
Thanks to @CelticMinstrel for the review comments and Xcode project updates.
* DiD S3: Resolved Darken Volk speaking from the darkness at the end of the scenario (resolves#7758)
* Restore victory event changes for Darken Volk.
* Correct indentation.
This is a complement to #7416 where it replaces opening the replay's download URL in a browser with directly downloading it into the player's save folder.
Turning GLIBCXX_ASSERTIONS adds some bounds checks, such as checking
in std::string::operator[]. It's a subset of the checks that GLIBCXX_DEBUG
adds, but has the advantage that it doesn't require a rebuild of the Boost
libraries.
None of the CI builds enable these assertions, as they slow down the code
which makes the unit tests time out.
If the northmost hexes of the map are visible, put the text on the bottom; if
the southmost are visible, put it on the top. Also, make the text smaller if
it's very wide.
It used to be fixed to the bottom of the screen, but this meant that it always
obscured the southmost hexes of the map, and the only way to avoid that is to
scroll east/west, or to add an extra row on the south. Similarly, having it at
the very top obscures the northmost hexes.
Moving it to any fixed location that isn't the edge of the screen makes it
possible to edit all the hexes, but also makes it more annoying when working
elsewhere on the map; that trade-off was rejected in review.
For very small maps, it will be at the bottom of the screen in the border
outside the map area. For any screen resolution there will be a specific
map-height that still has the old issue, but that's an improvement on it
happening for every map size.
Cherry-pick of 29d86d2c36.
The previous bugfix fixed a crash when loading savegames with units whose
abilities accessed the map while the display_context was still being
constructed, however it reintroduced a bug in the scenario editor. Using the
unit tool always crashed when adding any unit.
This commit uses 4d1fc268b1's code path whenever possible, however it falls
back to 6a21fdc675's code path when 4d1fc268b1 would assert. In practise one
path is used in game and the other is used in the scenario editor, but doing
the logic in this way ensures that any edge cases are going to affect the
scenario editor rather than the game itself.
Cherry picked from commit 1485cfd625,
with conflicts because code from attack_type::weapon_specials() has
moved to attack_type::weapon_specials_impl_adj().
Because of the move to hardware rendering in commit
afd6baa7cf, some relevant info
was lost that was previously used to limit bar height in
particular.
This patch re-adds a dimension check and additionally ensures
that the bar width doesn't exceed the tile size either.
Fixes#7171.
These orbs no longer look the same as the player's own orbs, so they
won't cause confusion in multiplayer.
The relevant part of the advanced preference now shows:
```
[ ] - Show ally orb
[ ] - During ally’s turn, use a two-color orb to show movement
Radio buttons for colors: ( ) ( ) ( ) ( ) ( ) ( ) ( )
```
That offers these choices:
* Don't show ally orbs at all
* Always use the one-color (with ally color, not status)
* Use the two-color when that ally is playing, single color at other times
* Use the two-color when that ally is playing, no orb at other times
Rename some `allied_orb` functions to be `ally_orb`. This makes them consistent
with both the names of the corresponding `enemy_orb` functions and the WML
attribute that's used in the preferences file.
This probably doesn't need a change to the in-game help, at least for the en_US
version of the documentation. The current text in data/core/help.cfg is:
* Blue for allied units, except during that ally's own turn.
* During the ally's own turn, their units will be shown with the colors showing
whether the units can still move and attack; however their moves, and the
corresponding orb changes, are delayed as explained in "Shroud and Fog of War'.
Add some spacing to make it clearer what is grouped with what, move the
disengage orb's setting to be part of the partial orb's group, and add
a tooltip for it.
This dialog uses checkbox labels as section headers to indicate what the rows
of colors refer to. This commit doesn't change that, but it makes the grouping
clearer. Actual section headers would take additional space and probably not
look any better.
The island gives the player two fronts to progress on, and it's early enough
to give the player time to prepare for the SoE. Hint to them about improving
their recall list.
When trying to add that hint as a single-line change to the dialogue, I
reviewed the existing text and felt it didn't flow well. Reading the feedback
thread, Delfador should have more emotion about finding his childhood home
overrun; however I've gone for practical thoughts first.
The hint isn't #ifdef to only appear on easy, because the text wouldn't flow
without it - take that line out and it goes from "there are more orcs than I
thought" to "we must fight these orcs, who aren't the ones at the SoE". Also,
players who are already doing XP management can feel knowledgeable when they
see it.
Partially reverts 6a21fdc675Fixes#5643Fixes#7238
There's a bunch of global things that can be accessed either via global
pointers in the `resource` namespace, or via `display::get_singleton()`. The
singleton and these global pointers are set up in `play_controller::init`,
however there's a section where things are available via the global pointers
but the `display` singleton doesn't exist yet. During that time, checking
whether an ability is active can crash the game.
Removing the global pointers is a good goal, but detouring through a GUI class
to access the data causes its own problems.
The "has already been confirmed valid by both callers" comment is replaced with
an assert, because there's currently at least three callers.
