Make FilterByClass functional

[PinkysBrain]

The FilterByClass bodypart filter function in X2SimpleBodyPartFilter.uc and the other functions which make use of it, don't make sense. They do not check against the character class being identical to the part template reqclass like you'd expect (they fundamentally can't either, Set(...) would have to pass the character class first). They checks if HQ exists and if so they check if the reqclass exists on the crew roster ... which makes little sense, unless it's intended for them to just hand their class helmets out to rookies as welcome gifts.

Easily observed by just spamming create character in the character pool, which creates rookie soldiers with such helmets occasionally. This presumably was why they used the work around of helmet lists in XComNameList.ini.

[robojumper]

Hello,

as far as I can see, it works like it's supposed to work. The WotC *Content.ini add the Hero helmets as helmets available to all soldiers, but they are only available as soon as the faction is contacted.

I don't see a compelling argument to change it, especially since -- as you said -- X2SimpleBodyPartFilter doesn't even know about the target class. Customization code is duplicated A LOT in mods and DLC code, so any changes would probably only work 50% of the time.

---

I'm actually not sure about the character pool behavior. Getting XComHQ on the shell is iffy. It is an actionable issue, I think, to specify that behavior, as in:

In the Character Pool, ReqClass filters always pass.

or

In the Character Pool, ReqClass filters are denied.

and reflect that in the code.

---

I'm not sure I understand your point about XComNameList.ini..

[PinkysBrain]

The helmets have ReqClass="Templar"/"Skirmisher"/"Reaper" in their BodyPartTemplateConfig in DefaultContent.ini ... which currently get checked against the crew by MeetsSoldierClassGates in XComGameState_HeadquartersXCom.uc after HQ exists. So it really is as if they start handing them out once they get on board, except that the HQ check also means they end up on created characters in the character pool.

XComNameList.ini has MaleHeads/FemaleHeads arrays of allowed helmets for each resistance hero. The normal mechanism for such functionality is to build a list on the fly with Bodyfilters and Ubertemplates and BodyPartTemplateConfig parameters, so you don't have two lists which can go out of sync.

To give an example of why this is generally a bad idea other than a quick work around to ship can be found in this mod https://steamcommunity.com/sharedfiles/filedetails/?id=1186461636 ... he wanted to allow the hero classes to wear normal helmets, but not each others. The logical way to do that would be to build lists of helmets for ReqClass == "Soldier" or "" or their own hero class, combine them and then pick from that. Instead he adds the other hero class helmets to an ExcludeHelmets array. This a fragile solution which breaks the moment someone else adds a variation on a hero class helmet (ie. one with a ReqClass entry). Even if he had used the MaleHeads/FemaleHeads arrays of the other classes instead, which would have been slightly more elegant it would still be inherently fragile.

There is a method to Bodyfilters which the lack of true class filtering breaks. That they end up on rookies is almost certainly a bug. Also they look just incredibly ugly on most soldiers and they don't have a DLCName, so you can't filter them out with the sliders in the gameplay menu.

[PinkysBrain]

I'm playing a campaign now with the following added code in CreateTSoldier in a an override of XGCharacterGenerator.

BodyPartFilter = CGF_X2SimpleBodyPartFilter(`XCOMGAME.SharedBodyPartFilter);
BodyPartFilter.SetCharacterTemplateName(CharacterTemplateName);

and the following override :

class CGF_X2SimpleBodyPartFilter extends X2SimpleBodyPartFilter;

var protectedwrite name CharacterTemplateName;

function SetCharacterTemplateName(name inCharacterTemplateName)
{
	CharacterTemplateName = inCharacterTemplateName;
}

function bool FilterByClass(X2BodyPartTemplate Template)
{
	if ((Template.ReqClass == '') || (Template.ReqClass == CharacterTemplateName))
		return true;
	return false;
}

Everything seems to work fine and those fugly helmets stay off my recruits.

[PinkysBrain]

Playing again because of LWotC and decided to throw up the mod which fixes FilterByClass to actually filter by class on the workshop.

https://steamcommunity.com/sharedfiles/filedetails/?id=2336346346

Also allows setting the random generation chances for gender, tattoos, scars, facepaint, camo and non standard eye colour. Also filters out cosmetics by blacklist and has a hard coded fix for Destroyer's face pack.

[Iridar]

Faction soldier helmets appearing on new soldiers created in character pool is - arguably - a problem, but fixing it by fundamentally changing how the filter works in the actual campaign is outside of the Highlander's scope. So I'll be closing this issue. Feel free to reopen or file a new one if you wish to offer another solution.

As an alternative, look into #784. It is a general-purpose hook that gives you the appearance of a generated unit, and then you can do arbitrary changes to it. Including removing/replacing faction soldier helmets on soldiers created in character pool.