wesnoth/data/test/scenarios/put_to_recall_and_modify.cfg
2022-11-02 15:16:23 -05:00

91 lines
2.5 KiB
INI

#textdomain wesnoth-test
# This is almost the same as the modify_unit_which_recall_list test, except that
# creating Charlie on the map can leave an on-map x,y pair in Charlie's data,
# which needs to be handled within the WML API.
#####
# API(s) being tested: [put_to_recall_list], [modify_unit], [role][auto_recall]
##
# Actions:
# Create Charlie, belonging to side 1, on the map.
# Repose Charlie on the recall list.
# Assign Charlie to side 2.
# Recall Charlie next to his side's leader.
##
# Expected end state:
# Charlie is on the map next to side 2's leader.
#####
{GENERIC_UNIT_TEST "put_to_recall_and_modify" (
[event]
name = start
# Create a unit on the map, belonging to side 1.
[unit]
x,y=2,2
type=Orcish Grunt
side=1
id=Charlie
name=_"Charlie"
role=TestSubject
canrecruit=no
[/unit]
[put_to_recall_list]
id=Charlie
[/put_to_recall_list]
# Check Charlie has moved to the recall list. Using count=0 is equivalent to putting a
# [not] around the [have_unit] - using two different but equivalent syntaxes makes it
# easier to work out which of the two asserts failed.
{ASSERT (
[have_unit]
count=0
id=Charlie
search_recall_list=no
[/have_unit]
)}
[modify_unit]
side=2
[filter]
id=Charlie
[/filter]
[/modify_unit]
# Check that Charlie is still on the recall list, that modifying him
# hasn't moved him back to the map.
{ASSERT (
[not]
[have_unit]
id=Charlie
search_recall_list=no
[/have_unit]
[/not]
)}
[role]
role=TestSubject
reassign=no
[auto_recall][/auto_recall]
[/role]
# Check that Charlie has been recalled next to side 2's leader
#
# Currently [role][auto-recall] uses the recall list (not the side attribute)
# to determine where on the map to recall the unit; if this changes then this
# test could pass with a false positive.
{ASSERT (
[have_unit]
id=Charlie
[filter_location]
location_id=2
radius=1
[/filter_location]
[/have_unit]
)}
{SUCCEED}
[/event]
)}