this is intended to replace PluginCommand and CommandExecutor, both of which are overengineered and unfit for purpose.
Allowing a closure allows much greater flexibility.
We can't use this within the core yet, as plugins will expect PluginBase->getCommand() to return PluginCommand (with its associated setExecutor() and similar APIs).
However, I think this is useful enough to add by itself.
The following callbacks can now be registered in timings, to allow threads to be notified of these events:
- Turning on/off (`TimingsHandler::getToggleCallbacks()->add(...)`)
- Reset (`TimingsHandler::getReloadCallbacks()->add(...)`)
- Collect (`TimingsHandler::getCollectCallbacks()->add(...)`)
Collect callbacks must return `list<Promise>`. The promises must be `resolve()`d with `list<string>` of printed timings records, as returned by `TimingsHandler::printCurrentThreadRecords()`. It's recommended to use 1 promise per thread.
A timings report will be produced once all promises have been resolved.
This system is used internally to collect timings for async tasks (closes#6166).
For timings viewer developers:
Timings format version has been bumped to 3 to accommodate this change. Timings groups should now include a `ThreadId` at the end of timings group names to ensure that their record IDs are segregated correctly, as they could otherwise conflict between threads. The main thread is not required to specify a thread ID. See pmmp/timings@13cefa6279 for implementation examples.
New PHPStan error is caused by phpstan/phpstan#10924
a couple of usages of properties that no longer exist couldn't be migrated.
in addition, this revealed a couple of dead properties in the default file.
this is not an ideal solution (I'd much rather model the configs using classes and map them) but in the absence of a good and reliable library to do that, this is the next best thing.
'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
Perhaps this and EnchantOption should be called EnchantingHelper and EnchantingOption respectively. The terminology used is rather inconsistent, but 'enchantment' definitely isn't the right word here.
This occurs if the player had very high levels of Health Boost or other weird modifications.
It doesn't really make sense to apply damage modifiers to suicide anyway.
Really I'm doubtful that suicide should even be considered a damage type (perhaps we should add an EntitySuicideEvent), but that's a discussion for another time.
it doesn't make sense to have to parse the string every time we want to verify permissions, nor to expect that people will somehow know to use ; to separate them without it being documented anywhere...
Having no permission is almost always a bug. We already have behaviour elsewhere in the core that assumes undefined permission = permission denied.
This behaviour might confuse some people, but I think it's much less dangerous than accidentally allowing everyone to use your command.
I'm not quite sure this is the best way to enable such functionality, but it's already used for some other stuff, so I'm not too worried for now.
This allows the following commands to have their usage limited to self or others:
- /effect
- /enchant
- /gamemode
- /give
- /spawnpoint
- /teleport
- /title
I envision this being useful for creative mode servers, and test servers such as test.pmmp.io.
this is pretty much always going to cause unexpected behaviour, as most execute() implementations don't expect empty strings, and it can also pad the args with dummy entries, breaking argument count requirements (e.g. aliasing say and using the alias with no arguments will confuse the target command).
Instead:
- Drop arguments that cannot be resolved (leave them unspecified)
- If they are at the end of the argument sequence, this is OK - it will behave the same as if some optional arguments weren't specified.
- If they are in the middle of the argument sequence, this will generate an error - this is preferable to having the target invoked with an empty string, which might cause unexpected behaviour.
fixes#5379
getName() essentially serves as an ID for the command for CommandExecutors. It has no other sane use case.
Since it's not unique (multiple commands with the same name may be registered, and the fallback alias will be used on conflict), it cannot be used for array indexing. It's also not correct to use it for any display purpose, since the command may not be able to be invoked by its 'name' if there was a conflict.
There is an open debate about what to do with getName() and the wider CommandExecutor ecosystem, but that's a topic for another discussion.
closes#5344
