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.

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].

AI 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.

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 remove 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).

AI 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].

I would support that. If name suggestions are welcome, I would suggest [modification], for consistency — length, at least, does not appear to me to be a concern in the naming of WML tags.

Pentarctagon wrote:Another name suggestion: [unit_change]/[add_unit_change]/[remove_unit_change], which would make it much more obvious what the tags change.

This is a thing indeed, but I'm still in favor of [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.

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.

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:

Attachments

itempickupdialog.png (96.68 KiB) Viewed 12076 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?

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]?

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]?

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.

That was an additional plan, but even less defined and I ran out of time to type it out.

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.