due to the extremely large performance cost of instantiating AsyncTasks, it's usually not worth bothering with async compression except for very large packets.
While this large overhead can be significantly reduced by using specialized threads, it's early days in the testing stages for such improvements, and for now, we still have this to deal with.
Since async compression is always used prior to player spawn, this change may slightly improve the performance of the pre-join stage of the game.
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 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.
