Xalzar's WML Headaches

[Xalzar]

In this topic I'm going collect all my questions which will eventually arise when I work with WML.
I have an identical topic on my forum of origin but here there is a wider audience...

Here is the malfunctioning event:

Code: Select all

[event]
	name=ship_inspection
	first_time_only=no

		{DEBUG_MSG "$my_ship.id|,$unit.id|,debug"}
		[set_menu_item]
            id=$my_ship.id|
            description= _ "$my_ship.variables.passenger.name| MOV:$my_ship.variables.passenger.moves|/$my_ship.variables.passenger.max_moves| HP:$my_ship.variables.passenger.hitpoints|/$my_ship.variables.passenger.max_hitpoints| XP:$my_ship.variables.passenger.experience|/$my_ship.variables.passenger.max_experience|"
			image=$my_ship.variables.passenger.image|
			[filter_location]
				[filter]
					id=$my_ship.id|
					#race=mechanical
				[/filter]
			[/filter_location]
            [command]
			{DEBUG_MSG "$my_ship.id|,$unit.id|,debug"}
			[/command]
		[/set_menu_item]
[/event]

And it is fired by (I report only the relevant part of the "parent" event):

Code: Select all

[event]
	name=prestart
    [set_menu_item]
            id=ship_in
            description= _ "Imbarca!"
			image=units/transport/galleon.png
			[default_hotkey]
				key=3
				alt=yes
			[/default_hotkey]
            [show_if]
                [have_unit]
					[filter_location]
						terrain=*^Bw*
					[/filter_location]
                    side=$side_number
					[not]
						race=merman,naga,bats,gryphon,falcon,mechanical,monster
					[/not]
                [/have_unit]
			[/show_if]
			[filter_location]
				[filter]
					[filter_location]
						terrain=*^Bw*
					[/filter_location]
                    side=$side_number
					[not]
						race=merman,naga,bats,gryphon,falcon,mechanical,monster
					[/not]
				[/filter]
			[/filter_location]
            [command]
				[unit]
					type=IT_Ship
					id=t_$unit.id
					side=$side_number
					canrecruit=$unit.canrecruit
					x,y=$x1,$y1
					placement=map_passable
					moves=0
					[status]
						unhealable=yes
					[/status]
				[/unit]
				
				[store_unit]
					[filter]
						id=t_$unit.id
						type=IT_Ship
					[/filter]
					kill=no
					variable=my_ship
				[/store_unit]

				[store_unit]
					[filter]
						id=$unit.id
					[/filter]
					kill=yes
					variable=my_ship.variables.passenger
					mode=append
				[/store_unit]
				
				[set_variable]
					name=my_ship.level
					value=$my_ship.variables.passenger.level
				[/set_variable]
				
				[unstore_unit]
					variable=my_ship
				[/unstore_unit]
				
				[redraw]
				[/redraw]

				[fire_event]
					name=ship_inspection
					[primary_unit]
						id=$my_ship.id|
						race=mechanical
					[/primary_unit]
				[/fire_event]
				
				{CLEAR_VARIABLE my_ship}
............

The second event functions perfectly, the problem is in the first one, in the filter exactly.

The first is clearly a custom event which makes an option appear when right-clicking the filtered unit. The option description reports some data extracted from the unit (the passenger) saved inside another one (the ship). The process of inserting a unit into another is presented in the "parent" event (also the variables which I substitute in the custom event are in this event).

I want to recognize the right ship for the right option to appear, and this can be achieved only using the variable $my_ship.id (as reported). But it doesn't work.

Here is what the two debug_msg say (I use as example a Red Mage):
the first (appears when the custom event is fired)

t_Red Mage-1,t_Red Mage-1,debug

the second (appears when I click the option)
-on the same unit

,t_Red Mage-1,debug

-on another unit

,t_Another Unit-2,debug

The point is that variable $my_ship.id| disappears. What happened? Perhaps the variable $my_ship is canceled by the {CLEAR_VARIABLE} of the "parent" event before the set_menu_item is evoked by right-clicking, but then why the reported data are correct then?

How do I know that are correct? I tried to filter by race=mechanical (but then all the ships gains the option/s) and then with id=$unit.id| (but then all units can access the option/s: the $unit variable is overridden when right-clicking). So I know for certain that the option's image and description are correct, and I can "fire" the second debug_msg.

I know I can simply put a general description for the option (like "inspect!" or whatever), filter by race and then in the [command] store the information contained in the unit and display it. But I wanted to avoid using a [message] for this (for gameplay reasons), and diplay the information directly in the options.

I ask whether is it possible to solve the problem, if yes how, if not why and what are other clever means for displaying such information, and then if there are none I will follow the alternative road and use a [message].

P.S.: I don't know anything of Lua, don't even mention it.

[Ravana]

Select event maybe.

20150126 18:24:43< zookeeper> well, need it or not, i already did http://pastebin.com/gtz4vEUX

[zookeeper]

My first guess would be that variable substitution for the [set_menu_item]'s [command] block happens when it's used, not when the menu item is created; my_ship would have been cleared at that point.

http://wiki.wesnoth.org/InterfaceAction ... nu_item.5D seems to agree.

[Xalzar]

Firstly, thank you very much for your replies.

@Ravana: the select event is not MP-safe (sorry, I didn't mention these events are included in a MP scenario)

@zookeeper: it makes sense, except that we still not know why $my_ship survives to substitute values in "description" and "image" in the [set_menu_item] but not in the [filter]. Perhaps that values are substituted when the event is fired but the filter is only applied when right-clicking? How unconvenient.

What a pity that delayed_variable_substitution applies only to variable substitutions included in [command], then
Also there is no way to store anything before the filter I think, and if I store out of the [set_menu_item] it stores when the event is fired and not when the [set_menu_item] is called.

Is there a way out?

[Ravana]

needs_select: if yes (default no), then the latest select event (see EventWML) that triggered before this menu item was chosen will be transmitted over the network before this menu item action will be. This only has any effect in networked multiplayer, and is intended to allow more elaborate menu item behaviour there without causing out of sync errors. If you don't know what this means, just leave it false.

So it should be useable in scenario too.

[Xalzar]

Another question: how does exactly the Swarm special work?
I ask where exactly does the special extract the "max_hitpoints" value.
I understood it stores the actual value of the unit's max_hitpoints, found in the unit's files.

The problem is that in one of my addons, I "hack" that value, and then Swarm behaves how it should, but not how I would have wanted.

An example of what happens in one of my events...

Two units attack each other:
1) when an attack hits, a random variable is set, it can assume a value between 0 and the amount of damage it can produce;
2) the damage is normally inflicted on the hitpoints;
3) then the random value is subtracted from the maximum hitpoints.

So if unit A hits unit B (25/25 HP) for 10 damage, the results could be:
B: 25-10=15 hitpoints, random 5: 25-5=20 max_hitpoints
Assuming B has a 3-10 attack with the Swarm special, the unit normally would have lost 40% of its hitpoints (15 = 60% of 25) and so 4 attacks (becoming a 3-6), but with the contemporaneous decrease of the max_hitpoints the percentage changes to 25% (15 = 75% of 20), losing 3 attacks (or 2? but the point remains; now the attack is a 3-7/8).

In my mind instead, the unit should lose 4 attacks, ignoring the new value of max_hitpoints. I don't know how I can do this without saving the max_hitpoints' value in unit.variable.original_max when units are recruited.

Are there any more "elegant" solutions?

[Xalzar]

Aaaaand I'm back! Cheers!

...*silence*... Ok...

Code: Select all

#define LONDONDERRY
	x="8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32"
	y="102-104,102-106,101-106,102-107,101-106,101-106,100-106,101-108,101-108,102-108,102-107,103-108,102-107,103-107,101-106,101-107,100-107,100-107,100-107,100-107,100-106,100-106,100-104,101-103,101"
#enddef

#define SAVE NAME AREA
	
	[store_locations]
		{AREA}
		variable=region[$region_counter|].area
	[/store_locations]
	[set_variable]
		name=region[$region_counter|].name
		value={NAME}
	[/set_variable]
	[set_variable]
		name=region_counter
		add=1
	[/set_variable]
	{DEBUG_MSG "c'mon...region[$region_counter|]"}
#enddef

#define REGIONS
[event]
	name=prestart
	
	[set_variable]
		name=region_counter
		value=0
	[/set_variable]
	{DEBUG_MSG "region[$region_counter|]"}
	[store_locations]
		x=10,11-12
		y=10-14,11
		variable=region[$region_counter|].area
	[/store_locations]
	[set_variable]
		name=region[$region_counter|].name
		value=_ "Ouagadougou"
	[/set_variable]
	[set_variable]
		name=region_counter
		add=1
	[/set_variable]
	{DEBUG_MSG "region[$region_counter|]"}
	{SAVE (_ "Londonderry") ({LONDONDERRY})}
[/event]
#enddef

The macro doesn't work. The displayed debug messages are "region[0].area" and "region[1].area", and the third one doesn't appear.
The stderr reports:

20150629 19:45:57 warning engine: variable_info: invalid WML array index, region[0].area

...quite strange, since the stderr refers to the only functioning variable, while the one which should have been created by the macro apparently goes undetected.

Trying to store in region[$region_counter|] (removing ".area") and deleting region[$region_counter|].name (in an attempt to isolate the problem) didn't solve the issue.
Adding another store_locations and set_variable which adds 1 to region_counter results in the two correct debug_msgs, two working variables, two reports from the stderr, and once again the macro not working.

What's the problem with that macro? Its content is identical to the part written directly into the event! I'm using 1.12.2.

[Ravana]

It looks correct,
region[1]

Code: Select all

#textdomain wesnoth-Maps_by_Inanna
name=_"Londonderry"
[area]
	terrain="Gg"
	x=8
	y=102
[/area]
[area]
	terrain="Gg"
	x=8
	y=103
[/area]
[area]
	terrain="Gg"
	x=8
	y=104
[/area]
[area]
	terrain="Gg"
	x=9
	y=102
[/area]
[area]
	terrain="Gg"
	x=9
	y=103
[/area]
[area]
	terrain="Gg"
	x=9
	y=104
[/area]
[area]
	terrain="Gg"
	x=9
	y=105
[/area]
[area]
	terrain="Gg"
	x=9
	y=106
[/area]
[area]
	terrain="Gg"
	x=10
	y=101
[/area]
[area]
	terrain="Gg"
	x=10
	y=102
[/area]
[area]
	terrain="Gg"
	x=10
	y=103
[/area]
[area]
	terrain="Gg"
	x=10
	y=104
[/area]
[area]
	terrain="Gg"
	x=10
	y=105
[/area]
[area]
	terrain="Gg"
	x=10
	y=106
[/area]
[area]
	terrain="Gg"
	x=11
	y=102
[/area]
[area]
	terrain="Gg"
	x=11
	y=103
[/area]
[area]
	terrain="Gg"
	x=11
	y=104
[/area]
[area]
	terrain="Gg"
	x=11
	y=105
[/area]
[area]
	terrain="Gg"
	x=11
	y=106
[/area]
[area]
	terrain="Gg"
	x=11
	y=107
[/area]
[area]
	terrain="Gg"
	x=12
	y=101
[/area]
[area]
	terrain="Gg"
	x=12
	y=102
[/area]
[area]
	terrain="Gg"
	x=12
	y=103
[/area]
[area]
	terrain="Gg"
	x=12
	y=104
[/area]
[area]
	terrain="Gg"
	x=12
	y=105
[/area]
[area]
	terrain="Gg"
	x=12
	y=106
[/area]
[area]
	terrain="Gg"
	x=13
	y=101
[/area]
[area]
	terrain="Gg"
	x=13
	y=102
[/area]
[area]
	terrain="Gg"
	x=13
	y=103
[/area]
[area]
	terrain="Gg"
	x=13
	y=104
[/area]
[area]
	terrain="Gg"
	x=13
	y=105
[/area]
[area]
	terrain="Gg"
	x=13
	y=106
[/area]
[area]
	terrain="Gg"
	x=14
	y=100
[/area]
[area]
	terrain="Gg"
	x=14
	y=101
[/area]
[area]
	terrain="Gg"
	x=14
	y=102
[/area]
[area]
	terrain="Gg"
	x=14
	y=103
[/area]
[area]
	terrain="Gg"
	x=14
	y=104
[/area]
[area]
	terrain="Gg"
	x=14
	y=105
[/area]
[area]
	terrain="Gg"
	x=14
	y=106
[/area]
[area]
	terrain="Gg"
	x=15
	y=101
[/area]
[area]
	terrain="Gg"
	x=15
	y=102
[/area]
[area]
	terrain="Gg"
	x=15
	y=103
[/area]
[area]
	terrain="Gg"
	x=15
	y=104
[/area]
[area]
	terrain="Gg"
	x=15
	y=105
[/area]
[area]
	terrain="Gg"
	x=15
	y=106
[/area]
[area]
	terrain="Gg"
	x=15
	y=107
[/area]
[area]
	terrain="Gg"
	x=15
	y=108
[/area]
[area]
	terrain="Gg"
	x=16
	y=101
[/area]
[area]
	terrain="Gg"
	x=16
	y=102
[/area]
[area]
	terrain="Gg"
	x=16
	y=103
[/area]
[area]
	terrain="Gg"
	x=16
	y=104
[/area]
[area]
	terrain="Gg"
	x=16
	y=105
[/area]
[area]
	terrain="Gg"
	x=16
	y=106
[/area]
[area]
	terrain="Gg"
	x=16
	y=107
[/area]
[area]
	terrain="Gg"
	x=16
	y=108
[/area]
[area]
	terrain="Gg"
	x=17
	y=102
[/area]
[area]
	terrain="Gg"
	x=17
	y=103
[/area]
[area]
	terrain="Gg"
	x=17
	y=104
[/area]
[area]
	terrain="Gg"
	x=17
	y=105
[/area]
[area]
	terrain="Gg"
	x=17
	y=106
[/area]
[area]
	terrain="Gg"
	x=17
	y=107
[/area]
[area]
	terrain="Gg"
	x=17
	y=108
[/area]
[area]
	terrain="Gg"
	x=18
	y=102
[/area]
[area]
	terrain="Gg"
	x=18
	y=103
[/area]
[area]
	terrain="Gg"
	x=18
	y=104
[/area]
[area]
	terrain="Gg"
	x=18
	y=105
[/area]
[area]
	terrain="Gg"
	x=18
	y=106
[/area]
[area]
	terrain="Gg"
	x=18
	y=107
[/area]
[area]
	terrain="Gg"
	x=19
	y=103
[/area]
[area]
	terrain="Gg"
	x=19
	y=104
[/area]
[area]
	terrain="Gg"
	x=19
	y=105
[/area]
[area]
	terrain="Gg"
	x=19
	y=106
[/area]
[area]
	terrain="Gg"
	x=19
	y=107
[/area]
[area]
	terrain="Gg"
	x=19
	y=108
[/area]
[area]
	terrain="Gg"
	x=20
	y=102
[/area]
[area]
	terrain="Gg"
	x=20
	y=103
[/area]
[area]
	terrain="Gg"
	x=20
	y=104
[/area]
[area]
	terrain="Gg"
	x=20
	y=105
[/area]
[area]
	terrain="Gg"
	x=20
	y=106
[/area]
[area]
	terrain="Gg"
	x=20
	y=107
[/area]
[area]
	terrain="Gg"
	x=21
	y=103
[/area]
[area]
	terrain="Gg"
	x=21
	y=104
[/area]
[area]
	terrain="Gg"
	x=21
	y=105
[/area]
[area]
	terrain="Gg"
	x=21
	y=106
[/area]
[area]
	terrain="Gg"
	x=21
	y=107
[/area]
[area]
	terrain="Gg"
	x=22
	y=101
[/area]
[area]
	terrain="Gg"
	x=22
	y=102
[/area]
[area]
	terrain="Gg"
	x=22
	y=103
[/area]
[area]
	terrain="Gg"
	x=22
	y=104
[/area]
[area]
	terrain="Gg"
	x=22
	y=105
[/area]
[area]
	terrain="Gg"
	x=22
	y=106
[/area]
[area]
	terrain="Gg"
	x=23
	y=101
[/area]
[area]
	terrain="Gg"
	x=23
	y=102
[/area]
[area]
	terrain="Gg"
	x=23
	y=103
[/area]
[area]
	terrain="Gg"
	x=23
	y=104
[/area]
[area]
	terrain="Gg"
	x=23
	y=105
[/area]
[area]
	terrain="Gg"
	x=23
	y=106
[/area]
[area]
	terrain="Gg"
	x=23
	y=107
[/area]
[area]
	terrain="Gg"
	x=24
	y=100
[/area]
[area]
	terrain="Gg"
	x=24
	y=101
[/area]
[area]
	terrain="Gg"
	x=24
	y=102
[/area]
[area]
	terrain="Gg"
	x=24
	y=103
[/area]
[area]
	terrain="Gg"
	x=24
	y=104
[/area]
[area]
	terrain="Gg"
	x=24
	y=105
[/area]
[area]
	terrain="Gg"
	x=24
	y=106
[/area]
[area]
	terrain="Gg"
	x=24
	y=107
[/area]
[area]
	terrain="Gg"
	x=25
	y=100
[/area]
[area]
	terrain="Gg"
	x=25
	y=101
[/area]
[area]
	terrain="Gg"
	x=25
	y=102
[/area]
[area]
	terrain="Gg"
	x=25
	y=103
[/area]
[area]
	terrain="Gg"
	x=25
	y=104
[/area]
[area]
	terrain="Gg"
	x=25
	y=105
[/area]
[area]
	terrain="Gg"
	x=25
	y=106
[/area]
[area]
	terrain="Gg"
	x=25
	y=107
[/area]
[area]
	terrain="Gg"
	x=26
	y=100
[/area]
[area]
	terrain="Gg"
	x=26
	y=101
[/area]
[area]
	terrain="Gg"
	x=26
	y=102
[/area]
[area]
	terrain="Gg"
	x=26
	y=103
[/area]
[area]
	terrain="Gg"
	x=26
	y=104
[/area]
[area]
	terrain="Gg"
	x=26
	y=105
[/area]
[area]
	terrain="Gg"
	x=26
	y=106
[/area]
[area]
	terrain="Gg"
	x=26
	y=107
[/area]
[area]
	terrain="Gg"
	x=27
	y=100
[/area]
[area]
	terrain="Gg"
	x=27
	y=101
[/area]
[area]
	terrain="Gg"
	x=27
	y=102
[/area]
[area]
	terrain="Gg"
	x=27
	y=103
[/area]
[area]
	terrain="Gg"
	x=27
	y=104
[/area]
[area]
	terrain="Gg"
	x=27
	y=105
[/area]
[area]
	terrain="Gg"
	x=27
	y=106
[/area]
[area]
	terrain="Gg"
	x=27
	y=107
[/area]
[area]
	terrain="Gg"
	x=28
	y=100
[/area]
[area]
	terrain="Gg"
	x=28
	y=101
[/area]
[area]
	terrain="Gg"
	x=28
	y=102
[/area]
[area]
	terrain="Gg"
	x=28
	y=103
[/area]
[area]
	terrain="Gg"
	x=28
	y=104
[/area]
[area]
	terrain="Gg"
	x=28
	y=105
[/area]
[area]
	terrain="Gg"
	x=28
	y=106
[/area]
[area]
	terrain="Gg"
	x=29
	y=100
[/area]
[area]
	terrain="Gg"
	x=29
	y=101
[/area]
[area]
	terrain="Gg"
	x=29
	y=102
[/area]
[area]
	terrain="Gg"
	x=29
	y=103
[/area]
[area]
	terrain="Gg"
	x=29
	y=104
[/area]
[area]
	terrain="Gg"
	x=29
	y=105
[/area]
[area]
	terrain="Gg"
	x=29
	y=106
[/area]
[area]
	terrain="Gg"
	x=30
	y=100
[/area]
[area]
	terrain="Gg"
	x=30
	y=101
[/area]
[area]
	terrain="Gg"
	x=30
	y=102
[/area]
[area]
	terrain="Gg"
	x=30
	y=103
[/area]
[area]
	terrain="Gg"
	x=30
	y=104
[/area]
[area]
	terrain="Gg"
	x=31
	y=101
[/area]
[area]
	terrain="Gg"
	x=31
	y=102
[/area]
[area]
	terrain="Gg"
	x=31
	y=103
[/area]
[area]
	terrain="Gg"
	x=32
	y=101
[/area]

So the question is what you want to do with these locations?

[zookeeper]

The macro doesn't work. The displayed debug messages are "region[0].area" and "region[1].area", and the third one doesn't appear.

Well, it worked for me.

[Xalzar]

Well, it worked for me.

It looks correct

Oook...that's something.

I tried then to relocate everything in the scenario file, with the event inside [multiplayer] and the two definitions out and first in the page. It worked!

Then I deleted all in the event except for the first set_variable and the macro (as it should be in the end - only with more macros), and it worked.
I deleted LONDONDERRY from that file (it remains in another file in another folder) and it worked. I deleted SAVE NAME AREA and it didn't work.
Maybe I am approaching the true evil behind all this...

So the question is what you want to do with these locations?

I want them saved in some variable because I need to access the data in other events. Too long to explain...

EDIT: another obsolete definition in my files was named SAVE REGION AREA...
It was after the right definition, but whatevs. Case solved.

Thank you, now I'll hide in my lair..to feel bad

[Xalzar]

This is my problem: I want to have an effect like [color_adjust] but restricted to an area of the map, and [time_area] doesn't color enough if I set a custom time of day with the RGB values I want. What can I do without resorting to colored halos?

[Samonella]

This probably isn't much better than your ideas with halos, but I would try using colored overlays with terrain graphics.

Maybe it would be good enough to [color_adjust] whenever you select a unit in the area?

[Xalzar]

Thanks! At the end I solved using the void terrain as a base, which enhances the color of the time_area (I was trying with lighter colours).

[Xalzar]

Another day another question: how can I store an unknown number of hexes inside a circle formed by units?

Storing locations near those units is not what I want since I'll include the hexes outside the unit circle too. And let's not talk that I should then store the locations adjacent to the first ones, many times. But I cannot foresee how big is the area encircled beforehand, and I don't want to put restrictions.

Also, when I say "circle" of units, I mean whatever line of adjacent units which connects start and end to divide two areas, so I cannot predict a perfect hexagonal area inside of it.

I looked up [find_path] and I could see that by creating an invisible dummy unit adjacent to a unit of the circle and trying to find a path to the edges of the map I could distinguish the inside from the outside. If I couldn't find it, it mean it is in the circle and I can start storing an area starting from its coordinates with a massive radius which stops when finding a unit of the circle.

This is however quite complicate (possibly unneccessarily) and expensive (in terms of iterations of trial and error), so... Does anyone know if there's anything else which is simpler and could aid me in this task?

[Samonella]

I looked up [find_path] and I could see that by creating an invisible dummy unit adjacent to a unit of the circle and trying to find a path to the edges of the map I could distinguish the inside from the outside. If I couldn't find it, it mean it is in the circle and I can start storing an area starting from its coordinates with a massive radius which stops when finding a unit of the circle.

To build off that idea, you could use [store_reachable_locations] when you find a tile from which the unit can't reach map borders.