until now, any thread crash would show as a generic crash since we aren't able to get the trace from the crashed thread directly. This uses some dirty tricks to export a partially serialized stack trace to the main thread, where it can be written into a crashdump.
This enables us to see proper crash information for async tasks in the crash archive (finally!!!) as well as being able to capture RakLib errors properly.
normally I would hesitate to reinvent the wheel, but we only need a tiny subset of the ASN.1 spec which is trivial to implement by itself.
I'd rather this than depend on another library that could introduce security vulnerabilities (I'm looking at you, jsonmapper).
closes#5935
this switches from a 'can be supported by' concept to a 'can stay at this position' paradigm, which requires way less boilerplate code.
there may be further improvements we can make from here, such as adding traits, but this is a good first step.
if users want these, they can broadcast them themselves using Server::broadcastMessage(), which will also record the message in the server log like chat
closes#5669
This occurs if the player had very high levels of Health Boost or other weird modifications.
It doesn't really make sense to apply damage modifiers to suicide anyway.
Really I'm doubtful that suicide should even be considered a damage type (perhaps we should add an EntitySuicideEvent), but that's a discussion for another time.
modern versions save 24 exactly, but previous versions saved more. We don't use the excess, so it's not a problem if they are missing, but this is nonetheless non-compliant with vanilla.
suicide damage is a voluntary damage source, which noDamageTicks is intended to prevent getting damaged while the player gets their bearings after (re)spawning.
closes#5854
Cancelling task runs doesn't make any sense.
- It breaks sequential task execution - later tasks might depend on state from earlier tasks
- It doesn't actually cancel the task - at best, it prevents it from running, but cannot interrupt it (though interrupting a task does not make sense either)
We don't use this "feature" in the core anymore since 22b5e5db5e, as this was causing unexpected behaviour for plugins anyway, along with the occasional shutdown crash due to inconsistent worker states.
