Dylan T.

This is confusing to implement when considering that we already have permissions `pocketmine.command.gamemode.self` and `pocketmine.command.gamemode.other`. It's not super clear how permissions like these would fit into the system.

If the client isn't sending the release action, I'm not sure how you expect the server to fix it...

It's fine, nobody else noticed it either :) There are two approaches usually used for this sort of thing: 1) closure to delay resolution 2) keep the target blocks in...

Ok, turns out it's not just the VanillaBlocks/VanillaBlocksInputs dependency that's a problem... VanillaItems and VanillaBlocks depend on each other, and VanillaItems also depends on VanillaArmorMaterials. Since the script doesn't try...

Latest commits should resolve the aforementioned issues with registry interdependence. `registerDelayed` can now be used to provide a callback that will only be invoked when the registry is setup, while...

Overall this is looking better since the last time I reviewed, but there's still some work left to do. Thanks for sticking with it 🙂

That might be a good idea. But I'm more thinking about an `enable-weather` setting for `server.properties`. Normally weather cycle would be controlled by game rules, but we don't have a...

I don't want to put this in pocketmine.yml. pocketmine.yml is supposed to be the place for "don't touch, might break stuff" settings. Something this simple should be easily accessible.

The problem here is that `getDrops()` requires a compatible tool. However circumventing the tool check is not a correct fix (this will cause tallgrass and other things to drop).

I would prefer not adding more methods for this if it can be reasonably avoided.