I built my own entity groups by dumping all entity types from the game, applying various heuristics to collect some of them into groups, exporting some JSON, and pasting that into my TruePVE config.

...I then discovered that I couldn't kill some NPCs because they have names like `NPC_Bandit_Guard` but TruePVE's trace shows `npc_bandit_guard`.

Does TruePVE convert everything to lowercase or something?

I adjusted my output to convert everything to lowercase, and it works for that case, but I want to make sure that's the right thing to do.

it is case sensitive in some parts of the code.

type is in title case (BanditGuard), and the prefab is lowercase (npc_bandit_guard). this is how the game does it, and how it's setup in the default config.

`NPC_Bandit_Guard` is a prefab, and should be in lowercase. It's type in title case would be BanditGuard

why you do need entity groups for each of these though when the config covers most by default? anything missing, like Bike, could be added

it is case sensitive in some parts of the code.

type is in title case (BanditGuard), and the prefab is lowercase (npc_bandit_guard). this is how the game does it, and how it's setup in the default config.

`NPC_Bandit_Guard` is a prefab, and should be in lowercase. It's type in title case would be BanditGuard

I'm running code that I got from the lead developer of Carbon that extracts the type and name of all entities. It is not making up the case of `NPC_Bandit_Guard` so I don't know where that mixed case is coming from. I'll have to poke at it some more.

why you do need entity groups for each of these though when the config covers most by default? anything missing, like Bike, could be added

Because I have no idea what's missing, let alone what the exact names are; I just know there's missing stuff because TruePVE hasn't had a new release in a while. I'm not going to comb through stuff by hand when I can just have a script generate a new entity group list for me!

I understand it is difficult to know what is missing. this is especially difficult because prefabs have types. and prefabs inherit specific types. some prefabs inherit many types, and using the incorrect type would cause the specific rule to not function. in this instance, using prefabs only would be the safest option when creating your own entity groups. however, nothing of importance should be missing from the default config except for Bike. the plugin is up-to-date otherwise. if you notice something missing then I will include it in the next update for you.

it should be noted that prefabs for buildings, doors, and others are not included with the default config. this is because damage to these entities are blocked by default as defaultAllowDamage is set to false. you would need to manually add these if you wished to allow the damage instead. though this should not be necessary. for example, if you want to allow owners and their ally to damage their own entities then flags are available for this.

TruePVE and other similar PVE plugins are very expensive on server performance as they handle all damage on the server from every source. it is important that there be as few prefabs and types used to reduce the impact that it has on server performance. using more prefabs and types will increase the amount of time it takes for evaluations, and therefore require more server resources. the default config uses the least amount of prefabs and types to cover the most extensive range of protection by default. of course, there is always room for improvement, and some redundancies do exist simply to give a better understanding to users on how to create their own rules and entity groups.

if you are having an issue with a specific rule, flag, or entity group then there is no question that I can't answer. I am less familiar with schedules, but I did pin a thread demonstrating how to use this. mappings for zones is usually part of ZoneManager or DynamicPVP, but I can try to answer those questions too.

Regarding my code: It looks like the problem was that Raul had me using `UnityEngine.Object.name` instead of `BaseNetworkable.ShortPrefabName` - which turns out to be the same thing as `UnityEngine.Object.name.ToLower()`. Edit: I should also clarify that while I'm generating a full set of entities, I'm not creating rules for all of them!

Appreciate the background info, as I'm new to TruePVE. I did not create any rules for buildings/doors (except for barricades and high walls because I don't want players walling off PvE monuments) as I intend to use AgileZones to make player bases PVP zones in order to allow online raiding (and to allow edwin's OfflineRaidProtection to handle damage to everything in a build privelege).

One question: The documentation on the `HumanNPCDamage` flag is just "Enables HumanNPC damage" - what does this actually mean? When I enabled it, it seemed to actually mess things up, and when I disabled it, things seemed to behave according to my rules.

ah ok nice. interesting setup. HumanNPCDamage allows npcs to do damage to players. multiple types of npc exist now so it was extended to every npc type. this doesn't include animals. this should not cause any unexpected behavior. here is the relevant code.

                    // allow Human NPC damage if configured
                    if (ruleSet.HasFlag(RuleFlags.HumanNPCDamage) && IsHumanNPC(attacker, victim))
                    {
                        if (trace) Trace("Initiator or target is HumanNPC, with HumanNPCDamage flag set; allow and return", 1);
                        return true;
                    }​

Okay, I tested again, and I think maybe what scared me off of HumanNPCDamage it allowed me to kill `bottest` entities, making it impossible to tell without a real player online whether PvE enforcement is working.

I got things to work the way I wanted via rules, but I suppose HumanNPCDamage is better for performence due to avoiding ruleset lookups?

P.S. If you're interested, here is my TruePVE config - feel free to poke holes in it since I'm still learning: https://pastebin.com/7GSwCy6m

not necessarily. if you wanted to block specific npc from hurting a player then you would not use the flag.

poking holes. I hope that you understand that I am trying to be helpful and all of my comments below is to improve performance by reducing the size of the config.

this config was surely a tedious task, and I love the enthusiam behind it, but the majority of it is centered around allowing damage to multiple types which requires entity groups with a large assortment of prefabs. many of the prefabs could be replaced with its type, which would considerably shrink the size of the config. 

multiple entity groups contain members of entities that will not be evaluated (or used), such as HZ_NonCombatEntity. this is because weapons generally (with some exceptions) would have the player as the initiator. so the player would be registered as causing the damage rather than the weapon. such prefabs could be removed from the config without altering its functionality

defaultAllowDamage exists to minimize the amount of rules, entity groups, and members within entity groups:
if set true, then you would create rules specifically for blocking damage to entities instead. 
if set false, then you would create rules specifically for allowing damage to entities. this is how the default config is designed. there are some exceptions, but the majority of damage would be blocked by default.

it certainly looks like it was an interesting experience writing this config and I hope that you learned a lot from it. it is invaluable as a server owner to have such specific knowledge. 

poking holes. I hope that you understand that I am trying to be helpful and all of my comments below is to improve performance by reducing the size of the config.

100% understood and appreciated.

this config was surely a tedious task, and I love the enthusiam behind it, but the majority of it is centered around allowing damage to multiple types which requires entity groups with a large assortment of prefabs. many of the prefabs could be replaced with its type, which would considerably shrink the size of the config. 

I don't quite follow this, as I went as high as I could in their class hierarchies as seemed to make sense for grouping purposes. A ridiculous number of them also derive directly from `BaseCombatEntity`.

multiple entity groups contain members of entities that will not be evaluated (or used), such as HZ_NonCombatEntity. this is because weapons generally (with some exceptions) would have the player as the initiator. so the player would be registered as causing the damage rather than the weapon. such prefabs could be removed from the config without altering its functionality

That's excellent info, thanks!

defaultAllowDamage exists to minimize the amount of rules, entity groups, and members within entity groups:
if set true, then you would create rules specifically for blocking damage to entities instead. 
if set false, then you would create rules specifically for allowing damage to entities. this is how the default config is designed. there are some exceptions, but the majority of damage would be blocked by default.

Right. I clearly struggled with this. I was scared off of `defaultAllowDamage: true` because someone in this forum said it had unexpected side-effects, and others responded that they shouldn't use it. But the thing is, I ultimately only care about preventing damage to players that is caused directly or indirectly by other players - I don't want to have to fiddle with things to preserve ch47 damaging scarecrows etc. (talk about tedious!)

it certainly looks like it was an interesting experience writing this config and I hope that you learned a lot from it. it is invaluable as a server owner to have such specific knowledge. 

I'm getting there, but it's still a bit squishy. I should probably circle back around to your default config and really try to understand your thinking there.

yes it is a ridiculous number, but that's because entities with health will inherit BaseCombatEntity. I understand why that would be confusing, but it would be like saying people are humans. though some are cops, doctors, firefighters, criminals, elderly, guards, etc. those would be the "types" of people, they just inherit being a human too, if that makes sense.

defaultAllowDamage and my responses were towards PVE servers in saying that false should be used more often than not. when wanting to block PVP and allow the rest then it's a different story. 

it should be easy for you after having created your own config now. just take note that there are some redunancies simply to show examples to user on how to edit.

Right, but stuff like advent calendars, drones, fishing bobbers (why?!), new year gong, etc. all derive directly from BaseCombatEntity - there's nothing in else in their class hierarchy like there is for BanditGuard (HumanNPC->NPCPlayer->BasePlayer->BaseCombatEntity). I don't want randomly placed deployables to be impervious to player damage.

It will be interesting to see what pops out of a reexamination - I'm concerned about how fiddly hammering out PvE-versus-PvE stuff is going to be (e.g. allowing cars to hurt scientists, ch47 to hurt scarecrows, etc.). I can see where `HumanNPCDamage` is going to help sidestep a huge swath of cases there, though.

because they can all be destroyed. I agree though. they wouldn't be immune to damage with defaultAllowDamage set to true unless you have a rule forbidding it

HumanNPCDamage is for npc damage to players, and wouldn't be necessary with defaultAllowDamage set to true.

all damage would be allowed that has no rule or flag. you would create rules to block damage

Sorry I missed "when wanting to block PVP and allow the rest then it's a different story." I guess I'll play with defaultAllowDamage set to true, since yes my intention is to block only PvP when not in an exclusion zone or outside of height limits. I run a casual server that currently allows KOS/PVP only at medium/high tier monuments, and am working towards using a collection of plugins to enforce that.

no problem..good luck