closes#5032
this is evidently not an ideal solution, and something more dynamic would be preferred so that we don't have to manually register an item for every permutation.
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.
Since the text is barely visible on dark mode (black on black), i added an inverted version that only shows with dark mode using the [picture](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/picture) tag.
The tag is supported in all browsers except IE since ~2015
I added an exception block for old IE versions, new versions dropped support for `[if IE]` though
this resolves a range of issues with quoted arguments when using placeholders, as well as improving performance (no redundant combine -> re-parse needed).
this time, without breaking eval commands ... stripslashes likes to strip ALL backslashes, whether they are actually escaping something or not, which is super annoying.
This required the following:
- A generation task (taskA) to already be running for any chunk (chunkA)
- A chunk (chunkB) is requested for generation, and the task (taskB) to do the generation
is commenced immediately
- chunkB generation promise is aborted (e.g. due to chunk unload) and
taskB is orphaned
- chunkB is subsequently re-requested, but ends up in the generation
queue because taskB is still running
- taskA completes and drains the generation queue
- chunkB attempts to be populated a second time, but taskB has not yet
been collected, resulting in an assertion failure.
This bug has been appearing intermittently ever since PM 4.0 release.
For most users there is no obvious effect since production servers don't
have assertions enabled; however, it's unclear what kind of weird side
effects this bug may have had.
