same reason for this as why we trigger the branch sync from here - we need to make sure the cron doesn't get disabled
RestrictedActions can do things this repo can't - the old workflow would've failed because GH Actions doesn't have pull_request write perms here (which we can't grant because it would also allow it to approve PRs)
the separated language repository has long been a source of inconvenience and annoyance,
particularly for PR contributors, because having to sync two PRs across different repos
for no reason adds unnecessary friction.
In addition, having the language files separate creates unnecessary requirements for
versioning and branching, which could all be avoided if the language strings were managed
directly in this repository.
This change will make it much easier to do new features that require adding new translation
strings, as well as getting rid of the inconvenience of cleaning up older strings.
Translation updates from Crowdin should also be able to be merged more quickly, since they
will have higher visibility on this repository.
Crowdin doesn't understand {%param}, which affects our ability to do QA on Crowdin directly. It does understand {param}, which is the closest neighbour.
* New translations eng.ini (Romanian)
* New translations eng.ini (Russian)
* New translations eng.ini (Vietnamese)
* New translations eng.ini (Vietnamese)
* New translations eng.ini (Vietnamese)
This allows packet handlers to tell the network session to discard any following packets if their buffers were identical to the current one.
This is a very conservative and basic limiter. If we start having problems with multiple packets being spammed at once interleaved, this will become ineffective. However, for now, all the known spam bugs are of single packets, and the buffers of said packets are always identical. Dealing with interleaved packets would be quite a bit more complex. This mechanism is very simple and should avoid any negative side effects.
This PR started out as an effort to decouple Command and CommandMap, but it's turned into a bit more than that.
A summary of changes:
## UX
- Added `cmdalias create`, `cmdalias delete` and `cmdalias list` commands
- `/help` now shows prefixed names such as `pocketmine:help`
- Prefixed command name (e.g. `pocketmine:help`) are now visible to Minecraft clients
- Permission denied messages are now able to show more useful context when e.g. checking subcommand permissions
- Multiple commands claiming an alias make the alias unusable (an error will be shown when used telling the user to pick from the namespaced names), instead of whichever plugin loaded last getting lucky
## API
- Added `CommandAliasMap`, which handles mapping of aliases to namespaced command IDs
- Added `CommandSender->getCommandAliasMap()` for user-specific aliases
- Added `CommandMap->getAliasMap()` for global fallback aliases
- `Command` no longer tracks its own registered aliases (now the job of `CommandMap`), breaking circular dependency
- Aliases must now be provided to `CommandMap->register()`
- Aliases can now be individually registered and unregistered without re-registering/unregistering the whole command using `CommandAliasMap` APIs
- Aliases are no longer namespaced, only the main command name (e.g. `pocketmine:?` is now gone while `pocketmine:help` still exists)
- `Command` now requires a `$namespace` parameter, which replaces the old `$fallbackPrefix` parameter of `register()`. It should be set to the name of the plugin.
Relevant issues
- #6508
- #3371 - this PR doesn't implement storage, but allows configuration of per-user aliases during server runtime
