When Death Notes is loaded with TruePVE, Molotov/FireBall damage stops working on things like wooden boxes.

I checked and it happens because Death Notes changes the HitInfo.Initiator in OnFireBallDamage.
If I unload TruePVE, Fireball damage works again.
If I remove OnFireBallDamage hook, Fireball damage works again.

I'm unable to reproduce your issue. I run a PvE server that uses TruePVE and DeathNotes, and I'm able to damage and destroy wooden boxes with molotovs and other fire with no issue. If I were to take a guess, you have a configuration issue in your TruePVE that is preventing the damage to occur. This is likely why the issue is resolved when you unloaded TruePVE.

Can you share your truepve config with me so I can take a look?

Merged post

Sorry, I forgot to mention that it was only in the wood storage boxes that spawn with the Dungeons Event plugin. I checked the plugin and there are no settings that mention fire/fireballs.

I see that plugin has a non-trivial cost, so I won't be able to obtain it and confirm my suspicion that the Dungeon plugin is the issue. DeathNotes receives a copy of the HitInfo.Initiator information. Because it's received in a call-by-value way, changes made to the Initiator by DeathNotes do not impact other plugins calling the same hook. The fact that boxes burn just fine in normal gameplay with DeathNotes running, but do not with your Dungeon plugin makes it pretty evident that they are spawning the boxes in some atypical way that is causing the problem you're seeing. I apologize that I can't be more helpful, but this does not appear to be a DeathNotes issue and I would recommend reporting your problem to the Dungeon plugin dev.

The code snippet you included isn't an example because hitinfo isn't being modified and like I said, is call by value. However, you're referencing OnFireBallDamage, specifically this, correct?

using Oxide.Core.Plugins;
using UnityEngine;

namespace Oxide.Plugins
{
    [Info("DungeonTest", "Test", "1.0.0")]
    class DungeonTest : RustPlugin
    {
        // For test purposes: treat every StorageContainer as "dungeon"
        bool IsDungeonEntity(BaseEntity ent) => ent is StorageContainer;

        object CanEntityTakeDamage(StorageContainer storageContainer, HitInfo hitinfo)
        {
            Puts("CanEntityTakeDamage");
            if (storageContainer == null || hitinfo == null) return null;
            if (!IsDungeonEntity(storageContainer)) return null;

            Puts($"Initiator: {(hitinfo.Initiator != null ? hitinfo.Initiator.GetType().Name : "NULL")}");
            Puts($"InitiatorPlayer: {(hitinfo.InitiatorPlayer != null ? hitinfo.InitiatorPlayer.displayName : "NULL")}");

            if (hitinfo.InitiatorPlayer == null)
            {
                return false;
            }

            return true;
        }
    }
}

Please see my last comment, comment those two lines out, and let me know. Thanks. Also, I'm real curious why the Dungeon plugin requires a player to be Initiator for box destruction to work properly. 

OK, great, you're set then. I'm still evaluating whether or not this will cause issues to the plugin to make that change permanent. I know that DeathNotes uses Initiator as a backup source if the player/NPC entity is unknown for whatever reason. Early testing shows no observable effects. In any case, you have a workaround for now.

There's real danger in a plugin relying on Initiator to determine whether or not fire damage should destroy an object. Since fire can spread from one object to the next, it may have an environmental Initiator regardless. Just food for thought.

		private void OnFireBallDamage(FireBall fireBall, BaseCombatEntity target, HitInfo hitInfo)
		{
		    if (hitInfo.InitiatorPlayer != null)
		        return;
		
		    hitInfo.Initiator = fireBall;
		}

Maybe update the hook to avoid overwriting the Initiator when a player is already present?

I may go that route, but so far I'm not seeing where setting the Initiator to the fireball is even necessary. I've done all sorts of fire damage to NPCs, animals, and objects, and I don't see a difference. If that proves to be the case, I'll remove the hook call entirely.