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.
