This brings a significant performance improvement to login sequence handling, reducing CPU cost of `PrepareEncryptionTask` by over 90% and `ProcessLoginTask` by over 60%. It also allows us to shed a dependency.
while it's true that you might be able to skip the CPU waste from verifying a player's login just to find out that they are banned, this is generally a minority case anyway, so it doesn't make a lot of difference overall. This additional note is essentially a recommendation premature optimisation, which will likely lead to people making security mistakes.
this gains a very small performance improvement by avoiding unnecessary !== null checks on every packet written in either direction. It's insignificant for sure, but I just found this code in an old stash, so what the heck.
the reason there hasn't been any API until now is because of how inconvenient it was to expose a LSP-compliant API _and_ use the same base class for handling all the connection logic. This commit fixes that problem by abstracting shape handling away from BaseRail entirely, so that now it deals exclusively with connections. Deciding the shape of rail to use is now the job of the subclasses.
this will break non-standard use cases with large forces, but they only have to stick a 'null' at the end of the parameter list.
Since this function should be primarily used for vanilla knockback, it makes more sense to keep the default as vanilla, but allow people to change it if they want to.
closes#4106 (this is close to #4106 anyway, but small enough that it was easier to recreate it than pull and modify it)
closes#2707
this doesn't implement the server-side logic for the "stickiness" (slowdown) because we don't have the system needed for it yet.
It also doesn't have parity with vanilla on the damage.
SingletonTrait is pointless here for multiple reasons:
1) the class is final
2) this is protocol-specific translation of types, no loss of data or alternative mutation of it needs to occur
Using SingletonTrait is an obstacle to separating the protocol library from the core code, so it has to go.
while this is a bit hacky outside of the protocol namespace, it makes it much easier to use the protocol library for alternative purposes, such as for a client or MITM proxy.
It also removes all but one remaining core dependency of the protocol library, making it very close to being able to be separated from the server core entirely.
