this needs to be dealt with before release otherwise we'll be stuck with FortuneDropHelper::grass()
this is the obvious solution and should have been done some time ago - stuff like flammability was already a problem for double tall grass anyway
this produced a 40% performance improvement in a simulation with 800 item entities.
If the items were all different, then this would still be a problem. However, many of the same unstackable items occupying the same space is a problem for SkyBlock farms, so this should improve performance for SkyBlock quite a bit.
this produced a 40% performance improvement in a simulation with 800 item entities.
If the items were all different, then this would still be a problem. However, many of the same unstackable items occupying the same space is a problem for SkyBlock farms, so this should improve performance for SkyBlock quite a bit.
this was requested and PR'd as far back as 2020 (see #3782).
Since no issue was filed about this, it became forgotten until #5946.
However, #5946 overcomplicates the solution to the problem, and breaks BC without an obvious reason.
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.
