this is a pain :(
It appears the client always sorts the keys in alphabetical order due to use of std::map. However I'm not sure of the exact ordering behaviour, so it needs to be investigated.
in particular, the information from VerifyLoginTask shouldn't be sent to clients, as it could contain sensitive information.
This change only affects disconnection screens. The server log shows the same amount of information as before (though formatted differently in some cases).
Sync-prepared batches account for the vast majority of outbound packets. Avoiding these useless objects further reduces the overhead of zero-compressed packets, as the creation of these objects is a significant part of the overhead for these cases.
closes#6157
this is supported since libdeflate 1.15 and ext-libdeflate 0.2.0.
Everyone should be using these versions by now anyway, and if they aren't, they should update.
libdeflate's level 0 compression is over 20 times faster than zlib, so this is a nice performance improvement.
This allows better compensation for floating point errors introduced by the subtraction of the 1.62 height offset.
For example, if the player is at y=7 exactly, their Y coordinate will be reported as 8.62, which, because of floating point errors, will be something like `8.619999999`. Subtracting `1.62` from this (really something like `1.62000000000005...`) leads to the calculated Y coordinate being slightly below 7.
Rounding after subtracting this offset allows this to be rounded to 7 sharp. Similar errors appear in various other coordinates.
a couple of usages of properties that no longer exist couldn't be migrated.
in addition, this revealed a couple of dead properties in the default file.
this is not an ideal solution (I'd much rather model the configs using classes and map them) but in the absence of a good and reliable library to do that, this is the next best thing.
'enchant' just didn't feel right, being a verb.
All these things pertain to the act of enchanting.
This is now also consistent with CraftingTransaction etc. The ship already sailed on EnchantInventory, which will have to be renamed at a later datte. However, that was already inconsistent with 'enchanting table', so that's the odd one out here.
this is a really dumb bug and seems similar to the armor bug I fixed a while ago.
fixes#5987
it's unlikely that #5727 will be solved by this, but one can hope...
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
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
