I don't think these are actually causing any real problems, ASan
complains about them though since it's kind of a code smell I guess and
a potential source of problems. But our case is fine, so cast to silence
them.
* Convert common/eq_limits.cpp to use make_unique
* Convert common/net/console_server.cpp to use make_unique
* Convert common/net/servertalk_client_connection.cpp to use make_unique
* Convert common/net/servertalk_legacy_client_connection.cpp to use make_unique
* Convert common/net/servertalk_server.cpp to use make_unique
* Convert common/net/websocket_server.cpp to use make_unique
* Convert common/net/websocket_server_connection.cpp to use make_unique
* Convert common/shareddb.cpp to use make_unique
* Convert eqlaunch/worldserver.cpp to use make_unique
* Convert loginserver/server_manager.cpp to use make_unique
* Convert loginserver/world_server.cpp to use make_unique
* Convert queryserv/worldserver.cpp to use make_unique
* Convert ucs/worldserver.cpp to use make_unique
* Convert world/clientlist.cpp to use make_unique
* Convert world/expedition.cpp to use make_unique
* Convert world/launcher_link.cpp to use make_unique
* Convert world/login_server.cpp to use make_unique
* Convert world/main.cpp to use make_unique
* Convert world/ucs.cpp to use make_unique
* Convert world/web_interface.cpp to use make_unique
* Convert world/zonelist.cpp to use make_unique
* Convert world/zoneserver.cpp to use make_unique
* Convert zone/client.cpp to use make_unique
* Convert zone/corpse.cpp to use make_unique
* Convert zone/dynamiczone.cpp to use make_unique
* Convert zone/expedition.cpp to use make_unique
* Convert zone/main.cpp to use make_unique
* Convert zone/mob_ai.cpp to use make_unique
* Convert zone/mob_movement_manager.cpp to use make_unique
* Convert zone/pathfinder_nav_mesh.cpp to use make_unique
* Convert zone/worldserver.cpp to use make_unique
It's not guaranteed that deflate output will be smaller than the input.
In some cases zlib-ng (Z_BEST_SPEED) compression is causing packets to
increase in size and exceed m_max_packet_size. This results in the
packets never being fully received by the client.
Currently this is most reproducible in the spell_book section of the
OP_PlayerProfile message. After using #scribespells this portion of the
player profile has a lot of incrementing spellids which may be affecting
the compression algorithm. The client never processes the player profile
(MSG_SEND_PC) message and times out on zone entry.
This isn't necessarily a bug with zlib-ng since it inflates back to the
original input and normal zlib could do this too, but the current netcode
doesn't handle this.
