From 32daa68bd11adbd7c963f335a860ba4da457aa84 Mon Sep 17 00:00:00 2001 From: Chris Beck Date: Sat, 12 Jul 2014 10:51:52 -0400 Subject: [PATCH] update changelogs --- RELEASE_NOTES | 7 +++++++ changelog | 6 ++++++ 2 files changed, 13 insertions(+) diff --git a/RELEASE_NOTES b/RELEASE_NOTES index adcfa3b13b98..3478de4a4e1b 100644 --- a/RELEASE_NOTES +++ b/RELEASE_NOTES @@ -38,6 +38,13 @@ Fixed bug that caused incorrect / missing minimap data to be displayed in the pr Note that you must refresh your save_index to get proper behavior, by deleting it from the userdata folder. [/section] +[section="Bugfixes for [filter_vision]"] +The [filter_vision] tag introduced in 1.11 series was discovered to have some bugs, it would behave with different logic depending on whether it was in a unit filter or a location filter. Neither of these implementations was actually quite right, and the simplest way to fix it was to make it work as originally intended. In 1.11.16 and future versions of wesnoth, [filter_vision] works like most other tags such as [has_unit], that is, +[list][*]When used in a unit filter, a [filter_vision] check succeeds if there is [b]any[/b] side with vision of the unit (no fog there and unit is not hiding from that side) which passes the side filter in [filter_vision], and fails otherwise. +[*] When used in a terrain_filter, a [filter_vision] check succeeds if there is [b]any[/b] side with vision of the location (no fog there, or if respect_fog=false, then no shroud there) which passes the side filter in [filter_vision], and fails otherwise. +[/section] + + [section="Example section 2"] Example contents 2. [/section] diff --git a/changelog b/changelog index e23c0146924f..c7db466d2ea3 100644 --- a/changelog +++ b/changelog @@ -110,6 +110,12 @@ Version 1.11.15+dev: start-of-scenario saves, but it seems to be a different issue.) * Fixed the SCATTER_UNITS macro so that it may no longer attempt to place units at the map borders. + * Fixed [filter_vision] bugs here: http://forums.wesnoth.org/viewtopic.php?f=21&t=40702 + [filter_vision] was found to be inconsistent depending on whether it appears in location + or unit filter. The simplest way to fix the logic was to give an implementation matching + the original intention. Now, a [filter_vision] check succeeds, for a unit or a location, + if there is *any* side matching the side filter has vision of that location / unit, and + fails otherwise. Version 1.11.15: * Graphics: