RFC1920

Open the GUI and make sure that the top right shows that the plugin is "Globally Enabled" (green button near top right). Click on the default ruleset and make sure it shows as "Enabled" (green button near top right). If you have made a copy of the default ruleset, but its default damage is set to true AND has no zone assignment, it will likely override the default globally. Otherwise, there may be some other plugin that is in conflict.

Changed Status from Pending to Closed Changed Fixed In to 1.2.6

Changed Fixed In from 1.2.5 to 1.2.6

Changed Status from Pending to Closed Changed Fixed In to 1.2.5

Well, enable /pvelog, run some tests, disable /pvelog, then upload the log here.

It may actually be misbehaving. But, I would start by removing all of the rules in the pvp_smallharbor ruleset, flip it to Default Damage True, then re-add anything you don't want to happen in that zone. Fewer rules may be the way here.

For the default ruleset, which should apply anywhere NOT in a zone with a different ruleset, make sure of two things: 1. Default damage: false 2. No rules added for building damage, etc. - Any rule you add in the default ruleset is counter to the default damage setting and would be allowed.

For plugins like DynamicPVP (not sure there are any like it), they are able to create their zones on the fly and map them into one ruleset in NextGen programmatically. If you are managing those zones yourself, you will most likely have to create a ruleset for each zone. The good news is that once you get one of them right you can clone that into other rulesets for the other zones. You would only then need to change the zone id for those cloned rulesets. Note that ZoneManager has per-zone flags which might help tweak some of the settings for each one (other than the PVP setting).

I think you're going to have to be a bit more patient than that!

Changed Status from Pending to Closed Changed Fixed In to 0.4.0

Yup.

You can try using https://github.com/WheteThunger/ParentedEntityRenderFix. Configure this to include the piano, lantern, etc., at a minimum: { "EnabledEntities": [ "piano.deployed", "lantern.deployed" ] } This is a workaround, and ymmv. There is probably a more thorough and accurate description, but from your perspective, it impacts any plugin that builds an object using multiple entities and/or those that generally aren't meant to move. Sadly, these are some of my favorite plugins. It didn't used to be a problem but began as part of Facepunch's efforts to improve game performance a couple of years ago. I've even had issues with plugins I'm working on that only consist of one object, but one that is generally grounded and not supposed to fly.

Changed Status from Pending to Closed Changed Fixed In to 0.3.9

Pushed it, and we shall see if it holds.

Nice... That's good because although I had it sort of working, I am out of time here.

I am guessing that you are not getting a message like "You cannot use /sethome so close to a cave.", but maybe "Home cannot be set here -". This will be fixed in 1.2.3.

Any logged errors to report or just no response when they type /home XYZ?

Changed Fixed In to Next Version

@pookinsI had no trouble setting home on a foundation but due to a logic problem, with "HomeRequireFoundation" false, it came back with home cannot be set here with no message. Fix pending and easy to do. Also, the tickets here auto close after a certain amount of time, and I have been busy with other things. @WavyDankkFor the 5 people actually using the plugin I am happy to still be working on it along with the 30 other plugins I've been juggling recently, all in my spare time since this is not my full time job. Life happens LOL.

I whipped one up, just for fun. https://github.com/Remod-org/MyMiniCopter

You may have "disableWarning": true in the config, which would hide the warnings including possibly what you are expecting. This is the only place where the plugin would override the game if there are items in the cupboard. Note that with matching materials in the cupboard, our decay function is most likely not getting called at all. But, the warning disable would still function. Try flipping that to false to see if it helps.

I would save a copy of your database, delete the old one, and reload the plugin. Check your settings and then verify that MLRS can no longer damage things. That should be the default with a clean database. Perhaps something happened with the updates.

AdventCalendar was added in the last update. StabilityEntity is unfortunately way too broad to be added just for this entity. It should be a deployable already protected but I will need to look. Finally, a fire_fire rule would allow damage of fire on fire, so I am not sure that would apply for preventing damage.

Changed Status from Pending to Closed Changed Fixed In to 1.0.9

Without a rule enabled it should be blocked anyway. I have mlrs_building enabled to allow it for testing.