This function adds "base" format to a string. The given formats are inserted directly after any RESET code in the sequence.
An example of where this is needed is in the logger.
Without this change, the following code:
$logger->notice("I'm a " . TextFormat::RED . "special" . TextFormat::RESET . " cookie");
causes the "cookie" part of the message to show as grey, instead of the expected aqua for NOTICE level messages.
There are also many workarounds for this problem throughout the server, mostly in command outputs, being forced to use WHITE instead of RESET to avoid breaking the logger output.
There's no need to use an extra thread for this, since there's no concern of a socket getting stuck in a blocking read.
This is one less thing that can go wrong because of pthreads.
see #5057
jury is out on whether or not this should override difficulty on preexisting worlds, but it's non-controversial that it should apply at least to newly generated worlds.
closes#3080
If plugins fail to load for some reason, it's highly likely that some critical functionality of the server is compromised. For example:
- if an NPC plugin fails to load, all custom entities added by that plugin will be deleted from worlds
- if a world protection plugin fails, players will be able to grief your otherwise immutable lobby map
- if a worldgen plugin fails, worlds using custom generators won't load
- if a permission plugin fails, players might have access to commands and features they aren't supposed to have
- the list goes on...
This change makes the server commit graceful suicide if any plugin fails to load for error-related reasons, including (but not limited to):
- Incompatible API version
- Missing dependencies
- Invalid plugin.yml
- Invalid main class
Plugins prevented from loading by `plugin_list.yml` are not considered errors and **are not** included in this change. If a plugin is disallowed from loading due to the `plugin_list`, the server will continue to run as if the plugin was not present.
I thought I did this already in eff856d8e513a1f01eca16ab55bacf6e83399527, but it looks like my brain slipped a gear.
Without this change, it's possible to crash the server by specifying an invalid generator for the default world if it doesn't yet exist.
I've stuck to only doing this in the places where I'm sure we should never get false back. Other places I'm less sure of (and I found more bugs along the way).
this fixes many cases of corruption during disk-full situations - file_put_contents() would write an empty file, destroying the original data.
fixes#3152
this allows CrashDump to be used just to generate data, which will come in useful for non-crash error reporting in the future (e.g. packet decoding errors).
this is not as good as phpstan/phpstan-src#769 (e.g. array_key_first()/array_key_last() aren't covered by this, nor is array_rand()) but it does eliminate the most infuriating cases where this usually crops up.
