Mr01sam

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!

Changed Status from Pending to Can't Reproduce

Changed Status from Pending to Closed

Changed Status from Pending to Work in Progress

Hi, this issue will be fixed in a future update - in the meantime however you can simply add barrels (and any other entities you want ignored) to the "IgnoredEntities" list in the config. Here is a list of the entities https://github.com/OrangeWulf/Rust-Docs/blob/master/Entities.md you want the short name. The short name for barrels is "loot_barrel_1" and "loot_barrel_2". Here is an example of how this should look: Hope that helps!

So the Delay After Taking Damage is more of a setting for the delay a player must wait before they can manually start protection in the case that they are being online raided. The Delay for offline protection is the time that starts right after all owners go offline before protection starts. If the owner is already offline, then the Delay After Taking Damage no longer applies - instead it will continue to reset the Delay for offline protection as long as the building is attacked.

Is there any noticeable performance issue when this occurs?

Maybe you could reach out to me on discord so I can help in more depth? Discord - mr01sam

Could you elaborate more on what you requesting to be added?

Changed Status from Pending to Closed

Yup support for Survival Arena atleast is already on the suggestion board - closing this out since its not a bug.

Its a bit unclear to me what you are suggesting here, could you elaborate some more?

Changed Status from Pending to Closed