Mr01sam

I'll check it out then!

Changed Status from Pending to Work in Progress

The problem is that for that specific hook, the umod documentation defines it to return a bool, however it seems this can be changed to an object. If this was done in both WarMode and DCProtect, then this hook conflict in theory would be resolved. I might include this change in the next WarMode patch, I'll DM you what this would look like for both plugins and you can let me know if it resolves it for you.

Hey, so I did try this the other day (as I was fixing some other bugs) and the ignore permission seemed to be working correctly... even without a plugin reload. I know its been awhile, can you walk me through the steps of what exactly you are doing with the permission. For instance, are you assigning it directly to a player, or are you assigning it to a group? Is the person you are assigning it to the "founder" of the base, or are they just an "owner". Are they also an admin?

When you say "backpacks" do you mean like a wearable backpack that has been dropped, or a corpse bag?

Changed Status from Pending to Closed Changed Fixed In to 1.3.3

Changed Status from Pending to Closed Changed Fixed In to 1.3.3

Added that name now

DM sent

I might have a fix for you to try out in a few minutes, I'll DM you when ready

Are you on oxide or carbon? And do you have any plugins that add npc players?

That might be doable

Added you on discord

Changed Status from Pending to Closed Changed Fixed In to 1.3.2

Changed Status from Pending to Closed

Adding it to suggestion board - closing this out

Changed Status from Pending to Not a Bug

So although its not ideal, this is intentional - and here is the reason.. In order for WarMode to provide protection it needs to know who the attacker is, and who the victim is. For most entities/projectiles the information for who the attacker was is sent along with the projectile. However, for whatever reason, Facepunch doesn't provide this information for fire, so for any given fire entity there is no saying whether it came from a pvp or pve player, and therefore WarMode cant apply rules to it. So we could have it just always allow fire damage, but this is an issue because pvp players would use this exploit to raid pve players bases. So alternatively, fire damage is just disabled to prevent these exploits, at least until Facepunch makes the attacker info available for fire. This only happens when there's a TC because WarMode doesn't provide protection for most things if they are outside a base. Its also worth noting that its only the fire damage over time that is disabled. The initial fire damage from incendiary rounds/flamethrowers/molotovs and whatnot should still follow rules appropriately. Hope that clears things up - going to close thing one since its intentional.

Changed Status from Pending to Not a Bug

Hello! So I looked into this for you and what I found was kind of interesting. So it appears that this is actually working correctly, but it is a bit confusing, so let me explain. The InitialPlayerMode only is used for players who have never been assigned a mode in the past. Modes are driven by oxide permission groups, so if a player already belongs to the group "warmodepvp" then the InitialPlayerMode will not apply to them - it will only apply to people who have never joined your server since WarMode has been installed. If you want to make sure everyone has a "clean slate" then first unload WarMode, then run "oxide.usergroup removeall warmodepvp" this will of course make it so no one is in the pvp group. Then, if you have InitialPlayerMode set to pve, when you reload the plugin, everyone should be pve now as they do not already belong to another mode group. Keep in mind this is assuming you haven't added any other custom modes - if you have, you'll just want to clean those up as well.

I don't know if this helps, but just to clarify the "NPC" mode only applies to "npc players" as in, player entities that are spawned in by other plugins. NPC raiders should fall under this category and if I recall correctly I think that Zombies Hordes would too. Assuming they're both counted, there's currently no way to designate which ones are counted as NPCs. What's tricky about this is that these all are "player" entities, so its difficult to distinguish which plugin they came from in a way that could be provided by a config. I'm open to ideas though on how this might look in a config?

How would you suggest that a player is able to designate a friendly "neighbor" base, versus a neighbor they do not want to share stuff with?

Changed Status from Pending to Not a Bug

Currently NPCs actually refer to "fake players" that are created by plugins like BotRespawn. I know the name is a bit confusing, but currently this plugin does not provide protection against things like Animals, Scientists, or Tanks/Helis. So this is intentional for the time being.

I'll check it out for you!