RFC1920

The best way to know what is happening is: 1. Enable debug using the "nodecay log" command (add slash in chat). 2. Set decay tick, e.g. using "decay.tick 30" in console (not chat). Before doing that, run "decay.tick" to see your current setting - should be 600 by default. 3. Messages should be logged to the oxide log for all decaying items. 4. Set decay tick back to normal using "decay.tick 600" 5. Run "nodecay log" again to disable logging. 6. Send me the relevant logging or at least a portion of it showing the decay operations on blocks, doors/windows, etc. Ultimately, they should show a before value > 0 and then an after value of 0, as long as some other plugin or server setting is getting in our way. Again, if there are materials in the cupboard that would protect the building or parts, this will happen without NoDecay being able to intervene.

Changed Status from Pending to Can't Reproduce

Can you run /lp log (or lp log in console) to get some logging around the same time this may be happening?

Changed Status from Pending to Closed Changed Fixed In to 1.3.4

With materials in the TC that match the base grade(s), the plugin is skipped altogether.

Other than not needing the Multipliers section this looks fine. It shouldn't interfere with anything, but what's the problem?

Changed Status from Pending to Can't Reproduce

I just looked and I do see the electrical branch on the right side of the fridge (when facing the front), and I was able to connect a generator to the Power In connection.

Switches should not be in the default config. If they are in there and set to true, then they would have to be shared. /lp log as admin to enable logging.

These are a complete mystery unless I can see what else was happening around the same time with the log enabled on NextGenPVE. FWIW, the two traces above are similar but different. @Ondraasek, please update to 1.3.2 and let me know if that goes away. @HowlingWolf, are you running RaidableBases or DynamicPVP, HumanNPC/Humanoids, etc.?

Changed Status from Pending to Closed Changed Fixed In to 0.4.6

0.4.6 should now unlock the copter(s) of players with unlimited permission if allowFuelIfUnlimited is true. It also prevents adding fuel on every plugin reload since the point was to add 1 fuel with zero consumption just to keep it flying. The server restart fuel consumption thing has always been a problem. The easiest workaround is to nomini/mymini to create a new copter until I find a nice way to handle this.

I think so. We're both set false?

Do you have this in your config? "requireCupboard": true, "cupboardCheckEntity": true,

About to release 1.3.2 partially to test a theory about that. It doesn't happen that often on my server so it was harder to track down.

Changed Status from Pending to Closed (Bad docs, sorry)

I updated the doc. It's actually myminicopter.canhover (CANhover).

Changed Status from No Response to Closed Changed Fixed In to 1.0.80

I added a secondary check into 1.0.80 to cover this case where there is a nearby building in cupboard range but without a tool cupboard. In that case, cupboardRange will be used. You can and should go ahead and set useCupboardRange to false, as that only applies to entities - they should still be covered.

I'll check in the morning. But, the block checking code has not changed in over a year.

Changed Status from Pending to Closed Changed Fixed In to 1.3.1

Well, for now.... Global disable was set in the most recent version. I have to rethink the GUI portion because of general Cui complications and the need for use of the worst of that. If only there was a dropdown menu. Closing this for now.

Changed Status from Pending to Closed

Changed Status from Pending to No Response

Changed Status from Pending to Closed Changed Fixed In to 1.0.79