Reme's warning not to get too attached to clansmen: get variation for the clansman being loyal to work

[cooljeanius]

I tried doing so, but it doesn't seem to work:

A_New_Order/scenarios/02_Fighting_for_Passage.cfg

Lines 740 to 768 in 3b71676

	[event]
	name=last breath
	[filter]
	type=Akladian Clansman
	side=1
	[/filter]
	{MSG_Gawen _"Poor fellow!"}
	{MSG_Reme _"He dies an honorable death. You cannot let the fear of losing units paralyse you; there are many more clansmen ready to fight for you."}
	# FIXME: This loyalty check doesn't seem to work, even after changing it from a "die" event to a "last breath" event, so I don't know what's wrong:
	[if]
	[have_unit]
	id=$unit.id
	[filter_wml]
	upkeep="loyal"
	[or]
	[modifications]
	[trait]
	id=loyal
	[/trait]
	[/modifications]
	[/or]
	[/filter_wml]
	[/have_unit]
	[then]
	{MSG_Gawen _"But he was loyal to our cause though!"}
	{MSG_Reme _"Well, I suppose you do have a point there. Feel free to be more careful with our most loyal supporters."}
	[/then]
	[/if]
	[/event]

[cooljeanius]

(this is in S02, "Fighting for Passage", for reference)

[cooljeanius]

I think #110 closes this... @Toranks might be submitting an alternate solution, though, but I guess if that happens, we can reopen this...

[cooljeanius]

I think we might actually need to reopen this; I've been trying running the validator lately, and it issues the following complaint about the new filter we're using:

20231231 01:39:40 error validation: Invalid key 'upkeep=' in tag [have_unit]
at ~add-ons/A_New_Order/./scenarios/02_Fighting_for_Passage.cfg:939
    included from ~add-ons/A_New_Order/_main.cfg:94

Although maybe that's an example of wesnoth/wesnoth#7817?
cc @Toranks

[cooljeanius]

ok yeah I think that validator message is actually correct, as I've seen that conditional fire on the death of a non-loyal Clansman...
cc @Toranks

[cooljeanius]

I think #110 closes this... @Toranks might be submitting an alternate solution, though, but I guess if that happens, we can reopen this...

OK so looking back at #110 it looks like @Toranks actually put his alternate solution in the comments there, so I might need to try using that instead...

[cooljeanius]

I think #110 closes this... @Toranks might be submitting an alternate solution, though, but I guess if that happens, we can reopen this...

OK so looking back at #110 it looks like @Toranks actually put his alternate solution in the comments there, so I might need to try using that instead...

(his and @knyghtmare's, that is)

[cooljeanius]

ok I think the check in cooljeanius/A_New_Order@8d30be6 finally gets it right; will re-close this once a PR that contains that commit is merged...