this has been a bug ever since Snooze was first introduced. The load statistic, similarly to timings, did not account for time spent processing notifications between ticks. The problem is that this is often where a significant amoutn of the load actually comes from, because Snooze is most often activated due to incoming packets.
This change fixes the problem by including the time spent processing notifications since the previous tick in the current tick's usage metric.
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 eff856d8e5, 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.
