Some Trouble with Ineffectual {MODIFY_UNIT}s

[PsychoticKittens]

Right so, I'm working with this macro to 'store' units in a building-styled unit, and edit in the building-styled unit's second attack values to have the stored unit's damage, damage type, and number (strikes).

Running Wesnoth 1.8.2 on Windows 7.

Full Code:

Spoiler:

Code: Select all

#define MDC_TOWER_STORE
[event]
	name=prestart
	[set_menu_item]
		id=mdc_tower_storeunit
		description= _ "Store Unit in This Tower"
		[show_if]
			[have_unit]
				type=mdc-tower
				[and]
					[filter_location]
						x,y=$x1,$y1
					[/filter_location]
				[/and]
				[and]
					side=$side_number
				[/and]
			[/have_unit]
			[have_unit]
				type=mdc-bowmen
				[or]
					type=mdc-longbowmen
				[/or]
				[or]
					type=mdc-sharpshooters
				[/or]
				[or]
					type=mdc-crossbowmen
				[/or]
				[or]
					type=mdc-heavycrossbowmen
				[/or]
				[or]
					type=mdc-shortbowmen
				[/or]
				[or]
					type=mdc-bombardiers
				[/or]
				[or]
					type=mdc-javelineers
				[/or]
				[or]
					type=mdc-axethrowers
				[/or]
				[or]
					type=mdc-monks
				[/or]
				[or]
					type=mdc-mystics
				[/or]
				[or]
					type=mdc-wizards
				[/or]
				[or]
					type=mdc-handcannoneers
				[/or]
				[and]
					x,y=$selectx,$selecty
				[/and]
				[and]
					side=$side_number
				[/and]
				[and]
					[filter_location]
						[and]
							x=$x1
							y=$y1
							radius=1
						[/and]
					[/filter_location]
				[/and]
			[/have_unit]
		[/show_if]
		[command]
			[store_unit]
				[filter]
					x,y=$x1,$y1
				[/filter]
				variable=tower
			[/store_unit]
			[store_unit]
				[filter]
					x,y=$selectx,$selecty
				[/filter]
				variable=to_store
			[/store_unit]
			[if]
				{MDC_VARIABLE tower.variables.type_stored equals $to_store.type}
				[or]
					{MDC_VARIABLE tower.variables.type_stored equals empty}
				[/or]
				[then]
					[if]
						{MDC_VARIABLE tower.variables.type_stored equals empty}
						[then]
							{VARIABLE tower.variables.type_stored $to_store.type}
							{VARIABLE tower.variables.range $to_store.variables.range}
							{VARIABLE_OP tower.variables.range multiply 1.5}
							{VARIABLE_OP tower.variables.range round ceil}
							{VARIABLE count_to_store $to_store.hitpoints}
							{VARIABLE number 10000}
							{VARIABLE_OP number divide $to_store.max_hitpoints}
							{VARIABLE_OP number multiply .0001}
							{VARIABLE_OP count_to_store multiply $number}
							{CLEAR_VARIABLE number}
							{VARIABLE_OP count_to_store round ceil}
							{VARIABLE_OP tower.variables.count_stored add $count_to_store}
							{MODIFY_UNIT (x,y=$tower[$i].x,$tower[$i].y) attack[1].damage $to_store.attack[1].damage}
							{MODIFY_UNIT (x,y=$tower[$i].x,$tower[$i].y) attack[1].type $to_store.attack[1].type}
							{MODIFY_UNIT (x,y=$tower[$i].x,$tower[$i].y) attack[1].number $count_to_store}
							[unstore_unit]
								variable=tower[$i]
							[/unstore_unit]
							[kill]
								x,y=$selectx,$selecty
								animate=no
								fire_event=no
							[/kill]
						[/then]
						[else]
							{VARIABLE count_to_store $to_store.hitpoints}
							{VARIABLE number 10000}
							{VARIABLE_OP number divide $to_store.max_hitpoints}
							{VARIABLE_OP number multiply .0001}
							{VARIABLE_OP count_to_store multiply $number}
							{CLEAR_VARIABLE number}
							{VARIABLE_OP count_to_store round ceil}
							{VARIABLE_OP tower.variables.count_stored add $count_to_store}
							{VARIABLE new_count $tower.attack[1].number}
							{VARIABLE_OP new_count add $count_to_store}
							{MODIFY_UNIT (x,y=$tower.x,$tower.y) attack[1].number $new_count}
							[kill]
								x,y=$selectx,$selecty
								animate=no
								fire_event=no
							[/kill]
							[unstore_unit]
								variable=tower
							[/unstore_unit]
						[/else]
					[/if]
				[/then]
				[else]
					[message]
						message= _ "This tower is already occupied by a different kind of unit!"
					[/message]
				[/else]
			[/if]
		{CLEAR_VARIABLE count_to_store}
		{CLEAR_VARIABLE new_count}
		{CLEAR_VARIABLE tower}
		{CLEAR_VARIABLE to_store}
		[/command]
	[/set_menu_item]
[/event]
#enddef

This portion defines a bunch of variables, and then has the three {MODIFY_UNIT} that aren't affecting anything. I checked the variables it's changing to, and those were all correct. so I'm guessing it's the ( ).
I'm not sure if attack[#].____ is affected by the weapons' ranges, but the stored unit and the tower have different attack ranges.

Code: Select all

						[then]
							{VARIABLE tower.variables.type_stored $to_store.type}
							{VARIABLE tower.variables.range $to_store.variables.range}
							{VARIABLE_OP tower.variables.range multiply 1.5}
							{VARIABLE_OP tower.variables.range round ceil}
							{VARIABLE count_to_store $to_store.hitpoints}
							{VARIABLE number 10000}
							{VARIABLE_OP number divide $to_store.max_hitpoints}
							{VARIABLE_OP number multiply .0001}
							{VARIABLE_OP count_to_store multiply $number}
							{CLEAR_VARIABLE number}
							{VARIABLE_OP count_to_store round ceil}
							{VARIABLE_OP tower.variables.count_stored add $count_to_store}
							{MODIFY_UNIT (x,y=$tower.x,$tower.y) attack[1].damage $to_store.attack[1].damage}
							{MODIFY_UNIT (x,y=$tower.x,$tower.y) attack[1].type $to_store.attack[1].type}
							{MODIFY_UNIT (x,y=$tower.x,$tower.y) attack[1].number $count_to_store}
							[unstore_unit]
								variable=tower[$i]
							[/unstore_unit]
							[kill]
								x,y=$selectx,$selecty
								animate=no
								fire_event=no
							[/kill]
						[/then]

I tried it with a {FOREACH} to make it have [$i] on the x's and y's in the () , but that didn't change anything. I also started it off originally with x,y=$x1,$y1 and that doesn't work either. The only difference between other {MODIFY_UNIT} that I've done correctly is that it's using another unit's variables, instead of just a variable variable, but since I checked the variables I don't see what that's affecting anything.

[A Guy]

Try removing the [unstore_unit] in the second bit of code.

[PsychoticKittens]

Hrm. Well I did need to store the variables, so after removing it and noting that it worked, I moved it up *before* the modification.

Didn't know unstores had an effect on modifications

Thanks.

[A Guy]

No problem. If you unstore the unit after modifying it, you're replacing the modified version with the stored version.

[PsychoticKittens]

Oooh, that makes more sense.

Anyway, I also wanted to replace the image of the "Tower" unit, with the image of the "stored" unit. I wasn't sure how to do that.

[Sapient]

Normally you store the unit into a variable (such as "tower[$i]"), make some changes to that variable, then unstore it.

With the convenient MODIFY_UNIT macro, it takes care of storing and unstoring for you. It stores the filtered unit(s) into a temporary variable (different from your variable), makes one single change, then unstores it. All that extra storing and unstoring does however, make this approach a bit bulky in the savefile when it is called many times in a row. But who cares about a few extra lines in the savefile if it makes your WML code more readable right?

Now the problem occurs when MODIFY_UNIT was making changes to the temporary variable and it wasn't modifying your own variable "tower[$i]", so your variable still has the old unit stats. Therefore, when you unstore "tower[$i]" you put the old unit on the map and overwrite the one that was unstored by MODIFY_UNIT.

[Anonymissimus]

With the convenient MODIFY_UNIT macro, it takes care of storing and unstoring for you. It stores the filtered unit(s) into a temporary variable (different from your variable), makes one single change, then unstores it. All that extra storing and unstoring does however, make this approach a bit bulky in the savefile when it is called many times in a row. But who cares about a few extra lines in the savefile if it makes your WML code more readable right?

In 1.9 you can use the [modify_unit] tag for this - changing all required attributes with a single call, store/unstore process and very few code both preprocessed and non-preprocessed. [/advertisement]

[Sapient]

In 1.9 you can use the [modify_unit] tag for this - changing all required attributes with a single call, store/unstore process and very few code both preprocessed and non-preprocessed. [/advertisement]

Right, it is much more compact. That is a good advertisement.

[A Guy]

With the convenient MODIFY_UNIT macro, it takes care of storing and unstoring for you. It stores the filtered unit(s) into a temporary variable (different from your variable), makes one single change, then unstores it. All that extra storing and unstoring does however, make this approach a bit bulky in the savefile when it is called many times in a row. But who cares about a few extra lines in the savefile if it makes your WML code more readable right?

In 1.9 you can use the [modify_unit] tag for this - changing all required attributes with a single call, store/unstore process and very few code both preprocessed and non-preprocessed. [/advertisement]

I do prefer manually modifying the variable, as that allows me to add and subtract and multiply and divide.

[Sapient]

Good point. Not sure if it does this already or not, but it should autostore $this_unit to allow use of FormulaAI Lanugage.

e.g.:

Code: Select all

hitpoints="$($this_unit.hitpoints / 2)"

[Anonymissimus]

Good point. Not sure if it does this already or not, but it should autostore $this_unit to allow use of FormulaAI Lanugage.

e.g.:

Code: Select all

hitpoints="$($this_unit.hitpoints / 2)"

Done in r48922.

[Sapient]

Good point. Not sure if it does this already or not, but it should autostore $this_unit to allow use of FormulaAI Lanugage.

e.g.:

Code: Select all

hitpoints="$($this_unit.hitpoints / 2)"

Done in r48922.

Thanks. I reviewed the code a little bit and it looks like it should work fine, but I'm no Lua expert.

It's a pity that you can't make use of the C++ utilities for lazy storing into a scope-controlled variable stack, but I suppose it won't make any difference from a practical viewpoint since ActionWML can't be stacked over FilterWML and overwriting/clearing this_unit should thus bear no consequence.

[Anonymissimus]

It's a pity that you can't make use of the C++ utilities for lazy storing into a scope-controlled variable stack, but I suppose it won't make any difference from a practical viewpoint since ActionWML can't be stacked over FilterWML and overwriting/clearing this_unit should thus bear no consequence.

Not quite sure I understand. The process are two steps however - first all units are gathered and then all are modified so it is unrelated to the this_unit variable usable in the SUF.

Where are the formulas evaluated btw ? (IIRC that belongs to your area of expertise Sapient). They're just handed over at wesnoth.set_variable as they are.