[and] and [or] filter usage

[Jaume]

I apologize in advance if this question has been asked before, but this board's search utility ignores both 'and' and 'or' in my requests (which obviously doesn't help in my case!)

Here's my problem: I want to use the [event] name=attack end tag to unstore an unit (or a group of units) that's been stored/killed in a previous attacker hits or defender hits event. I'd need to use a filter in the form of:

(filter AND filter_second_attack) OR (filter_second AND filter_attack)

but I can't figure out exactly how to code this. Intuitively it'd look like:

Code: Select all

	[event]
		name=attack end
		first_time_only=no

		[or]
			[and]
				[filter]
					[not]
						[filter_wml]
							[status]
								not_living="yes"
							[/status]
						[/filter_wml]
					[/not]
				[/filter]
				[filter_second_attack]
					special=feeblemind
				[/filter_second_attack]
			[/and]
			[and]
				[filter_second]
					[not]
						[filter_wml]
							[status]
								not_living="yes"
							[/status]
						[/filter_wml]
					[/not]
				[/filter_second]
				[filter_attack]
					special=feeblemind
				[/filter_attack]
			[/and]
		[/or]
# {DEBUG_MSG "attack end ($unit.id($x1:$y1),$weapon.name; $second_unit.id($x2:$y2),$second_weapon.name)"}

		{FOREACH unit_fb unit_fb_index}
# {DEBUG_MSG "unstore: $unit_fb[$unit_fb_index].id"}
			[unstore_unit]
				variable=unit_fb[$unit_fb_index]
				red=255
				green=0
				blue=255
				text= _ "feeblemind"
				find_vacant=no
			[/unstore_unit]
		{NEXT unit_fb_index}

		[clear_variable]
			name=unit_fb
		[/clear_variable]

	[/event]

but obviously the [and] and [or] filters don't work that way. What's the correct way to code this then? Assuming it's possible to use this sort of conjunctional logic in an event filter at all (maybe it's not)? I'm fairly new to WML (about 2 weeks) and I'm clueless about this one.

[zookeeper]

Nope, not possible. If you cannot do what you want by using [and] and [or] inside the filter tags, then you need to make several similar events with different filters for them. That's unfortunately often the case with combat-related events.

[7thWolf]

@Jaume The first set of [or] tags doesn't need to be there.

One important thing to remember is if you are using [or] tags, the first conditional statement should not have an [or] tag wrapped around it.

So, your code should look like this

Code: Select all

   [event]
      name=attack end
      first_time_only=no

      [and]
           [filter]
               [not]
                  [filter_wml]
                     [status]
                        not_living="yes"
                     [/status]
                  [/filter_wml]
               [/not]
           [/filter]
           [filter_second_attack]
               special=feeblemind
           [/filter_second_attack]
      [/and]
      [or]
         [and]
            [filter_second]
               [not]
                  [filter_wml]
                     [status]
                        not_living="yes"
                     [/status]
                  [/filter_wml]
               [/not]
            [/filter_second]
            [filter_attack]
               special=feeblemind
            [/filter_attack]
         [/and]
      [/or]
# {DEBUG_MSG "attack end ($unit.id($x1:$y1),$weapon.name; $second_unit.id($x2:$y2),$second_weapon.name)"}

      {FOREACH unit_fb unit_fb_index}
# {DEBUG_MSG "unstore: $unit_fb[$unit_fb_index].id"}
         [unstore_unit]
            variable=unit_fb[$unit_fb_index]
            red=255
            green=0
            blue=255
            text= _ "feeblemind"
            find_vacant=no
         [/unstore_unit]
      {NEXT unit_fb_index}

      [clear_variable]
         name=unit_fb
      [/clear_variable]

   [/event]

Note: as zookeeper said, this still won't work, but that's how you should be using the [or] tags.

[Jaume]

Thanks to both for the quick replies.

... then you need to make several similar events with different filters for them. That's unfortunately often the case with combat-related events.

Actually I already had a workaround (using an extra ad hoc variable) that avoids this, but it's still a bit awkward and I was looking for the "natural and elegant way" to code stuff. Too bad it doesn't work here, but since you guys do, I suppose I can live with it too