[avoid] for specified units?

[Spannerbag]

Hi,
I've been playtesting a campaign and it would be handy to specify an [avoid] clause that only applies to certain units on the ai side.
Specifically I want an [avoid] clause that is only obeyed by trolls in an ai side that can recruit a mix of human and troll unittypes.

I can't think of a suitable way of doing this because adding a [filter] would have the effect (as I understand it) of limiting locations to those satisfying the [filter] whereas I want to restrict it the units (in this case to race=troll).

I could split the ai side into trolls and everyone else but that introduces other issues and with suitable dialogue it works as-is; the leader telling the trolls to avoid certain terrain but the rather dim trolls carry on ploughing through the terrain anyway...

However if I have missed something and this can be done in a straightforward manner, please let me know.

Cheers!
-- Spannerbag

[Celtic_Minstrel]

I can't think of a way of doing this without heavy AI customization (like, custom Lua candidate actions or something).

If the locations are a specific terrain, I suppose you could modify the troll units to treat that terrain as impassable, but if they're a mixed bag then that won't work.

[beetlenaut]

I think I would flip recruited trolls to a different team. The new team could be leaderless, hidden, and the same color as the original one. I don't think many players would notice.

[Lord-Knightmare]

I think I would flip recruited trolls to a different team. The new team could be leaderless, hidden, and the same color as the original one. I don't think many players would notice.

I guess it is doable, assuming they dont open the status table and see some weird unit count values. Like you see 20 units but the table shows 13.

[Spannerbag]

Thanks for the replies and advice, much appreciated.
Seem like I hadn't missed anything obvious (for once) and the options are either separate side or ai customisation.

I'm wondering if this would be a helpful option to suggest via the ideas forum?
Has anyone here ever needed anything like this before?

[ramblings]
I did have a bit of a mull over how [avoid] could be made to consider units.

The underlying code is a black box to me but I thought adding a restricted [filter] to identify a sub-set of a side's own units might be workable?
This could be named [units_for] or somesuch and off the top of my head I think could safely ignore the following sub-tags/filters:
defense, movement_cost, side, status, x,y=,
[filter_adjacent], [filter_location], [filter_side] and [filter_vision].

However, I think [has_attack] might be useful.

Not sure about [filter_wml] but suspect only unit variables would be generally useful so maybe allow [filter_wml] but ignore everything except [variables]?
Or ignore [filter_wml] entirely and use formula=?
I've no idea which is easiest/feasible.

Also the current side is hardwired so within side 3's [avoid] all location filters have the unit subfilter:

Code: Select all

[units_for]
  side=3
[/units_for]

baked in and any additional [units_for] WML is appended to this default value.

You could mix and match locations with some being avoided by all units in the side whilst others are avoided only by specified units.

So you might have

Code: Select all

[avoid]
  [and]			# Avoided by entire side (default)
    x,y=3,27
   radius=3
  [/and]
  [and]
    terrain=S*^*
    [units_for]		# Avoid mud/swamp (trolls only)
      race=troll
    [/units_for]
  [/and]
[/avoid]

No sure whether leader(s) should be included or not by default?

I think for most purposes the unit attributes that would be most widely used are likely to be:
id, race, type/type_adv_tree, role and probably less often [has_attack], unit variables and ability/ability_type.
[/ramblings]

Anyway, it's just a thought but I have no idea if there's any wider demand for this sort of functionality beyond myself?
Thoughts/opinions welcome!

Cheers!
-- Spannerbag

[Celtic_Minstrel]

I don't think your idea will work very well, unfortunately. The thing is, only one [avoid] can be active at any given time, so a single tag needs to cover the entire side. There are facilities for varying the [avoid] based on the turn number or time of day, but those are also things that have a single global value at any given time. That means the game can easily cache the current value of [avoid].

Theoretically, a variation on your proposal could be implemented in the expanded syntax, looking something like this:

Code: Select all

[aspect]
	name=composite_aspect
	id=avoid
	[facet]
		id=troll_avoid
		[filter_own] # filter_own to mirror the similar functionality in [candidate_action]
			race=troll
		[/filter_own]
		[value]
			# the contents of [avoid] go here
		[/value]
	[/facet]
[/aspect]

But that undermines the caching system. The game can't cache the active aspect value anymore – it needs to recalculate it every time it's asked for. To make matters worse, it can't calculate it without knowing the unit it's applying the aspect to. Right now, every time something wants the value of an aspect, it just asks the engine for the value of the aspect. No unit is involved at all.

So, while the above syntax is logical and makes sense, it's a massive change to the AI system that probably breaks compatibility with everything.

If you really want to avoid splitting the side in two, then [filter_own] on [candidate_action] is probably helpful. Figure out which candidate actions use the [avoid] filter and set them to not run on trolls. Then make duplicates of those candidate actions that use your custom [avoid] filter instead of the actual one, and set them to only run on trolls, at the same priority as the non-troll versions.

The hard part is the "make duplicates" step. The C++ candidate actions have no configurability at all, so at present the only way to do that is to reimplement the entire thing in Lua… which is probably not an easy task. Adding some configuration options to C++ candidate actions would likely be doable, though. I think that would be a better feature request than what you suggested.

[Spannerbag]

I don't think your idea will work very well, unfortunately...

Ah. Well, at least the underlying logic is a bit less of a black box now.
Many thanks for the detailed and comprehensive explanation. I even understood most of it

... Adding some configuration options to C++ candidate actions would likely be doable, though. I think that would be a better feature request than what you suggested.

Heh, I've no idea what sort of additional options would be useful/doable...

As the scenario plays well as it is (IMHO) and the troll avoid thing isn't fatal I think I'll leave it as it is.

Many thanks for taking the time and trouble to explain why my proposal wouldn't work, it's appreciated and I learned something.

Cheers!
-- Spannerbag