RFC1920

If possible, I need to know what else was going on at the time of the error. Enable debugging if you can.

Changed Status from Pending to Closed

Not a problem. I only rediscovered checking on your issue.

I was going to test to verify, but Steam Auth Timeout is in the way for now.

You cannot test as admin. The code returns true for admins on checks for unlocking and painting signs.

Nevermind. It seems that the oxide hook simply does not work. It gets called, we return true (or even false), and access is still granted.

Are you using NextGenPVE?

Changed Status from Pending to Closed

Changed Status from Gremlins to Closed

1. NextGenPVE only manages damage, not looting of boxes, etc. You can use another plugin for that, e.g. LootProtect. However, I am currently trying to get some traction with the current maintainer of DynamicPVP so that we can also automatically manage zones there. Unclear how RaidableBases handles this, or if it does. 2. DynamicPVP by default uses a ruleset called "exclude" not "include". However, whatever ruleset is configured in DynamicPVP will be managed in NextGenPVE. Just make sure that whatever ruleset is configured in DynamicPVP ("TruePVE Mapping") exists in NextGenPVE. 3. DynamicPVP manages its zones, and will remove and add them as needed. This is the extent of the interaction between the two plugins: managing that list of zones dynamically. You should not need to be concerned with the zone ids as they will change on every reload, etc. 4. However the NextGenPVE "exclude" ruleset is configured, damage should be controlled for the zones DynamicPVP sets. Set the "exclude" ruleset however you want to control damage in zones managed by DynamicPVP. As I understand it, the general concept of DynamicPVP is to manage zones where a PVE plugin will make exceptions to its rules. Usually, this means assigning a different ruleset other than default to allow PVP in those zones. As far as both plugins are concerned, the rest of the map is PVE only. I don't see evidence of RaidableBases integrating with either plugin, but my copy may be old. Finally, there has been a lot of work recently to manage the null reference exceptions especially around heli activity. This is not yet perfect but you should update to the latest version.

You might try modifying the function to include a new line: private void OnPlayerInput(BasePlayer player, InputState input) { if (player == null || input == null) return; if (!player.userID.IsSteamId()) return; // ADD THIS LINE if (!configData.Global.UseKeystrokeForHover) return; The only reason this might be a problem is if some NPC plugin is somehow triggering this. I only suggest this because it's not clear when it is happening. Is it during boot or only when an actual player first connects, tries to the use a copter, etc.

NextGenPVE was fixed for part of this list of problems. However, I have received no response from the maintainer of DynamicPVP.

Changed Status from Pending to Closed Changed Fixed In to 1.0.5

Changed Status from Pending to Closed

Try a new config file. I don't see why this would be happening.

I don't see "NOT in PVE zone" or even "NOT in" in any of my plugins. However, I do see a problem in NextGenPVE regarding the hook we use to determine ruleset/zone status (to be fixed in 1.4.4). Yes, you need to enable useZoneManager. DynamicPVP does name their zones as you showed, but they manage the NextGenPVE ruleset called 'exclude' last time I looked.

Changed Status from Pending to Not a Bug

The message " [NoDecay] TC owner 7656119802110XXXX has NoDecay permission!" comes from OnEntitySaved, which is not a decay check. It appears to be getting a valid ownerid as shown in that same message. For what its worth, this is where we decide whether or not to show the GUI overlay and also to set the decay warning. The message "[NoDecay] sleepingbag_leather_deployed owner 7656119825433XXXX does NOT have NoDecay permission. Standard decay in effect." comes from the actual decay loop. This appears to be working. Call me confused.

I see that the sleeping bags were skipped based on the permission. Are you sure you don't have some users in another group that also has the permission assigned? If you're not already, definitely use Permissions Manager for that.

The config looks fine. Can you run /nodecay log, wait several minutes, then check the log? After that, run /nodecay log to disable logging. Check the oxide log and see what messages it has from NoDecay regarding permissions.

Changed Status from Pending to Closed Changed Fixed In to Next Version

Confirmed and that much is an easy fix. However, I see that they also get lost anyway. Working on it.

Changed Status from Pending to Closed Changed Fixed In to Next Version

Changed Status from Pending to Closed Changed Fixed In to Next Version

Changed Status from Pending to Not a Bug