Uri van Roe weird behavior in S4

[nemaara]

@cooljeanius Your code here doesn't behave how you might think it does:

A_New_Order/scenarios/04_Battle_of_Barnon.cfg

Line 539 in fb1f257

{MSG_Uri _"This is taking too long. Men, gather me an escort, for I shall be taking this battle to the mixling myself!"}

.

Turns out you can make him run between your keep and his own so he gets stuck in limbo and doesn't recruit again. Makes the scenario a lot easier to just defend forever.

[cooljeanius]

ok so I guess #30 isn't actually fixed after all... I wonder if this is a general issue with the [leader_goal] tag, or just how it's being used here?

[cooljeanius]

(note that the [leader_goal] tag has been there since before I started modifying this campaign; the only stuff I've changed about it has been the addition of the dialogue surrounding it, and the provision of some extra reinforcements for him)

[cooljeanius]

maybe it's worth trying setting some of the other keys that the [leader_goal] tag accepts? e.g. auto_remove=, id=, and/or max_risk=... or maybe adding a [micro_ai] tag?

[nemaara]

Yea your code does exactly what you're telling him to do. The problem is the logic is flawed. By setting a leader goal only when someone is on the keep, all I have to do is make Gawen or any other unit run on and off the keep and Uri will just run back and forth. So it needs some better logic to either go straight there and charge into you or to just stay at his base permanently. No waffling back and forth lol.

[cooljeanius]

Oh you mean this part:

A_New_Order/scenarios/04_Battle_of_Barnon.cfg

Lines 547 to 567 in fb1f257

	[if]
	[not]
	[have_unit]
	side=1
	x,y=21,21 # Gawen's keep
	[/have_unit]
	[/not]
	[then]
	# He already has a leader_goal aiming here, but if the path is already clear, then give him a bit of extra prompting:
	[modify_unit]
	[filter]
	id=Uri van Roe
	[/filter]
	goto_x,goto_y=21,21 # The empty keep that Gawen presumably abandoned
	[/modify_unit]
	{MSG_Uri _"To Barnon!"}
	[/then]
	[else]
	{MSG_Uri _"You can't stay holed up there forever, Gawen!"}
	[/else]
	[/if]

That's different from the setting of the [leader_goal] here:

A_New_Order/scenarios/04_Battle_of_Barnon.cfg

Lines 215 to 231 in fb1f257

	[ai]
	turns=15-30 # Turn 15 corresponds to a hardcoded event, so keep that end of the range constant
	[leader_goal]
	x,y=21,21 # Gawen's keep
	[/leader_goal]
	leader_aggression={ON_DIFFICULTY 0.5 0.6 0.7}
	[goal]
	name=protect_unit
	[criteria]
	id=Uri van Roe
	side=4
	canrecruit=yes
	[/criteria]
	protect_radius=6 # MP of an Akladian Lord
	value={ON_DIFFICULTY 9 7 5}
	[/goal]
	[/ai]

Also the event from L547-L567 only ought to fire once, on turn 15, not every time Gawen moves on or off the keep. If Uri keeps waffling about which way he wants to go, that's got to be decisions made by his AI instead.

[nemaara]

Hmmm. You're right so that means the AI probably needs some tweaking. Can't release without this fixed I think.

[cooljeanius]

Hmmm. You're right so that means the AI probably needs some tweaking. Can't release without this fixed I think.

I'm busy tomorrow, but I should be able to get around to testing 13dfd3c sometime within the next week or so...

[cooljeanius]

OK I've tested some changes, and... I'm getting kind of tired testing this scenario, tbh; can I just submit a PR for what I've got so far and leave the rest of the testing to you?

[nemaara]

Sure thing!

[cooljeanius]

Sure thing!

ok I opened PR #49

[cooljeanius]

so, did merging PR #49 fix this satisfactorily?

[nemaara]

Yeah seems fine.

[cooljeanius]

We might need to reopen; @knyghtmare discovered another oddity with this

[cooljeanius]

Yeah I'm reopening this; szopen sent me a message on the forums with a replay from another player who was able to kill Uri because of this; I'm attaching it here:
ANO-Battle of Barnon Turn 21.gz

[cooljeanius]

ok so #76 should do a better job of addressing this (not necessarily "fixing" it per se, just making the effects of it more manageable to the point where this can be closed again)

[cooljeanius]

OK hopefully e2cca67 can count as closing this for real this time; it might still require some further tuning, though...