DPVP: Optionally create event zones on plugin (re)load

[HunterZ]

DynamicPVP currently doesn't create zones around certain events (airdrops? hackable crates? Can't remember) when (re)loaded, which is problematic updates/reconfiguration on a live server.

Should probably have a configuration-driven option to create these zones immediately or on configured creation delays when the plugin is (re)loaded.

Note that this would slam the lever from one extreme - never creating a zone for existing event-triggering entities - to an opposite extreme - immediately always creating a zone for said entities, but it seems better to err on the side of allowing PVP. Also, this is why it's a good idea for the behavior to be configurable.

I do not think it's worth trying to track full states in a data file and recover them (e.g. ensure the zone gets created at time X if that's what was set to happen before a reload).

[HunterZ]

Update: This would be challenging given the architecture of DPVP, and the nature of some of the events.

Successful implementation would probably look something like:

• store event type, associated netID, state, and timer in the data file on event creation/update, and don't wipe it on unload
• on load, try to replicate state of all events in the data file whose times indicate they should still be active, and purge the rest
  • any entities that existed before unload but not on load should also trigger on-kill behavior if/as appropriate
• on load, also scan for any entities with on-spawn triggers that don't have file data, and trigger on-spawn behavior if/as appropriate

Will probably keep this on the TODO list, versus holding up the first update release.

[HunterZ]

Excavator and Chinook crate support will be added in DPVP 4.4.0.

Bradley and Heli are difficult because the events start on entity death, meaning there's nothing to detect on (re)load.

The major problem with air drops is that DPVP is fancy and tries to offer separate events for timed(/excavator?) drops versus supply signal called drops, and there's no way to tell which is which on (re)load.

Probably already mentioned this, but: If data file persistence is implemented for General Events, it should probably capture duration/timer states - possibly including crate hack start/end time - so that we can do a better job of recreating proper state. This may still not account for things like unloading for 1 minute and missing the exact time that a timer trigger should have started (e.g. player looting something), but at least it could cover the simple cases.