RFC1920

If resources matching any part of the building (as shown in the TC interface) are allowed to be added to the cupboard, then they will be used in the standard decay process. The way this normally has worked, and I am not aware that it changed, is that this bypasses the plugin altogether, at least for that resource. Since you seem to want to block all resources, please also set blockCupboardResources to true. This may have changed as of the most recent update because of some discovered faulty logic in the plugin. In short, if resources are in the TC when the decay.tick fires, we can't prevent the game from consuming those resources if they match any part of the building. Also, make sure that you are using the version from this site because it is not compatible with plugins with the same name on other sites.

Changed Status from Pending to Not a Bug Changed Fixed In to Next Version

This is controlled by Zone Manager Auto Zones. All of its monument zones should use a NextGenPVE ruleset called "exclude" by default. This appears to operate exactly like DynamicPvP. If you do not have a ruleset in NextGenPVE called "exclude," you would need to add one and set its default damage to true. Then, reload Zone Manager Auto Zones. It should populate the zone list for "exclude" using the zone ids it creates.

Changed Status from Pending to Closed Changed Fixed In to 0.4.2

Looking into it, should have a fix in the morning.

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

This should be fixed in 1.2.6. If that makes life worse, please roll back to 1.2.5 and I'll take another look.

I can see where that might be a problem. Will try to look this weekend.

Generally speaking that is true. But, we do not modify the helicopter's behavior. We monitor it. If it has decided to target you for any of the normal reasons, that is what determines whether or not your base will take damage. Looking over the code again (it has been awhile), it appears that you must set HonorBuildingPrivilege to true for this check to work. The only goal here was to prevent someone from intentionally using the heli to raid your base by baiting it while hiding in or around your base. If you want more in-depth control over heli behavior I am sure there are other plugins for that. The exception here to "we do not modify the heli's behavior" is HeliTurretTargetsPlayers which, if set to false, does modify the heli to not target players with it's turrets at least.

Looks like it is set to be days + 1.

Changed Status from Pending to Closed Changed Fixed In to 1.0.75

If you were targeted by the heli for any reason then your base would be fair game (shot at it, wearing more than 2 items of clothing, holding an actual gun of some kind).

There is already a check for inactivity called protectedDays. For example, if set to 14 and the player has not been on for 14 days, it should start decaying their building regardless. My concern is that the blocking of resources is not working, which I will check in a bit. It definitely used to work. Are you sure you are using the official NoDecay from either codefling or remod? What version number? EDIT: I think I found it. I guess no one ever used this because it was not checking those config values correctly. Fix pending.

On their page they specify that you have to exclude "CustomScientistNPC". Check out the videos on the description page for more information. I think you may need to use the Rule/Entity Editor to verify that CustomScientistNPC is set as category NPC.

The default configuration allows players to damage the heli, heli to damage the players attacking the heli, and heli to damage buildings owned by a player targeted by the heli. I know this much works, so if it does not then there must be something else conflicting. Worst case there is a reset and/or you can delete the nextgenpve.db in data and the NextGenPVE.json in config and reload to get back to the default.

debug, if true, enables a bunch of extra logging, primarily for development or finding problems. allowRespawnWhenActive was supposed to be a check to allow the player to run mymini to kill and respawn their mini if they already had one. I don't think it actually works. If true, it will just tell the player that they already have a mini, which is opposite of the intended functionality. This should probably just be removed at some point...

Curious what your config looks like because it works just fine for me.

Do you mean that it's damaging the attacker's building or another player's building (heli-raiding) ?

I don't know what one has to do with the other to be honest. What problem are you seeing?

Changed Status from No Response to Closed

Changed Status from No Response to Closed

A little history: I used to maintain HumanNPC on umod before I left umod. I noticed not long after that NO ONE was working on HumanNPC, so I continued working on my own version separately on GitHub and later Remod. This was the version I wrote HumanNPCGUI for. I added the hooks that are required for HumanNPCGUI to work, and the version on umod.org does not have these. So, this will probably never work with their version. I would recommend that they either create their own GUI or create sufficient hooks so that a third party app can create a GUI for it. However, I will not be working on that.

Changed Status from Pending to Closed

Changed Status from Closed to Pending