this is not used in the PM core, and is only used by 1 plugin in the whole public ecosystem: BigBrother. It makes more sense to make BigBrother maintainers shoulder the responsibility of maintaining this code, since they are the only ones that need it - besides, if this changed in any MCJE update in the last 5y, nobody has updated it, and nobody has maintained it either due to not having a fucking clue what the thing is for (the documentation is basically nonexistent).
this makes translation usage much more statically analysable.
The only places this isn't used are:
- places that prefix translations with colours (those are still a problem)
- places where server/client translations don't match (e.g. gameMode.changed accepts different parameters in vanilla than in PM)
this also fixes use cases like:
[1] = something;
[0] = match(...)
It made no sense whatsoever to discard the keys anyway.
Language::translateString() already supported named parameters since
forever anyway.
I was never able to reproduce this, but it appears that Windows breaks the character encoding of command parameters (and also unicode environment variables, even though UNICODE_ENVIRONMENT should be set in php-src) when the file path contains Unicode characters (such as Cyrillic).
We workaround this problem using base64, which is an abysmally shitty hack, but not worse than using a subprocess for ConsoleReader in the first place. PHP fucking sucks, and so does Windows.
closes#4353
I moved these to a trait in anticipation of having multiple full Inventory implementations. That's no longer necessary because of the abstraction of SimpleInventory.
this happens if the parent process is killed via SIGINT, because its stdin will be closed, interrupting a blocking read. This might also happen if the user pressed CTRL+D, so we don't die unless end of socket stream was also detected.
closes#4335
This brings a significant performance improvement to login sequence handling, reducing CPU cost of `PrepareEncryptionTask` by over 90% and `ProcessLoginTask` by over 60%. It also allows us to shed a dependency.
while it's true that you might be able to skip the CPU waste from verifying a player's login just to find out that they are banned, this is generally a minority case anyway, so it doesn't make a lot of difference overall. This additional note is essentially a recommendation premature optimisation, which will likely lead to people making security mistakes.
