[modify_unit] without triggering the advance animation?

[Dugi]

First, I am a complete noob to lua, but I have read through some documentation, examples and wml_tags.lua, so I suppose I should understand a bit how it works.

In my campaign, I needed to create an useful way to remove [object]s from units. Storing the unit, deleting the object, then unstoring it removes the object, but does not update the stats. I had to use {ADVANCE_UNIT $unit.x $unit.y $unit.type} to do it, but that is quite annoying because it launches an animation, that takes some time, and during the animation, unit's health and exp is shown wrongly (they are returned to the unit right after it, but while the animation takes place, the direct actions after it wait). Putting it to the recall list does not help, because it gets redrawn after that the even ends (not even if I place the redraw action after putting it to the recall list).

So I have decided to make a clone of the [modify_unit] tag, with the action of triggering the animation removed. While reading the code, I noticed that it stores the unit, creates a new unit, adds all properties of the base unit to it, moves all modificating things from the previous unit, and then puts all effects on it. But I could not find what triggers the animation.

Here is the code of the lua, just to make it easier to look at it.

Spoiler:

Code: Select all

function wml_actions.modify_unit(cfg)
	local unit_variable = "LUA_modify_unit"

	local function handle_attributes(cfg, unit_path, toplevel)
		for current_key, current_value in pairs(helper.shallow_parsed(cfg)) do
			if type(current_value) ~= "table" and (not toplevel or current_key ~= "type") then
				wesnoth.set_variable(string.format("%s.%s", unit_path, current_key), current_value)
			end
		end
	end

	local function handle_child(cfg, unit_path)
		local children_handled = {}
		local cfg = helper.shallow_parsed(cfg)
		handle_attributes(cfg, unit_path)

		for current_index, current_table in ipairs(cfg) do
			local current_tag = current_table[1]
			local tag_index = children_handled[current_tag] or 0
			handle_child(current_table[2], string.format("%s.%s[%u]",
				unit_path, current_tag, tag_index))
			children_handled[current_tag] = tag_index + 1
		end
	end

	local filter = helper.get_child(cfg, "filter") or helper.wml_error "[modify_unit] missing required [filter] tag"
	local function handle_unit(unit_num)
		local children_handled = {}
		local unit_path = string.format("%s[%u]", unit_variable, unit_num)
		local this_unit = wesnoth.get_variable(unit_path)
		wesnoth.set_variable("this_unit", this_unit)
		handle_attributes(cfg, unit_path, true)

		for current_index, current_table in ipairs(helper.shallow_parsed(cfg)) do
			local current_tag = current_table[1]
			if current_tag == "filter" then
				-- nothing
			elseif current_tag == "object" or current_tag == "trait" then
				local unit = wesnoth.get_variable(unit_path)
				unit = wesnoth.create_unit(unit)
				wesnoth.add_modification(unit, current_tag, current_table[2])
				unit = unit.__cfg;
				wesnoth.set_variable(unit_path, unit)
			else
				local tag_index = children_handled[current_tag] or 0
				handle_child(current_table[2], string.format("%s.%s[%u]",
					unit_path, current_tag, tag_index))
				children_handled[current_tag] = tag_index + 1
			end
		end

		if cfg.type then
			if cfg.type ~= "" then wesnoth.set_variable(unit_path .. ".advances_to", cfg.type) end
			wesnoth.set_variable(unit_path .. ".experience", wesnoth.get_variable(unit_path .. ".max_experience"))
		end
		wml_actions.kill({ id = this_unit.id, animate = false })
		wml_actions.unstore_unit { variable = unit_path }
	end

	wml_actions.store_unit { {"filter", filter}, variable = unit_variable }
	local max_index = wesnoth.get_variable(unit_variable .. ".length") - 1

	local this_unit = start_var_scope("this_unit")
	for current_unit = 0, max_index do
		handle_unit(current_unit)
	end
	end_var_scope("this_unit", this_unit)

	wesnoth.set_variable(unit_variable)
end

P.S. Lesser question, if I do absolutely same thing in lua than in wml, will the lua version work faster?

[Anonymissimus]

While reading the code, I noticed that it stores the unit, creates a new unit, adds all properties of the base unit to it, moves all modificating things from the previous unit, and then puts all effects on it. But I could not find what triggers the animation.

No. It creates a wml unit variable for each unit to modify, sets keys and tags in that variable, and unstore-overwrites the old on-map unit from it.
The animation is triggered by the unstore_unit tag used in the code. It cannot be turned off at present I suppose. This is neither a problem with modify_unit nor lua, but the wml tag unstore_unit instead. You may file a feature request, such as an [unstore_unit]animate=yes|no (def yes) key, which determines whether to animate in case of an advancement taking place upon unstoring. However, the engine's structure may not or not yet support that.

[Dugi]

Is there some way to simply update the unit's properties to the values of the corresponding unit_type modified by objects? I don't need to alter the type of the unit and I don't fully understand why did unstore unit animate it even if it advanced to the same unit, while in most other cases it does not animate it.

[Anonymissimus]

Is there some way to simply update the unit's properties to the values of the corresponding unit_type modified by objects?

The usual way to do that is an (animated...) advancement.

I don't fully understand why did unstore unit animate it even if it advanced to the same unit, while in most other cases it does not animate it.

Please post the wml code you call the tag (modify_unit) with.
Reading the code, it (modify_unit) should only advance (and animate) in case the type is modified.

[Dugi]

Code: Select all

{ADVANCE_UNIT id=$unit.id $unit.type}

Nothing complex, the regular macro in core.
I was not changing the unit's type before (between storing creating this variable, unstoring it and this), just altered resistances, weapon specials, damage, attacks, attack icons, halo, and similar stuff by a wml chunk that is applied any time I update the base stats with this.

This might be possibly related to the fact that if I advance a unit to something (the same thing, but in this case, it does not matter), it asks me what should the unit become and lists all possible AMLA that does not have the 'strict_amla=yes' token.

[Anonymissimus]

Code: Select all

{ADVANCE_UNIT id=$unit.id $unit.type}

This counts as changing the type, since a type= parameter is passed at all to modify_unit.
However, why do you do that call in the first place ? Probably to actually let the removed [object]s have effect ?
I don't know of another way to suppress the animation then. Other than the suggested feature above.

[Dugi]

But if I don't specify the type, it will become its next advancement. Is there a way to alter the lua code to make not alter the unit type?

And yes, I am using it when removing objects. The other technique to remove objects is to use counter objects, that for first makes all units get tons of data in their modifications after a longer gameplay (if it was an rpg campaign, it would not bother, but if all units can use objects and it is useful to move objects from one to another, it bothers), and is also awkward for me because I am altering the unit's resistances after the modify_unit to make sure that no resistance got too high.

[Anonymissimus]

I feel like repeating myself. you could just as well use (untested)

Code: Select all

		{VARIABLE unit.advances_to $unit.type}
		{VARIABLE unit.experience $unit.max_experience}
		[unstore_unit]
			variable=unit
			advance=yes
		[/unstore_unit]

in order to trigger re-applying the objects to the type, and it would cause the animation as well. Obviously you cannot work around it in the lua code which calls the tag as well.

The fact that objects are not actually deleted from the units' wml definitions but instead (can) nullify each other is indeed a design fault.

[Dugi]

This triggered the animation, and also asked me which AMLA should the unit take.
If I placed a blank levelout animation by a wml chunk before it, it would fix a half of the problem, but not the entire problem.

So there is probably no way... I will have to request a feature. This idea will not be so out of mind like most ideas in that forum.

[Sapient]

I agree that animate=no would be a nice feature for [unstore_unit]. I just thought I would link to this thread in case you haven't read it:
http://forums.wesnoth.org/viewtopic.php ... 73#p505273

In particular, this sentence:

If you, as the WML author, find yourself wanting to remove objects, then you probably should have gone with direct unit modification to have the finer degree of control

My post also explains why I felt a general-purpose [remove_object] was ambiguous.

However, it might be possible and desirable to detect situations where a new object can safely combine with and/or annihilate another object of the same type. This would mean carefully checking all the intermediate objects between the two.

[Dugi]

I have read only the beginning when I saw it, so I read it whole now. Anyway, I cannot see why a [remove_object] tag would be ambiguous, you can set an object to get removed after some time (duration=level), but cannot remove it spontaneously.

Anyway, I think that in my case, doing the stuff with direct modifications would be fairly counterproductive, because I am using the objects in [modifications] also as an inventory and also to notice some macros that some other effects have to be finished by direct modifications, because they are not coded (apply_to=alignment//alignment=liminal).
I suppose that the best possibility would be to remove the object and do inverse changes to the unit, but I am not sure how long would it take because of the number of effects possible, in addition that some unit's properties are permanently lost in some cases (alignment change, set_icon, set_description...), but this can be handled with [store_unit_type]. This might mean making it run in lua rather than in wml because of speed... and I am back at creating the [remove_object] tag.
I will try myself first, and ask questions only if I fail.