Co-authored-by: MD <1917406+md678685@users.noreply.github.com>
This PR makes HelpInput use knownCommands in the command map, rather than relying on plugin descriptions. This means that commands that have been registered programmatically (or impromptu) will be recognized and displayed in the help menu.
The ugly reflection is due to Spigot not exposing the command map getter. This has been tested on Spigot 1.8, 1.16.3 and Paper 1.16.3 with plugins that register commands directly to the command map.
Co-authored-by: MD <1917406+md678685@users.noreply.github.com>
Fixes#3579 (async `/skull` command)
Fixes#3336 (improve codestyle of commands)
Partially addresses #3339 (`/spawn` and `/setspawn` are now hidden from tabcomplete)
Closes#3087 (`/paytoggle` is now a loop command)
Closes#1332
The spawner delay feature has been broken in Essentials for as long as anyone can remember. The reasons for this are mentioned in the issue above.
This PR fixes this by changing the command to utilize new API for setting the minimum and maximum spawn delay on spawners. This API was added in 1.12.2, so all supported versions before that (1.8.8 thru 1.12.1) require NMS to function properly. I'm aware that Essentials avoids NMS for maintainability reasons, however that should not be of much concern here since all versions 1.12.2 and later are going to be using the Bukkit API. Hence, no NMS updates will be necessary.
Also let me know if you want the NMS code refactored somewhere else. I saw the net.ess3.nms packages, but I wasn't sure where this would fit into the organisation of that.
Tested on:
1.8.8, 1.9.4, 1.10.2, 1.11.2 (NMS)
1.12.2, 1.15.2 (Bukkit API)
Adds `/tpr` and `/settpr` commands, which respectively allow you to teleport randomly or set teleportation parameters.
Server owners are expected to set the center with `/settpr` before players can use `/tpr`. They can also set the minimum and maximum range to be teleported from the center (default 0-1000).
Also includes an event where plugins can adjust or cancel the teleport.
Closes#3154.
This PR updates the version of the bStats Metrics class to the latest version, supporting plugin IDs in place of just plugin names. It also adds the following graphs:
- Active permissions backend
- Active economy backend
- Whether or not a command has been used as a bar chart (pending bStats backend implementation)
- Version history graph as a multiline graph (also pending bStats impl)
It also removes the weird `getMetrics` and `setMetrics` APIs which should never have been API in the first place.
As discussed in #2960. Allows Essentials to register contexts with permission plugins that support them. A working implementation for LuckPerms is included in this PR. PermissionsEx 2 also has support for registering contexts, however it should probably be added at a later date, since as per zml2008 on Discord, the API is not yet stable.
https://user-images.githubusercontent.com/17698576/82718550-f5507500-9c57-11ea-970d-9d5f8bce8037.png
This PR removes the 1.8 R1 and R2 spawner providers. I was looking into refactoring these to use reflection instead of importing NMS code (in order to avoid requiring buildtools to compile), but after some research it looks like these are actually not even used anymore, in favor of the LegacySpawnerProvider (which Essentials appears to use for 1.8.0-1.12.2). Thus, keeping these is fairly pointless and causes more harm than good. There is no reason to continue including them, nor maintaining them. Essentials currently doesn't even officially support these versions anyway.
Waits for an ongoing backup task to complete in onDisable (and yells at users for `/reload`ing), and adds a `backup.always-run` option to enable always running backups even when no users have logged in since the last backup.
Fixes#3257 and closes#2646.
This aims to reduce the unintended consequences of granting all Essentials permissions or giving a player op, by defaulting permissions some more permissions to false, including `essentials.hat.prevent-type.<type>`. There's also a new essentials.exempt metapermission to have one parent that controls exemption from kick/ban/mute/etc. This will change behaviour for ops to some extent.
(description from #2608)
So... I've implemented a system for toggling whether or not AFK messages are broadcasted to the entire server and also changed a few things along the way:
1. I added a config toggle broadcast-afk-message that will change whether AFK messages are broadcast globally or not.
2. In both cases the AFK target now recieves a "self-oriented" message instead of the global default. Basically just says "You are now/no longer AFK". This would be a change from the default behaviour.
3. I created a way to exclude certain IUsers from broadcastMessage messages using an IUser... varargs parameter. I wasn't too sure how to implement the exclusion, but this seemed like a fairly good option.
I'm not too sure if what I've come up with is an optimal solution, but it's been tested and confirmed to work as intended.
closes#2116, closes#959
---
* implement toggle for broadcasting afk message
* add "self-private" AFK messages, implement exclusion system for broadcastMessage
* remove rogue import, clarify config comment
* move excluded collection creation out of loop, use set instead
* use set instead of varargs
* ok but actually use the set this time
* address requested changes
* update missed message section
* move from Collection to Predicate for broadcast exclusion
* update Predicate variable name
* use identity comparison (cleanup)
* clean up unnecessary imports, remove extra spacing
Just a simple config toggle for whether or not command block commands should be logged.
closes#1153, closes#162
---
* Add toggle for command block logs
* update setting name
Adds world specific perms for whether a player may use /back to teleport
back to a given world. Adds logic to default
essentials.back.into.<world> permissions for loaded worlds to true to
maintain backwards compatibility.
* Replace vanishedPlayers list with set
Not sure if there is any particular reason to keep it ordered, but for now I've used a LinkedHashSet.
* Change return of new method from Set to Collection
Also makes return of old method an unmodifiable list, but this is just as breaking as just changing the method return type as far as I can see
* Move kits to kits.yml
We will now use a separate kits.yml file.
Any kits that were defined in the config.yml will be migrated over to the kits.yml file automatically on startup.
