wml.fire and wesnoth.wml_actions.

[hermestrismi]

Hi,
I need to understand the difference between

Code: Select all

wml.fire

and

Code: Select all

wml_actions

I have two functions here:

Code: Select all

function print_results(results_table)
		for i, entry in ipairs(results_table) do
			local unit = entry.unit
			local amount_of_bet = entry.amount_of_bet
			local side = entry.side
			local x_unit = 17
			local y_unit = 14 + i
			wesnoth.units.to_map({ type = unit, side = side }, x_unit, y_unit)
			wml.fire("store_unit", { variable="my_unit", { "filter", { canrecruit="no" } } })
			print("Unit:".. unit ..", Amount of Bet:".. amount_of_bet ..",Side:".. side)
			wesnoth.map.add_label({x = 3, y = 24 + i, text = "Unit: " .. unit .. " | Amount of Bet: " .. amount_of_bet .. " | Side: " .. side})
		end
	end
	
	function convert_to_wml_array(results_table)
		local wml_array = {}
		local target = {}
		local T = wml.tag
		
		for _, entry in ipairs(results_table) do
			local unit_entry = {
				unit = entry.unit,
				amount = entry.amount_of_bet,
				side = entry.side
			}
			local unit = entry.unit
			local amount_of_bet = entry.amount_of_bet
			local side = entry.side
			wesnoth.wml_actions.set_variables {
				name="targets",
				mode="append",
				T.value {
					unit=unit,
					amount=amount_of_bet,
					side=side
				}
			}
			table.insert(wml_array, unit_entry)
			table.insert(target, unit_entry)
			-- wml.array_access_set("target", unit_entry)
		end
		-- wml.variables["target"] = wml.tostring(target)
		return wml_array
	end
	

I get two arrays, one from [0] to [13], the other from [0] to [14] .
I will use wml.fire but I want to understand why

Code: Select all

wesnoth.wml_actions.set_variables

gave different result?
also, any comment on the code itself is welcome ofc

[Celtic_Minstrel]

wesnoth.wml_actions is the place to define new WML actions. Because of that, it is technically possible to also call a WML action via it, but doing so creates a problem – WML actions are intended to be run on substituted WML tables (ak vconfigs), but calling it manually typically ends up passing an unsubstituted, plain WML table.

wml.fire is intended for calling a WML action. Thus, when passed a plain WML table, it automatically converts it to a substituted one. By always using wml.fire instead of wesnoth.wml_actions to call WML actions, you can safely write your WML actions to assume the input is substituted.

As a side note, there are two equivalent ways to call wml.fire:

Code: Select all

wml.fire("store_unit", { variable="my_unit", { "filter", { canrecruit="no" } } })
wml.fire.store_unit{ variable="my_unit", { "filter", { canrecruit="no" } } }

So if you dislike wml.fire on the basis of the syntactic difference, there's no need – it can be called in the same format as wesnoth.wml_actions. Technically, the first form shown above is the older method and the second form was added later, but we don't have any plans to remove the first form.

[hermestrismi]

wesnoth.wml_actions is the place to define new WML actions. Because of that, it is technically possible to also call a WML action via it, but doing so creates a problem – WML actions are intended to be run on substituted WML tables (ak vconfigs), but calling it manually typically ends up passing an unsubstituted, plain WML table.

wml.fire is intended for calling a WML action. Thus, when passed a plain WML table, it automatically converts it to a substituted one. By always using wml.fire instead of wesnoth.wml_actions to call WML actions, you can safely write your WML actions to assume the input is substituted.

As a side note, there are two equivalent ways to call wml.fire:

Code: Select all

wml.fire("store_unit", { variable="my_unit", { "filter", { canrecruit="no" } } })
wml.fire.store_unit{ variable="my_unit", { "filter", { canrecruit="no" } } }

So if you dislike wml.fire on the basis of the syntactic difference, there's no need – it can be called in the same format as wesnoth.wml_actions. Technically, the first form shown above is the older method and the second form was added later, but we don't have any plans to remove the first form.

thank you for the explanation