URL:
  <http://gna.org/bugs/?19685>

                 Summary: Request for a [detect] ability
                 Project: Battle for Wesnoth
            Submitted by: the_other
            Submitted on: Tue 01 May 2012 10:13:30 AM GMT
                Category: Feature Request
                Severity: 1 - Wish
                Priority: 5 - Normal
              Item Group: WML
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: Any
        Operating System: Any

    _______________________________________________________

Details:

Following a forum discussion
[url](http://forums.wesnoth.org/viewtopic.php?f=21&t=36547&p=527349#p527339)[/url],
this is a request for the addition of a [detect] function within [abilities].
The purpose of this would be to allow units with this ability to locate hidden
units, without moving adjacent to them, while making them visible ONLY to the
player who controls the detecting unit.  This is a bit long, I'm hoping [
section ] tags will work properly here...

[section="An ideal solution"]An ability that can take [filter]s for the
location and condition of both the detecting unit, and the unit to be
detected, and a radius= key.  Example:

[detect]
id=example_detect
name= _ "Detection Example"
description= _ "During daylight, this unit can detect hidden units in forests
within a radius of 6 hexes around itself"
radius=6
[filter_self]
time_of_day=lawful
[/filter_self]
[filter_second]
terrain=aliases of all forest terrains
[/filter_second]
[/detect]

Ideally, the radius= key could also take a value of 'vision', setting it to
equal the unit's normal vision range, or be omitted or left blank (in which
case it would default to unlimited radius, covering the entire map)[/section]
I see that there could be an issue here if a unit has multiple or
multi-faceted [hides] abilities in effect at the same time (the example
ability above would reveal units with Ambush, even if they were also being
hidden by Nightstalk).  How and if this can be solved is dependent on how the
game engine processes [hides] abilities - one way to avoid it is by processing
in the following sequence:
[section="This information is also in the forum thread referenced above"]1. 
All units meeting filters for terrain-based [hides] abilities are flagged as
"invisible"
2.  All units currently flagged as "invisible" are checked to see if they
satisfy the filters in any [detect] ability.  If so, the "invisible" flag is
removed.
3.  Same as step 1, but for time-of-day-related [hides] abilities
4.  Repeat step 2
5.  Same as step 1 and 3, but for other types of filtering eg. status-based
[hides] abilities
6.  Repeat step 2.
...insert any other possible filtering types here...
7.  Flag as "invisible" all units with unfiltered [hides] abilities (ie,
constant invisibility)
8.  Repeat step 2.
9.  Any units that still have an "invisible" flag become hidden.
Thus, the problem of multiple [hides] abilities is solved (in the example case
above, the unit is hidden by Ambush, revealed, but then hidden AGAIN by
Nightstalk).  Hopefully that made sense...[/section]
If this is not possible or practical, a second option would be for the
[detect] ability to take keys for radius= and detected=, with the latter being
the ID of the specific [hides] ability which is countered (potentially a
comma-separated list, or a blank key which would default to "all forms of
[hides] ability"

Finally, I see that vision range is now being made separate from max_moves. 
In this case, perhaps detection_range could also be added within [unit_type],
describing the radius within which hidden units are automatically detected
(defaulting to 1 if omitted) - a far simpler solution from a
player/UMC-maker's perspective, if it is practical to implement.

Thanks!




    _______________________________________________________

Reply to this item at:

  <http://gna.org/bugs/?19685>

_______________________________________________
  Message sent via/by Gna!
  http://gna.org/


_______________________________________________
Wesnoth-bugs mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-bugs

Reply via email to