How are advance and post advance events fired in 1.11.1+ ?

[Dugi]

I was able to learn this in 1.10 and 1.11.0, but in 1.11.1 it was changed and I cannot understand it. The only way for me to work on it is to try and see.

This is how it should behave:
1. A unit kills an opponent, earning enough experience to advance.
2. Last breath and die events are fired.
3. Advance event is fired.
4. The GUI asking what should it advance to appears, and the change chosen is performed.
5. Post advance event is fired.
If it advances via unstore_unit, nothing is fired.

However, on 1.11.1+, I am experiencing strange behaviour, like advancing before the advance event, difference between AMLA advancement and normal advancement in matters of firing events and even unit not stored into $unit, $x1, $y1 in post advance event.

Can somebody tell me how does it actually work?

[gfgtdf]

I think it's never been like that, it was more like:
1. A unit kills an opponent, earning enough experience to advance.
2. Last breath and die events are fired.
3. The GUI asking what should it advance to appears
4. Advance event is fired.
5 and the change chosen is performed, but it is aborted if certain things happend (for exaple changed type) in the advance event.
6. Post advance event is fired.

[Dugi]

It appears that you might be right, but what would be the point of showing the advancement GUI if the unit might not advance due to the advance event?
Wait... the wiki says that it asks, then the advance event is fired, then the changes are performed and then the post advance event is fired. I wonder what is the point of the separation of advance and post advance events then, except for storing the unit (that can be done without it anyway). Transformations of the unit can be done in post advance as well. If the unit's advancement is stopped in the advance event, the GUI shows up uselessly. Hm...

[Anonymissimus]

[unstore_unit] contains a fire_event= key controlling this.

I wonder what is the point of the separation of advance and post advance events then, except for storing the unit (that can be done without it anyway).

The advance event could cancel the advancement, for instance, or change the type the unit advances to.

I agree that it should make more sense to show the query after the advance event, so that the advance event can decide whether to show it at all.

and even unit not stored into $unit, $x1, $y1 in post advance event.

I've seen this happen with sighted events only so far and would be a pretty severe bug. As usual, you should provide a minimized test case...

[Dugi]

I agree that it should make more sense to show the query after the advance event, so that the advance event can decide whether to show it at all.

Please do it. If you want to do some changes on the unit before it advances, the GUI should reflect them, otherwise it is almost useless.

I placed this into A simple campaign's only scenario. $x1 and $y1 were stored (to my surprise, I had to set these variables myself in my campaign to get things working before), but the message was shown three times (or the number of times it shows is random, I think it appeared twice before).

Code: Select all

	[event]
		name=post advance
		[message]
			speaker=narrator
			message="$x1 $y1 $unit.name"
		[/message]
	[/event]

[gfgtdf]

i just tested

Code: Select all

	[event]
		name=post advance
		[message]
			speaker=narrator
			message="$x1 $y1 $unit.name"
		[/message]
	[/event]

with a simple scenario.
and it worked as wanted with amla and levelup, with first_time_only and without.

(version 11.2 win7 64bit)