I'm pretty far along on a complimentary plugin to DynamicPVP that will manage dynamically-sized PvP ("exclude") zones around player bases, moving zones around tugboats, and fixed zones around legacy shelters.

While writing my `CanEntityTakeDamage()` hook handler, it occured to me that there's a limitation here: If an airdrop lands next to a player base - such that the PvP zones are close but don't overlap - and they both run into the no-mans-land between zones while fighting each other...the damage will stop being applied, because both DynamicPVP and my plugin will shrug and return `null` despite considering them to each be in some kind of PvP exit delay.

It's probably too late now due to all the plugins out there, but I can think of a couple ways to address this:

1. TruePVE could fire hooks asking "is this attacker excluded?" and "is this target excluded?" and then apply damage if it gets back a `true` for both.

2. TruePVE could provide API for other plugins to say "I want to exclude this player" and "I no longer want to exclude this player", using a counter or unique identifiers (e.g. plugin name) to handle overlaps. This could potentially be a LOT more efficient, since TruePVE wouldn't have to fire off hooks every time damage is dealt if it already has all the info it needs.

I would rather not implement that as its a bunch of overhead. you can use CanEntityTakeDamage to allow damage for pvp delay rather than returning null

nivex

I would rather not implement that as its a bunch of overhead. you can use CanEntityTakeDamage to allow damage for pvp delay rather than returning null

• Attacker has PVP delay in RaidableBases only
• Target has PVP delay in DynamicPVP only

hi HunterZ, I didn't miss the point. you can keep track of the pvp delay and allow it with CanEntityTakeDamage. DynamicPVP provides OnPlayerAddedToPVPDelay and OnPlayerRemovedFromPVPDelay hook calls for this which you can implement in your plugin.

That scales pretty badly because there are already several such plugins (2+ of which are yours!), and I'm writing yet another.

Maybe a universal PVP delay plugin or a cross-plugin PVP delay plugin are possible, but they don't seem super practical.

not necessarily. using the hooks these plugins provide would still be more efficient in general

OnEntityTakeDamage -> CanEntityTakeDamage <-> IsSuchAndSuchExcluded is multiple redundant conditional checks, and can be more expensive in terms of performance because it introduces unnecessary processing every time the hook is triggered. by using individual PVP delay hooks, you eliminate the need for extensive conditional checks with these general hooks. each hook has a clear and concise purpose, is easier to maintain, and will perform better in general

furthermore, you need only to subscribe one damage hook. Subscribe CanEntityTakeDamage and Unsubscribe OnEntityTakeDamage for PVE. vis-versa for PVP.

OnEntityTakeDamage can use the conditionals from CanEntityTakeDamage to return the result. 

private object OnEntityTakeDamage(BaseCombatEntity entity, HitInfo hitInfo)
{
    if (CanEntityTakeDamage(entity, hitInfo) is bool val && !val) return true;
    return null;
}

private object CanEntityTakeDamage(BaseCombatEntity entity, HitInfo hitInfo)
{
    if (!entity || hitInfo == null || !hitInfo.Initiator) return null;
    // implement normal logic here
    if (this and that) return true;
    if (this but not that) return false;
    return null;
}

When I say "that scales pretty badly" I'm referring to your comment "DynamicPVP provides OnPlayerAddedToPVPDelay and OnPlayerRemovedFromPVPDelay hook calls for this which you can implement in your plugin."

You're describing a combinatorial explosion that nobody is ever going to attempt to implement:

• Abandoned Bases should track PVP delays reported via the unique hooks provided by Dynamic PVP, Raidable Bases, my plugin, some other plugin, etc.
• Dynamic PVP should track PVP delays reported via the unique hooks provided by Abandoned Bases, Raidable Bases, my plugin, some other plugin, etc.
• Raidable Bases should track PVP delays reported via the unique hooks provided by Abandoned Bases, Dynamic PVP, my plugin, some other plugin, etc.
• My plugin should track PVP delays reported via the unique hooks provided by Abandoned Bases, Dynamic PVP, Raidable Bases, some other plugin, etc.
• Some other plugin should track PVP delays reported via the unique hooks provided by Abandoned Bases, Dynamic PVP, Raidable Bases, my plugin, etc.

ya, and I replied to that. everyone implements as many hooks as necessary to get the functionality that they need. I understand your point as a whole, but there's no point in discussing suggestion #1 further

I looked at suggestion #2 again and it's not a bad idea. too much focus was put elsewhere and it wasn't given enough attention.

I have no problems implementing that, but I want to exclude this player would not work properly if the I no longer want to exclude this player didn't get called for some reason.

var userid = (ulong)player.userID;
this = the plugin that is the caller
TruePVE.Call("ExcludePlayer", userid, maxDelayLength, this);
TruePVE.Call("IncludePlayer", userid, this); 

• it would be required that the delay length be provided to avoid such issues where IncludePlayer is not called
• use ulong in both calls as BasePlayer would be null when the player is dead and offline
• the first point creates an issue when the delay is reset. it would be required to refresh by calling ExcludePlayer again
• IncludePlayer would not be necessary with #1 but could still serve a purpose if you wanted to immediately cancel

I like this solution:

1. Requiring plugins to "keep their ball in the air" means TruePVE doesn't have to trust them to close the loop (albeit at the expense of TruePVE having to run hopefully-redundant timers).
2. userID versus player is my preference also, for various reasons.
3. Requiring this solves the overlapping-but-staggered requests problem (userID-this pair/tuple becomes the conceptual uniqueness key for the request, and any requests active for the userID means the player is "excluded").

yeah IncludePlayer wouldn't be needed except the immediately cancel

let's introduce four players:
Rob, excluded
Jon, excluded
Mel, not excluded
Ray, not excluded

implementation A:
if Rob and Jon deal damage to each other then damage is excluded
if Rob or Jon deals damage to Mel or Ray then damage is not excluded
if Mel or Ray deals damage to Rob then damage is not excluded
if anything else deals damage to Rob or Jon then damage is not excluded. though I think they should take damage from all other sources that isn't from a player, except then outside observing players will drop turrets outside of events to exploit this and reap the rewards.

implementation B:
if I remove the limitation where both the victim and attacker must be excluded, then Rob or Jon could take damage from anything and everything. potentially from undesired sources.

Ray camps his roof top waiting for players to exit an event area, knowing that they will be flagged with a PVP delay when they do so. Ray shoots everyone leaving the event which causes damage to them. neither Rob nor Jon can hurt Ray because Ray is not excluded. etc

how do you wish to proceed? this should be friendly for server owners without requiring any options since the API is controlled entirely by other plugins.

implementation A (save as TruePVE.cs): https://pastebin.com/shZvWQya

not really seeing a use for `this` or `plugin` as is

I'm confused about your terminology, so I'll lay out my thinking on hybrid PvE/PvP:

• "excluded" means PvP eligible (and vice versa):
  
  • any combat entity has this status when any of the following criteria are true:
    • in zone manager zone mapped to "exclude" ruleset
    • above/below Y coordinate thresholds
  • players specifically may also have this status when the following is true:
    • player has active PvP exit delay in effect
• damage resolution:
  
  • if both source and target are PvP eligible:
    
    • this is considered a PvP exchange
    • TruePVE does not interfere
  • else (one or both entities are not PvP eligible):
    • this is considered a PvE exchange
    • TruePVE applies its rules

implementation A is what you've described in your request and what I've provided to you. I should rename ExcludePlayer to SetPlayerPvpDelay or a more suitable name given its purpose is solely for PVP delays

implementation B is how TruePVE would normally handle exclusions. this is typical of zonemanager zones where it is excluded from all rules and flags, and exclusions in entity groups use the inverse of matching rules

Compared your code to the current release version:

I'm not sure I fully understand the AllowDamage() code, but it looks like maybe the new logic currently only checks the case that both players have an active PVP exit delay?

Here's what I was trying to describe before, but in a table form:

yes, checking one case is how it worked. I was too tired and overlooked your other conditions

check it now

save as TruePVE.cs: https://pastebin.com/shZvWQya