Changing bot desirability of inventory without subclassing?

[1337GameDev]

I have an item that when bots pick it up, cannot pick up armor, health, shieldbelt, etc.

I notice an odd behavior; when they have my item, they get stuck trying to pick up a "denied" item. How would I change desirability of items that the bot attempts to path towards?

My item restricts all items that have "IsAnArmor" set to true, so i cannot just subclass all items.....

Ideas?

[sektor2111]

What is hard-coded in armor and has a dynamic desire based on that code cannot be changed without rewriting/replacing function. Armors are not having clue about non-stock community items for adjusting themselves and also they don't know what will be done in 2024.

[papercoffee]

Let's say it would be sub-classed...
can you target an individual bot and lower only for this one the desirability when it has a special item?

[sektor2111]

Okay, resuming...
If we look at Armors generally they don't have too much Bot related code... but "super class" Inventory has something concerning charge.
I suspect that first move doable would be setting up desire "-1" and then... calculating "ArmorAbsorption" vs "Charge".
Snippet from Inventory - "BotDesireability( pawn Bot )"

Code: Select all

	if( bIsAnArmor )
	{
		if ( !bChecked )
			AlreadyHas = Bot.FindInventoryType(class); 
		if ( AlreadyHas != None )
			desire *= (1 - AlreadyHas.Charge * AlreadyHas.ArmorAbsorption * 0.00003);
		
		desire *= (Charge * 0.005);
		desire *= (ArmorAbsorption * 0.01);
		return desire;
	}
	else return desire;

If calculus returns "-1", I think Bot won't move at these items at all - it's ignoring them.
Secondary measure: Replacing/Removing these buggers in presence of another "uber" item, bugging things together might not work normally and it's a lot of work for no reason. I would replace these with some clone looking like an armor but having no desire and no reaction at touching. Why would have Armors if they cannot be picked up ?

Note: Some people said that replacements are slowing down things generally. Actor is checked for desired class using ISA. For me things can be accelerated normally using UT rules "Other.bIsPawn" "Other.bIsItemGoal" preventing checks if Pawn is an armor and an armor if is SkaarjTrooper. In my games DMMutator (and other similar copy-paste codes) is already history. Checking a bool in front of an iterator is definitely faster - last time clocking a bool check in my rigs was delivering 0.000000 seconds. Why would use ISA first for checking "Other" when "Other" is an "Actor" which can be all sort of classes ?

[1337GameDev]

Hmm, i really don't want to swap out these items, as I want other bots to still target them.

I am not sure of a way to modify the desirability for an item, per bot....

I also don't want to set charge of the items to 0, as this would also modify OTHER desirability for other bots....

Ideas? If I subclassed, i'd be able to override bot desirability, and just return -1 if the bot has my item, but i don't know what items will be on which map and don't want to subclass dozens of classes, and hope other mods or etc don't interfere..... :/ meh.