RFC1920

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.

I am getting this: QUERY START READING... Checking ruleset default for mlrs attacking building. Found MLRS attacking BuildingPrivlidge. Checking ruleset default, zone 0 Found exception match for MLRS attacking BuildingPrivlidge No exclusions for MLRS to BuildingPrivlidge Sanity check foundexception: True, foundexclusion: False Ruleset 'default' exception: Setting damage to True DAMAGE ALLOWED for MLRS attacking BuildingPrivlidge, majority damage type Explosion Default ruleset query So, I think it must have just missed.

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

Make sure you do not have the fire_building rule enabled. If not and it still does it, please enable the log (/pvelog) and paste some of the log here.

For new installs the rules were missing to allow damage, so damage should have been prevented. However, the entity may have also been missing. If you are just getting started it might be easier to wipe the database after updating to 1.2.1. Otherwise, please enable/disable the log via /pvelog before and after the MLRS attack and show me here what you get in the log file (oxide/logs/NextGenPVE/datedlogfilehere).

Possibly a conflict with the plugin of the same name vs the game object. This was bound to happen at some point.