players were switching from a weaker tool to a stronger one to get double knockback in PvP.
while it's intended that we don't cancel the second attack during hit cooldown if the damage is
higher (the first damage is subtracted to prevent doubling up), we don't want them to get double
knockback.
this behaviour now matches vanilla to the best of my observations.
Come at me PvP community... I know some people are going to hate this change
this ensures the greatest amount of consistency with vanilla.
in order to prevent the sounds being broadcasted on armor damage with the old method, we'd also have to sacrifice the sound when replacing one leather helmet with another, for example.
this approach minimizes the gameplay impact at the possible expense of plugins.
closes#6325
as seen in pmmp/BedrockBlockUpgradeSchema@ebd768e5b2, this enables use of newFlattenedName in more places (by allowing the flattened values to be transformed before building the new ID), as well as reducing the number of remappedStates in general by compacting stuff which was partially transformed like color silver -> light_gray.
ErrorToExceptionHandler currently prevents these from appearing by turning them into exceptions, but this won't always be the case.
For example, in the future we may not want to turn ALL types of E_* errors into exceptions (e.g. E_DEPRECATED).
Because ext-phar sucks, tmp gets spammed by cache files for every thread when loading files from the phar on the fly.
Instead, we convert the `.phar` into a decompressed `.tar` in the tmp directory and require files from inside it. Surprisingly, this works because `ext-phar` supports `tar` and `zip` natively. No stream wrapper is required, as the `PocketMine.php` bootstrap loads files relative to its location, so the cache is automatically used for everything.
To be honest I would rather get rid of phars entirely, but they are still the easiest way to have PhpStorm load PocketMine-MP API information for now, and the alternatives are more complicated and inconvenient.
### Caveats
Everywhere that previously used `new Phar(Phar::running(false))` in the core code needs to be updated to use `PharData` for this to work correctly. Plugins don't need to do anything.
### Why not just use `Phar::decompressFiles()`?
This requires setting `phar.readonly` to `0`, which is a security issue. Technically, we could have used a subprocess to do this, but it just didn't seem right.
### WTF? `phar://` can be used on `tar` files???
Yup. I was just as surprised to find out that `require` works in such contexts.
### Relevant issues
- Closes#6214
## Changes
### API changes
None.
### Behavioural changes
Server startup will be slightly slower, as the phar has to decompress and convert itself into a `.tar`. However, testing showed that this generally takes less than 200 ms, so it should be barely noticeable.
## Backwards compatibility
No BC issues.
## Tests
Locally tested and the CI will also verify
