Somescrub

Alrighty.... I reverted AlphaLoot back to the original file and updated Botrespawn. I got it working by changing CanPopulateLoot to match AlphaLoot’s signature and not using IsBRSCorpse(), because IsBRSCorpse() only returns true while corpse == null — by the time AlphaLoot calls CanPopulateLoot, the corpse is already tied, so IsBRSCorpse returns false and AlphaLoot still populates. The working change is essentially “block if the steamID exists in BotDeathData regardless of corpse linkage” for CanPopulateLoot only. I didn’t change ShouldBLPopulate_NPC (BetterNPC/BetterLoot gate) — but since your original intent for IsBRSCorpse seems BetterNPC timing-specific, you may want to test BetterNPC/BetterLoot to ensure nothing relies on CanPopulateLoot as well. I'm thinking if that doesn't work you could keep IsBRSCorpse semantics and add a separate helper for CanPopulateLoot. Here is the revised snip that at least fixes the AlphaLoot issue, without modifying AlphaLoot: private object CanPopulateLoot(BaseEntity entity, LootableCorpse corpse) { if (!loaded || entity == null || corpse == null) return null; ulong id = corpse.playerSteamID; if (id == 0) return null; return DeathData.BotDeathData.Any(x => x.SteamID == id) ? (object)true : null; } Let me know your thoughts on that - I don't use BetterNPC or BetterLoot so I can't test those out with this change

Thanks for digging into that, it helped I think. I was able to isolate it to AlphaLoot. With AlphaLoot disabled, NPCKits loot populated correctly every time. Root cause looks like AlphaLoot’s corpse hook is still running on BotReSpawn corpses because the CanPopulateLoot veto hook in BotReSpawn has a signature mismatch from what I can tell (you can confirm). AlphaLoot calls CanPopulateLoot(BaseEntity entity, LootableCorpse corpse) from OnCorpsePopulate(...), but BotReSpawn currently implements CanPopulateLoot(ScientistNPC entity, NPCPlayerCorpse corpse), so AlphaLoot never receives the veto and populates the corpse anyway (on top of BotReSpawn’s own AlphaLoot.Call PopulateLoot logic). Might consider updating this method: private object OnCorpsePopulate(BaseEntity entity, LootableCorpse corpse) { if (!entity || !corpse) return null; object obj = Interface.CallHook("CanPopulateLoot", entity, corpse); if (obj != null) return null; return PopulateLoot(entity, corpse) ? corpse : null; } To this: private object OnCorpsePopulate(BaseEntity entity, LootableCorpse corpse) { if (!entity || !corpse) return null; var brsSignal = Interface.CallHook("ShouldBLPopulate_NPC", corpse.playerSteamID); if (brsSignal != null) return null; object obj = Interface.CallHook("CanPopulateLoot", entity, corpse); if (obj != null) return null; return PopulateLoot(entity, corpse) ? corpse : null; } That makes AlphaLoot skip BR corpses (it already exits if CanPopulateLoot returns non-null), and your AlphaLoot integration continues to work as intended. I tested this for a few dozen NPCs and it appears to be working as expected again. AlphaLoot is technically already doing the right thing by providing a veto hook and respects it; it’s just not being hit because of the type mismatch. Let me know your thoughts - I will continue monitoring behavior and let you know if I see anything else squirrely going on. Hopefully this puts it to bed!

Looks like the attached image... The bandana and sheet metal I believe are just from the default scientist loot pool. The dog tag is part of the kit this particular profile pulls from (don't know which one in-particular, there are a thousand defined per-portfolio). The thing that is not making sense is that the tag is just one item out of those inventories, so I don't understand why the rest is suddenly getting wiped. I will run into one of these every 2-3 NPCs I kill, sometimes even more frequently. Never did this before I updated the plugin, and there are no console errors occurring.

Everything is freshly updated from the patch on the 18th, but my first report on this came in on the 16th anyways. The only other thing I changed within that timeframe was the NPC ID issues with XDQuest and TalkingNpc, which shouldn't be causing this behavior I wouldn't think. I updated this plugin at the same time, because I noticed I was still on 1.4.4 - that is why I felt there was some sort of logic change that was causing this

Hey there, I've gotten reports, and experienced myself, several instances of bots that are not producing the full inventory of a kit when killed. In most instances I have kits defined with 10-15 items in the inventory that will drop on death, but since updating to 1.4.9 just a few days ago (related to the ID issues) there are many instances where they are only dropping 3-4 items on death. This isn't a 1:1 issue - other bots behave correctly, but randomly others display the above behavior. This does not appear to be a complete kit failure either, as they are dressed appropriately and also have the correct weapons - this is just an inventory issue. The reduced items are also technically correct, as one item I have persistent across profiles are the use of tags - those are still always present, so I know it is pulling on the config. Would like your thoughts on it - I have not changed anything else related to them, so I don't know if maybe this is a change to the on-death wipe logic or not?

Those two I mentioned are core to my server design, so I will probably just investigate fixing them myself for the time being until they get an update. However, I do appreciate you explaining what is happening here - I did not realize that was what was going on, but it does make sense.

If I am understanding that correctly you are saying that any plugin spawning NPCs that utilizes userID could make any other plugin spawning NPCs, regardless of userID use, become invisible? That's a pretty shitty situation to pass off to both devs and admins from the framework side - has this not been a consideration to solve for broadly? I mean even an oxide debug warning that calls out userID collisions sounds like an appropriate thing for something so impactful. I did a quick search on my December backup plugins folder: Based on what you described, it looks like maybe XDQuest or TalkingNpcs could be the offenders? I see XDQuest it is making a hardcoded ID for the questgiver NPC. To compound that issue a bit, I do reload the plugin every hour to ensure the building gets pasted correctly, so I could see how that might cause conflicts randomly. I have quite a few TalkingNpc NPCs as well, and those are basically hardcoded IDs in practice - so I could see how that might also affect it. However, both of those plugins have been running un-altered for quite some time... is this userID logic something FP introduced specifically in November?

I don't know if they spawn invisible, or turn that way... only time I have ever caught them they are already invisible, and players report the same. I suppose load could be a factor, but I'm not really in a position to completely disable any of them - they are all doing it, so something more broadly must be causing the issue... whether it is load, code, or gremlins. Only thing that is consistent is that this all started after the November update...

It is happening to multiple players - I have experienced it myself several times, and the screenshots I provided over at my other support ticket were taken by me. All reports, with the exception of today's for zombiehorde, have been for invisible Botrespawn npcs and Bossmonster npcs.

That checked out as well - I don't think I ever edited it from default to be honest. Attached it for reference. NpcSpawn.json

I realize the error is specific to NPCSpawn, hence why opening the ticket here. To your point though, I am seeing the same behavior with BotReSpawn NPCs and also got a report today for ZombieHorde NPCs being invisible. Identical behavior happening across multiple plugins that spawn NPCs, but leveraging different spawn methods. The JSON checks out, at least for the BossMonster files. I haven't made any recent changes to BotReSpawn or ZombieHorde since November that would explain those. These invisible NPCs also happen randomly. It is not an entire profile or anything that it triggers exclusively to, or an entire profile population. Just a random one here or there across the map. I attached a boss config for reference (the one in the provided screenshots over on my BossMonster ticket: https://codefling.com/files/support/25268-invisible-bosses/). Cobalt Captain Kael Durn(1).json

This is occurring across plugins that leverage NPC Spawn and those that do not - which tells me it is a coding issue holistically. For instance, the same behavior is being identified with Botrespawn and ZombieHorde NPCs, but those do not leverage the NPC Spawn plugin. This seems to be a more holistic issue with custom NPC spawning in general, but does warrant some additional investigation on the part of the spawn plugin devs. These issues surfaced after the November update - @Steenamaroo attempted some fixes for BotReSpawn, but I am still seeing the issue occur even with the fix version in place (haven't had a chance to open a support ticket on that one).

yes - does not matter whether that setting is enabled or disabled, happening regardless

I am not for this particular boss. I do for others though, and I get this issue regardless occasionally. With the invisible ability they eventually should become visible again, but in this case they remain invisible indefinitely.

Getting this semi-frequently in console: Failed to call hook 'SpawnNpc' on plugin 'NpcSpawn v2.8.4' (NullReferenceException: Object reference not set to an instance of an object) at Oxide.Plugins.NpcSpawn+CustomScientistNpc.UpdateInventory () [0x00116] in :0 at Oxide.Plugins.NpcSpawn+CustomScientistNpc.ServerInit () [0x00164] in :0 at BaseNetworkable.Spawn () [0x0004f] in :0 at BaseEntity.Spawn () [0x00000] in :0 at Oxide.Plugins.NpcSpawn.CreateCustomNpc (UnityEngine.Vector3 position, Oxide.Plugins.NpcSpawn+NpcConfig config) [0x0007b] in :0 at Oxide.Plugins.NpcSpawn.SpawnNpc (UnityEngine.Vector3 position, Newtonsoft.Json.Linq.JObject configJson) [0x00008] in :0 at Oxide.Plugins.NpcSpawn.DirectCallHook (System.String name, System.Object& ret, System.Object[] args) [0x000b0] in :0 at Oxide.Plugins.CSharpPlugin.InvokeMethod (Oxide.Core.Plugins.HookMethod method, System.Object[] args) [0x00079] in :0 at Oxide.Core.Plugins.CSPlugin.OnCallHook (System.String name, System.Object[] args) [0x000de] in :0 at Oxide.Core.Plugins.Plugin.CallHook (System.String hook, System.Object[] args) [0x00060] in :0

You think this is something that is fixable, or no? If not I am going to remove blastmine from my item perks, because it will never be worth using when you have epic gear on (or my RP skills on top of it)

My players started reporting that food buffs don't persist when they get disconnected. I'm pretty sure this isn't a bug, considering there doesn't seem to be a reference to buff durations in the data files - but is this something that can be added? For those of us running expensive cooking recipe setups it is a real downer when you get a flyhack, timeout, or high ping type of disconnect and lose hours of ingredient farming for the big buff you had been saving up for.

So did some simple tests with some epic gear on and with/without the cooking super serum recipe I have that mimics the in-game serum attributes. When mining a single node of metal with the serum active I got 8727 metal ore. When I applied the legendary with blastmine perk and harvested a sulfur node, with a metal node within proximity, I am only getting 2175 metal ore for the perk trigger. Definitely not applying the cooking item buff to the blastmine perk trigger for those nodes within proximity, and I would agree it would not be worth using the item with the perk as a result.

For the record - also getting this for BotReSpawn NPCs, but I see he has a fix out for that which I need to put in and see if it actually fixes for them. Same thing going on with this plugin, however. NPC is invisible, can damage player and player can damage it. Floating weapon on spawn location. Does not happen all of the time, and there are no console errors when this occurs, or during interaction.

I did have him test it with a normal p2 and he experienced the same behavior, so you are correct it does not seem to be this plugin. Not entirely sure what is happening, havnt been able to replicate it myself... might just be a FP thing.

Had a player run into an issue today with a semi-auto pistol that is configured as a legendary item. He has a shield equipped, and when attempting to aim with the weapon it will unequip and give a white line center screen, plus the shield icon over to the left, but can't use the weapon - even though it is a shield compatible weapon.

I've been tied up lately, but I will try and get some testing in today on this and give you some data

One of my players recently noticed that when using a legendary item with the blast mine perk it only incorporates the mining buffs from vanilla sources like tea and pie. His concern was about a Cooking recipe I have for Super Serum (copy of the vanilla version, but custom in Cooking for the persistence aspect). He wasn't getting the mining bonus from the Cooking item for the nodes that the Perk triggered on. I am assuming this is because "the player" wasn't the one to mine out those extra nodes within the vicinity - that's the perk script. However he did bring up a good point that if that is the behavior (and I am assuming at this point the same for mining perks using EpicLoot), then it is not worthwhile to have, because you will always yield less ore than if you just ran node to node and had the other mining buffs active. Can you confirm this is the case?

My players noticed since the last update that tugboat protection is no longer working. I confirmed on my test server - you can add protection, but when damaging the boat it will not protect/deduct from the balance. Possibly unrelated, but the 30 second repair timer on the tugs also resets when it gets to 20 seconds - so they cant even be repaired. I doubt this plugin is doing that, but if so there is that context as well. No console errors to reference, unfortunately.

Thank you - that checked out... I also use CustomRecycle and there is a pickup option, which makes the button appear. No conflict on pickup when disabling, so we are good.