Fixes the currently suspected root cause of #5108, but requires further testing
to confirm that it fixes that issue.
Closes#6501 (the question of how to test the mapgen filter).
(cherry picked from commit 30f50bac68)
The edge-case of calling evaluate_single within an unsynced event was
surprising, and I'm not sure it's correct. However, as we're about to
release the 1.16 branch I think it's better to include that as a test
that the API doesn't change during the stable branch.
Check that the scenario's next_scenario= exists, and display a warning
if it would lead to an "Unknown Scenario" error. This also checks any
[endlevel] tags in events.
The error message includes the id of the missing scenario, but is mainly
a recommendation to check the forums and report a bug in the campaign.
This version has a short, one-size-fits-all, text for the error message.
When processing [effect]apply_to=movement, if apply_to_vision is 'yes'
(which is the default) then the vision points will change by the same amount.
Previously, it sometimes affected vision and sometimes didn't; for most cases
where it makes a difference, I expect it to be a change from unanticipated
behavior to expected behavior.
Please refer to the new unit test added in this commit for more detailed docs;
that test is also a rough draft for the Wiki update needed when this merges.
The reason it sometimes affected vision was that the special value of -1 vision
points was interpreted as "use the value of the max movement points instead".
The special value of -1 is still supported and frequently used, and refactor that
is out of scope for this commit - it's easy to check when the code path changed
in this commit is used, however it's considerably more complex to find all
routes that create a unit with vision set to -1.
I'm expecting one add-on, Rebirth In Nature, to need a large update for this;
as well as a trivial change needed to the Add Creature Pack.
There are several mods that have their own handling for vision, recalculate the
values frequently, and are expected to continue working as before, as they'll
just overwrite any changes that the engine makes.
* Proper Flying Mod / Proper Vision Mod
* LotI
* Blessed Altar Mod
* Shards Era's `CALCULATE_WEAPONS_ONLY` macro
* Castle of Evil Spirit
Rebirth In Nature is an RPG-style campaign that expects the player's unit to
have vision separated from movement along with right-click menus that change
the character's movement, this will probably need `apply_to_vision=no` in
many places. OTOH, its `item_id=mobility` uses `apply_to=movement` followed by
`apply_to=vision` to implement in 1.14 what this change will make default
behavior in 1.16.
There are a few sharpshooter units which have vision better than their
movement. If given a buff which boosts their movement, this will give
them a buff to vision too; likely a change towards expected behavior.
* Archaic Era's Royal Ranger
* Ageless Era's Royal Ranger and Dwarvish Forest Sniper
* Eastern Europe at War's Yacht and Great Yacht
* Era of More Units's Lone Wolf
* Southernerns has several sharpshooters
* WWII Era has several sharpshooters
* War of Dominions has some guard towers with very low movement
Silver Age has abilities that modify vision based on time-of-day, but unlike
the Proper Flying Mod and LotI these are done by adding and removing objects
that add or subtract one vision point, these should be unaffected by this
change. Unrelated to that, it declares values for `[unit_type]vision=` even
when the value is the same as max moves - like the sharpshooters this means
that buffs to their movement wouldn't have buffed their vision but now do.
There are few units with vision less than movement. Generally these seem to be
missile weapons that are represented as units, and they probably won't meet any
apply_to=movement statements - even if a movement power-up is available, the
player would probably choose a different unit.
The Add Creature Pack has two creatures (the Cactose Elder and Carnivore Fatal
Plant) that have reduced vision, along with AMLAs that increase those units'
movement; these AMLAs will need to use `apply_to_vision=no`. These two
creatures are used in Castle of Evil Spirit, but they won't get enough
experience to get an AMLA there.
Fixes#3356.
The old version's [event]name=sighted had a {RETURN} statement in it,
which meant the test stopped on the first sighting. Most of the test
wasn't testing anything.
Add 'ability_id_active' attribute to filter
Until now, only the type of ability could be filtered with activity, and id only for unit who have ability, same if she's inactive.
Previously it calculated max movement, and then added the adjacent hexes. This
version should correctly handle:
* units with vp different to max mp
* units with vision costs different to movement costs
* jamming by enemy units
Draft changelog entry for this:
* `[store_reachable_locations]range=vision` now calculates vision, instead of using movement costs and max movement points (issue #4179)
These would also pass on 1.14, checking that movement does affect vision if and
only if vision hasn't been modified separately. The comments talk about an
[effect]also_apply_to_vision= attribute which hasn't been added yet, the aim of these
tests is to regression test that attribute when it is added.
The reported issue being that the FORCE_CHANCE_TO_HIT macro was able to force an increase in an attack's chance to hit, but no longer able to force a decrease.
I'm working on a bugfix for the [resistance_defaults] tag, for which the
unit test is going to be out-of-tree until we support some method of testing
it without affecting other tests. The version here is the part of that which
can be in-tree, because it doesn't change the core unit's stats.
The existing tag has a confusing name - it returns the chance to be hit rather
than the defense, for example 30 would be returned for a unit on 70% terrain.
The new tag returns a higher-is-better value.
This adds an additional `test_result` attribute to [endlevel], intended for use with the automated unit tests. This allows for the unit tests to differentiate a pass/fail result separately from scenario victory or defeat, which allows for more accurately determining the outcome of a test as well as addresses the potential, for example, for a scenario to be expect to pass because of the {SUCCEED} macro but instead passes because the scenario ended as a victory through some other method.
Additional unit tests which were the original motivation for this change are also added as part of this. They test, as much as possible, that events are executed at all, and are then also executed in the expected order.
All weapon specials can now be used in [abilities] to effect all weapons of the unit that pass the filter given in [filter_student][filter_weapon].
Explanation: filter_student filters on the unit that is under the effect of the ability (which is usually the unit itself, but not always if [affect_adjacent] is used). [filter_student][filter_weapon] filters on the active weapon of that unit (the student) in a specific combat.
[filter_weapon] is now supported in all filter_opponent, filter_student, filter_attacker, filter_defender
Note that constructs like [filter_student][or][filter_weapon] are not suported, [filter_weapon] must be a direct subtag of the four just mentioned tags.
[filter_second_weapon] is no longer used for abilities that come from weapon specials.
implements #4629 , #4475 , #4389
Co-authored-by: gfgtdf <daniel.gfgtdf@gmail.com>
This is part of working out whether a subset of the "fail" tests could be run
in one Wesnoth instance. To run a test that returns TEST_FAIL_BROKE_STRICT with
any other test would require a mechanism to reset lg::broke_strict()'s flag.
All tests that fail with an {ASSERT} will also set the lg::broke_strict() flag,
the tests with the new status are only those that would pass without the strict
flag.
In the SUF tests, change a test from fail-on-success to breaks-strict, rename
the formula tests and add some comments. The rename is because "fai" is
"Formula AI", an obsolete name for WFL.
Adding this is issue 2 of #4177, changing the behavior when [find_path]
is given a SLF which matches multiple hexes.
The map and tests here should be easy enough for manually editing them. It
duplicates some of the functionality of the existing characterize_pathfinding
tests, however those tests need their expected values to be calculated and
can't be changed by hand.
'''nearest_by''': {DevFeature1.15|2} possible values "movement_cost"
(default), "steps", "hexes". If the [destination] SLF matches multiple hexes,
the one that would need the least movement points to reach may not be the one
that's closest as measured by '''hexes''', or closest as measured by steps,
from the starting point.
Behavior in 1.14 depended on which hex was checked first.
Fixes#4253.
The schema's validation of ranges now rejects negative numbers, because the C++
code doesn't support them (both before and after this commit):
* utils::parse_range("-7") will return {0,0}, because std::stoi("") throws invalid_argument.
* src/map/location.cpp will parse it as -7, but that will never match an on-map coordinate
this test whether we succesfully prevent the exceution and parsing of
precompiled lua chunks, which can be used to break the lua sandbox.
This test does not cover all affected functions in particular not the ai
code that loads lua chunks.
(cherry-picked from commit 6b13a63bb0)
Several keys were either missing or misnamed in the formula view.
These have been changed to match the Lua and WML names for the keys.
This affects canrecruit, moves, and max_moves, as well as status.
In addition, a large number of keys were missing entirely from the formula view.
Most of these keys have now been added and can be accessed from formulas.
A few that have little use in filters (such as image_mods or profile) are still missing.
The Lua view missed a few keys that the formula view did provide.
Although these could in principle have been obtained by using the special __cfg key,
they have now been added to the Lua view anyway.
(With unit tests to back it up!)
- Fixes [for]step=0
- Fixes [for]start,stop=0,0
- Fixes [for]start,end,step=0,1,-1
- Probably fixes several other things too
