Why does this exist?

Entities in D&D are broadly classified as "creatures" or "objects."
Only creatures can be "enemies" or "allies," and most spells target only creatures.

BG3 instead has "characters" and "items", which line up nicely and are used interchangeably, which works great for 99% of cases.

One of the 1% that hits a limitation is the Echo produced by the Echo Knight Fighter subclass. It's an object that looks like the character that created it. BG3 doesn't support items that look like characters, so it needs to be a BG3-character that works like a D&D-object.

This mod was made to support my Echo Knight mod, but there's nothing class-specific in it, and I've covered cases that weren't relevant but may be helpful for other mods. I encourage other modders with similar problems to use this mod instead of duplicating its functionality, as cloning it would cause conflicts between the two versions and be less performant than a single shared mod.



What does it do?

Adds a few tags that can be applied to characters to classify them as objects, patches the target conditions of thousands of spells and interrupts to respect the tags, and provides a function for retrieving a list of status immunities that mods can use to patch their own character stats to cover some spells that are applied via status auras.

It is not a complete one-stop-shop solution for making object-characters but handles the messiest part. Mods using it should still apply broader boosts and immunities fitting their particular cases. In general, the rules state that objects are immune to poison and psychic damage, and this mod further assumes but does not provide immunity to the SG_Poisoned status group. It's also assumed that the IgnoreLeaveAttackRange() boost is used, as objects don't provoke opportunity attacks.

I've set up rules for spells that exist in D&D to match as closely as possible (though surely making mistakes; there are a lot of spells.)
For unknown spells it's assumed that attacks can target objects and saving throws cannot. More complex cases will depend on how their target conditions are expressed.



How do I use it?

As a player, place this mod before (above) any mods that require it in the load order.


As a modder, add the OCS_ObjectCharacter tag to your character's GameObject template via GUID, as well as the OCS_MagicalObject and OCS_NonFlammable tags if applicable.

Do not use the Tag() boost, as that sometimes causes crashes if the mod containing the tag is removed.

Call Mods.ObjectCharacterSupport.GetStatusImmunitiesString() to get the status immunities to add to your character's PersonalStatusImmunities. See the Echo Knight mod for an example of how to use it.

Shatter and Disintegrate can target objects but not magical objects.

Burning Hands, Fireball and Lightning Bolt can target objects but not non-flammable objects.
The game also has many spells and effects based on Burning Hands and Fireball, and I've given those the same treatment in most cases.



Compatibility

This mod is safe to uninstall at any point, even while keeping a mod that uses it, as long as Larian doesn't change the game to start crashing on missing tag GUIDs.

The spell patching is done entirely via BG3 Script Extender so doesn't cause file or definition conflicts, but it's possible it could cause problems with other mods in two ways:

For spells that weren't covered by some special case patching rule and couldn't be deduced to be irrelevant, calls to Character/Item/Enemy/Ally classification functions made in the target conditions will be replaced with alternate versions that handle the new tags.

This by itself shouldn't cause any problems, but if another mod does the same kind of patching of the same functions, or inspects the condition looking for them, then either it will have to be aware of this mod's functions or the other way around, depending on load order. I'm not aware of any other mods like this, and it would likely be simple to resolve such conflicts, but it would have to be done. Let me know if it's ever an issue.

For spells that were covered by a special case (so the above didn't apply), the entire pre-existing condition is wrapped in a parenthesis and combined with another check. It's possible this might cause problems if the previous condition contained a syntax error that was accepted by the game anyway. If so the original mod should be fixed.