ActionWML to remove [object]s
Moderator: Forum Moderators
ActionWML to remove [object]s
With [object]'s new 'turn' duration, along with the renamed 'scenario' duration (freeing up 'level' for objects to be removed on levelup somewhere in the future), direct modifications to units are less and less needed. If an object needs to be removed at a different time though, only option other than adding an extra object to cancel the effect of the first, is hand-hacking the stored unit to remove the object and then either using [transform_unit] to rebuild it or manually correcting for the object's [effect]s.
The [remove_object] tag in 8680's lua pack uses the second method.
I'd like to implement the tag in C++ using the first method, but there's the issue of identifying an object. The lua pack version uses [filter_wml] or [filter_effect] to identify the object (example), but that's not the prettiest solution. I'd like to filter for [object]id, but that brings up another issue.
The 'id' key is already in use to ensure an object is only picked up once (example in THoT). This makes it unusable for objects that may be given to multiple units, unless you start working the unit's ID in there or something.
The possibility of an 'allow_multiple' key or the like was suggested, but I'd prefer to just get rid of that feature, possibly along with its [then] tag.
The [remove_object] tag in 8680's lua pack uses the second method.
I'd like to implement the tag in C++ using the first method, but there's the issue of identifying an object. The lua pack version uses [filter_wml] or [filter_effect] to identify the object (example), but that's not the prettiest solution. I'd like to filter for [object]id, but that brings up another issue.
The 'id' key is already in use to ensure an object is only picked up once (example in THoT). This makes it unusable for objects that may be given to multiple units, unless you start working the unit's ID in there or something.
The possibility of an 'allow_multiple' key or the like was suggested, but I'd prefer to just get rid of that feature, possibly along with its [then] tag.
Re: ActionWML to remove [object]s
Several people have suggested just adding extra keys to the [object] to filter on, as the entire tag is thrown into [modifications].
Another point is that [object] originated as the functional part behind an [item], but is now used far more as a vehicle for [effect]s added in other ways. It could make sense to move this functionality to a different tag. Pyrophorus suggested a [change] tag, to be added and removed with [add_change] and [remove_change].
Another point is that [object] originated as the functional part behind an [item], but is now used far more as a vehicle for [effect]s added in other ways. It could make sense to move this functionality to a different tag. Pyrophorus suggested a [change] tag, to be added and removed with [add_change] and [remove_change].
Re: ActionWML to remove [object]s
I will note that both methods have their limitations — the first would discard any direct modifications made to the unit (acceptable in some use cases, but rendering it useless in others), and the second apparently cannot removeAI wrote:[…] hand-hacking the stored unit to remove the object and then either using [transform_unit] to rebuild it or manually correcting for the object's [effect]s.
new_ability
[effect]
s (though this may well be merely the fault of my mess of an implementation). To cover all use cases, it may thus be necessary or desirable to make both methods available, via an attribute or via separate tags (of which the former seems to me preferable).I would support that. If name suggestions are welcome, I would suggestAI wrote:It could make sense to move this functionality to a different tag. Pyrophorus suggested a [change] tag, to be added and removed with [add_change] and [remove_change].
[modification]
, for consistency — length, at least, does not appear to me to be a concern in the naming of WML tags.- Pentarctagon
- Project Manager
- Posts: 5599
- Joined: March 22nd, 2009, 10:50 pm
- Location: Earth (occasionally)
Re: ActionWML to remove [object]s
Another name suggestion: [unit_change]/[add_unit_change]/[remove_unit_change], which would make it much more obvious what the tags change.
99 little bugs in the code, 99 little bugs
take one down, patch it around
-2,147,483,648 little bugs in the code
take one down, patch it around
-2,147,483,648 little bugs in the code
Re: ActionWML to remove [object]s
This is a thing indeed, but I'm still in favor ofPentarctagon wrote:Another name suggestion: [unit_change]/[add_unit_change]/[remove_unit_change], which would make it much more obvious what the tags change.
[modification]
. I think it makes it clear enough what it does, and it sounds better in my opinion. Well, no matter what it's called, it'd be good to have a tag like this.Formerly known as the creator of Era of Chaos and maintainer of The Aragwaithi and the Era of Myths.
Re: ActionWML to remove [object]s
A phone is not the ideal device to write this with, so here's a short summary of my current plan:
A [modification] tag that contains [effect]s along with a duration key and any other keys (for filtering purposes). These will go verbatim into [unit][modifications].
[object] will retain its [filter], [then], id key, cannot_use_message and everything else related to picking up items. The rest will become the new [modification] subtag.
I'm not sure what the removal tag should look like yet, and I just realized [modification] might be confused with MP modifications by automated tools. I'll also have to look into the new_ability removal failing.
A [modification] tag that contains [effect]s along with a duration key and any other keys (for filtering purposes). These will go verbatim into [unit][modifications].
[object] will retain its [filter], [then], id key, cannot_use_message and everything else related to picking up items. The rest will become the new [modification] subtag.
I'm not sure what the removal tag should look like yet, and I just realized [modification] might be confused with MP modifications by automated tools. I'll also have to look into the new_ability removal failing.
Re: ActionWML to remove [object]s
The solution would be to make itAI wrote: I'm not sure what the removal tag should look like yet, and I just realized [modification] might be confused with MP modifications by automated tools.
[add_modification]
and [remove_modification]
, although I don't know how that would look like inside [object]
.Formerly known as the creator of Era of Chaos and maintainer of The Aragwaithi and the Era of Myths.
Re: ActionWML to remove [object]s
I agree with bumba about the [add_modification] tag name, but I'm wondering, why make it retain [effect] instead of allowing it to directly access the code under [effect], but with it's own duration= and id= keys. That would prevent another layer of WML, and would effectively be a rename and expansion of the [effect] tag. Eg:
And in regards to [object], if you're going to keep it as an interface for picking up items, should not it have a built-in way to decide whether to pick up or decline to pick up the object without UMC authors having to use [message][option]?
Something like this:
Code: Select all
[add_modification]
id=foo
duration=turn
apply_to=new_ability
[abilities]
{ABILITY_REGENERATES}
[/abilities]
[/add_modification]
Something like this:
- Attachments
-
- itempickupdialog.png (96.68 KiB) Viewed 26320 times
Creator of Shadows of Deception (for 1.12) and co-creator of the Era of Chaos (for 1.12/1.13).
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
SurvivalXtreme rocks!!!
What happens when you get scared half to death...twice?
Re: ActionWML to remove [object]s
I second this, although I do think there should still be some flexibility, and the option to make 'accepting' the object mandatory should still exist.vultraz wrote: And in regards to [object], if you're going to keep it as an interface for picking up items, should not it have a built-in way to decide whether to pick up or decline to pick up the object without UMC authors having to use [message][option]?
Formerly known as the creator of Era of Chaos and maintainer of The Aragwaithi and the Era of Myths.
Re: ActionWML to remove [object]s
The reason for retaining [effect] is grouping things together.
That was an additional plan, but even less defined and I ran out of time to type it out.bumbadadabum wrote:I second this, although I do think there should still be some flexibility, and the option to make 'accepting' the object mandatory should still exist.vultraz wrote: And in regards to [object], if you're going to keep it as an interface for picking up items, should not it have a built-in way to decide whether to pick up or decline to pick up the object without UMC authors having to use [message][option]?
- Celtic_Minstrel
- Developer
- Posts: 2290
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: ActionWML to remove [object]s
So, three years later, there is now a
[remove_object]
tag in 1.13 which uses the duration expiry mechanism to remove an object that matches a WML filter (as with [filter_wml]
).- beetlenaut
- Developer
- Posts: 2832
- Joined: December 8th, 2007, 3:21 am
- Location: Washington State
- Contact:
Re: ActionWML to remove [object]s
Very nice! I have wished this tag existed before.
Campaigns: Dead Water,
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
The Founding of Borstep,
Secrets of the Ancients,
and WML Guide
Re: ActionWML to remove [object]s
Hi Celtic_Minstrel,
This tag is great, but could it be set to accept more keys than the [object] id? If the object is set with WML, the id field causes it to work only once (if generated via WML, though not Lua), in which case this tag isn't that useful (for UMC creators not using Lua). If dealing with whatever custom fields are thrown into an [object] is too big a pain, some convention for an alternative field like "name" would probably work well enough.
This tag is great, but could it be set to accept more keys than the [object] id? If the object is set with WML, the id field causes it to work only once (if generated via WML, though not Lua), in which case this tag isn't that useful (for UMC creators not using Lua). If dealing with whatever custom fields are thrown into an [object] is too big a pain, some convention for an alternative field like "name" would probably work well enough.
BfW 1.12 supported, but active development only for BfW 1.13/1.14: Bad Moon Rising | Trinity | Archaic Era |
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
| Abandoned: Tales of the Setting Sun
GitHub link for these projects
Re: ActionWML to remove [object]s
wesnoth.remove_modification is not documented. I see its implementation has //TODO, so might be that it is not decided what it should do.
Added [remove_object] to Template:WML Tags.
In WML you could still iterate over units and objects, query their attribute, and if needed, query id and remove that id.
Added [remove_object] to Template:WML Tags.
In WML you could still iterate over units and objects, query their attribute, and if needed, query id and remove that id.
- Celtic_Minstrel
- Developer
- Posts: 2290
- Joined: August 3rd, 2012, 11:26 pm
- Location: Canada
- Contact:
Re: ActionWML to remove [object]s
wesnoth.remove_modification supports arbitrary keys (it basically runs a
[filter_wml]
on the entire [object]
), so allowing that in the WML tag should be relatively easy.