Position Packet Compression Pipeline is Throughput Inefficient

[KelseyK44]

Is your feature request related to a problem? Please describe.

Most of the throughput between servers and clients are position packets. When there are many players in a server at once, the amount of data that must be transferred through client and server internet connections can start to become an issue.

Current Situation

Currently, position packets are constructed into a long string before compression, such as:
TestData = R"({"tim":10.428000331623,"vel":[-2.4171722121385e-05,-9.7184734153252e-06,-7.6420763232237e-06],"rot":[-0.0001296154171915,0.0031575385950029,0.98994906610295,0.14138903660382],"rvel":[5.3640324636461e-05,-9.9824529946024e-05,5.1664064641372e-05],"pos":[-0.27281248907838,-0.20515357944633,0.49695488960431],"ping":0.032999999821186})";

This string works out to just over 300 characters long, with each character requiring one byte of data after compression. With 15 players at once in a server with positional update rates of 20hz, the server has to upload 14 player positions to each of the 15 players, as well as download the 15 player positions. Assuming 300 byte payloads at minimum(they seem to be 300-340 bytes), the server would need to upload 9844kbps and download 88kbps of position packets.

Switching to Floats Compressed into a Defined Array Size/Order

Alternatively, position packets could be constructed differently prior to compression, with a defined format like:
{time_float, vel_float_x, vel_float_y, vel_float_z, rot_float_1, ..., ping_float}
so that decompression is still straightforward with the constant packet size/order of values.

Using floats instead should provide plenty enough accuracy and precision for all the values, and each variable would only require 4 bytes of data after compression. With a total of 15 floats to compress, that would reduce position payloads down to just over 60 bytes, rather than over 300 bytes.

Going back to the case of 15 players in a server, throughput would be reduced by a factor of about five from 9844kbps up / 88kbps down to ~2000kbps up / 18kbps down. This would allow hosting servers on internet connections with poorer upload speeds by increasing the maximum player count of a server before bandwidth problems become problematic.

Describe alternatives you've considered
Alternatively, double floats could be used if more precision is required. However, throughput reduction would still be substantial.

Additional context
Representing a double float as a string with redundant "tim", "vel" and other characters due to variable string lengths is memory inefficient for sending data thousands of times a second over the internet.