previously in `undoable_action->undo(side_) ` the undo stack was not in sync with the relpay stack becasue the code called `undos_.pop_back();` before that and `resources::recorder->undo_cut` after that, this could confuse the code which sends replay commands to the other clients.
hitpoints from 42 to 48
movement from 9 to 7
claws from 5x4 to 6x4, now usable on offense
bite from 15x2 to 9x2 charge, now usable in defense
arcane resistance from 20% to 10%
price from 21 to 30
This reverts commit b3802f44ea.
Since commit 70df290 restores the Elvish Outrider to essentially its original stats, the 1.18 balance fix for this one campaign scenario is no longer useful.
Redesigns the Naga Guard, Shield Guard, and High Guard to make their shield bash attack less redundant.
Also adds the new Unwieldy and Guard specials, and deprecates the Absorb special.
This is way more readable and more semantically correct. Essentially, instead of truncating the current and last timestamps to seconds and checking if we were "in" a different second, actually check the duration between the current frame and our last lap point .
Since we're relying on free functions to parse and serialize time_points, it makes more sense to do likewise for durations rather than relying on a config_attribute_value member function. Leaves the assignment support for now.
Includes adjustments to client code to likewise use chrono types. I decided to keep using time_t
(which is just an alias for long_long) for serializing time points. This avoids compatibility issues,
since we keep the same resolution (seconds since Unix epoch), and unless we're going to "properly"
store time points in config, the time_t's unitless value is a good a representation as any.
The pre-processing for --max-fps was basically identical to what draw_manager::get_frame_length does.
This replaces the draw_delay preference with a new refresh_rate preference that more accurately describes
what is being set. video::current_refresh_rate will now take this preference into account, meaning the
build info report will correctly report player-set FPS limits.
The Limit FPS option in the prefs UI was also removed. When it was first introduced (cca79afe4b)
it specifically affected the map rendering code, not the rendering pipeline as a whole. With the 1.17
rendering refactor, this is no longer the case, and so its current usage as the lower bound for frametime
calculations did nothing (all it did was change the lower bound from 0 to -1 when enabled).
It might be worth adding a slider to the UI to dynamically set max fps, but that's a separate change.
Only two places actually made use of the only thing it was useful for (the current tick count),
the countdown clock and the music thinker. The former was simpler to do without, and though it
was slightly useful for the latter, the music thinker really needs to be rethought.
The only thing this could be useful for is providing a stable timestamp for every process call.
That wasn't how it was designed, however. ticks() would populate its value the first time it was
called. Even if (as I considered doing) you change it to register the tick when constructing the
pump_info object, it's still easier (and easier to read) to just call steady_clock::now directly
as needed.
* Functions that return time values now return proper std::chrono::duration units (milliseconds,
seconds, etc.). This removes the need to do manual unit conversions.
* Simple time-to-execute logging was replaced with `utils::optimer`.
* Most uses of `SDL_GetTicks()` have been replaced with `std::chrono::steady_clock`.
* Uses of events::pump_info::ticks() have been replaced with direct calls to steady_clock::now().
This made the countdown_clock code significantly simpler. As for the music_tinker, that needs
to be rethought wholesale.
In special_id/type without the _'active' suffix only the encoding of the special in the attack is checked, and therefore the specials encoded in the [abilities] tags are de facto excluded, except that I forgot this logic in [filter_special] and I have to fix my error before updating the wikia.
uses portraits in the character selection and single click selection on pictures instead of buttons
also adds a dark background to hint messages to make them easier to read
adds arrow markers in the beginning on the units
Addresses https://github.com/wesnoth/wesnoth/issues/9309
when used, the amlas in [unit_type] are replaced by list of amlas in [modify_unit_type],i cannot done add [advancement] without erase amla already present.
GUI2 still does its own handling with double clicks. This doesn't touch that. The default SDL handling is either 500ms (unchanged) or queried from the OS on Windows (an improvement). The click radius defaults to 32, which honestly seems like an acceptable adjustment.
This interface was extremely confusing. pum_info is designed to set `ticks_` only once. This can lead to a situation (exemplified by the music code) where if ticks() is called multiple times in a row, the subsequent times with a counter, that counter would never be incremented since the condition that tests them short circuits on the is-ticks-not-set check.
Also, giving ticks() multiple side effects was very confusing.
