Null effectBundle added on first player death [CLOSED]

[R.D.]

Using the latest code (commit 16b2a1e), I noticed that an effectBundle is added to the player the first time they die after starting the program. It is not added on the 2nd second onwards, regardless of whether its the same character.

The on-screen "save versus spell made" message can appear once or multiple times when this happens.

A debug message like the following, with its trace, appears in the Unity console:

Code: Select all

Adding bundle -961925120
UnityEngine.Debug:LogFormat(String, Object[])
DaggerfallWorkshop.Game.MagicAndEffects.EntityEffectManager:AssignBundle(EntityEffectBundle, Boolean) (at Assets/Scripts/Game/MagicAndEffects/EntityEffectManager.cs:505)
DaggerfallWorkshop.Game.MagicAndEffects.EntityEffectManager:PassiveSpecialsCheck() (at Assets/Scripts/Game/MagicAndEffects/EntityEffectManager.cs:1609)
DaggerfallWorkshop.Game.MagicAndEffects.EntityEffectManager:Update() (at Assets/Scripts/Game/MagicAndEffects/EntityEffectManager.cs:212)

To reproduce, load a Unity save (haven't tried with a classic save) and die (confirmed with both being killed by enemy attack and dying from a fall.).

[R.D.]

Seems to also happen whenever you load a classic save, when the game loads, rather than when the player dies.

[Interkarma]

The PassiveSpecialsEffect is an always-running effect that delivers permanent non-spell payloads like special advantages/disadvantages. This is assigned when not already present as part of the EntityEffectManager update loop, so it can happen at any time.

For most characters, this effect is restored as part of normal effect bundle deserialization. This means you will only see it assigned when character is reset (e.g. character creation, death, or loading a classic save). The effect itself is persistent and stateless - it just needs to exist as an active incumbent in the player's effect bundles. It's mostly dormant unless it needs to perform work based on character specials.

It doesn't appear to be null to me at the time it's being added by PassiveSpecialsCheck(), and it is intentional this effect is added whenever missing. I'm not sure if this one is a bug so much as intended behaviour.

Edit: Ah, I think I see. The core issue is probably not that the effect is being added, but that it can be resisted, resulting in one or more "resisted" messages. Yes, this is an unintentional side-effect of recent resistance changes for non-magnitude effects. I'll fix this shortly, along with other cases it could be a problem. Thank you for bringing to my attention.

[Interkarma]

The problem of passive specials and other system effects being improperly resisted should now be resolved by this merge.

[R.D.]

Thanks for fixing the spell resistance messages.

It doesn't appear to be null to me at the time it's being added by PassiveSpecialsCheck()

I probably shouldn't have called it a "null effectBundle". I didn't mean there was a null reference exception or anything, but when I printed out the name of the effect being added it was (and still is), "Null".

Just before the line

Code: Select all

Debug.LogFormat("Adding bundle {0}", instancedBundle.GetHashCode());

in EntityEffectManager.cs, I added

Code: Select all

                Debug.Log(instancedBundle.liveEffects[0]);
                Debug.Log(instancedBundle.name);
                Debug.Log(instancedBundle.bundleType);

and the results were

Code: Select all

DaggerfallWorkshop.Game.MagicAndEffects.MagicEffects.PassiveSpecialsEffect
Null
None

which seems kind of odd, but is this intended behavior? The character I tried it with has no spells, enchanted equipment, special abilities or diseases.

Is it that all characters always get a PassiveSpecialsEffect bundle, regardless of whether there are any actual effects on that character?

[Interkarma]

All characters get an instance of this system effect. It's never seen by player and doesn't require a display name. The effect system itself only need key and class type to track instance.

The presence of this effect bundle isn't a bug. But you also identified it was being resisted, which was. I've fixed that issue now. Thanks for the spot, it would have caused some problems if that went through to next builds.