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
the motivation for this is described in #5917
a new version of DevTools will be required, as the current version will cause the server to abort during startup with this change due to duplicated plugin loading.
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.
