Despite set to false, it protects the TC. Seems to be defined, but nowhere used in source code. 

it's used for subscribe, but I forgot to add an option check since it is shared with newly added options. fixed in next update thanks!

Tried with TruePVE from github, completely without Teams, Clan and Friends.

Well, it's a question of what "enemy player" means? For now it blocks already TC-authed players. Is not, what I exspected.

Hi, thank you for trying it out! An enemy is any player who does not own the TC and is not an ally of the owner. An ally is any player who is a friend, clan member, or teammate. For Tool Cupboards, being authorized does not make the player an ally; having access to the locked lock does.

Anyone who is not an ally or the owner should not be allowed to access a TC without a locked lock. If the TC has a locked lock, access is not blocked. As shown below, this code checks whether a lock exists and is locked, then returns without blocking if it is.

if (baseLock != null && baseLock.IsLocked()) return null;​

• If a TC is protected by a locked lock, any player with access to that lock may auth on the TC without being an ally or the owner. I could make this optional, but I don't see why that would be necessary. 
• However, players who are not an ally or owner cannot auth on a TC with no lock, or with an unlocked lock, in order to place their own lock and gain authorization that way.

• If you are not the owner or an ally, and are authed on TC, then you should not be allowed to loot the TC unless the TC has a locked lock. 

Well, I begin to understand the problem. Let's explain my general view for PvE-servers:

First situation, you have an item or buildingblock outside a buildingrights (TC) area. So you have to go with the ownerID and allys, is there a lock?, etc. Give some options for the admin, how it should be handeld. For my server I prefere vanilla behaviour, and configured the remover tool the same way. But other more cosy servers may set it more protective.

Second situation, you have items and buildingblocks in a TC range: What can happen?

1) You have a strict solo player, who is the owner of everything and TC-authed.

2) Now comes the PvE or RP Situation: A group of players build together, all TC-authed. Now you end up with a mix of owners at items and buildingblocks. They of cause like to change/destruct things set by teammembers while the wipe goes.

3) You have a solo or group playing RP, where for interior a designer is hired, and electricity is made by someone else. All these contractors would get TC-authed to get building rights for a short time to do their work. After that, they are deauthed. Or a original member of the group leaves, maybe just doing it's own thing, or because of an devorce in RP, so it's deauthed at TC.

In my opinion regarding to protect/destroy Items and building blocks, if there is a TC, the ownerID of things in the TC-area doesn't matter at all, also do the allys of this ID. If a player is TC-authed and so has building rights, he/she can destroy and take things, because this is needed for building. If the player is not TC-authed, TruePvE by default blocks all damage because of "handleDamage": true". So, if prefered we only need some clear options to relax the protection a little more like vanilla is:

"Building Protection": {                                    <== ex. "TwigDamage (FLAG)" config
"Block Damage To Twig: false,
"Block Damage To Wood": true,
"Block Damage To Stone": true,
"Block Damage To Metal": true,
"Block Damage To HQM": true,
"Block Damage When Owners Are Offline": false,          <---- offline raid protection
"Log Offenses": true,
"Notify Offenders": true,
"Reflect Damage Multiplier": 0.0,
"Multiplier Allows Armor Protection": true
}

If the "Block Damage To ..." part is internally a bitmask, it can easely be binary-anded with 0x0f to see if there is something to do, and fire the messages.

I would allways have in mind TruePvE should be a protection-plugin against vanilla rust. By default trying to protect everything, but giving options to relief this protection a little bit. But not more, than vanilla Rust is. And Teams for example have nothing to do with building-rights. They are for common markers on the map-view, seeing the green dot at distance and having team chat.

On the other Hand, it is Rust. If someone wants 100% protection against other players, he/she should go on a private server, or a sandboxed building server. 

"Block Damage When Owner Is Online" and "Block Damage From Ally" do not make sense to me, because who is the owner, or ally of whom? As I said, when there is a TC all TC-authed players at a given time are owners, if you like so.

Assuming it should be some kind of offline-raid protection, it should be "Block Damage When Owners Are Offline", and means all "Block Damage To Twig/Wood/Stone.." options should be  assumed as set true for the time, no TC-authed player (Owner) is online.

And "Block Damage From Ally" means something like if damage is allowed, but block friendly fire? You than have to check if the offender is an ally of any TC-authed player. Quite expensive, and I don't know if it will be used by some server.

Well, back to the topic: All in all, I personally would just delete the option "Protect unlocked TC from being accessed by enemy players". If some server-admin think their players are not mature and intelligent enough to decide, if they want a lock on their TC, there already is "Auto lock (codelock, keylock, nothing)": {"cupboard.tool.deployed": "nothing"}

I also had the idea of integrated default-profiles for different server-types, like "hard-pve", "soft-pve", "cosy-pve", "soft-rp" and "rp". Each profile predefines all options in a documented way. Could be a table and is not so hard to make. Then a server-admin just chooses the profile which best fits his/her needs, and only needs to tinker a very small subset of all options. But as alway, who should implement it?  ;-)

Hope you can draw some usefull ideas out of my jumble of thoughts.

Greetings

Heya.

An option for ownership won't be added, that could hurt new or inexperienced server owners and that's the last thing I want to do. What I will do is place these owner checks into helper methods so you can easily disable them in the cs file yourself.

I can add an option for TC authed.

I can add an option under TwigDamage FLAG that acts as "building protection system" but it will unavoidably override all other related rules, flags, and options while enabled.

If someone wants to contribute additional profiles, I am happy to review them and potentially include them in the plugin. The current configuration was built from years of experience to cover the needs of the standard PVE server by default. I try to be thoughtful about the needs of the community as a whole, and sometimes that includes knowing when to say "no."