Filtering for Unit ID on [set_extra_recruit]

[AkaMeDaemon]

Hey there! Sorry if this is addressed elsewhere; I couldn't find any posts on it. I have looked over the filters and StandardUnitFilters sections extensively; however, this is my first time using WML and filters. I'd appreciate any help on this.

Basically, I've created a scenario where you have multiple leaders on a team, and I want each leader to be able to recruit unique units. Each leader has a unique ID. So, I tried to use [set_extra_recruit] with a filter for the ID of one of the leaders at the beginning of the game to accomplish this.

Example code:

Code: Select all

[event]
    name=start
    [set_extra_recruit]
        [filter]
            id=Leader1
        [/filter]
        extra_recruit=Unique_Unit
    [/set_extra_recruit]
[/event]

Surprisingly, (to me anyway) this code actually gives Unique_Unit as a recruitment option to every leader in the game.
Am I using filters conceptually wrong here? Is what I'm attempting to do possible without going into the C++ code (i.e., does [set_extra_recruit] only affect a side's recruitment and cannot specify an individual unit's recruitment?) Also, if anyone has a solution in WML, it would be greatly appreciated.

Thank you!

[octalot]

set_extra_recruit is one of the tags that doesn't expect a [filter] around its filter, so it should be just:

Code: Select all

[event]
    name=start
    [set_extra_recruit]
        id=Leader1
        extra_recruit=Unique_Unit
    [/set_extra_recruit]
[/event]

[AkaMeDaemon]

Thanks for the reply.

I think your solution is actually how I first interpreted StandardUnitFilter. I just tried it again to make sure.
For whatever reason, it doesn't seem to work either. I also tried using quotes around the ID just in case. I even tried using the [side] ID to see if that would work.

The result: None of the leaders gain access to the Unique_Unit for recruitment in any of these cases.

[WhiteWolf]

For whatever reason, it doesn't seem to work either. I also tried using quotes around the ID just in case. I even tried using the [side] ID to see if that would work.

The result: None of the leaders gain access to the Unique_Unit for recruitment in any of these cases.

That's strange. If all supposed leaders have their canrecruit=yes set properly, and all leader id's and unique unit types are fine (typo-free), then I can't help in identifying what's wrong, but alternatively, you can also use the [modify_unit tag to set a leader's unique recruit list:

Code: Select all

		[modify_unit]
			[filter] # note that this tag does expect a filter child
				id=id_of_your_leader_unit
			[/filter]
			extra_recruit="Unique Unit Type"
		[/modify_unit]

I can assure that this definitely works well, because this is how I set up unique recruit lists with multiple leaders.

[AkaMeDaemon]

YES! That works! Thank you, WhiteWolf!

EDIT:
Turns out both methods work. This was not my actual issue. I had assumed that the ID was declared in the Leader.cfg file; however, I had to declare the ID in the [unit] tag that created the leader for the scenario (i.e., the filter was always working, but there wasn't a unit with the ID I was filtering).

Thank you both! Again, both methods do work.

[beetlenaut]

You have to declare an ID in both places because they mean different things. The ID in the Leader.cfg file is inside a [unit_type] tag (I assume), so it's the ID of the type. The ID in a [unit] tag is the ID of the specific unit that's being created.