[modify_unit] in advance events causes a loop

[sevu]

If the unit, which is going to advance right after this event, is modified in any wayby [modify_unit], the advancement-choice dialog is shown again.
As afterwards as expected advance events are triggered, it result's in a loop.

The wiki explains a similar case, but it should not happen here:

Triggers just before the primary unit is going to advance to another unit, or advance by AMLA. (This is after the player selects which advancement, if there is a choice). If this event removes the unit, changes the unit's type, or reduces the unit's experience below what it needs to advance, then the advancement is aborted. This also applies to advancement by AMLA.

It's enough to give an object or change hp. Example code:

    [event]
        name=advance
        first_time_only=no
        [filter]
            type=Spearman
        [/filter]

        [modify_unit]
            [filter]
                id=$unit.id
            [/filter]

            hitpoints=1
            #[object]
            #    [effect]
            #        apply_to=attack
            #        increase_damage=100
            #    [/effect]
            #[/object]
        [/modify_unit]
    [/event]

Applying the commented-out object without the use of [modify_unit] does not trigger this, so this points to [modify_unit].
My intention was to use [modify_unit] to apply an [advancement].

Tested with version 1.15 - 31a5120

[stevecotton]

What if you apply the effect in a post_advance event instead?

It doesn't sound like a bug to me, [modify_unit] is going to put a unit on the map that has more XP than it needs to advance, so that probably should trigger an infinite loop.

I just checked whether this was a regression that would break SXC, and saw that SXC already uses a post_advance. Specifically it uses an advance event to store the unit's current HP, and the post_advance event to re-apply the effect if the unit has more HP than it's maximum (which can happen in an due to an add-on specific event).

Edit: when using an advance, post_advance pair, a rare case edge case to be aware of is when a unit gets enough XP to advance twice. The event sequence is either {advance, post_advance, post_advance} or {advance, advance, post_advance, post_advance}. I remember that it causes a WML error in SXC, but it doesn't break the game and I decided it wasn't work the extra code to handle it. That's an SXC bug, the first post_advance does a [clear_variable] on the variables stored in advance, and then the second post_advance tries to use that variable.

[CelticMinstrel]

It doesn't sound like a bug to me, [modify_unit] is going to put a unit on the map that has more XP than it needs to advance

It's not putting a unit on the map, it's altering one that's already there. The [modify_unit] tag doesn't use store-unstore for most changes. Unless it alters experience, I don't think this should happen; and even if it does alter experience there should be some exit condition in the engine so it doesn't loop infinitely.

so that probably should trigger an infinite loop.

Nothng in WML code should trigger an infinite loop.

[sevu]

I wanted to use the advanceevent to give AMLA options to the max_level units, using advance instead of post advance, because there one filters still for the old unit type, while the post advance event would also fire not only after the unit reached max level, but always when it AMLAs.

However, I actually don't need to use [modify_unit] here, it is for giving an AMLA directly, not to give the option to choose an AMLA later. What I apparently need is to add an object which adds a new advancent with the AMLA – and using [object] does not cause this issue.

So, no use case anymore.

[virtualghetto]

This error also happens in pre advance
I was trying to use modify_unit to add new advancement options in addition to amla default.
Giving new advancement options with [object][effect]apply_to=new_advancement didn't cause problems.