Possible bug with advancement filters not clearing

[Ken_Ohio]

I say "possible" bug, because it could just be me not understanding something. It's a wml question, so I believe this is the right place to ask.

The code below is simplified from my actual campaign, but I tested it and the problem still happens.

I have these two advancements in my [unit_type] tag. One is the standard +1 Melee damage. The second one gives the character poison immunity, but has a filter to test a variable called "mushrooms". Both advancements work as expected:

Code: Select all

[unit_type]

    {CHARACTER_BASE}

	[advancement]
       		max_times=2
       		always_display=yes
	 	id=adv_melee
       		description= _ "+1 melee damage"
       		 image=attacks/sword-human-short.png
       		 
       	 	[effect]
            		apply_to=attack
            		range=melee
         		increase_damage=1
       		 [/effect]

           	[effect]
           		apply_to=variation
            		name=Stage02
        	[/effect]
	[/advancement]


	[advancement]
		[filter]
			 formula = wml_vars.mushrooms > 0
		[/filter]
		
      		max_times=2
        	always_display=yes
	 	id=adv_mushroom
        	description= _ "Mushroom:  Gain poison immunity."
       		 image=icons/herb-bag.png
       		 
       		 [effect]
            		apply_to=status
			add=unpoisonable
		[/effect]

           	[effect]
           		apply_to=variation
            		name=Stage02
        	[/effect]
	[/advancement]

You can see that both advancements also progress the character to a new variation called Stage02. The [variation] for Stage02 is below. The advancements are EXACTLY THE SAME, except the order is reversed. This no longer works correctly.

Code: Select all

    [variation]
        {CHARACTER_BASE}

        variation_id=Stage02
        inherit=yes

	[advancement]
		[filter]
			 formula = wml_vars.mushrooms > 0
		[/filter]

        	max_times=2
        	always_display=yes
	 	id=adv_mushroom
	        description= _ "Mushroom:  Gain poison immunity."
       		 image=icons/herb-bag.png
       		 
       		 [effect]
            		apply_to=status
			add=unpoisonable
		[/effect]

           	[effect]
           		apply_to=variation
            		name=Stage02
        	[/effect]
	[/advancement]

	[advancement]
        	max_times=2
        	always_display=yes
	 	id=adv_melee
	        description= _ "+1 melee damage"
       		 image=attacks/sword-human-short.png
       		 
       	 	[effect]
            		apply_to=attack
            		range=melee
           		increase_damage=1
       		 [/effect]

           	 [effect]
           		apply_to=variation
            		name=Stage02
        	[/effect]
	[/advancement]

[/variation]
[/unit_type]

The code appears directly after the first block, still inside my [unit_type] tag.

The Melee advancement does not appear when the character advances in the Stage02 variation. There is no filter, and the max_times aren't used up, so it should definitely appear. When I look at the unit in Inspect Mode, I can see the problem. The [filter] for the mushroom variable somehow got imported into the Melee advancement.

So, the obvious work-around is to just not change the order. However, the actual campaign will have more than 2 advancements and I don't really want to have to constantly worry about what order I"m listing them in. Also, it took me HOURS to figure out why the advancement was not appearing, so I thought somebody else might benefit. (I didn't know about inspect mode... )

So is it a bug, or am I just being dumb? If there is any other work-around, so I don't have to constantly monitor the order, please let me know. Thanks!

Edit: fixed a typo in the code sections, where I had accidentally put max_times=-2 (negative 2). The error still happens with the correct max_times=2.

[Ravana]

It is intended. Variation and base_unit apply merge operation https://wiki.wesnoth.org/InternalAction ... riables.5D. Similar https://github.com/wesnoth/wesnoth/issues/7486

[Ken_Ohio]

Thanks for the reply. I don't think it is intended to add unwanted filters to advancements, based on what order the user types them in.

It's also not consistent. If there are three advancements, it doesn't add the filter to all of them. It only copies the filter if the advancement is in the same order as the previous variation. Like, if Variant01 has a filter on the second listed advancement, then Variant02 will get an unwanted filter added to the second listed advancement, but not the others.

[Ravana]

Tags are merged by index. In order to avoid seeing merge, one side needs to be empty, or both sides need to be equal within their shared index of tags. So all [advancement] could be in unit_type.

Assuming {CHARACTER_BASE} contains same text in both code blocks, [variation] one of them is useless, since merged result is used.

[Ken_Ohio]

Okay thanks. So it sounds like advancement filters won't merge if the advancements are all in [unit_type], with no variations. I guess need to either put all the advancements directly under [unit_type] or possibly create different unit types.

The reason for the Stage02 variation was because there are other advancements (not shown in my code block above), and I want them to NOT be available as the first pick. So whatever you choose first puts you into the Stage02 variation, and that's when other options become available. Anyway, I can just do that with filters or alternate unit types.

[lhybrideur]

Maybe you can add a variable (not sure if possible) or an silent ability (I use that here for example https://github.com/rodolphecombe/loti-e ... n.cfg#L568) to the unit in each of the "prerequisite" advancements and filter in the "better" advancement the state of this variable/ability

[Ken_Ohio]

Maybe you can add a variable (not sure if possible) or an silent ability (I use that here for example https://github.com/rodolphecombe/loti-e ... n.cfg#L568) to the unit in each of the "prerequisite" advancements and filter in the "better" advancement the state of this variable/ability

Yes, I think a variable will do the job. It took me a long time, and lots of trial and error, before I figured out "formula=wml_vars...." for managing variables in a filter, but now that I know how to do it, it will be the way forward.

I will just make a variable to track the total number of advancements the character has. Combined with the basic require_amla key, that should be good enough. I'm a little concerned about what happens on promotion (or transformation) to a different unit_type, but maybe I will just avoid that altogether for the main characters.

As you say, filtering by abilities might be useful too. I already have a few dummy abilities in place. Not for filtering, but just to make the advancement appear in character stats. Like the unpoisonable ability above -- you can't really tell the character has it without creating an ability for it.

[Celtic_Minstrel]

If you add two empty [advancement] tags inside the [variation] before the real tags, I think what you're trying to do should work. If your intent is to delete the old advancements and switch the order, that's probably possible too, though I don't think that would actually do anything.

[Ken_Ohio]

If you add two empty [advancement] tags inside the [variation] before the real tags, I think what you're trying to do should work. If your intent is to delete the old advancements and switch the order, that's probably possible too, though I don't think that would actually do anything.

Good idea, empty tags might be useful to fix the problem. However, I'm trying to do it without using variations at all, so I hopefully I won't need to try that.

Switching the order wasn't really the point. I just simplified the situation for purposes of this thread. The real problem is that I don't want to have to worry about the order that the advancements appear in the code, and whether or not they have filters, etc. It just seems like unnecessary overhead.