Slow projectiles can be fixed with raycasts, but it's sort of a halfassed solution.
What I've noticed: in a server with > 100 ping, there will be a delay between actual clicking->firing. This can be seen with the old school rifle. You can be aiming perfectly at the players (on your screen), click, but it will be delayed by 100ms regardless, and you will miss. It's like quake, you have to head your players by your ping. And that's no fun.
Here's what the source engine does to fix this problem:
When you fire, client sided prediction (for weapons) draws bullets instantly no matter what. It completely kills that unnatural feeling with that ugly 100 ms delay. But you may be thinking: when the server get's that packet indicating you're firing, it's going to trace the bullets late and just miss the player. Well there's also a fix for this, and it's called lag compensation.
Let's say you have 100ms lag, and 100ms interpolation period. The server, when it gets the firing packet, would "reverse" everyone's position based on that time (200ms). It would then trace the bullets then instead of with the current, real-time positions. If you feel like this is inefficient, well screw you, you go and google it yourself. Valve has all kinds of docs on this and how it works.
One more thing: how would the client render the fire of random things (cone spread, bullet spread)? Wouldn't the server and client have to have the same seed for random?
The sad answer is yes. This is a flaw in the networking code. The client must "send it's seed" to the server in order for the server to trace the same randomized bullet angles. Hackers have abused this method in many engines for no spread, unfortunately. But it's the only way for an efficient, good looking client prediction and realistic gameplay.
Blockland has none of these, so that's the reason there is no "no-spread" hacks/cheats, because random seeds are the current time in MS and theres no way to predict that efficiently.
