Add [object] to units on the recall list. (GNA #4450)

[wesnoth-bugs]

Original submission by anonymous on 2005-09-29

There are three related issues here.

Currently the [object] code in game_events.cpp appears to make the

assumption that the object action is triggered by a moveto event

but doesn't actually check to make sure that is the case.

Currently if no filter is supplied the code tries to apply to

the unit located at the moveto event. This is made use of in a

couple places in the standard campaigns. This isn't documented

and may or may not be desired. An alternative meaning would be to

apply the object action to the first unit found in the unit list

as some other actions do.

The last is really a feature request but it probably isn't too

hard to do.

The object action doesn't apply the filter to units on the recall

list as some other actions do. This makes sense if it really only

applies to moveto events. But giving objects to units as a way to

manipulate their stats is a nice tool to have and it seems the

event and not searching the recall list limitations could be

easily removed.

I am willing to update the wiki documentation to describe the

event limitation, implicit filter and/or the recall list

limitation if I hear back what you guys are planning to do

with this.

For more background, you can read a discussion I had with Ott

about this at:

http://wesnoth.debian.net/%23wesnoth-dev-2005-09-29.log

starting at about 1500.

(Reproduced on Any)
Release: 1.1-svn
Priority: 3 - Low
Severity: 3 - Normal

[wesnoth-bugs]

Modified on 2006-09-25

queenkiller changed category: Bug -> Feature Request

queenkiller changed priority: 5 - Normal -> 3 - Low

queenkiller wrote:

first and second issue is already fixed

Third is feature, so I change it to feature request and low.

[wesnoth-bugs]

Modified on 2016-01-11

gfgtdf changed title: Issues with [object], events, recall list and default filter -> Add [object] to units on the recall list.

[ProditorMagnus]

unit:add_modification works for recall list units, so all that would be needed to implement it would be including call to wesnoth.get_recall_units in function wml_actions.object(cfg). Though it would only make sense to do so if user explicitly asks for it with new key to not break anything.

Might make sense to require silent object for recall unit.

[CelticMinstrel]

It might be better to document that [object] doesn't work for recall list units and include a note that [modify_unit] can be used instead (by placing an [object] tag in it that only contains [effect] subtags). I'm not sure if [modify_unit] does currently work for recall list units, though, so that would need to be checked. (Also, [modify_unit] affects all units matching the filter while [object] only takes the first, but if I recall correctly, you can add limit=1 to the filter to get the same effect in [modify_unit].)

Basically my point is the same as @ProditorMagnus's final sentence - most of the [object] tag's ActionWML logic is irrelevant for recall list units.

[gfgtdf]

I agree here. Added a note in the wiki, im closing this. If someone has a real usecase in on of his/her addons whre [object] would be suprerior to [modify_unit][object] for recall unit s he can open a new report ( In particular this one is also too hard to read with the outdated information in the first post)

[CelticMinstrel]

@gfgtdf - Did you verify that [modify_unit] works for recall list units?

[gfgtdf]

yes (actualyl i had to fix it in master)